Why accessibility scanners only detect 30% of issues

If you use a classic accessibility scanner to test your site, you may think that "0 errors" means "accessible site". It does not. These tools only detect 20 to 30% of WCAG criteria.

The number that makes you think

Independent studies show that automated tools can only test 30 to 40% of WCAG 2.1 Success Criteria. And among those they do test, they miss many real-world cases.

Researcher Eyal Eshet analyzed the output of several automated tools on a sample of real-world sites and found an effective detection rate of 20 to 25% of accessibility issues.

Why so few?

Scanners perform static DOM analysis

A classic scanner inspects the HTML of the page at load time. It can check:

The presence of alt attributes on images
Color contrast between text and background
The presence of the lang attribute on the <html> tag
Misused ARIA roles
Forms without labels

What they CANNOT do

1. Test keyboard navigation

A scanner does not press the Tab key. It does not know whether a user can reach every interactive element, whether focus is visible, or whether a keyboard trap exists. Yet WCAG 2.1 Success Criteria 2.1.1 (Keyboard), 2.1.2 (No Keyboard Trap), 2.4.3 (Focus Order) and 2.4.7 (Focus Visible) are exactly about these things.

WCAG 2.1.2 — No Keyboard Trap
A scanner sees: <div tabindex="0" onkeydown="...">
The scanner says: No error
The reality: the user is trapped, Tab never leaves this component

2. Test interactive components

ARIA menus, modals, accordions and tabs must respect the APG Design Patterns:

A menu should open with Enter, navigate with arrow keys, and close with Escape
A modal should trap focus and restore it on close
Tabs should switch with left/right arrow keys

A scanner does not click, does not press Enter, does not check that Escape closes the modal. It only verifies that role="dialog" is present — not that it actually works.

3. Check visible focus

WCAG 2.4.7 requires every interactive element to have a visible focus indicator. A scanner can detect outline: none in the CSS, but it cannot verify:

Whether a box-shadow or border compensates for the removed outline
Whether the :focus-visible pseudo-selector is used
Whether the focus style has sufficient contrast with the background

4. Test reflow and zoom

WCAG 1.4.10 (Reflow) requires content to remain readable at a 320px width. WCAG 1.4.4 (Resize Text) requires that zooming to 200% does not cause content loss. A scanner does not resize the window.

5. Evaluate relevance

A scanner can verify that an image has an alt. It cannot verify that the alt is meaningful. alt="image" is technically present but completely useless.

What Scrutia does differently

Scrutia goes beyond static analysis by running real dynamic tests on your page:

Real keyboard navigation

Scrutia simulates a full Tab journey on your page and verifies that every interactive element is reachable, that focus is visible, and that no keyboard trap blocks progression.

ARIA component testing

Menus, modals, tabs and accordions are tested against the W3C APG Design Patterns: opening, closing, internal keyboard navigation.

Reflow and zoom testing

Scrutia verifies that content stays readable and usable in zoom and reduced-width conditions, matching WCAG criteria on reflow and text spacing.

Conclusion

An accessibility audit that only tests the static DOM misses 70% of issues. The most critical criteria — keyboard navigation, interactive components, visible focus — require dynamic testing. That is why human audits remain essential, and that is what Scrutia automates.