If you own a website, you’ve probably run an accessibility scanner — or had a “compliance” plugin promise you a green checkmark. Then a demand letter shows up anyway, and you wonder how a site that “passed” can still be a legal target. The answer is almost always the same: a scanner tested the things a machine can measure, and skipped the things only a person can judge. This guide explains, in plain English, what each kind of testing actually catches — and why a real audit uses both.

Automated testing: fast, cheap, and partial

An automated scanner (axe, WAVE, Lighthouse, and the engines behind most “compliance” tools) reads your page’s code and flags patterns it can measure with certainty. It’s genuinely good at this. It will catch a missing alt attribute, a color-contrast ratio below the threshold, an empty link or button, a missing page-language declaration, and broken HTML structure. These are real problems, and they’re everywhere: the WebAIM Million 2026 report found detectable WCAG failures on 95.9% of the top one million home pages, averaging 56.1 errors per page — with low-contrast text on 83.9% of pages, missing alt text on 53.1%, and missing form labels on 51%.

So scanners earn their keep. The catch is coverage. By one criterion-level analysis, automated tools reliably flag only about 13% of WCAG 2.2 AA success criteria (7 of 55), partially detect roughly 45%, and cannot detect 42% at all (Accessible.org). Deque, which makes the popular axe engine, reports its automated testing catches about 57% of issues by volume — higher than the criteria count because a few auto-detectable problems like contrast are extremely common — but that still leaves a large share, and even Deque’s guided-but-still-human-assisted workflow only reaches roughly 80% (Deque).

Read that carefully: a clean scan means no machine-detectable errors were found. It does not mean a blind person can check out of your store.

Manual testing: slower, smarter, and where the real barriers hide

Manual testing is a trained person using your site the way a disabled visitor would — and asking questions a machine can’t. A scanner can confirm an image has alt text; only a human can tell you the alt text says “image123.jpg” instead of “Red leather handbag, front view.” That gap repeats across the most important parts of accessibility:

  • Keyboard navigation: A scanner sees focusable elements; a person tabs through your checkout and discovers the “Apply coupon” button is unreachable, or the focus order jumps around randomly.
  • Screen reader experience: Only a human listening with VoiceOver or NVDA hears that your form error says nothing, or that a modal traps the cursor.
  • Meaning and context: Are headings in a logical order? Do link texts make sense out of context? Is the contrast failure on decorative text that doesn’t matter, or on your “Buy now” button?

These are judgment calls, which is exactly why automated tools punt on them. Reading the actual WCAG success criteria makes the split obvious: requirements like 1.1.1 (non-text content) or 2.4.7 (focus visible) hinge on quality and experience, not on whether a tag exists.

When to use which

Think of it as a workflow, not a competition:

  1. Run an automated scan first. It’s the cheapest way to clear the high-volume, repeatable issues — contrast, alt attributes, labels — so a human isn’t wasting expensive hours on things a tool finds in seconds. Start with a free accessibility scan.
  2. Then test manually for everything that survives: keyboard flows, screen-reader output, focus management, and whether content actually communicates.
  3. Re-test after fixes — and keep monitoring, because a single content update can reintroduce errors.

For small sites, automated scanning catches a meaningful first wave. But “automated only” is a known trap, and it has legal consequences.

Why “the scanner said we passed” isn’t a defense

This is the part business owners care about most. More than 5,000 digital accessibility lawsuits were filed in 2025, with e-commerce sites the target in roughly 70% of them (UsableNet). A plaintiff’s tester doesn’t run your scanner — they use a real screen reader and document where the site breaks. That’s manual testing, used against you. The barriers they cite are usually the exact things automated tools miss.

It’s also why accessibility overlays don’t protect you. A widget bolts a control panel onto a broken page; it doesn’t run the manual testing the law effectively expects, and companies using overlays keep getting sued — in the first half of 2025, roughly a fifth of all filings targeted sites that had an overlay installed (UsableNet). The honest path is manual remediation, not a widget.

This article is general information, not legal advice. For your specific exposure, consult a qualified attorney.

What a real audit combines

A credible accessibility audit doesn’t pick a side. It runs automated tooling across every template to sweep up the common, code-level errors, then puts a human on the flows that matter — keyboard, screen reader, forms, focus — to verify the site is genuinely usable against WCAG 2.1 AA. The output is a prioritized list tied to real barriers, not a vanity score. That combined approach is the foundation of ADA website compliance — and it’s how our team works, because it’s the only method that holds up when a real user, or a real plaintiff, shows up.

Start where it’s cheapest. Run a free scan to see your machine-detectable issues today, and we’ll show you what a scanner can never catch.