No single accessibility testing method is sufficient on its own. Production teams layer three complementary approaches — automated scanning, manual keyboard testing, and real assistive-technology passes — each catching a distinct category of failure the others structurally cannot.
1Automated Scanning: Fast Baseline Coverage
Tools like axe-core (which powers Lighthouse's accessibility audit and many browser extensions), and WAVE parse the rendered DOM and flag programmatically detectable violations: missing alt attributes, insufficient color contrast (calculable directly from computed styles), invalid or conflicting ARIA attributes, and missing form labels.
These tools are valuable specifically because they're fast and can run automatically in CI, catching regressions before they ship. But industry studies (including Deque's own research on axe-core) consistently find automated tools catch roughly 30-40% of real WCAG failures — everything requiring human judgment, like whether alt text is actually meaningful or whether a heading hierarchy makes logical sense, is structurally outside what static analysis can determine.
2Manual Keyboard Testing: Interaction-Dependent Bugs
Some failures simply cannot be detected by inspecting a DOM snapshot — they only manifest through actual interaction over time. A focus trap that doesn't release, a custom dropdown unreachable by Tab, a modal that silently steals focus without visually indicating it — all require someone (or something) to actually navigate the page sequentially.
The practical version of this test costs almost nothing: physically avoid the mouse, and complete a full core user journey — sign up, add to cart, submit a form — using only Tab, Shift+Tab, Enter, Space, and arrow keys. Every interactive element should be reachable, every focus state visible, and every custom widget's key behavior should match user expectations from the Keyboard Navigation lesson earlier in this module.
3Real Assistive Technology: The Authoritative Layer
The final, highest-signal layer is testing with an actual screen reader — VoiceOver on macOS/iOS, NVDA or JAWS on Windows, TalkBack on Android. This is the only method that reveals how announcements genuinely sound in sequence: whether a heading hierarchy tells a coherent story, whether a live region interrupts too aggressively, whether a custom ARIA widget's announced state actually matches its visual state.
A practical, sustainable workflow doesn't require deep screen reader expertise — a five-minute pass through core flows, checking that every control announces a sensible role, name, and state, catches the overwhelming majority of remaining issues after the automated and keyboard layers have already run.
4Step-by-Step Breakdown
No Single Tool Catches Everything. Automated accessibility scanners are fast and catch real issues, but industry research consistently shows they find roughly 30-40% of actual WCAG failures. A complete testing workflow layers automated linting, manual keyboard testing, and real assistive-technology passes — each catching what the others structurally cannot.
Automated Tools: Fast, Broad, Incomplete. Tools like axe-core, Lighthouse, and WAVE scan the DOM for detectable violations — missing alt attributes, insufficient contrast ratios, invalid ARIA. They run in seconds and catch a meaningful baseline of issues, but structurally cannot detect anything requiring human judgment, like whether alt text is actually meaningful.
Automated Tool Coverage. An automated scanner reports zero accessibility violations on a page. What can you conclude?
- →The page is fully accessible; no further testing is needed
- →The page passes automatable checks; manual and AT testing are still required
- →The scanner is broken, since real pages always have some violations
Manual Keyboard Testing: Cheap And High-Signal. Unplugging the mouse and navigating an entire user flow with Tab, Shift+Tab, Enter, Space, and arrow keys costs minutes but catches an entirely different category of bug: broken tab order, missing focus indicators, unreachable custom widgets, and focus traps that don't release.
Manual Keyboard Testing Value. Why does manual keyboard testing catch bugs automated scanners fundamentally cannot?
- →It's simply slower, which happens to be more thorough
- →Some failures (broken tab order, unreachable widgets) only manifest through actual interaction, which static analysis can't simulate
- →There's no real difference; it's redundant with automated tools
Real Assistive Technology: The Final, Authoritative Layer. Only testing with an actual screen reader reveals how announcements really sound — whether an accessible name is confusing, whether a live region interrupts too aggressively, whether a custom widget's ARIA pattern actually behaves as documented. It's the closest proxy to a real user's experience available.
The Role Of Real AT Testing. A component passes automated scans and manual keyboard testing. Why might a five-minute screen reader pass still be worth doing?
- →It's redundant at that point and can be safely skipped
- →It verifies how announcements actually sound and whether they make sense in sequence
- →Only for legal compliance documentation, no real UX value
Testing Workflow Complete. You now have a complete, layered accessibility testing workflow: automated scans for a fast baseline, manual keyboard testing for interaction-dependent bugs, and real screen reader passes for the judgment calls no tool can automate — closing out this Accessibility module.
Add A Live Region For Testing Tools. aria-live="polite" marks a region whose updates should be announced without interrupting the user.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Each Testing Layer Catches A Structurally Distinct Category Of Failure
Automated tools catch programmatically-detectable violations, manual keyboard testing catches interaction-dependent bugs, and real AT testing catches judgment-dependent issues — none can substitute for the others.
2A Five-Minute Manual Pass Delivers Outsized Return Relative To Its Cost
Both keyboard-only and real screen-reader testing take only minutes for a core user flow, yet catch entire categories of bugs that would otherwise ship silently to real users.
SEO Implications
- 1
Accessibility Testing Overlaps Directly With Lighthouse's Combined Performance/SEO/Accessibility Scoring
Since Lighthouse reports accessibility, performance, and SEO scores together, teams already running it for one purpose get accessibility regression detection essentially for free.
Best Practices
Run Automated Accessibility Scans In CI On Every Pull Request
It catches the fastest, cheapest category of regressions automatically, before a human reviewer or, worse, a real user ever encounters them.
Reserve Manual Keyboard And Screen-Reader Passes For Core Flows Before Major Releases
Testing every single page manually doesn't scale, but a five-minute pass through checkout, signup, or your product's primary flow catches the highest-impact remaining issues efficiently.
Frequent Bugs
A team ships a feature with a clean automated accessibility scan, then receives real user complaints about unusable keyboard navigation.
Automated tools alone don't catch interaction-dependent bugs. Add a manual keyboard pass to the release checklist alongside automated CI scanning.
Automated and keyboard testing both pass, but a screen reader user still reports confusing announcements.
Some issues, like announcement ordering or verbosity, are only detectable by actually listening. Add a real screen reader pass for core flows before major releases.
Real-World Examples
A Practical Release Checklist
A lightweight, sustainable accessibility gate a small team can realistically maintain before shipping a major feature.
// 1. axe-core CI check: 0 violations
// 2. Keyboard-only pass through the new flow
// 3. 5-minute VoiceOver/NVDA pass through the new flow