Automated Accessibility Testing
Automated a11y testing scans rendered pages for WCAG violations — contrast, labels, heading order, ARIA misuse — catching the mechanical subset of accessibility while manual audit remains mandatory.
Definition
Automated accessibility testing runs rule engines — axe-core, W3C ACT rules — against rendered DOM states, flagging violations like missing accessible names, broken heading hierarchy, insufficient contrast, and keyboard traps. It covers the mechanically decidable subset of WCAG; judgment calls — meaningful alt text, logical focus order, screen reader experience — need manual and assistive-technology testing.
Context and scope
Integrated as CI checks on rendered pages and components, as browser extensions during development, and as part of visual regression suites.
Common misconceptions
- A green axe report means accessible — automated rules catch roughly half of WCAG issues; the judgment-dependent half needs humans and screen readers
- Scanning the initial page state is enough — violations hide behind modals, tooltips, expanded menus, and post-interaction states that the scanner never reaches
- Accessibility is a QA-stage concern — the cheapest fixes happen in design tokens and component contracts before code exists
Anti-patterns
- Scanning only the default route state and shipping dialogs with focus traps no rule engine ever executed
- Fixing contrast warnings by deleting content instead of choosing accessible color tokens
- Pinning a11y scans to release week and accumulating months of violations into an unpayable backlog
Related concepts
Related examples
Authoritative source
What it is
WCAG success criteria split into machine-checkable rules and human-judgment criteria. Automated engines encode the first set and run on real DOM; they are cheap, fast, and honest about their own coverage limits.
How it works
The engine walks the accessibility tree and applies rules: inputs need programmatically associated labels, images need accessible names, headings must nest, color pairs must meet contrast ratios, landmarks and roles must be valid. Violations carry severity and a rule id that maps to documentation. Integration points: unit tests on components, e2e scans across routes and states.
When to run
Continuously — on every component build and every page render in CI, across interaction states. Treat the rule engine as a compiler for accessibility: violations block merges like type errors.
Pitfalls
Rule engines can only see the DOM they are handed: client-side state, dialogs opened on interaction, and dynamic content need explicit scan orchestration. Contrast rules read computed styles — background images behind text escape them. Zero violations plus unusable keyboard navigation is a real and common state.