Accessibility Testing Strategy

Last updated:

Combine automation for regressions, manual keyboard and zoom passes, and assistive technology on critical journeys.

01 — Purpose

Test like users experience the product

Accessibility needs automation for regressions, manual passes for real interaction, and assistive technology for behaviour automation cannot judge.

Scanners catch missing alt text, contrast failures, and some ARIA mistakes quickly. They cannot tell you whether a checkout flow makes sense with a keyboard, whether announcements help or harm, or whether a screen reader user can complete the task without frustration.

Use the accessibility QA checklist on every release for critical journeys.

02 — Automation

What automation can and cannot do

A green audit score is not the same as an inclusive product.

  • run axe or similar in CI — fix new regressions before merge
  • automation misses focus order in context, trap bugs, and confusing UX
  • do not block release on scanner green alone when dynamic UI was not manually exercised

03 — Manual

Keyboard, zoom, and mobile

Repeatable manual steps beat ad-hoc “looks fine to me” reviews.

  • keyboard — Tab, Shift+Tab, Enter, Space, Escape on each critical path
  • zoom — 200% and 400%; see zoom and reflow
  • mobile — real device or emulator with touch, not desktop-only
  • define journeys — sign-in, checkout, search, settings — every release

04 — Assistive tech

Screen readers and beyond

Hear what assistive technology hears — NVDA, VoiceOver, JAWS, voice control, magnifiers.

  • test core journeys with at least one screen reader — not only the homepage
  • validate dynamic updates and landmarks — see live regions
  • test more than one AT where you can — behaviour differs between engines

05 — Avoid

Testing theatre

Passing Lighthouse accessibility is not a substitute for inclusion.

  • “zero violations” with no keyboard or AT pass on dynamic UI
  • fixing only what the tool names — ignoring confusing flows the tool cannot see
  • outsourcing judgment to a dashboard — no one tests with real AT

06 — Close

Automate repeats, verify what matters

Accessibility requires human evaluation on the journeys users depend on.

Automate what repeats. Manually verify what matters. Both belong in the process — neither replaces the other.

See accessibility standard and accessible forms.

Common questions

Can accessibility automation replace manual testing?

No. Automated scans catch a fraction of issues — often under half of WCAG failures. They miss keyboard flows, focus order, and whether real users can complete tasks.

What do axe and Lighthouse not catch well?

Wrong control type, poor labels in context, confusing focus order, inadequate error recovery, and content that is technically valid but unusable with assistive technology.

What should run in CI versus before release?

Run automated checks in CI as a gate on regressions, then add keyboard, screen reader, and assistive technology passes before release on critical journeys.