We The People

Version 3.8.46 · 142 Documents · Open Questions: 42 open / 57 closed
Twelve Pillars. One Foundation. An Architecture for Shared Prosperity
PLATFORM

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:

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:

Compatibility

The platform is built to work with the following. Read that phrasing carefully: it is a statement of what the platform targets and codes against, not a claim that each has been verified by a person using it. Where something has actually been measured, it says so.

Why There Is No Accessibility Widget

This site deliberately does not use an accessibility overlay: the floating circular button, usually in a corner, that opens a panel of toggles for contrast, font size, and profiles named for particular disabilities. Several vendors sell these. We have chosen not to install one, and because this platform publishes its reasoning rather than just its conclusions, here is the reasoning.

They do not do what they claim. In January 2025 the United States Federal Trade Commission required the largest overlay vendor to pay $1 million to settle allegations that it misrepresented its product's ability to make websites conform to the Web Content Accessibility Guidelines. The final order, approved in April 2025, bars the company from claiming its automated product can make any website conformant unless it has evidence to support that claim. The regulator's complaint described sites using the overlay that still had missing or inaccurate alternative text, absent focus indicators, keyboard traps, and incorrect heading levels.

Automatically generated descriptions can be worse than none. A missing image description tells a screen reader user that something is missing, so they know to seek it elsewhere. A confidently wrong one does not. This matters particularly here, because this platform's figures carry analytical content: a chart of fund growth described incorrectly is not a cosmetic failure, it is a factual one, and it would undermine the same claim the chart exists to support.

They can override choices you have already made. If you have set a contrast preference, a reduced-motion preference, or a colour scheme at the level of your operating system or browser, this site already honours it. An overlay that presents its own competing set of toggles can override settings you configured once and expect to apply everywhere.

And they require third-party code. An overlay is JavaScript loaded from a vendor's servers on every page view. This site tells you that its calculators run entirely in your browser and transmit nothing. Adding an overlay would make that statement false. We would rather keep the promise than add the widget.

What we do instead. Accessibility is built into the pages rather than layered over them: semantic HTML, skip links on every page, keyboard operability throughout, text alternatives written by a person for every figure, information never carried by colour alone, and support for the preferences your system already exposes including reduced motion, colour scheme, and increased contrast. Each of these is described in the sections above, and the things that are not finished are listed under Known Limitations rather than hidden.

None of this makes the site accessible by assertion. It means the work is in the pages, where it can be inspected, rather than in a vendor's claim that cannot be.

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:

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.