How Do You Test a Web App for Accessibility?
Learn how to test web apps for accessibility using automated scanners, keyboard-only navigation, and screen reader audits.
Expected Interview Answer
Accessibility testing combines automated scanners that catch objective WCAG violations, manual keyboard-only and screen-reader walkthroughs that catch the majority of real issues automated tools miss, and structured audits against WCAG success criteria so a site is usable by people with visual, motor, auditory, or cognitive disabilities.
Automated tools such as axe-core, Lighthouse, or WAVE can flag roughly 30-50% of issues reliably: missing alt text, insufficient color contrast, missing form labels, and invalid ARIA usage. They cannot judge whether alt text is meaningful, whether a tab order makes logical sense, or whether a screen reader announcement is actually helpful, so manual testing is mandatory. A thorough manual pass unplugs the mouse and navigates the entire flow with Tab, Shift+Tab, Enter, and arrow keys, checking that every interactive element is reachable and that focus is always visible. Testing with a real screen reader (VoiceOver on macOS, NVDA on Windows) surfaces whether headings, landmarks, and live regions actually communicate structure and state changes. Teams typically wire axe-core into CI to fail builds on new violations, then run periodic manual audits and periodic real-user testing with people who use assistive technology daily, since automated coverage alone gives false confidence.
- Automated scanners catch objective violations early and cheaply in CI
- Keyboard-only testing surfaces trap states and unreachable controls
- Screen reader testing validates that announcements are actually meaningful
- Combining methods avoids false confidence from automation-only coverage
AI Mentor Explanation
Accessibility testing is like preparing a ground for both sighted umpires and a blind fan listening on radio commentary. An automated checklist confirms the boundary rope is marked and the sightscreen is white, catching the obvious physical setup errors. But someone still has to sit with headphones only, no video, and confirm the radio commentator actually describes every wicket and boundary clearly. Only that manual listening pass reveals whether the experience truly works for someone who cannot see the field.
Step-by-Step Explanation
Step 1
Run automated scans in CI
axe-core or Lighthouse checks every build for objective WCAG violations like missing labels and low contrast.
Step 2
Perform a keyboard-only pass
Navigate the entire flow with Tab, Shift+Tab, Enter, and arrows, confirming visible focus and no traps.
Step 3
Test with a real screen reader
Use VoiceOver or NVDA to verify headings, landmarks, and live regions announce meaningfully.
Step 4
Audit against WCAG success criteria
Cross-check remaining perceivable/operable/understandable/robust criteria a scanner cannot judge, like meaningful alt text.
What Interviewer Expects
- Knowledge that automated tools catch only a minority of real issues
- Ability to describe a concrete keyboard-only testing procedure
- Familiarity with at least one screen reader by name
- Understanding that CI integration and manual audits are complementary, not either/or
Common Mistakes
- Believing a passing automated scan means the app is fully accessible
- Never actually testing with a real screen reader
- Skipping keyboard-only testing entirely
- Treating accessibility as a one-time audit instead of a continuous CI gate
Best Answer (HR Friendly)
“I run automated tools like axe or Lighthouse in the build pipeline to catch obvious issues early, but I always follow up with a manual pass — navigating with just the keyboard and testing with a screen reader like VoiceOver — because those catch the majority of real problems automation misses.”
Code Example
const { AxeBuilder } = require('@axe-core/playwright')
test('checkout page has no automatic a11y violations', async ({ page }) => {
await page.goto('/checkout')
const results = await new AxeBuilder({ page })
.withTags(['wcag2a', 'wcag2aa'])
.analyze()
expect(results.violations).toEqual([])
})Follow-up Questions
- What percentage of WCAG issues can automated tools reliably catch?
- How would you test a modal dialog for accessibility specifically?
- What is the difference between WCAG A, AA, and AAA conformance levels?
- How do you get sign-off from real assistive-technology users, not just testers?
MCQ Practice
1. What proportion of accessibility issues do automated tools typically catch?
Automated scanners catch a minority of objective issues; most real problems require manual testing.
2. Why is keyboard-only testing essential?
Keyboard navigation exposes reachability and focus-order problems invisible to automated rule checks.
3. Which tool is commonly integrated into CI to fail builds on accessibility regressions?
axe-core provides a programmatic API well suited to CI pipelines for automated WCAG rule checks.
Flash Cards
What do automated a11y tools catch? — A minority (roughly 30-50%) of objective issues like missing labels or low contrast.
Name two screen readers used for manual testing. — VoiceOver (macOS) and NVDA (Windows).
What does keyboard-only testing reveal? — Unreachable controls, focus traps, and illogical tab order.
Best practice for CI? — Run automated scans on every build, supplemented by periodic manual audits.