57 percent of issues, 13 percent of criteria
How much can automated accessibility testing find? Both popular answers are true, because they divide by different things. What that means for a checkout, and for the claim that AI moves the line.
Two numbers keep coming back when people argue about automated accessibility testing. One says tools find about 30 percent of accessibility problems. The other says 57. Lately there is an AI version of the argument as well: if a model can look at the page, maybe the old limit is gone.
Both numbers are true. They have different denominators.
Two denominators
The 57 comes from Deque's coverage report: 57.38 percent of the issues found in first audits, nearly 300,000 of them, could have been found by automated testing. The denominator is issues. Every missing label counts, every low-contrast text counts.
The 30 is older and counts something else: the share of WCAG success criteria that automated checks can test at all. Steve Faulkner, who has used it for years, wrote in 2024 that the two figures measure different things, and admitted in the same post that he doesn't know where the 30 percent first came from. A stricter count by Accessible.org puts it lower: 7 of the 55 WCAG 2.2 AA criteria, 13 percent, can be flagged with mostly accurate detection.
What the 57 is made of
A share of issues is weighted by how often each kind of issue occurs. In Deque's data, contrast alone is 30.08 percent of all issues. The top five criteria together are 78.51 percent. One of those five is 4.1.1 Parsing, at 11.69 percent, which WCAG 2.2 removed. Assume every parsing issue was found automatically, which is what an HTML validator does, take them out, and 57.38 becomes about 51.7.
None of that is wrong. It just says something narrower than it sounds. Frequent, mechanical problems dominate the count, and tools are good at frequent, mechanical problems.
Imagine ten issues
Imagine an audit of a webshop that finds ten issues. Seven are contrast problems on different pages, two are missing alt texts, and one is a custom checkout button nobody can reach with the keyboard.
A tool finds nine of the ten. Ninety percent of issues, found automatically. The one it missed is the one that stops every keyboard user from paying. A share of issues is an average. A purchase is a path, and a path is only as good as its worst step.
Does a model change this?
A rule-based check returns pass or fail. A model looking at the same page returns something closer to "probably fine": this alt text probably fits the image, this link text probably makes sense on its own. That is useful. It tells a person where to look first, and it can look at things no rule could, like whether a description matches the picture.
It doesn't become a test result, though. EN 301 549, and the BFSG through it, ask whether each criterion is met, yes or no, on every page in scope. "Probably" has no column in that table. Someone has to decide, and a model's confidence doesn't sign the statement.
And the problems that block a task tend to be the ones nobody can see in the markup at all: whether focus lands somewhere sensible after a dialog closes, whether a custom widget responds to the keys its native version would, whether a page makes sense in the order it is read aloud. Those depend on behavior. Someone has to press Tab.
Ask for the denominator
Whenever someone quotes a percentage for automated testing, with AI or without, ask what it is a percentage of. Issues, criteria, pages or tasks give four different answers about the same site, and only one of them tells you whether a customer can pay.