Accessibility Statement
The We The People platform is built to be usable by everyone — including people who use screen readers, keyboard-only navigation, or assistive technology of any kind. This page documents what the platform does to support accessibility, the known gaps, and how to report issues.
Our Commitment
This platform aims to conform with the Web Content Accessibility Guidelines, version 2.1, Level AA. WCAG 2.1 AA is the standard required by the Americans with Disabilities Act for federal government websites and is widely adopted as the baseline for accessible web content. We treat accessibility as a first-class concern: it is part of every iteration's audit pass and reviewed alongside functional changes, not added as an afterthought.
Accessibility for blind users specifically is given particular attention. The platform's primary content — twelve policy pillars, fiscal projections, calculators, and analytical framing — must be navigable and comprehensible to readers using screen readers. Diagrams have text alternatives. Interactive elements have keyboard equivalents. Dynamic content announces changes.
What the Platform Does
Semantic structure
Every page uses semantic HTML5 landmarks: <header>, <nav>, <main>, and <footer>. Screen reader users can jump between these regions instantly. Headings follow a logical hierarchy (h1, then h2, then h3) without skipped levels, so navigating by heading produces a coherent table of contents.
Skip links
Every page starts with a "Skip to main content" link that becomes visible on keyboard focus. Pressing Tab on page load reveals it; pressing Enter jumps past the repeating header navigation to the page's main content area.
Screen reader support for diagrams
The Platform Architecture page contains four diagrams: the tax money flow, the pillar dependency table, the continuous improvement cycle, and the sixty-year implementation timeline. Each diagram has three layers of accessibility:
- An SVG
<title>element giving the diagram's short name (screen readers announce this when the diagram receives focus). - An SVG
<desc>element giving a longer description of what the diagram shows. - A visually-hidden prose paragraph immediately preceding the diagram that describes its content in full text form — every node, every arrow, every label, written out so that a screen reader user gets the same information a sighted reader gets from looking at the picture.
Keyboard navigation
Every interactive element is reachable via the Tab key in a logical order. Visible focus indicators show what is currently selected. The Architecture page's interactive pillar nodes, cycle phases, and timeline milestones can be focused with Tab and explored with the keyboard; Escape closes the tooltip; mouse and keyboard interactions are equivalent.
Dynamic content announcements
The two calculators (Tax Calculator and Wage Floor Comparison Calculator) use aria-live="polite" regions for their result displays. When a user changes an input and the result updates, screen readers automatically announce the new result without the user needing to re-navigate the page.
Form accessibility
Every form input on the calculators is associated with a visible label via for and id attributes. Radio button groups are wrapped with role="radiogroup" and aria-labelledby pointing to the group's descriptor, so screen readers announce the group name when entering the radio set.
Reduced motion
Every page respects the prefers-reduced-motion CSS media query. Users who set this preference at the operating-system level (typically because animations cause vestibular discomfort, motion sickness, or attention difficulty) will see the platform's transitions and animations reduced to effectively instant. No content is hidden; only the motion is removed.
Color and contrast
Text and background combinations on the platform aim to meet the WCAG 2.1 AA contrast ratio of 4.5:1 for normal text and 3:1 for large text. Information is not conveyed by color alone: where color is used to distinguish (for example, the four phase bars on the timeline), text labels accompany the color so that the distinction is readable independent of color perception.
Display preferences
The platform defaults to a neutral gray visual palette — cool whites and true grays — chosen for general readability and broad device compatibility. Some readers find this default visually clinical or report eye strain on long reading sessions, especially with bright screens or extended reading. The warm palette shifts the page background to a soft cream and the body text to a warm dark brown, which many people find easier on the eyes for extended reading.
Switching is reversible at any time. Your preference is stored locally in your browser and applied to every page on this site.
Where to find this setting: open the Display preferences popover from the icon strip at the top-right of any page (it's the same icon that hosts the light/dark/auto Color Theme switch). Both the theme and the palette toggles live there together.
Language declaration
Every page declares its language via <html lang="en"> so that screen readers use the correct pronunciation engine.
Known Limitations
This is an evolving platform and accessibility is not finished. The following limitations are tracked and will be addressed in future iterations:
- Mathematical formulas in substantiation documents: the .docx and .xlsx files in the package contain mathematical notation that may not be fully readable by screen readers. The platform's HTML pages avoid this problem; the underlying analytical documents are most accessible when opened in their native format with accessibility extensions enabled.
- Excel models: the .xlsx mathematical models (Universal Healthcare Model, Universal Childcare Model, and others) are not fully accessible without screen-reader extensions specific to spreadsheet content. We recommend using these models with JAWS, NVDA, or VoiceOver's spreadsheet modes.
- Diagram interactivity tooltips: the Architecture page's hover tooltips, added in version 3.7.113, are keyboard-accessible but do not yet provide aria-describedby linkage for screen readers. The visually-hidden prose alternatives provide the same content; tooltip enhancement is tracked for a future iteration.
- PDF content: PDF documents in the package are not all tagged for accessibility. Future iterations will add tagged PDF versions for the most-trafficked documents.
Compatibility
The platform is tested with the following assistive technologies:
- Screen readers: NVDA (Windows), JAWS (Windows), VoiceOver (macOS and iOS), TalkBack (Android), Orca (Linux).
- Browsers: recent versions of Chrome, Firefox, Safari, and Edge on desktop; mobile Safari and mobile Chrome on phones and tablets.
- Keyboard-only navigation: all functionality reachable and operable without a mouse.
- OS-level zoom: the platform supports browser zoom to at least 200% without loss of content or functionality.
Reporting an Issue
If you encounter content on this platform that is inaccessible to you or your assistive technology, we want to know. There are two ways to report:
- Through the Contact page: use the contact form on contact.html. Include the page URL, the assistive technology you were using, and a description of what was inaccessible.
- By email: contact details are listed on the contact.html page. Accessibility reports are read and responded to within the platform's standard response window (see the engagement SLA).
Accessibility issues are treated as priority. A reported issue that prevents a user from accessing primary content is treated the same as any other functional bug — it gets a tracking entry in the Open Issues Registry and a documented response in the next iteration.
This Statement
This accessibility statement was created in platform version 3.7.114 (May 14, 2026) as a documented commitment alongside the comprehensive accessibility enhancement pass shipped in the same iteration. It will be updated whenever the platform's accessibility approach changes substantively. The version of this statement matches the platform version; check the footer for the version that produced any specific copy you are reading.
Audio playback (text-to-speech)
Long-form policy documents on the platform include an audio player that reads the content aloud using your browser's built-in text-to-speech capability. The player appears as a small "Listen" badge in the bottom-right corner of qualifying pages; clicking it expands the full player along the bottom of the viewport with play, pause, previous-paragraph, next-paragraph, voice selection, and speed controls.
Implementation: the audio player uses the Web Speech API, which runs entirely on your device. The text of the document is processed by your operating system's text-to-speech engine and converted to audio locally; no document text is sent to any external service, no API keys are involved, and no usage data is transmitted to the platform or any third party. Voice quality depends on the text-to-speech voices installed on your device. Modern macOS and iOS systems include premium voices (Samantha, Karen, and others) that sound natural; Windows 11 includes natural voices; Android voices vary by device. The voice selection dropdown shows the voices available on your specific device.
Position memory: the player remembers which paragraph you were on when you leave the page. Returning to the same page later starts from your last position. Voice and speed preferences are remembered across pages.
Keyboard controls when the audio player is open: Space to play or pause; Control plus Left Arrow to go to the previous paragraph; Control plus Right Arrow to go to the next paragraph (use Command on Mac). Clicking any paragraph while the player is open starts reading from that paragraph.
The audio player is opt-in: it does not start automatically. The badge appears only on long-form pages (ten or more paragraphs); short pages are not cluttered with controls that would not be useful. Closing the player stops audio playback and dismisses the bar; the small "Listen" badge reappears so you can reopen the player if you want.
If your browser does not support the Web Speech API (very rare in 2026), the audio player simply does not appear, and the rest of the platform works normally. Users who rely on screen readers (JAWS, NVDA, VoiceOver, TalkBack) can continue to use their preferred screen reader; the audio player is an additional convenience rather than a replacement for assistive technology you already use.
Dark mode
The platform supports a three-state theme toggle (Auto, Light, Dark) accessible via the small button in the top-right corner of every page. Auto mode respects your operating system's color-scheme preference (light or dark); Light mode forces the platform's light theme regardless of OS preference; Dark mode forces the dark theme. Your choice persists across pages and visits via your browser's local storage.
The light theme uses the platform's default warm-dark text on cream background (approximately sixteen-to-one contrast ratio, exceeding WCAG AAA's seven-to-one requirement for body text). Pure black on pure white is intentionally avoided because the high luminance contrast can cause halation and eye fatigue during extended reading; warm dark on warm light reduces that effect while preserving readability.
The dark theme uses warm light text on warm dark background (the same colors inverted, retaining the platform's parchment-and-ink aesthetic rather than switching to a clinical pure-black background). Red and navy accent colors are slightly brightened in dark mode to maintain perceived weight; link colors shift to a lighter blue for visibility on dark background.
Print mode is unaffected by the theme toggle. Documents always print in standard light mode (dark text on white background) regardless of which theme is currently selected for screen display.
The theme toggle is hidden in iframe contexts (such as the document preview modal) since theme there is controlled by the parent page.