Lighthouse 100 Does Not Prove Accessibility—Here’s What to Test Next

A Lighthouse accessibility score of 100 can be accurate and still describe a website that blocks a real user journey.

That is not a contradiction.

Lighthouse answers a bounded question: did the automated audits included in this run detect failures in the page state they inspected? It does not answer a broader one: can people with different disabilities complete the important tasks this product supports?

The distinction matters because teams often turn a diagnostic signal into a conclusion it was never designed to support.

A score of 100 means that the included automated checks passed. It does not mean that accessibility has been proved.

What the score actually represents

Chrome's scoring documentation describes the accessibility score as a weighted average of its accessibility audits. Those audits are pass or fail, and their weights are based on axe impact assessments.

Lighthouse is useful for catching repeatable defects such as:

• controls without accessible names;
• form elements without programmatic labels;
• some color-contrast failures;
• invalid or conflicting ARIA attributes;
• missing document language;
• structural problems covered by its rules.

These are real defects. Fixing them matters.

But manual audits and other checks that do not affect the score are outside that number. Chrome made this boundary especially visible in Lighthouse 11: when automated accessibility audits pass, the interface expands the manual-audit section to emphasize that 100 does not guarantee an accessible page.

The score is not lying. The interpretation may be overreaching.

A perfect initial state can hide a broken interaction

Automated tools inspect observable page states. A user creates new states by opening a menu, validating a form, expanding a disclosure, changing a filter, or launching a modal.

Consider a custom dialog that has plausible semantics:

<button id="open-settings" type="button">
  Open account settings
</button>

<div
  id="settings-dialog"
  role="dialog"
  aria-modal="true"
  aria-labelledby="settings-title"
  hidden
>
  <h2 id="settings-title">Account settings</h2>
  <button type="button">Save changes</button>
  <button type="button">Cancel</button>
</div>

The names, roles, and relationships look reasonable. The failure may live in the behavior:

• focus stays on the opener behind the dialog;
• Tab escapes into the obscured page;
• Shift+Tab follows a different broken path;
• Escape does nothing;
• closing the dialog loses focus or sends it to the document body.

A static score cannot reconstruct the whole interaction from the markup.

The WAI-ARIA Authoring Practices dialog pattern expects focus to move inside a modal dialog, remain within its tab sequence, respond to Escape, and normally return to the invoking element when the dialog closes. Those behaviors require interaction testing.

Native HTML can reduce the amount of custom behavior a team must reproduce:

<button id="open-settings" type="button">
  Open account settings
</button>

<dialog id="settings-dialog" aria-labelledby="settings-title">
  <h2 id="settings-title">Account settings</h2>
  <button id="save-settings" type="button" autofocus>
    Save changes
  </button>
  <button id="close-settings" type="button">Cancel</button>
</dialog>

<script>
  const opener = document.querySelector("#open-settings");
  const dialog = document.querySelector("#settings-dialog");
  const closeButton = document.querySelector("#close-settings");

  opener.addEventListener("click", () => dialog.showModal());
  closeButton.addEventListener("click", () => dialog.close());
  dialog.addEventListener("close", () => opener.focus());
</script>

This is still not a conformance certificate. Initial focus depends on the dialog's purpose and content, labels still need review, and the complete task still needs to be tested. The improvement is that the browser now provides more of the interaction model instead of the application recreating it from scratch.

Run this 15-minute test after Lighthouse reaches 100

This is a triage method, not a WCAG audit. Its purpose is to expose pages that need deeper investigation.

Time	Test	Evidence to retain
2 min	Record the URL, viewport, browser, date, Lighthouse version, and tested state	A reproducible starting point
3 min	Navigate forward and backward using only Tab, Shift+Tab, Enter, and Space	Visible focus, logical order, no unreachable controls
3 min	Open and close menus, dialogs, disclosures, and custom controls	Initial focus, containment, Escape, and focus restoration
3 min	Submit one important form with missing or invalid data	Persistent labels, understandable errors, announced changes, successful correction
2 min	Test reflow and zoom on a priority viewport	No lost content, hidden action, or two-dimensional scrolling where it should not occur
2 min	Inspect the accessibility tree or replay one short journey with a screen reader	Roles, names, states, landmarks, and announcements that match the interface

Passing this test does not prove accessibility either. It gives you better evidence than the score alone and helps decide where a full evaluation should begin.

Separate four layers of evidence

A credible report should not merge every signal into a single percentage.

Layer	Question	Useful evidence	What it does not prove
Automated rules	Which defined, machine-testable failures were detected?	Lighthouse, axe, HTML validation, CI results	Meaning, usability, or full conformance
Interaction	Can the interface be operated through its important states?	Keyboard paths, focus logs, error scenarios, component states	That every template and assistive technology was covered
Assistive technology	Is the experience exposed coherently to the tested technology?	Screen-reader journey, accessibility-tree inspection	Universal usability across people and configurations
Conformance evaluation	Does the declared scope satisfy the applicable requirements?	Representative scope, criteria, tools, human evaluation, results, limitations	That every person will find the product easy to use

The W3C evaluation overview is explicit that no tool alone can determine whether a site meets accessibility standards. Its WCAG conformance guidance also describes testing as a combination of automated testing and human evaluation, applied to complete pages and processes rather than isolated green checks.

Put the right failures in CI

The limit of automation is not a reason to automate less. It is a reason to automate precisely.

Good candidates for continuous checks include:

• accessible-name regressions;
• missing form labels;
• invalid ARIA relationships;
• page-language and landmark invariants;
• contrast failures that a rule can compute;
• representative rendered states in Storybook or browser tests;
• keyboard contracts for high-risk components;
• focus restoration after dialogs close.

The pipeline should detect a defined regression and retain the evidence. It should not silently translate “the configured checks passed” into “the product is accessible.”

A useful release result might therefore say:

Automated checks: PASS
Keyboard journey: FAIL — focus escapes the account dialog
Screen-reader journey: NOT TESTED
Conformance claim: NONE
Decision: NO-GO until the blocking journey is corrected and replayed

That report is less reassuring than a single 100. It is also more actionable and more honest.

The decision after 100

Keep Lighthouse in the toolbox. Aim for 100 when the included rules apply. Fix every real issue it exposes.

Then change the question.

Do not ask:

Did the page get a perfect accessibility score?

Ask:

Which important journey, state, or meaning have we not tested yet?

That question turns a dashboard result into an engineering process.

Which accessibility failure have you found in a real journey after automated tools had already passed the page?

---

AI-assistance disclosure: this DEV edition was adapted from my original Edikka article with AI assistance for structure and English editing. The analysis, examples, verification, evidence boundaries, and publication decision remain my responsibility.