What percentage of accessibility issues can be automated?

Around 30-40% by most published estimates. Automated testing reliably catches missing attributes, contrast ratios and structural errors, and cannot evaluate whether alt text describes the image or whether an error message explains the problem.

Does passing an automated scan mean my site is WCAG compliant?

No. It means no machine-detectable failures remain. Compliance requires manual testing with a keyboard and a screen reader, and any tool claiming to certify compliance automatically is overselling what automation can do.

Why do two accessibility tools give different results?

Because they encode different subsets of WCAG techniques. two independent WCAG engines overlap heavily but each finds issues the other does not - which is why running two is genuinely useful, as long as their overlapping rules are not counted twice.

Accessibility26 July 20266 min read

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.