Every automated accessibility tool is built on the same engine. axe-core is what runs inside Lighthouse, inside the browser extensions, inside most of the paid dashboards, and inside this product. So the honest way to answer what a machine can catch is to count what that engine ships, and then check what those rules are attached to.
Every number below is counted from axe-core 4.12.1 at the version this site installs, mapped through the same function the product uses to cite a finding. The command that reproduces them is at the bottom.
What an automated checker covers
scripts/a11yfigs.cjs from
axe.getRules(), mapped through lib/standards.cjs.A hundred and five rules reads like broad coverage. Two things thin it out.
Thirty of them are not conformance failures at all. They carry axe’s
best-practice tag, which means somebody at Deque thinks it is a good idea and no
clause in the spec requires it. Useful, and not the thing you are asked about in a
procurement questionnaire.
The remaining seventy-five map to a success criterion. They land on twenty-nine.
Where the rules land
This is the part that surprised us, and it is the reason a rule count tells you so little.
The distribution is not even close to flat:
- 4.1.2 Name, Role, Value takes twenty-nine rules by itself. That is more than a third of everything that maps to the spec, all pointed at one criterion. It is the one about whether a control announces what it is, and it is genuinely dense, but it is one criterion.
- The top three carry forty-eight of the seventy-five. 4.1.2, then 1.3.1 Info and Relationships with twelve, then 1.1.1 Non-text Content with seven.
- Twenty-one of the twenty-nine criteria have exactly one rule. One rule for contrast. One for page title. One for target size. One for language.
And the criteria not on that chart have none. No rule, no automated signal, nothing a checker will ever tell you about them.
Seven AA criteria have an automated rule
Sorted by conformance level, the twenty-nine break down as seventeen at level A, seven at AA, four at AAA, and one that WCAG 2.2 has since retired.
Seven is the number worth sitting with, because AA is the bar. It is what the spec treats as the working standard, what public-sector procurement asks for, and what the European Accessibility Act has been enforceable against since June 2025. An automated checker can speak to seven of those criteria. It is silent on the rest.
That silence is not a bug in axe. Most of what AA asks for needs a person. Whether alt text is accurate, whether a heading describes the section under it, whether an error message tells you how to fix the problem, whether a flow can be completed by keyboard without a mouse-shaped mental model: none of those are decidable by a program, and a program that claimed to decide them would be lying.
Why no tool can tell you that you are compliant
This is the load-bearing part, and it is why this product will not print a score.
Naming the clause that a measured defect violates is a fact. The contrast on that button is 3.1:1, the requirement is 4.5:1, that is WCAG 1.4.3 at AA, EN 301 549 clause 9.1.4.3. Checkable, citable, and true.
“This element fails 1.4.3” is a statement about something that was measured. “This site is WCAG AA compliant” is a statement about everything that was not.
The second sentence covers the twenty-two criteria with no rule behind them, and every judgment call inside the seven that do. A tool that prints a compliance badge is asserting all of that on evidence it never had. So there is deliberately no aggregate here, no percentage and no badge: findings carry their clause, and the clause is only ever attached when the installed ruleset supplies the tag.
What our own checks map to: nothing
Worth stating plainly, because it cuts the other way. This product runs thirty-nine detectors of its own alongside axe, for things like a button that does nothing when pressed, a form that cannot be submitted, a dead link, a server key left in the page.
Exactly zero of them carry a WCAG clause, and they are not permitted to. They are real defects, several of them worse for a user than anything on the chart above, and none of them is an accessibility conformance failure. A citation nobody issued is the same class of lie as a compliance badge, so the mapper returns null and the finding ships without one.
What to do with this if you are shipping
- Run the automated pass anyway. It is free, it is instant, and the seventeen level-A criteria it covers are where the cheap catastrophic failures live: an image with no alt text, a form field with no label, a page with no language set.
- Do not read a clean report as a pass. A clean automated run means the twenty-nine criteria with rules found nothing. It says nothing at all about the rest.
- Keyboard-test one flow by hand. Tab through your signup, start to finish, without touching the mouse. That single exercise covers more of what automation misses than any other ten minutes you can spend.
- If someone sells you a compliance score, ask what is in the denominator. The answer is the twenty-nine criteria above, and usually not even all of them.
Reproducing this
Every figure on this page is counted at build time from the installed engine rather than typed in, so it moves when the dependency does:
node scripts/a11yfigs.cjsOne number is deliberately absent. “Automated tools catch N% of accessibility issues” is the sentence everyone wants, and producing it means dividing by the total number of success criteria in the spec, which this repository has no copy of. It would therefore be typed from memory and then quoted back as though it had been measured, which is the exact move this whole piece is arguing against. The numerator is above and it is named: these are the criteria with automated coverage, and the ones not listed have none.