Q6 of 24 · Accessibility
Which automated accessibility testing tools exist and what kinds of issues do they catch?
Short answer
Short answer: axe-core (the dominant engine), Lighthouse, Pa11y, and Deque's axe DevTools. They reliably catch missing alt text, insufficient contrast, missing form labels, and clear ARIA misuse — but only around 30-40% of real accessibility issues. Automated tools are a floor, not a ceiling.
Detail
axe-core: the most widely adopted open-source accessibility rules engine, maintained by Deque. Integrated into the axe browser extension, @axe-core/playwright, cypress-axe, and Lighthouse. It scans the page's accessibility tree and reports violations with a reference to the WCAG success criterion.
Lighthouse: Google's built-in audit tool (available in Chrome DevTools and as a CLI). The accessibility audit is powered by axe-core plus some additional checks. Produces a score (0-100) and a list of failures — useful for executive reporting, but the score is a composite that can obscure individual high-severity failures.
Pa11y: a Node.js CLI and CI tool that runs axe-core or HTML_CodeSniffer against a URL or list of URLs. Well-suited for sweeping many pages automatically in a pipeline.
What they reliably catch: missing or empty alt text, insufficient colour contrast on static text, unlabelled form inputs, empty button labels, incorrect heading order, and obvious ARIA role misuse.
What they miss: whether an alt text is meaningful (a photo of a dog with alt="image123" passes the check), keyboard navigation flow, screen reader announcement quality, cognitive load, reading order, interactive component behaviour (a custom dropdown that's technically labelled but unusable), and any issue requiring understanding the context or user intent.
Automated tools are fast, run in CI, and catch regressions — but human testing with keyboard and screen reader is required to catch the issues they miss.