Skip to content
wcagc
←Back to blog
automated testingWCAGmanual testingEAA

How much of accessibility can automated tools catch?

Automated accessibility tools catch roughly 30–57% of issues, depending on how you count. Here's what they find, what they miss, and why.

P

Pavel Charkasau

How much do automated accessibility tools catch? Roughly 30 to 57% of issues, and the exact figure depends entirely on what you count. Count by the number of individual problems a scan flags, and Deque's study of more than 2,000 audits puts automated coverage near 57%, because the most common barriers on the web are the machine-detectable ones (Deque). Count by how many WCAG success criteria a tool can even evaluate, and the older, widely quoted benchmark of 20 to 30% is closer to right. Both numbers are honest; they answer different questions. What neither number changes is the part underneath: a scanner finds problems, it does not confirm your site is accessible. The W3C is blunt about it — evaluation tools "can not determine accessibility, they can only assist in doing so" (W3C WAI). This guide explains where the 30% and the 57% each come from, what a scan reliably catches, what it can't, and how to think about the gap.

Why is there a range from 30% to 57%?

Because the two figures measure different things, and people quote them as if they were the same.

The lower number counts WCAG success criteria. WCAG 2.2 AA has 55 success criteria, and only some of them can be tested by a machine with any confidence — things like whether an image has an alt attribute or whether a page declares its language. A large share can't be checked mechanically at all, because they turn on meaning: is the alt text accurate, does the heading describe the section, can someone actually finish a task with a keyboard. Count the criteria a tool can assess and you land in the 20 to 30% range. That was the accepted benchmark for years.

The higher number counts issues by volume. In 2021 Deque analysed anonymised data from over 2,000 audits, spanning roughly 13,000 pages and nearly 300,000 individual issues, all checked with the axe-core rules library. Automated testing fully covered about 57% of the issues found (Deque). The reason the volume figure beats the criteria figure is simple: a handful of machine-detectable failures are extremely common, so they make up a large slice of the total pile.

The WebAIM Million backs this up with hard numbers. In its 2026 run across a million home pages, six error types accounted for 96% of all detected errors: low-contrast text (83.9% of pages), missing alternative text (53.1%), missing form labels (51%), empty links (46.3%), empty buttons (30.6%), and missing document language (13.5%) (WebAIM). Every one of those is machine-detectable. So a scanner does catch a big share of the volume — not because it is thorough, but because the web keeps failing the same few automatable checks over and over.

What can automated tools reliably catch?

The checks that don't require a human to interpret anything. A scanner reads your rendered HTML, CSS, and ARIA and flags failures it can confirm from the code alone:

  • Colour contrast below the WCAG ratio between text and its background.
  • Missing alt attributes on images (though not whether existing alt text is any good).
  • Form fields with no programmatic label, so a screen reader announces "edit text" and nothing else.
  • Empty links and buttons — an <a> or <button> with no accessible name.
  • Missing page language (<html lang>), which decides how a screen reader pronounces the page.
  • Some ARIA misuse, like a role that requires a child the element doesn't have.

These are worth catching. They are common, they break real tasks, and they are cheap to fix once you know where they are. This is exactly the work to automate on every deploy, and it maps cleanly onto the machine-checkable rows of a WCAG checklist. If a scan flags 40 contrast failures and 12 unlabeled inputs, that is 52 genuine problems you didn't have to find by hand.

What do automated tools miss?

Everything that needs a person to judge whether the page actually works. A scanner sees structure; it can't see sense.

It can confirm an image has alt text but not whether "image123.jpg" describes the chart. It can confirm headings exist but not whether the reading order matches the visual order, or whether the focus order makes sense when you tab through. It can't tell you if a keyboard user can open your menu, complete a checkout, or escape a modal. It won't know that your error message says "invalid input" without saying which field. It can't run a screen reader through your booking flow and hear where the announcements go silent. None of that lives in a rule a machine can evaluate; all of it is where real users get stuck.

Here is the founder's opinion, stated plainly: I don't trust a single coverage percentage, and you shouldn't either. The useful question is never "what percentage does the tool catch" — it's "which of my problems are in the half a machine can't see." A site can pass every automated check and still be unusable with a keyboard. That gap is not a rounding error. It is the difference between a green report and a person who can actually buy from you.

Does a green scan mean my site is compliant?

No, and any tool that tells you otherwise is repeating the mistake that cost an overlay vendor $1 million at the US Federal Trade Commission (FTC). A clean automated report means the machine-checkable issues are handled. It says nothing about the criteria a machine never tested. The W3C puts human judgment at the centre of evaluation for this reason, and warns that tools can even produce false or misleading results (W3C WAI).

So treat the scan as the first pass, not the verdict. Automation gives you a fast, repeatable baseline and a to-do list you can act on today. Conformance — the claim that your site meets WCAG at a given level — needs a person with a keyboard and a screen reader to check the rest. That is not a caveat we bury; it is how the standard is designed to work.

What does this mean for EAA and EN 301 549?

It means a scan is necessary but not sufficient for the paperwork the law asks for. Under the European Accessibility Act, in-scope products and services have applied WCAG-level requirements since June 2025, with the technical bar set by EN 301 549, which incorporates WCAG 2.1 Level AA for the web. EN 301 549 Annex C lists each requirement so you can record it as met, partially met, or not met — and "partially met" is an honest thing to write when automation covered a criterion but manual testing hasn't confirmed the rest.

The accessibility statement the EAA expects documents your level of conformance and known limitations, not a guarantee. That framing fits the coverage reality exactly. You scan to find the machine-detectable issues, fix them, test the rest by hand, and then write down honestly where you stand. A coverage percentage from a tool is an input to that process, never the output.

Frequently asked questions

How much do automated accessibility tools catch?

Roughly 30 to 57% of issues, depending on how you count. By volume of individual problems, Deque's study found automated testing covered about 57%, because the most common barriers are machine-detectable (Deque). By share of WCAG success criteria a tool can evaluate, the figure is closer to 20 to 30%. The rest needs manual review.

Why do some sources say 30% and others say 57%?

They count different things. The 20 to 30% figure counts WCAG success criteria a machine can test; the 57% figure counts individual issues by volume, and a few automatable failures are so common they dominate the total (Deque).

Can a scanner confirm my site is accessible?

No. The W3C states that evaluation tools "can not determine accessibility, they can only assist in doing so" (W3C WAI). A clean scan means the machine-checkable issues are handled; human review with a keyboard and screen reader confirms the rest.

What do automated tools reliably find?

Contrast failures, missing image alt attributes, unlabeled form fields, empty links and buttons, and missing page language. These six categories accounted for 96% of all errors detected across a million home pages in the WebAIM Million 2026 report (WebAIM).

Does a scan cover EAA compliance?

It covers part of it. A scan measures your site against the WCAG criteria a machine can test, which EN 301 549 and the EAA rely on, but full conformance also needs manual testing and an accessibility statement documenting your level of conformance and any known limitations.

Scan first, then test the rest by hand

The honest workflow is unglamorous and it works: automate the machine-checkable half, then put a person on the half a machine can't see. Run a free scan to get the machine-detectable issues on your key pages, mapped to WCAG. Fix those in your code, work through the manual criteria with a keyboard and a screen reader, and you'll have a real baseline — and the evidence to write an accessibility statement that says what you actually checked.

Pavel Charkasau, founder, wcagc.com. Last updated 18 July 2026.

Sources