Somewhere on your team, someone opened Chrome DevTools, ran Lighthouse, and watched the accessibility category light up green. A hundred out of a hundred. Screenshots got taken. The number went into a slide deck, maybe into a client report. Everyone exhaled.
That number is real. It is also almost meaningless on its own, and the gap between "Lighthouse says 100" and "a screen reader user can actually complete checkout" is where most accessibility complaints, support tickets, and legal exposure quietly live. Lighthouse cannot open a screen reader and listen to what it says. It cannot tab through your page and notice the focus indicator jumping to the wrong place. It cannot get confused, frustrated, or lost the way a real person with a cognitive disability might. It can only check what lives in the DOM against a fixed rule set, and a huge share of accessibility failures never show up there at all.
The Stat: Deque's own published research finds automated scanning alone, the same category of tool Lighthouse's accessibility audit is built on, catches roughly 57.38% of WCAG issues on a page. (Source: Deque Systems)
What Lighthouse actually checks (and why that's the ceiling, not the floor)
Lighthouse's accessibility audit is powered by axe-core, the same open-source rules engine that runs inside many standalone accessibility scanners. That is genuinely good engineering. Axe-core is precise about what it claims, and Chrome's own documentation on how the accessibility audit works is upfront that it is checking a specific list of automatable rules against the rendered DOM, not evaluating the experience of using the page.
That means Lighthouse is very good at catching things like:
- An
<img>with noaltattribute - Form inputs missing an associated
<label> - Text and background colors that fall under the minimum contrast ratio
- Buttons or links with no accessible name at all
- Invalid or duplicate ARIA attribute values
- Missing
langattributes on the<html>element
Every one of those is a real, worth-fixing issue. None of them tell you whether a person can actually use your product.
It helps to remember what "automated" actually means here. Lighthouse loads your page, inspects the rendered DOM tree, and runs a battery of pattern-matching rules against it. It never simulates a human. It does not click anything, does not listen to synthesized speech, does not experience frustration when a menu closes unexpectedly, and does not get lost when a "skip to content" link points at the wrong element. Its entire universe is static structure. Anything that only shows up through interaction, through timing, or through the subjective experience of using assistive technology sits outside that universe by definition, no matter how sophisticated the rule set gets.
That is not a criticism of the tool. It is a description of its job. The problem shows up when teams quietly promote "Lighthouse passed" into "we are accessible," because those are two very different claims, and only one of them is actually being tested.
The four categories a 100 score cannot see
Task flow. A checkout form can have perfect labels, perfect contrast, and perfect ARIA syntax, and still be impossible to complete if a validation error appears silently at the top of the page while focus stays on the submit button. Lighthouse has no concept of "did the user complete the task." It checks static markup, not a sequence of interactions.
Screen reader announcements. This is the big one. Axe-core (and by extension Lighthouse) can confirm that an ARIA attribute is syntactically valid. It cannot confirm that a screen reader announces it the way you'd expect, or that the announcement happens at a useful moment. A live region with aria-live="polite" might pass every automated check while announcing updates so late, or so verbosely, that a VoiceOver or NVDA user gives up before it finishes talking. The only way to know is to turn on a screen reader and listen.
Focus order. Tab order that loops back on itself, jumps to a hidden element, or gets trapped inside a modal with no way out is one of the most common real-world barriers for keyboard users. It is also invisible to Lighthouse, because "does pressing Tab move focus somewhere logical and visible" is a behavioral question, not a static DOM property.
Cognitive load. Nothing in the WCAG automatable rule set can score whether your error messages are written in plain language, whether your multi-step form gives people a way to review before submitting, or whether a page dense with competing calls to action overwhelms someone with an attention-related disability. These are judgment calls that require a human evaluator working through WCAG's own success criteria, not a linter.
Each of these categories shares a common trait: they are about behavior over time, not the shape of a single snapshot of the DOM. A scanner evaluates one frozen state of the page. A real user moves through the page, makes a mistake, waits for feedback, and tries again. Most of the barriers that actually stop someone live in that motion, not in the snapshot, which is exactly the part Lighthouse was never built to observe.
Why a green score still creates real risk
This gap matters beyond user experience. Accessibility legal exposure, whether under the ADA in the United States, the European Accessibility Act, or similar frameworks elsewhere, is generally assessed against whether a person with a disability could actually use the service, not against whether an automated tool reported a clean scan. A plaintiff's expert witness or a regulator is not going to open Lighthouse and stop there. They will use a screen reader, try to complete a purchase, and document exactly where it broke down. A 100 score does nothing to protect against that kind of finding, and citing it as evidence of compliance can actually make a team look less diligent, not more, once a real failure surfaces.
There is also an internal cost. Teams that treat the automated score as the finish line tend to stop looking. Accessibility work gets deprioritized because "the audit already passed," bug reports from actual assistive technology users get treated as edge cases instead of confirmed defects, and the next redesign repeats the same blind spots because nobody built a habit of testing the parts a scanner cannot see.
What this means for how you should actually test
Treat Lighthouse (and any automated scanner) as a fast, cheap first pass, not a finish line. It is excellent at catching the mechanical mistakes that are easy to introduce and easy to fix, and it is worth running on every build. But a 100 in that category should never be the signal that tells your team the work is done.
A more honest workflow looks like this:
- Run automated scans continuously in CI, so mechanical regressions get caught immediately.
- Fix everything the scanner flags, since those are genuinely real defects.
- Schedule a manual pass with an actual screen reader (VoiceOver, NVDA, or JAWS) walking through your core user flows, not just individual pages.
- Have someone test the site using only a keyboard, no mouse, and note anywhere focus gets lost or trapped.
- Review your content and flows against WCAG's cognitive and readability guidance, not just the technical success criteria.
If you want a deeper, checklist-driven walkthrough of how to combine automated tooling with AI-assisted review so you are not relying on manual testing alone for every single page, we laid out the full process in our AI-assisted WCAG audit checklist for 2026. It is the natural next step once you've accepted that the green score is a starting point, not a conclusion.
The honest takeaway
A perfect Lighthouse score is not a false result. It is a true answer to a narrower question than most teams realize they're asking. Lighthouse tells you that your markup avoids a defined set of automatable mistakes. It does not, and structurally cannot, tell you whether a real person using assistive technology can find what they need, understand what happened, and finish the task they came to do.
If your last accessibility check was a Lighthouse run and nothing else, it is worth getting a second, human-informed opinion before you tell a client, a regulator, or your own leadership that the site is accessible. You can start with a free audit that looks past the automated score and into the parts of the experience a scanner was never built to see.
Want to talk it through with a person first? Email experts@wcag.world and our team will walk you through what a full audit actually covers, or go straight to the free audit to get started.