Where Automated Accessibility Scanners Fall Short

A 100% score on Lighthouse or axe-core feels great, but it doesn't mean your website is accessible.

Automated tools perform static analysis on the initial DOM. They don’t interact with your application the way a human does. Because they can’t tab through a page, hover over custom controls, use a screen reader or interpret context, automated scanners catch roughly 30% to 40% of WCAG violations.

If you rely solely on automated testing, here are the three massive things that can be missed.

Focus management and keyboard traps

Automated tools load up the page and test the markup statically when they deem it ready. They don’t emulate keyboard navigation, which leaves interactive behavior completely untested. Without a human pressing the Tab key, scanners can’t determine if the focus order moves predictably through the DOM or jumps all over the page. They also can’t catch keyboard traps, like if a user tabs into a modal and gets stuck without a way out. Tools also miss critical focus restoration issues. For example, when a dialog closes, focus returns to the top of page instead of returning to the button that opened it.

Dynamic hover and focus states

Evaluating the page statically means the wonderful hover and focus states we spent so long working on can’t be verified with automated tools. They do not trigger pseudo-classes like :hover:, :focus or :focus-visible.

As a result, interactive elements like tooltips and drop-down menus don't get tested in their active state. These tools also can’t tell if hover content stays visible a mouse moves across it, focuses it, or if it can be cleanly dismissed using the Escape key.

Meaningful context vs. syntax existence

Automated testing often operates on a basic rule: does attribute X exist properly on element Y. It checks for presence, not purpose.

An important image will pass an automated scan simply because an alt attribute is present, even if alt="hero_bannerfinal_v2.png" provides zero helpful context to a screen reader user.

Similarly, links that say "Click Here" (please don’t bring this back) or buttons that say "Read More" will pass automated checks easily. The code is valid, but the text gives a user zero context.

Automated testing is a necessary first line of defense, serving as a linter for basic HTML syntax. But a 100% automated pass score is not proof of an accessible user experience. True accessibility lives in interaction, logic, and context, and those can only be verified by manual testing.