100 in accessibility: the meaningless score
Table of contents
The false positive
You just ran a Lighthouse audit. The accessibility score shows: 100/100. Green. Perfect. You close the tab, satisfied. The site is accessible.
Except it probably isn't.
Lighthouse checks roughly 30 to 40% of real accessibility issues. The remaining 60 to 70% — keyboard navigation, the screen reader experience, alt text relevance, dynamic content behavior — no automated tool detects them. A score of 100 means everything the machine can check is correct. Not that your site is usable by everyone.
This article will show you what Lighthouse sees, what it doesn't, why AI doesn't yet bridge the gap, and how to test what actually matters.
What Lighthouse sees
Lighthouse relies on axe-core, Deque's automated testing engine. It checks things that have a binary answer in the code — present or absent, correct or incorrect:
- Alt text — does every image have an
altattribute? (Not whether the text is relevant.) - Contrast — does the ratio between text and background meet the minimum threshold? (Not whether information relies solely on color.)
- Headings — is the
<h1>→<h2>→<h3>hierarchy respected? (Not whether the headings actually describe the content.) - ARIA attributes — do roles and properties exist and are they valid? (Not whether keyboard behavior matches the announced role.)
- Form labels — does every field have an associated
<label>? (Not whether the label helps understand what's expected.)
The pattern is always the same: Lighthouse checks presence, never relevance. It knows
your image has an alt. It doesn't know if that alt says "image" or actually describes
what the image conveys.
That's useful — it catches obvious omissions, regressions, ARIA syntax errors. But it's a wide-mesh net. Everything that requires judgment slips through.
What Lighthouse doesn't see
The most impactful accessibility problems are those that require context, judgment, or real interaction. No automated tool detects them.
Keyboard navigation
Lighthouse doesn't navigate your page with a keyboard. It doesn't know if a user can reach
every interactive element with Tab, if focus is visible, or if they get
stuck in a trap. It checks that tabindex doesn't have an
absurd value — not that the navigation experience makes sense.
Reading order
The screen reader reads the DOM in source code order, not visual order. An element positioned at the top of the page with CSS but placed at the bottom of the HTML will be read last. Lighthouse doesn't compare visual order to DOM order — that takes a human.
Text relevance
An alt="image" passes the automated test. A "click here" link too. An
aria-label="button" too. Technically, the attribute is there and the value is a non-empty
string. But a screen reader user who hears "link, click here, link, click here, link,
click here" while navigating by links has no idea where each link leads.
Dynamic content
A modal opening, an error message appearing, a cart updating — Lighthouse takes a snapshot
of the page on load. It doesn't test what happens when the user interacts. If your modal
doesn't send focus inside, if your error message has no aria-live, if your cart updates
silently — the score stays at 100.
User journeys
A three-step form can pass every automated test individually. But if moving from step 2 to step 3 doesn't move focus, if the final summary isn't reachable by keyboard, if step 1 errors aren't announced when returning — the experience is broken. Lighthouse tests pages, not journeys.
AI doesn't replace the audit
Faced with the limits of automated tools, two promises are circulating. The first is dangerous. The second is encouraging. Neither eliminates the need for an expert.
Overlays: the false remedy
Companies sell overlays — a line of JavaScript that promises to "make your site accessible" automatically. In 2024, 25% of accessibility lawsuits in the United States targeted sites that already had an overlay installed. Not the solution, then, but a lawsuit magnet. accessiBe, the most well-known, was fined $1 million by the FTC for misrepresenting its tool's capabilities. UserWay, its competitor, faces a class action lawsuit after a client was sued despite the overlay being in place.
The National Federation of the Blind — the largest organization of blind people in the United States — publicly stated that accessiBe "actively harms the ability of screen reader users to navigate websites efficiently".
These tools add a layer of JavaScript that modifies the DOM after load — exactly the kind of intervention that degrades performance and destabilizes the accessibility tree, as you saw in the previous article.
AI as co-pilot, not pilot
The approach that works is Deque's with axe: AI doesn't replace the human, it guides them. Their Intelligent Guided Tests combine automated checks with questions the AI asks a human tester — "does this alt text actually describe the image?", "does focus move correctly after this action?". Result: 80% coverage compared to 57% for pure automation as measured by the same Deque report. But the 80% relies on a human answering the questions — not an AI deciding alone.
This is a field I'm working in — building tools capable of reaching or exceeding Deque's 80% coverage, but without requiring a human at the controls for every test. The goal: an AI that can judge alt text relevance, keyboard journey consistency, heading hierarchy logic — decisions that today require an expert on every run. But even if that goal is reached, the remaining 20% will stay human. Edge cases, specific business contexts, real user journeys with real disabled people — no AI will replace that.
Testing for real
Lighthouse is the first floor. Here are the next ones.
Complementary tools
axe DevTools — Deque's free browser extension, using the same engine as Lighthouse but with more rules and more detailed results. It's the best starting point after Lighthouse.
WAVE — WebAIM's tool that displays problems directly on the page, visually. Particularly useful for spotting structure errors (headings, landmarks) and insufficient contrast at a glance.
Accessibility Insights for Web — Microsoft's extension that visualizes the keyboard path directly on the page (Tab Stops), checks landmarks and offers guided tests for the WCAG criteria that can't be automated. I talk about it in Put down the mouse.
The keyboard test
Put down your mouse and navigate your site with Tab. We detailed this in Put down the mouse — it's the simplest and most revealing test. If you can't reach an element, activate it, or escape from it, your site has a problem no automated tool will detect.
The screen reader test
Activate VoiceOver (Cmd + F5) or install NVDA (free) and navigate your page. We detailed the shortcuts and method in Screen readers don't read like you. The accessibility tree in developer tools is useful for a first diagnosis — but remember it's an X-ray, not a clinical exam.
User testing
The top floor — and the richest in insights. Have your product's critical journeys tested by people outside the team, in varied conditions: different browser, mobile device, screen reader activated, keyboard-only navigation. You don't need to have a disability to detect the majority of problems — an expert who knows VoiceOver and NVDA, or simply someone who puts down their mouse and navigates by keyboard, will find barriers no automated tool will see.
And if you want to go even further, including people with disabilities in your tests brings a dimension that even the most skilled expert can't simulate — navigation habits, workaround strategies, expectations that only daily experience builds.
The real 100%
You can get 100/100 on Lighthouse and exclude millions of people. You can pass every WCAG criterion and still have a site that's difficult to use for a person with a disability.
Standards are the bare minimum — the legal floor, the baseline below which you're in violation. But compliance isn't accessibility. Compliance says your code follows the rules. Accessibility says your product works for everyone. The difference is measured with humans, not with scores.
Sources
- David Mello — Playwright accessibility testing: what axe and Lighthouse miss
- DEV Community — Your accessibility score is lying to you
- Google — Lighthouse accessibility scoring
- Lainey Feingold — FTC fines accessiBe one million dollars
- Lainey Feingold — UserWay overlay lawsuit
- Adrian Roselli — FTC catches up to accessiBe
- Accessibility.Works — Overlay widgets attract lawsuits
- Deque — Advancing AI for axe
- Deque — Automated accessibility coverage report
- axe DevTools — Browser extension
- WAVE — Web accessibility evaluation tool
- NVDA — Free screen reader download