AccessibilityOverview
Accessibility is a default, not a feature.
Accessibility is not a checklist at the end of a project. It is the default. If a component ships without it, the component is broken.
Six commitments
The whole site holds these. Each is verified in CI and on the live URL.
| Commitment | How we hold it |
|---|---|
| WCAG 2.1 AA at every pairing | All foreground/background pairs clear 4.5:1 for body, 3:1 for large text |
| Keyboard-only navigation | Every interactive element is reachable and operable with the keyboard |
| Screen reader support | Every component has the right role, the right label, the right description |
| Visible focus | A single focus ring, applied through :focus-visible, never overridden |
| Respects motion preferences | prefers-reduced-motion: reduce drops transitions, keeps color changes |
| No information by color alone | State, status, and error are always paired with a second channel |
Three principles
- Perceivable. Every piece of information is available to at least one sense. The contrast is high enough. The focus is visible. The motion is optional.
- Operable. Every interaction is reachable by keyboard, by screen reader, and by touch. The next focusable element is always the right one.
- Robust. The components work with assistive technology. The HTML is semantic. The ARIA is the smallest amount that does the job.
Audits
Three audits run against the live site on every deploy.
- axe-core via Playwright, every page, every component demo
- Lighthouse accessibility, 100% target
- Manual keyboard walkthrough, every component, before each release
The six pages
Each commitment above has a dedicated page. The pages go in order — read top to bottom for the longest context, jump to the page that addresses the specific issue you're debugging.
The four token pairings and the math that holds them up.
FocusThe single focus ring and the rules for using it.
Motionprefers-reduced-motion and the three things that always animate.
KeyboardTab order, escape, arrow keys, and the Enter/Space rules.
Screen readerRoles, names, descriptions, and the ARIA we use and don't use.
Why this is a section in the docs
Most design systems treat accessibility as a sidebar. We treat it as the spine. The reason is that a design system is, before anything else, a contract with the people who use it. A contract that excludes a person is not a contract.