Q37 of 38 · Test design
How do you incorporate accessibility requirements into your formal test design?
Short answer
Short answer: Treat accessibility criteria (WCAG AA) as first-class acceptance criteria. Design tests at three levels: automated axe-core scanning for structural violations, keyboard-navigation test cases for interactive flows, and manual screen reader verification for complex widgets.
Detail
Accessibility testing is most effective when the test design mirrors how assistive technology users experience the product — not just running an audit tool and fixing flagged issues.
Automated scanning (axe-core, Deque, Pa11y) catches 30–40% of WCAG violations: missing alt text, insufficient colour contrast, incorrect ARIA roles. Run this in CI on every page render.
Keyboard navigation test cases: for every interactive flow (login, form submission, modal dialogs, dropdowns), write explicit test cases that verify the flow is completable using Tab/Shift-Tab/Enter/Escape only, with a visible focus indicator at every step. These are scripted test cases, not just exploratory checks.
Screen reader verification: for complex widgets (date pickers, multi-select, carousels), manual testing with NVDA/JAWS on Windows and VoiceOver on Mac is required. Automated tools cannot verify that the announced content makes semantic sense to a real user.
At the design level, involve an accessibility specialist in the three-amigos sessions so that ARIA requirements and keyboard patterns are specified upfront rather than retrofitted.