Automated Accessibility Testing

The plain-language idea

Two tools cover most of the real automated accessibility toolkit, and they catch problems at two different points in the workflow.

axe-core is an open-source accessibility testing engine that inspects rendered markup and reports specific, rule-based violations — missing form labels, insufficient contrast, invalid ARIA attribute values, images missing alt text. It runs in several places: directly in automated tests via a test-runner integration like @axe-core/playwright, as a standalone browser extension for spot-checking a page manually, or wired into CI so a pull request fails on a real violation instead of relying on someone remembering to check. This app, Praxis, actually uses axe-core this way as part of its own verification workflow — a concrete example of automated accessibility testing running against real, shipped UI rather than a toy example.

eslint-plugin-jsx-a11y catches a different, earlier subset of issues — at write-time, before the code even runs. A missing alt prop on an img, an interactive div with a click handler but no keyboard handler, a form label with no associated control: these show up as lint errors the moment they're typed, which is the cheapest possible point to catch a mistake, well before a test run or a code review.

See it in a real thing: what each tool actually flags

// eslint-plugin-jsx-a11y flags this at write-time, before it ever runs:
<div onClick={handleSelect}>Select plan</div>
// → "Visible, non-interactive elements with click handlers must have
//    at least one keyboard listener" (jsx-a11y/click-events-have-key-events)

// axe-core flags this at test/runtime, against rendered DOM:
<img src="/chart.png" />
// → "Images must have alternate text" (image-alt)

Both are real, valuable, and neither is close to sufficient on its own. Their honest, well-documented limitation — stated plainly by both tools' own maintainers and echoed across accessibility practice broadly — is that automated tools reliably catch mechanically checkable issues: things with an objectively correct answer, like whether an alt attribute exists or whether a contrast ratio meets a numeric threshold. Commonly cited estimates put automated coverage at roughly a third to half of real WCAG issues, not all of them. Whether an error message is actually understandable, or a tab order is actually logical, requires human judgment no automated rule can fully encode — there's no lint rule for "this instruction makes sense to a first-time user."

What people usually miss

Watch out

• "Zero axe-core violations" is not the same claim as "fully accessible." It means the mechanically-checkable subset is clean — a real, useful floor, not a ceiling.
• The two tools catch different things at different times, and both are worth having. eslint-plugin-jsx-a11y catches structural mistakes before code ships at all; @axe-core/playwright-style CI checks catch rendering-time issues a linter can't see (computed contrast, dynamically-generated markup).
• Automated coverage numbers (roughly a third to half of real issues) are widely cited for a reason — they're a genuine, stable finding across the accessibility field, not a one-off statistic, and worth internalizing rather than assuming "we run axe" means "we're covered."
• Automated tests are cheap to run on every PR precisely because they're narrow. That narrowness is the tradeoff that makes them CI-enforceable in the first place — a tool that required human judgment couldn't gate a pull request automatically.

Why this matters in interviews

"We run automated accessibility tests — are we covered?" is a real trap question, and the strong answer names the actual limitation precisely (mechanically-checkable issues only, roughly a third to half of real problems) rather than either overclaiming coverage or dismissing automated tools as pointless.