You ran an automated accessibility scan, the dashboard turned green, and you exhaled. Zero errors. Compliant. Done.

It’s a comforting feeling, and it’s the single most dangerous misconception in web accessibility. A clean automated scan tells you that a machine couldn’t find the problems a machine is capable of finding. That’s a much smaller claim than “this site is accessible,” and the gap between those two statements is exactly where real users get stuck — and where demand letters come from.

What an automated scanner can actually measure

Automated tools are genuinely useful. They’re fast, cheap, and excellent at catching the high-volume, mechanical failures that plague almost every site: missing alt attributes, form fields with no programmatic label, empty buttons, low color contrast, and broken ARIA references. Run one on a site that’s never been audited and you’ll get a long, legitimate to-do list.

But notice what all of those checks have in common: each one has a binary, machine-verifiable answer. Does the <img> have an alt attribute, yes or no? Is the contrast ratio above 4.5:1, yes or no? A computer can answer those questions perfectly. The trouble is that most of WCAG isn’t built from yes/no machine questions. It’s built from human judgment.

The number nobody puts on the marketing page

So how much does a scanner actually catch? It depends entirely on how you count.

Measured by the distinct WCAG success criteria a tool can reliably evaluate, the long-standing industry estimate is that automated testing covers only about a third — commonly cited as 30 to 40 percent — leaving the majority to human review. Deque, the company behind the widely used axe testing engine, even acknowledges that “20-30 percent of coverage” was the “widely-accepted belief” they set out to challenge.

Their counter-study reframed the question by volume of issues rather than criteria, and found their engine surfaced about 57 percent of issues across more than 13,000 pages and nearly 300,000 findings. That sounds reassuring until you read the fine print: the number is inflated by a handful of extremely frequent, easy-to-detect errors — color contrast alone makes up roughly 30 percent of all errors. High volume isn’t the same as high coverage. A tool can nail the common, repetitive failures and still be blind to entire categories of barrier.

WebAIM is blunt about the ceiling. In their guidance on evaluation tools, they state plainly that “no automated tool can tell you if your site is accessible, or even compliant” — because accessibility is about the human experience, and human testing is always necessary.

Why a clean scan is a false sense of security

Here’s the part that matters legally and practically: the absence of detected errors does not mean the page is accessible. That’s not our spin — it’s the explicit caveat WebAIM attaches to its annual research. In the 2026 WebAIM Million report, automated testing flagged WCAG failures on 95.9% of the top one million home pages, averaging 56.1 errors per page. But WebAIM stresses that because only automatically detectable failures were counted, “the rate of full WCAG 2 A/AA conformance was certainly lower” than the small fraction of pages that scanned clean. In other words: even among the pages that pass automated checks, most are still not actually conformant.

That’s the false sense of security in one sentence. A green scan moves you from “definitely has problems a machine can see” to “might still have plenty of problems a machine can’t see.” It is a floor, not a finish line.

What only a human can test

To make the gap concrete, here’s a sample of what a passing scan routinely walks right past:

  • Is the alt text meaningful? A scanner confirms an alt attribute exists. It cannot tell that alt="image123.jpg" or alt="product" is useless to a blind user. Judging quality is a human job — see our alt text guide.
  • Does the keyboard order make sense? A tool can verify an element is focusable. It can’t feel that the focus jumps from the header to the footer and back, or that a custom modal traps you. That only surfaces when a person tabs through, as we cover in keyboard navigation.
  • What does the screen reader actually announce? Machines don’t listen. Whether a control announces the right name, role, and state — the heart of criteria like 4.1.2 Name, Role, Value — requires testing with a real screen reader.
  • Are errors and instructions clear? A scanner sees a form has labels; it can’t judge whether the error message tells a user how to fix the problem, the substance of 3.3.2 Labels or Instructions.
  • Can someone complete the task? No tool measures whether a person using assistive technology can actually book the appointment, finish checkout, or read the menu. That’s the whole point — and it’s why we test by success criteria, not just by error count.

This is general information, not legal advice; if you’ve received a complaint or want certainty about your specific obligations, talk to a qualified accessibility attorney.

Why overlays make this worse, not better

If automated detection misses most issues, then any product built on top of automated detection inherits the same blind spots. That’s the structural flaw in accessibility overlays and widgets: they scan with a machine, then try to auto-repair with a machine, so they can only ever touch the same narrow slice a scanner sees — and they often introduce new bugs for assistive-technology users along the way.

The market has already returned a verdict. In 2024, more than 1,000 businesses that had an accessibility widget installed were sued anyway, accounting for more than a quarter of all cases in a year that saw over 4,000 digital accessibility lawsuits filed. A green dashboard didn’t protect them, and neither did the widget. We go deeper on this in overlay vs. manual remediation and on how to actually avoid a lawsuit.

Use the scan for what it’s good at — then test like a human

None of this means you should throw away automated tools. Run them. They’re the right first pass and a great way to catch regressions during development. Just be honest about what they are: a smoke detector, not a fire inspection.

Real conformance to WCAG 2.1 AA comes from pairing automated checks with manual, assistive-technology testing of the criteria machines can’t judge — then fixing the underlying HTML, ARIA, and content. That’s the whole premise of a proper manual accessibility audit, and the reason Curbcut does hands-on remediation rather than bolting on a widget.

A scan is a fine place to begin. Run a free scan to get your machine-detectable baseline — just remember that a clean result is the start of the conversation, not the end of it.