A Lighthouse accessibility score of 100 does not mean WCAG compliance. It means the page passed Lighthouse's automated axe-core checks, and automation covers only part of WCAG. Deque's Automated Accessibility Coverage Report found automated issues for 16 of the 50 Level A and AA criteria, and 57.38% of issues by volume. Keyboard traps, meaningless alt text and illogical focus order can coexist with a perfect score.
The score is a genuine signal that you cleared the machine-detectable floor, which is worth doing. It is not a certificate of accessibility, and it is not a conformance claim. This article explains exactly what the score measures, how much automation actually catches, the whole category of barriers a perfect score structurally cannot see, why "we passed Lighthouse" will not help you in a dispute, and what real compliance actually takes.
We work with a lot of teams who ship a green 100 and believe they are done, and we understand why: the number is designed to feel like a final grade. It looks like the accessibility equivalent of a passing test suite. But accessibility is not one number, and treating a score as conformance is the single most common way well-meaning teams end up with an inaccessible site and a false sense of safety. Let us take it apart honestly, because the gap between "scored 100" and "actually usable" is where the real work, and the real risk, lives.
What a Lighthouse accessibility score actually measures
A Lighthouse accessibility score is the percentage of applicable automated checks your page passed, weighted by user impact. That is the entire definition. It is not a measure of how accessible your site is to a real person; it is a measure of how many of a specific, finite list of automated rules came back clean.
Mechanically, the score works exactly as you would expect a test pass-rate to work. According to Google's own accessibility scoring documentation on Chrome for Developers, the Lighthouse accessibility score is a weighted average of all accessibility audits, with weighting based on axe user-impact assessments, and each audit is strictly pass or fail with no partial credit. If some buttons on a page have accessible names and others do not, the whole "buttons have accessible names" audit fails and contributes zero, regardless of how many buttons were fine. The final number is the weighted share of audits that passed, scaled to 100.
The crucial detail is what powers those audits. Lighthouse does not have its own accessibility brain; it runs axe-core, the open-source rules engine from Deque, against your rendered page. So a Lighthouse accessibility score is really an axe-core result wearing a friendlier interface, and it inherits both the strengths and the hard limits of what a rules engine can determine by inspecting the DOM. That inheritance is the whole story, because it means the ceiling on what Lighthouse can ever tell you is the ceiling of what automation can detect at all.
How much automation actually catches
Here is the direct answer people come looking for: automated accessibility testing finds issues for about a third of WCAG success criteria (16 of the 50 Level A and AA criteria) and for 57.38 percent of accessibility issues by volume, and no automated tool, Lighthouse included, catches more than a little over half. The rest requires a human. Those two figures are not a rounding error or vendor disagreement for its own sake; they come from two legitimately different ways of counting.
The first figure reflects the classic framing, that automated tools reliably evaluate only a minority of the WCAG success criteria, because most criteria require human judgment. Deque's report counts it directly: automated tests found issues for 16 of the 50 WCAG 2.1 Level A and AA criteria. The second figure comes from measuring differently. According to Deque's Automated Accessibility Coverage Report, when you count by the total volume of real-world issues rather than by the number of success criteria, automated testing with axe identified 57.38 percent of accessibility issues across a dataset of over 2,000 audits spanning more than 13,000 pages and nearly 300,000 issues. The reason the volume-based number is higher is that a handful of very common defect types, contrast, missing names, language of page, dominate real sites, and automation happens to be good at exactly those. The same figure is stated plainly in the engine itself: according to the axe-core project documentation on GitHub, you can find on average 57 percent of WCAG issues automatically, and axe-core returns elements as "incomplete" where it could not be certain and manual review is needed.
Both numbers are true, and both lead to the same conclusion. Whether you say a third of criteria or 57 percent of issues, you are describing a tool that misses a large fraction of what matters. Lighthouse actually sits at the more conservative end even of this range, because it runs a curated subset of axe-core's rules rather than the full set. So a perfect Lighthouse score certifies success on the most machine-checkable slice of a partial-coverage tool. That is a real and useful floor. It is nowhere near the whole building.
| Way of counting | Share automated tools catch | Why |
|---|---|---|
| By WCAG success criteria | 16 of the 50 Level A and AA criteria (about a third), in Deque's coverage report | Most criteria need human judgment, so a tool can reliably evaluate only a minority of them |
| By volume of real-world issues | 57.38 percent, in Deque's coverage report | A few very common defects (contrast, missing names, language of page) dominate real sites, and automation is good at those |
| Lighthouse specifically | The conservative end of the range | It runs a curated subset of axe-core's rules, not the full set (Lighthouse's axe-core configuration) |
What a score of 100 cannot see
This is the heart of it. The problem with a perfect score is not that automation is sloppy; it is that entire categories of accessibility are about meaning and interaction, which a rules engine cannot evaluate by reading markup. You can build a genuinely unusable site that scores 100, and people have done it deliberately to prove the point. Here are the barriers that live in the blind spot.
Keyboard operability and focus order are largely invisible to the score. Automation can confirm a focusable element exists, but it cannot tell whether a keyboard user can actually complete your checkout, whether focus moves in a logical order, or whether a custom modal traps someone with no way out. A keyboard trap is a serious WCAG failure and a real-world dead end, and a page full of them can still score 100.
Whether your structure makes sense to a screen reader is a judgment call automation cannot make. A tool can verify that heading tags exist and even that levels are not skipped, but it cannot decide whether your headings actually describe the content beneath them or whether your landmarks organize the page in a way that helps someone navigating by structure. Correct syntax is not the same as coherent meaning.
Link and button text that is technically present but useless passes automated checks. Consider this, which sails through any automated name check:
<a href="/report.pdf">click here</a>
<a href="/invoice.pdf">click here</a>
<a href="/terms.pdf">click here</a>Every link has accessible text, so the audit passes. But a screen reader user pulling up a list of links hears "click here, click here, click here" with no way to tell them apart. The markup is valid; the experience is broken, and the score cannot tell the difference.
Alt text that exists but says nothing is the same trap in image form. This passes:
<img src="chart-q4-revenue.png" alt="image">The alt attribute is present, so the "images have alt text" audit is satisfied and the page scores accordingly. But alt="image" conveys nothing; a blind user learns only that something visual is there, not that it is the Q4 revenue chart. Automation can check for the presence of alt text. It cannot judge whether the text is meaningful, which is the thing that actually matters.
The most fundamental blind spot is the fake control. A <div> styled to look like a button is a pattern automation struggles with, and it is everywhere in modern component code:
<div class="btn" onclick="submitForm()">Submit</div>This looks and, for a mouse user, behaves like a button. But it is a <div>, so it is not in the tab order, does not respond to the Enter or Space keys, and announces nothing useful to a screen reader. A real <button> gives you all of that for free. Depending on how it is built, a page like this can still post a high score while being unusable without a mouse. This class of problem, valid-looking markup that betrays its meaning, is exactly the kind of defect that proliferates in fast, generated code, which we dug into in the accessibility debt piling up in AI-generated code.
Finally, meaning carried only by color or sound is beyond reach. Automation can measure the contrast ratio of text, and that is genuinely valuable, but it cannot tell that your form marks errors in red with no text label, or that your "in stock" and "out of stock" states differ only by a green or red dot. If the only signal is a color a color-blind user cannot distinguish, the information is lost, and no score will flag it. If contrast is the one thing you fix from your automated results, at least do it properly; here is how to actually fix low color contrast.
The "needs review" trap
There is a quieter problem that even careful teams miss, and it hides inside the tool's own output. Automated engines do not only return pass and fail. They also return a third category, the checks the engine flagged as needing human review because it could not decide on its own.
Lighthouse surfaces these separately, and crucially they do not affect the score. According to Google's accessibility scoring documentation, manual audits are not included in the scoring table because they do not affect your score, and Lighthouse presents a set of "additional items to manually check" alongside the automated results. axe-core calls the same idea "incomplete": elements where it cannot be certain and explicitly asks for human review.
Here is the trap. A team sees the green 100, feels finished, and never scrolls down to the section that says, in effect, "these things could be broken, but only a person can tell." Those flagged-for-review items are not noise; they are the tool being honest about the edge of its competence. Ignoring them is how a page with real, tool-suspected problems gets shipped under a perfect score. The "needs review" list is a to-do list, not a footnote, and treating it as optional is one of the most common ways automated testing gives false comfort.
Why "we passed Lighthouse" is not a legal defense
If your accessibility strategy is a screenshot of a green 100, you do not have a defense; you may have evidence against yourself. This matters because the laws that govern web accessibility do not reference tool scores at all. They reference WCAG conformance.
WCAG conformance is defined per success criterion, not as an average or a percentage. According to the W3C's WCAG standards overview, the guidelines are built from testable success criteria organized under four principles, and conformance at a given level means satisfying all of the applicable criteria at that level. There is no partial conformance and no "we passed most of it" in the standard. A single unmet Level AA criterion means the page does not conform to Level AA, full stop. A Lighthouse score, by contrast, is explicitly an average that can sit at 100 while specific criteria, the ones automation cannot see, go unmet. The two are not measuring the same thing, and only one of them is what the law cares about.
There is a sharper edge to this. A documented, proudly displayed score of 100 can be turned around in a complaint. If a plaintiff's tester finds a keyboard trap or a set of unlabeled form fields, real WCAG failures that automation never catches, your public claim of a perfect accessibility score does not help you. It can be framed as a representation that the site was accessible when it was not, and it demonstrates that you had a testing process that stopped at the automated floor. "We ran the tool and it said 100" establishes that you checked the easy half and skipped the rest. Relying on a score as a shield is exactly the kind of surface-level fix that fails under scrutiny, which is the same reason fixing the source beats an overlay: a compliant-looking signal means nothing if the substance underneath is broken.
What compliance actually requires
Real compliance is not a tool; it is a three-layer process, and automation is only the first layer. Skipping the other two is what produces the perfect-score-but-inaccessible site.
- The automated floor. Run Lighthouse or axe on every page and in your build pipeline, and drive the machine-detectable issues to zero: contrast, missing names, missing alt attributes, invalid ARIA, language of page. This is the cheap, fast, repeatable layer, and it genuinely clears the highest-volume defects. It is necessary. It is just not sufficient, and its job is to get the noise out of the way so human attention can go where it is actually needed.
- Manual testing. This is where conformance is really won or lost. It has three distinct parts. Keyboard testing means putting the mouse away and operating every flow, navigation, forms, modals, menus, with Tab, Enter, Space, and arrow keys, confirming you can reach and use everything and that focus is visible and never trapped. Screen reader testing means actually listening to your key pages with a screen reader to hear whether the headings, link text, alt text, and announced states make sense, which is the only way to catch the "click here" and
alt="image"class of problems. And a cognitive walkthrough means checking that instructions are clear, errors are explained in words, and nothing relies on color or sound alone. None of this is automatable, and all of it is where the criteria automation cannot see actually get verified. - Documentation. Conformance is a claim you should be able to substantiate, so record what you tested, how, with which assistive technologies, what you found, and what you fixed or still owe. This is what turns "we think it is accessible" into something defensible, and it is the honest basis for a public accessibility statement. Rather than pasting a score, you can write an accessibility statement from what you actually found, grounded in real testing rather than a number. If you want the broader checklist that this process fits into, we laid out a full ADA compliance checklist separately. For how that documentation differs from a formal audit, see what an accessibility audit proves.
A practical workflow for developers
Putting it together, here is a workflow that uses the score for what it is good for without mistaking it for the finish line. Treat automation as your regression baseline, not your audit. Wire axe or Lighthouse into CI so no build ships with new machine-detectable failures, and get every page to a clean automated result. That is the floor, and keeping it green forever is exactly what automation is for.
Then, on top of that floor, do the human layer where it counts. You do not have to manually audit every page every week, but your critical flows, sign-up, checkout, search, core forms, need a real keyboard pass and a real screen reader pass, plus a check that no meaning rides on color alone. Do the full manual audit before major launches and on a schedule after, and always work through the tool's "needs review" items rather than ignoring them. Fix what you find at the source, in shared components, so one correction propagates everywhere. And write down what you did, so your accessibility claim rests on evidence. The score stays useful in this workflow; it just goes back to being a smoke test rather than a certificate.
Frequently asked questions
Does a Lighthouse score of 100 mean my site is accessible?
No. A score of 100 means your page passed Lighthouse's automated checks, which cover only part of accessibility. It cannot verify keyboard operability, meaningful alt text and link text, logical screen-reader structure, or meaning conveyed by color, so a site can score 100 and still be unusable for real people.
What percentage of accessibility issues does Lighthouse catch?
Automated tools cover only part of WCAG, and how much depends on how you count: in Deque's data, issues for 16 of the 50 Level A and AA success criteria (about a third), and 57.38 percent of real-world issues by volume. Lighthouse sits at the conservative end because it runs a subset of axe-core's rules.
What is the difference between Lighthouse and axe?
Lighthouse is Google's auditing tool that produces a 0 to 100 accessibility score, and it runs the axe-core engine under the hood to do the actual checking. axe-core is the underlying rules library from Deque. Lighthouse uses only a curated subset of axe-core's rules, so a dedicated axe tool typically catches more than Lighthouse does.
Can I be sued if my Lighthouse score is 100?
Yes. Web accessibility laws reference WCAG conformance, not tool scores, and a perfect score can coexist with real WCAG failures that automation cannot detect, such as keyboard traps or unlabeled forms. A publicly displayed 100 can even be cited as a claim of accessibility that the site did not actually meet.
Why did my site pass Lighthouse but fail a manual audit?
Because they test different things. Lighthouse checks machine-detectable rules; a manual audit checks the meaning-and-interaction criteria automation cannot, like whether a screen reader user can understand your headings or a keyboard user can finish a form. Passing the automated subset while failing human review is the expected outcome, not a contradiction.
Does a high Lighthouse score mean WCAG 2.1 AA compliance?
No. WCAG 2.1 AA conformance requires satisfying every applicable Level A and AA success criterion, and it is per-criterion with no partial credit. A Lighthouse score is a weighted average that can reach 100 while specific criteria go unmet, so the score cannot establish AA conformance on its own.
What can automated accessibility testing not detect?
It cannot judge meaning or interaction: keyboard operability and focus order, whether headings and landmarks make sense, whether alt text and link text are actually descriptive, whether errors and states rely on color or sound alone, and whether custom widgets work with assistive technology. These need human testing with a keyboard and a screen reader.
Is Lighthouse enough for ADA or EAA compliance?
No. Both the ADA (via WCAG) and the European Accessibility Act (via EN 301 549, which incorporates WCAG) require conformance that includes the manual-only criteria automated tools cannot verify. Lighthouse is a useful part of the process, but on its own it cannot establish the conformance these laws expect.
How do I test what Lighthouse misses?
Add a manual layer: operate every flow with the keyboard only and watch for traps and focus order, listen to key pages with a screen reader to check headings, link text, and alt text, and confirm no information is carried by color or sound alone. Then document what you tested and found so the result is defensible.
The bottom line
A Lighthouse accessibility score of 100 is a good smoke test and a bad certificate. It confirms you passed the automated checks, which find issues for about a third of WCAG criteria and a little over half of issues by volume, and structurally cannot see keyboard traps, meaningless-but-present alt and link text, incoherent screen-reader structure, fake controls, or meaning carried by color alone. WCAG conformance, the thing the ADA and EAA actually reference, is defined per success criterion with no partial credit, so a green 100 can sit on top of a page that does not conform, and a publicly displayed score can become evidence rather than a defense. Real compliance is a three-layer process: the automated floor, then manual keyboard, screen-reader, and cognitive testing, then documentation of what you did. Use the score for what it is worth, keep it green in CI, and then do the human work that the number was never able to do for you. That is the difference between a site that passes a tool and a site that works for the people it is supposed to serve.
Sources
Google, Lighthouse Accessibility Scoring (Chrome for Developers)
Deque, The Automated Accessibility Coverage Report
Deque, axe-core (GitHub project documentation)
W3C, WCAG Standards and Guidelines Overview
This article is educational and reflects Sitejar's point of view. It is not legal advice. For your specific situation, consult a qualified professional.