A Lighthouse accessibility score of 100 tells you that a machine found no problems it knows how to look for. That is a much smaller claim than "this site is accessible," and the gap between the two is where most real barriers live.
Start with the useful part. The score is a fast, free, repeatable floor. If you're at 62, you have concrete, mechanical problems that are hurting real users right now and you should fix them this week. But treat 100 as a finish line and you'll ship a site that a keyboard user cannot get through.
Where the score comes from
We pull it from the Google PageSpeed Insights API, which runs Lighthouse's accessibility category. Under that category sits axe-core, Deque's open-source rules engine, running a few dozen automated checks mapped to WCAG success criteria.
Our report grades it in three bands:
| Score | Status | What it means |
|---|---|---|
| 90 to 100 | Pass | No blocking issues the automated pass can detect |
| 50 to 89 | Improve | Real, fixable failures present |
| Below 50 | Fail | Serious mechanical barriers across the page |
We test the mobile rendering by default, and we list up to eight failing audits ordered by Lighthouse's own weighting, so the heaviest problems surface first rather than alphabetically.
One deliberate choice in how we read the results: Lighthouse marks some audits manual, notApplicable, or informative. Those are not pass/fail, and we exclude them. We will never report a "failure" you cannot act on. The trade-off is that the manual audits are exactly the ones covering the criteria automation can't judge, so their absence from your failure list is not a clean bill of health.
If the check shows as skipped in your report, that means no PageSpeed Insights API key is configured. The key is free from Google.
What the automated pass genuinely catches
These are the mechanical, machine-decidable failures, and they are worth taking seriously because each one maps to a person who cannot use your page.
Missing text alternatives (WCAG 1.1.1). An <img> with no alt attribute is a blank to a screen reader. If it's a product photo, the product has no name. If it's your logo linking home, the link has no destination anyone can hear.
Insufficient color contrast (WCAG 1.4.3). Normal text needs a 4.5:1 ratio against its background. Large text, meaning 18pt or 14pt bold and up, needs 3:1. Light gray placeholder text on white is the single most common failure I see, and it fails for everyone in bright sunlight, not only for users with low vision.
Unlabeled form controls (WCAG 3.3.2). An input with a placeholder but no <label> announces as "edit text, blank." On a checkout form that's a lost sale you'll never see in your analytics.
Broken ARIA (WCAG 4.1.2). Invalid roles, aria-labelledby pointing at an ID that doesn't exist, required child roles missing. Bad ARIA is reliably worse than no ARIA, because it overrides the correct native semantics with a lie.
Links and buttons with no accessible name. An icon-only button with no text and no aria-label announces as "button." Screen reader users get a page of unnamed buttons and no way to guess.
What it structurally cannot catch
This is the part that matters for anyone treating the score as coverage.
Automated tools evaluate what can be decided from the DOM. A large share of WCAG success criteria require human judgment about meaning, sequence, or intent, and no rules engine resolves those.
- Is the alt text right?
alt="image"passes the automated check. It has an alt attribute. It communicates nothing. - Does the keyboard path work? Whether every interactive element is reachable and operable by keyboard (WCAG 2.1.1), in a sensible order, without traps, is something you find by putting your mouse away and pressing Tab.
- Is focus visible? (WCAG 2.4.7) A
:focus { outline: none }in a stylesheet with no replacement leaves keyboard users with no idea where they are. Automation sees valid CSS. - Does the heading structure describe the content? Heading order is partly checkable. Whether the headings actually reflect the page's meaning is not.
- Do error messages explain the fix? A red border is not an error message.
- Does a custom widget behave like the thing it claims to be? A
<div role="tablist">can have flawless ARIA and still fail every arrow-key expectation a screen reader user has.
Deque's own documentation is direct that axe-core catches a portion of accessibility issues and is designed to complement manual testing rather than replace it. Take the tool's authors at their word here.
Where to start when the score is low
Fix in this order. It's roughly the ratio of user impact to effort.
- Contrast. Usually a handful of CSS variables. Highest ratio of users helped to hours spent, and it also improves readability for everyone.
- Form labels. Small, mechanical, and directly tied to conversion on any page that takes input.
- Image alt text. Mechanical to add, but write real descriptions. Decorative images take
alt=""(empty, not missing) so screen readers skip them cleanly. - Accessible names on controls. Icon buttons, close buttons, hamburger menus.
- Remove ARIA you don't need. Native
<button>and<nav>beatrole="button"androle="navigation"every time. Deleting bad ARIA often raises the score and the actual experience together.
Then stop looking at the score and do the twenty-minute manual pass: unplug your mouse, Tab through the whole page, and try to complete your primary conversion. You will find things Lighthouse never mentioned.
A note on legal exposure
Web accessibility carries legal obligations in a number of jurisdictions, and the specifics vary enough that I won't summarize them here. What I will say plainly is this: do not treat an automated score as a defense.
A Lighthouse 100 demonstrates that one automated tool found no failures in its own ruleset on the pages it tested. It is not a conformance claim, and it is not an audit against WCAG 2.1 AA. Those are different artifacts produced by different work.
If conformance genuinely matters for your organization, the automated score is triage and a manual audit against the specific success criteria is the actual deliverable. Get advice from someone qualified for the jurisdictions you operate in before publishing any conformance statement.
FAQ
We scored 100. Are we accessible?
You have no failures that this automated ruleset can detect on the tested page. That's genuinely good and worth keeping. It says nothing about keyboard operability, focus management, alt text quality, or whether your custom components behave correctly, because none of those are machine-decidable.
Why does our score change between runs?
Lighthouse tests the rendered page. If content is injected by JavaScript, loaded from a third party, or varies by A/B test, different runs can see different DOMs. Cookie banners and consent overlays are a frequent cause, since they sometimes render over the page and sometimes don't.
Should we test mobile or desktop?
We default to mobile because that's how most people arrive and because narrow viewports expose contrast and touch-target problems that desktop hides. Test both if you can. They can differ more than you'd expect.
Does accessibility help SEO?
Some of it overlaps directly. Alt text, semantic headings, descriptive link names, and a valid lang attribute all serve both screen readers and crawlers. But the overlap is partial, and framing accessibility as an SEO tactic tends to produce sites that satisfy neither. Do it because people can't use your site otherwise.
Key Takeaways
- A Lighthouse accessibility score comes from axe-core running a few dozen automated checks through the PageSpeed Insights API, and it reflects only machine-decidable WCAG failures.
- A score of 100 means no detected failures in that ruleset, not WCAG conformance, and it cannot assess keyboard operability, focus visibility, alt text quality, or custom widget behavior.
- The highest-impact automated failures are color contrast below 4.5:1 for normal text (WCAG 1.4.3), missing text alternatives (1.1.1), unlabeled form controls (3.3.2), and invalid ARIA (4.1.2).
- Invalid ARIA is worse than no ARIA because it overrides correct native semantics, so removing unnecessary roles often improves both the score and the real experience.
- Automated scores are triage, not a conformance claim or a legal defense; a manual keyboard pass finds barriers no rules engine reports.
Want your accessibility score with the failing WCAG audits named in plain language? Run a free audit: we report the score and the heaviest failures, weighted so you know what to fix first. More in the technical explainers.