QA Testing
WCAG 2.2 Accessibility Testing — Developer's Field Guide
Accessibility used to be a nice-to-have. In 2026, it's a legal requirement in the EU, US, and multiple APAC markets. Non-compliant products are exposed to fines, lawsuits, and lost enterprise deals. Here's how to actually test for it.
#accessibility#WCAG-2.2#a11y#axe#screen-reader-testing
Accessibility used to be a "nice to have." That era is over.
In 2026, accessibility is legally required in the EU (European Accessibility Act), US (ADA), and multiple APAC markets.
The four WCAG principles (POUR)
Perceivable — Can users perceive all content?
Operable — Can users interact with the product?
Understandable — Is content clear and predictable?
Robust — Does it work with assistive technologies?
Testing checklist
Automated tools: axe, WAVE, Lighthouse, Pa11y CI
Manual keyboard testing: Tab order, focus states, escape closes modals
Screen reader testing: VoiceOver, NVDA, TalkBack
Color and contrast: 4.5:1 (normal), 3:1 (large), 3:1 (UI)
Motion: respect prefers-reduced-motion
Forms: labels, error messages, required fields
Most common failures
Missing alt text (still #1)
Contrast ratios under 4.5:1
Focus indicators removed by CSS resets
Unlabeled form inputs
Focus traps in modals
Motion without reduced-motion fallback
Interactive elements under 44×44px
New in WCAG 2.2
Focus Not Obscured
Dragging Movements
Target Size Minimum (24×24)
Consistent Help
Accessible Authentication
How to make it continuous
Add axe-core to CI
Keyboard checklist in PR reviews
Quarterly manual audit with screen readers
Accessibility champion on every product team
User testing with people who use assistive tech
Key takeaways
- WCAG 2.2 is law — not preference
- Test with axe/WAVE + screen readers + keyboard-only
- Contrast, labels, focus states are the top 3 issues
- Respect prefers-reduced-motion
- Add axe-core to CI to prevent regressions
Further reading
About the author
Senior QA Engineer →Senior QA Engineer · Quality Assurance Labs
