We The People

Version 3.7.121 122 Documents 12 Pillars 1 Foundation
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:

  • 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.

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.