accessibility

Find real accessibility barriers: things that stop people using the product with a keyboard, screen reader, magnification, voice control, switch device, or with cognitive, motor, visual or vestibular differences. Every finding names the WCAG criterion, who is affected, and a concrete fix.

Scope: WCAG 2.2 Level A and AA. AAA criteria only where they surface naturally. Related: design-system for contrast at token level | design for accessible design decisions | seo-audit for the semantic overlap.

Workflow

1. Context. What is being audited (whole site, key flows, one component)? Which user journeys matter most (sign-up, checkout, core task)? Any legal driver (ADA/Section 508, the EU's European Accessibility Act, procurement requirements)? Conformance is judged on complete pages and processes, so audit end-to-end flows, not just components. Don't give legal conclusions; flag where legal review is needed.
2. Detect the stack. Framework, component library (Radix, Headless UI, MUI, Chakra, shadcn/ui, custom), styling approach, and where design tokens live. Libraries with good baselines are audited by their usage and theme overrides, not by their internals; custom components are the highest risk. The patterns in the references use JSX and utility-class examples: adapt them to the project's templates and CSS.
3. Scope. Offer Full | Quick (semantics, keyboard, forms) | Component audit (forms, dynamic, keyboard) | Content audit (images, colour, semantics) | Layout and pointer | Custom.
4. Load references/a11y-method.md (how to verify, severity, report) and the chosen modules.
5. Audit. Run each module's search patterns, then read the flagged files and confirm real violations, not false positives. Extract actual colour values before judging contrast. Group identical patterns ("12 inputs with no label", not twelve findings). Where a browser is available, verify with the checks in the method reference, and mark findings Verified in browser or Code review only.
6. Report.

Priority

Level A failures first (they block access outright), then Level AA. Don't hunt for AAA.

Report

Accessibility Audit | WCAG 2.2 AA | Stack: [...] | Component library: [...]
Scope: [modules and flows] | Verified: [browser / code only]
Findings: Critical X | High Y | Medium Z | Low W

Each finding:

**[SEVERITY] Title**
- WCAG: [number and name] (Level A/AA)
- Location: `file:line` (+ N similar)
- Who is affected: e.g. "keyboard users cannot open the menu"
- Evidence: snippet or observed behaviour
- Fix: concrete change with code
- Verified: browser | code review

Group by severity, then module. Finish with quick wins, the order to fix things in, and suggestions for ongoing protection: automated checks in CI, accessibility tests for key flows, and periodic manual testing with a screen reader.

After the report

Offer: fix Critical and High findings | add automated checks (axe-core, or Playwright with axe) | add accessibility tests | a screen-reader walkthrough plan. Make no changes until the user picks.

Skip

Third-party embeds (maps, payment widgets, chat): note them, don't audit them | PDF and native-app accessibility (separate audits) | AAA-only criteria | WCAG 4.1.1 Parsing (removed in 2.2).