What can automated accessibility testing actually catch?
Roughly a third of WCAG issues. Automated tools find machine-checkable failures reliably and are structurally unable to judge whether alt text is meaningful.
By Sapun Lamichhane · Arcetis
Roughly a third of WCAG issues, and the third it catches it catches very reliably. The other two thirds require someone to make a judgement, and no amount of tooling changes that.
This is worth being precise about, because the gap between 'passed the scan' and 'usable by a disabled person' is where most accessibility work actually lives.
What automation catches reliably
- Missing attributes - `alt` on images, `label` on form controls, `lang` on the document, `title` on frames.
- Colour contrast, computed from rendered styles. This needs a real browser, which is why source-only checkers cannot do it.
- Structural errors - duplicate ids, invalid ARIA roles, ARIA attributes on elements that do not support them, headings that skip levels.
- Keyboard traps that are detectable statically, such as positive `tabindex` values and focusable elements inside `aria-hidden` containers.
What it structurally cannot catch
- Whether alt text is *correct*. `alt="image"` passes every automated check and communicates nothing.
- Whether focus order is logical. A tool can see the order; it cannot know that tabbing from the price to the footer and back to the buy button is confusing.
- Whether an error message is useful. 'Invalid input' has a role and an accessible name and tells the user nothing.
- Whether a custom widget behaves as its role promises. A div with `role="tablist"` passes; whether arrow keys move between tabs is a behavioural question.
- Whether content makes sense when linearised. Automation sees a heading structure; it cannot tell you the page is incomprehensible read top to bottom.
Is `alt=""` a failure?
No - and getting this wrong is a common tooling bug. An empty alt attribute is the correct way to mark a decorative image: it tells assistive technology to skip it. Omitting the attribute entirely is the failure, because a screen reader then falls back to announcing the filename.
A checker that flags `alt=""` is generating work rather than finding it. This product made exactly that mistake on its own illustrations before it was caught.
So what should I actually do?
- 1Run automated testing on every deploy. It is cheap, it never gets bored, and it catches regressions the day they ship.
- 2Tab through the page yourself. No tool replaces ten minutes with a keyboard and no mouse.
- 3Turn on a screen reader for your primary flows. VoiceOver and NVDA are both free.
- 4Fix the automated findings first - they are unambiguous and they are usually quick.
How do I run the automated part?
The accessibility checker on this site runs an industry-standard WCAG rule engine against your live rendered page in a real browser, with a second independent engine alongside it as a second engine for coverage.