What automated WCAG scans catch — and the categories they fundamentally can’t.

Accessibility scanners like axe, WAVE, and Lighthouse are essential infrastructure. They catch real bugs and they catch them at scale, on every page, every deploy. They also have hard structural limits on what they can detect, and those limits matter more than vendors of automation-only solutions admit. Here's what the scanners are good for, and the categories of accessibility bug that no scanner will ever find.

The marketing for accessibility automation tools is consistently better than the technology. Every vendor promises “ensure WCAG compliance with automated testing.” Several promise a number — 50%, 70%, 80% of WCAG issues caught automatically. The honest framing is different. Automated scanners catch some categories of bug, completely, and none of the others, ever. The framing of “catches X% of issues” obscures which X.

What the scanners reliably catch.

Anywhere the bug is a property of the static rendered HTML and the bug is well-defined enough to write a regex for, automated scanners catch it. The categories are:

• Missing alt attributes on images. The scanner can see whether the attribute exists; that part is binary. (Whether the alt text is meaningful is the part it can’t see, more on that below.)
• Color contrast violations on text against its background. Compute the contrast ratio for solid text over solid backgrounds. (Note: Scanners notoriously fail and require manual review when text sits over background images, gradients, or relies on CSS opacity).
• Form fields without associated labels. The HTML structure either has the label/input pair properly linked or it doesn’t. Trivial to detect.
• ARIA syntax errors. Invalid role names, conflicting attributes, references to IDs that don’t exist. Structural mistakes that don’t match the ARIA spec.
• HTML structure violations. Heading levels skipped (h1 directly to h3), tables without proper markup, duplicate IDs, missing language attributes on the document. Pattern-matchable.
• Document-level metadata. Missing page title, missing language declaration, malformed meta viewport. Simple presence checks.

These categories together cover a real and meaningful percentage of common accessibility bugs. Running an automated scanner on every page and every deploy is genuinely valuable. It’s the first line of defense, and a lot of bugs really do get caught there.

What no scanner can catch.

The categories that automation fundamentally cannot detect, because the bug isn’t a property of static markup:

• Whether alt text is meaningful. A scanner can see that alt="photo" exists. It can’t see that the alt should describe what the photo shows in context. alt="photo" passes the automated check and fails the actual user.
• Whether interactive elements are reachable in a sensible order. Keyboard tab order is a property of the live DOM at runtime, not the static HTML. A scanner reading rendered HTML can’t tell you whether tabbing through the page lands in a logical sequence.
• Whether dynamic content updates are announced. A form validation message that appears via JavaScript after submit failure should be announced to screen readers via aria-live. Whether it actually is depends on runtime behavior the scanner doesn’t simulate.
• Whether focus management works. When a modal opens, does focus move into it? When it closes, does focus return to the element that opened it? Both are runtime behaviors. Scanners can flag the absence of a focus trap pattern; they can’t verify the actual focus journey works.
• Whether ARIA labels match the visual experience. A button has aria-label="Close", the visible text says “Cancel,” the icon shows an X. The scanner sees consistent ARIA. Screen reader users hear “Close” while sighted users see “Cancel.” The experiences are now diverging without a way to detect it programmatically.
• Whether content makes sense at high zoom or with text spacing applied. WCAG 1.4.10 (Reflow) and 1.4.12 (Text Spacing) require the page to remain usable when zoomed to 400% or when text spacing is increased. A scanner can’t render the page under those conditions and check whether content still works.
• Whether videos and audio have meaningful captions and transcripts. Presence of a track element is detectable. Whether the captions actually match the audio, whether they cover the relevant content, whether the transcript is accurate — not detectable.
• Whether the cognitive load of the content is appropriate for its purpose. WCAG specifications include criteria about reading levels (plain language) and consistent navigation. Automation can’t evaluate either meaningfully.

What this means for site testing.

The serious accessibility testing workflow uses automation as the first layer and human testing as the second. Specifically:

1. Run an automated scanner on every page on every deploy. This is your continuous coverage. Bugs introduced into the static markup get caught fast.
2. Run a screen reader against the high-traffic templates manually, periodically. NVDA on Windows, VoiceOver on macOS/iOS, JAWS for the most demanding cases. The bugs that only show up in real assistive technology use get caught here.
3. Run keyboard-only navigation against the same templates. Tab through every page, activate every control. The focus and reachability bugs surface immediately.
4. Audit the editorial process for alt-text and content patterns. The scanner can verify alt exists. Whether it’s good requires editorial judgment.

Together, the four layers cover most of what’s practically catchable. Skipping any of them means accepting the bugs in that category will reach users. There’s no toolchain that catches everything automatically — the marketing claim that there is should be treated as a sign that the vendor doesn’t understand accessibility, or hopes you don’t. See accessibility that holds up for what real coverage looks like.