Part 3 · 2 chapters · ~15 min

Accessibility in Depth: Testing, Audits and the Gate

What each method finds (static lint, rule engines, component tests, manual keyboard and screen-reader passes, expert audits, testing with disabled users) and at what cadence, and accessibility as a gate: merge and preview checks with a baseline, a human release gate, a severity-ranked backlog with owners, training, and metrics on the shared dashboard.

7

What each testing method finds

no method finds everything; each finds a kind
  1. Static lint (jsx-a11y and the design-system rules): markup mistakes as typed: missing alt, click handlers without a role and key handler, positive tabIndex, invalid ARIA, anchors as buttons. Cheapest and narrowest; blind to runtime state and computed contrast.
  2. Rule engines on rendered pages (axe-core in stories, end-to-end tests and CI on the preview; Lighthouse): about a third of WCAG failures with near-zero false positives: names, roles, ARIA validity, solid-colour contrast, labels, landmarks, headings, lang, duplicate ids. A clean run is the floor.
  3. Component tests: Testing Library queries by role and name (so every test is an accessibility test), keyboard scripts with focus assertions, state assertions on aria-expanded, aria-selected, aria-invalid.
  4. Manual passes per flow per release: twenty minutes with no mouse (reach, order, focus visible and unobscured, traps, focus after changes: part 1) and twenty with VoiceOver or NVDA (sense, names, announcements, reading order: parts 1 and 2).
  5. Expert audits against every AA criterion for a defined scope, findings mapped to criteria with severity, producing a conformance report (the VPAT-based ACR for procurement; the statement the EAA requires). Yearly, before major launches, or on request.
  6. Testing with disabled users (screen-reader, keyboard-only, switch, low-vision, cognitive): finds the conformant-but-exhausting flow, the correct-but-confusing label, the legal-but-too-short timeout. A few compensated sessions a year, recruited through organisations that do this work. Everything else exists so these sessions find what only people can.
TESTING ACCESSIBILITY: WHAT EACH METHOD FINDS
lint, automated checks, component tests, keyboard passes, screen-reader passes, audits and user testing
swipe the figure sideways, or tap expand for full screen
1/6
static lint
Static lint (eslint-plugin-jsx-a11y; the Design course part 7's rules): img without alt, click handlers on non-interactive elements without a role and key handler, positive tabIndex, autoFocus, invalid ARIA attributes or values, anchor without href used as a button, label without a control. Runs as you type; catches the mistakes before they are rendered; cannot see runtime state, computed contrast or anything assembled from components.
8

Accessibility as a gate

mechanical where it can be, a named checklist where it cannot
  1. Merge gates: lint, axe on every story of changed components with zero violations, role-and-name tests, keyboard scripts for changed primitives; deterministic and inside the merge-path budget (the Architecture course part 1).
  2. The preview gate: axe on every page of the smoke flows against the PR's preview, with a baseline so only new violations fail (the TypeScript course part 8's pattern), reviewed and shrunk weekly. A failure names the rule, the element and the criterion.
  3. The release gate: a keyboard pass and a screen-reader pass per changed flow by a named person against a short checklist, recorded in the release ticket; skipped only with a written, dated exception. The train waits for it (the Big-company FE course part 6).
  4. The backlog: every finding with its criterion, severity (blocker: cannot complete; serious: great difficulty; moderate; minor), surface, owner from OWNERS and a target by severity (blockers this sprint, serious this quarter). A blocker reported by a user is an incident.
  5. Ownership and training: surface owners own their findings; the design system team owns component findings; an accessibility lead owns the programme, the audit and the checklist; everyone is trained to at least part 1's screen-reader basics; accessibility is a review item in the review bar.
  6. The metrics, on the same dashboard as performance and errors: violations by surface and severity, blockers and their age, release passes done versus skipped, conformance per surface, time to fix by severity, support contacts tagged accessibility. A broken experience for a screen-reader user is a production defect.
the exercise
Add axe to your smoke-flow end-to-end tests with a baseline of today's violations. Read the baseline: that file is your accessibility backlog, sorted by page, and the gate means it can only shrink.
ACCESSIBILITY AS A GATE
what blocks a merge, what blocks a release, what is tracked, and who owns the backlog
swipe the figure sideways, or tap expand for full screen
1/6
merge gates
Merge gates: jsx-a11y and the design-system lint (part 7 of the Design course) in stage one (the Architecture course part 1); axe on every story of any changed component, zero violations; Testing Library tests that query by role and name (a renamed button fails the test); keyboard scripts for changed primitives. Deterministic, under the merge-path time budget, no flake.