No — a Lighthouse accessibility score of 100 does not mean your website is ADA compliant. It means your page passed every check Lighthouse can run automatically, and Google’s own documentation defines the score as nothing more than that: a weighted average of pass/fail machine audits. A page that no human with a disability could actually use has scored a perfect 100, on purpose, as a public demonstration.
If your developer or agency just showed you that green circle as proof you’re covered, this article is the context they left out. None of it means Lighthouse is a bad tool. It means the score answers a much smaller question than the one you’re asking.
What does a Lighthouse accessibility score of 100 actually mean?
It means zero failures on the automated audits Lighthouse ran — and only those. According to the Chrome for Developers scoring documentation, the accessibility score “is a weighted average of all accessibility audits,” with weights “based on axe user impact assessments.” Each audit is binary: “a page doesn’t get points for partially passing an accessibility audit.”
Two details in that documentation matter more than the number itself. First, the checks come from axe-core, the same open-source rule engine behind most accessibility scanners — so Lighthouse inherits the same machine-only limits as every other automated tool. Second, the doc lists a separate set of “manual audits” — checks a human must perform — and states plainly that they don’t affect your score.
So the score is real, but narrow. It can verify that an img tag has an alt attribute. It cannot verify that the attribute says “Blue ceramic mug, 12 oz” instead of “image123.” It can measure the contrast of styled text. It cannot tell whether your checkout works without a mouse.
The proof: a perfectly unusable page that scored 100
In May 2019, developer Manuel Matuzović published an experiment called “Building the most inaccessible site possible with a perfect Lighthouse score.” He set out to sabotage a page in every way a real user would feel — while keeping the automated checks green.
His page, among other tricks:
- set
aria-hidden="true"on the body, hiding the entire site from screen readers - disabled all mouse interaction with
pointer-events: none - removed keyboard operability, so Tab gets you nowhere
- dropped text to near-invisibility with
opacity: 0.03— a trick contrast checkers don’t catch - made text color match the background for users in high-contrast mode
Lighthouse’s verdict on this page: 100. Keyboard users, screen-reader users, low-vision users, and mouse users were all locked out, and the score never flinched. Matuzović’s point wasn’t that Lighthouse is broken — he echoes the report’s own caveat that “only a subset of accessibility issues can be automatically detected” and argues automated testing is “just a first step” before manual testing.
That experiment is now the standard citation for a simple rule: the score measures what a machine can check, not what a person can do.
How much do automated checks actually catch?
The best available studies put automated coverage somewhere between “a minority of barriers” and “about half of issue volume” — and both framings are worth understanding.
The UK’s Government Digital Service built a test page seeded with 143 known accessibility failures and ran 10 automated tools against it in 2017. The best result any single tool managed was 41% of the barriers — and only when counting the manual checks that tool prompted a human to do. Google’s developer-tools audit found 17%. Even combining all ten tools, 29% of the barriers were invisible to every single one.
The counterpoint comes from Deque, the company that makes axe. Its 2021 study of roughly 300,000 real audit issues found automated testing identified 57% of issues by volume — higher than the industry’s assumed 20–30% — because the most machine-checkable problems, like contrast and missing alt attributes, also happen to be the most common.
Read together, the honest summary is this: automation catches a lot of the frequent problems and a minority of the kinds of problems. The failures it structurally cannot see — keyboard traps, broken focus order, meaningless alt text, unannounced form errors — are exactly the ones assistive-technology users hit first, as our field guide to manual vs. automated testing breaks down.
Lighthouse vs. a WCAG audit vs. a plaintiff’s tester
Here’s the gap between the test your developer ran and the tests that actually decide whether you have a problem.
| What’s being checked | Lighthouse score | WCAG 2.1 AA audit | Plaintiff-side tester |
|---|---|---|---|
| Who runs it | Automated axe-core checks in Chrome | Human expert with assistive tech, plus automated baseline | A person with a disability, or a tester, on your live site |
| Alt text | Present or missing | Present and accurate and useful | Hears “image123.jpg” on your product page |
| Keyboard access | Not tested end to end | Every control reached and operated by keyboard | Gets trapped in your popup, documents it |
| Screen reader experience | Not tested — markup checks only | Full task flows in NVDA, JAWS, or VoiceOver | Uses one on your site and documents what fails |
| Focus order and visibility | Largely a “manual audit” — unscored | Checked page by page | Experienced directly |
| Forms and error messages | Labels present | Errors announced, understandable, recoverable | Abandons your contact form, screenshots it |
| Output | A number out of 100 | Findings mapped to each WCAG success criterion | A demand letter or federal complaint |
That last row is the one to remember: complaints are written about what a human encountered, task by task — not about a score.
How to beat your own perfect score in five minutes
You don’t have to take Matuzović’s word for it. If your site scores 100, run these five human checks and see how long the halo lasts:
- Unplug your mouse and press Tab. Can you reach and operate every menu, button, and form on the page — with a visible outline showing where you are? Our 10-minute keyboard test walks through this step by step.
- Download NVDA and listen. NVDA is a free screen reader from NV Access. Close your eyes and try to learn what’s on your homepage from audio alone — including what your images say.
- Submit a form wrong on purpose. Leave a required field empty. Does the error get announced by the screen reader, or does the page just silently turn something red?
- Read your link text out of context. A screen-reader user can pull up a list of every link on the page. Does “Learn more” times six tell them anything? (Here’s why “click here” links fail.)
- Zoom the browser to 200%. Text should reflow without content or controls disappearing or overlapping.
Most sites with a perfect score fail at least one of these in the first two minutes. Every one of them is a WCAG 2.1 AA requirement, and none of them moves the Lighthouse number.
Is the Lighthouse score useless, then?
No — it’s genuinely useful as a floor, and dangerous only as a ceiling. A score below 100 is an unambiguous signal that machine-detectable defects are in your code right now; there is no reason to leave those in place. Teams also use the score well as a regression alarm: if a release drops it from 100 to 84, something broke.
What the score can’t do is stand in for a compliance assessment, because it never tested the criteria that matter most to real users. That’s not a Lighthouse quirk — it’s true of every automated scanner, for the structural reasons we cover in why automated scans miss issues. Lighthouse just happens to be the scanner whose number gets quoted to business owners most, because it’s built into the browser their developer already uses.
So when someone tells you “the site scores 100,” the right response isn’t suspicion — it’s one more question: “Great. What did the human testing find?”
What a 100 means for your ADA risk: very little
The legal standard isn’t a score. The Department of Justice’s Title II rule names WCAG 2.1, Level AA as the technical standard for state and local government web content — background in our DOJ web rule explainer — and it’s WCAG success criteria, not scanner scores, that accessibility law is written around. Many of those criteria simply cannot be verified by a machine.
Meanwhile, the testing that triggers lawsuits is human. UsableNet’s year-end tracking counted more than 5,000 digital accessibility lawsuits filed in 2025, with complaints alleging code-level barriers — including barriers that block screen reader users — on live sites. A perfect score never appears in that equation. (The usual caveat applies: this is general information, not legal advice.)
The practical takeaway for a small-business owner is short. Keep the 100 — it’s the cheap part. Then verify the part machines can’t: get a human accessibility audit that tests your site with a keyboard and a screen reader against WCAG 2.1 AA, and fix what it finds in the actual code.
Want to see your automated baseline first — from a company that will tell you exactly where that baseline stops? Start with a free accessibility scan.