Your web designer sends a screenshot: four green circles, and the one marked Accessibility says 100. Or the opposite happens, and a marketing agency points at your 72 and says the site has a serious accessibility problem. Both conversations lean on the same number, and both can mislead.
The Lighthouse accessibility score is useful. It is also narrow. This post explains what Google Lighthouse actually checks for accessibility, how the score is worked out, why a perfect score can sit on top of real barriers, and how to use the report so it helps instead of reassuring you falsely.
Where the score comes from
Lighthouse is an open source auditing tool from Google. You can run it in three common places:
- In Chrome, open developer tools (F12 or right-click and Inspect) and choose the Lighthouse panel.
- On PageSpeed Insights, which runs Lighthouse for you and shows the accessibility score alongside performance.
- From the command line or in automated build checks, which developers use.
If you are unsure how the Chrome panel and PageSpeed Insights relate, our comparison of Lighthouse and PageSpeed Insights explains the difference. For accessibility, they run the same set of checks; this post ignores performance entirely.
What the Lighthouse accessibility score measures
The accessibility checks in Lighthouse come from axe-core, the open source engine from Deque that also powers the axe DevTools extension. Lighthouse runs a selection of those rules and turns the results into a number from 0 to 100.
How that number is built matters:
- Each audit is pass or fail. If one image out of fifty lacks alt text, the whole “image elements have alt attributes” audit fails. If fifty out of fifty lack it, the audit also just fails. The score does not grow worse with more instances.
- Audits are weighted. Some count for more than others, roughly in line with how badly they affect users. Missing button names or form labels cost more than a minor structural issue.
- Audits that do not apply are left out. A page with no video or no tables is not scored on those audits at all. A very simple page has fewer chances to fail.
- Manual checks are listed but not scored. Under a heading for items to check manually, Lighthouse lists things like logical tab order, visible focus, and whether custom controls have proper roles. These are some of the most important checks on any page, and they add nothing to the score.
So the score answers one question: of the automated checks that apply to this page, in the state it loaded, how many passed, weighted by importance? That is a fair question. It is not the same as “can people with disabilities use this page?”
Why a perfect 100 can hide real barriers
Here is a page that can score 100 and still lock people out. It is a composite, but every part of it is common on WordPress sites.
- The main menu opens dropdowns on mouse hover only. Keyboard users cannot reach the service pages. Lighthouse does not use the keyboard, so it never notices.
- The theme removes the focus outline with CSS. Tab through the page and you cannot see where you are. This sits in the unscored manual list.
- Every image has alt text, so the alt audit passes. The alt text says “image”, “banner” and “IMG_2231”. Lighthouse checks that alt exists, not that it means anything.
- A newsletter popup appears after five seconds. Focus stays behind it, and Escape does nothing. The popup was not open when Lighthouse loaded the page, so it was never tested.
- The contact form shows errors in red text only, with no message read out to a screen reader. Lighthouse does not submit forms.
- The hero video has automatic captions full of mistakes. Lighthouse cannot judge caption quality.
None of these are rare. A score of 100 means the page passed every automated check Lighthouse ran. It is a good sign about code basics, nothing more. The post on what automated tools can judge and what needs a person goes into why.
The opposite also holds. A score in the 70s does not automatically mean a site is unusable. One failed heavyweight audit, such as unnamed icon buttons repeated across a template, can pull the score down sharply while being a single fix in the theme.
Reading the report, not just the number
Under the score, Lighthouse groups failed audits by theme: names and labels, contrast, navigation, ARIA, tables and lists, best practices and so on. Open each failed audit and you see:
- A short description and a link to more detail on the rule.
- The failing elements, with a snippet of their HTML and a way to locate them in the page.
That list of elements is the useful part. Count how many are in the header, footer or sidebar. Those come from templates and will fail on every page. Fix them once and many pages improve together.
Then read the manual checks list. Treat it as a to-do list for a person with a keyboard and, later, a screen reader. Our accessibility testing guide covers those human passes in order.
Finally, glance at the passed audits. They tell you what the page already does right, which saves you re-checking it by hand.
Using Lighthouse well
A few habits turn Lighthouse from a vanity number into a working tool.
Test the right pages
Do not run it only on the home page. Test one page of each template, every page with a form, and the pages visitors use most. A home page with a 100 tells you very little about the booking page.
Test the right state
A standard Lighthouse run tests the page as it loads. Menus are closed, popups have not opened, errors have not appeared. Recent versions of the Chrome panel offer a snapshot mode that checks the page in its current state, so you can open the menu or trigger a form error first. If your version does not have it, use an extension like axe or WAVE for those states.
Watch the trend, not the number
Run Lighthouse on the same set of pages after each theme or plugin update. A drop from 98 to 85 after an update is a clear signal that something changed, such as a new plugin adding unlabeled buttons. That is where the score is at its most useful: as an early warning, not a grade.
Do not chase 100 at the expense of real fixes
It is possible to game the score. Adding aria-label=”button” to every unnamed button passes the audit and helps nobody. So does stuffing alt attributes with the page title. If a developer is working toward a number, ask what each fix changed for an actual user.
Check focus by hand every time
Visible focus often disappears after a theme update, and it sits in Lighthouse’s unscored list. Press Tab a dozen times on any page you scan. If you lose track of where you are, read up on visible focus and the 2.2 focus rules.
Lighthouse score versus WCAG conformance
People sometimes treat the score as a WCAG grade. It is not. WCAG 2.2 Level AA has dozens of success criteria, and many of them, such as 2.1.1 Keyboard, 2.4.3 Focus Order, 1.2.2 Captions and 3.3.1 Error Identification, cannot be fully judged by an automated check. Lighthouse covers a subset of what can be automated, on one page, in one state.
So a sentence like “we scored 100 so we meet WCAG” is not accurate. A better sentence is “Lighthouse found no automated failures on these pages; we also tested by keyboard and screen reader and fixed what we found.” That second sentence is also much more useful if you ever need to show what work was done. Questions about legal obligations are for a lawyer, not for a score.
Frequently asked questions
What is a good Lighthouse accessibility score?
Lighthouse shows scores of 90 and above in green, and most well-built pages land there. But a high score only means the page passed the automated checks that applied to it. Treat 90 or more as a sign the code basics are in place, then test by keyboard and with a screen reader to find what the score cannot see.
Why does my Lighthouse accessibility score change between runs?
Usually because the page itself changed: a different hero image, a cookie banner that sometimes loads, a rotating slider, or a plugin update. Accessibility scores are much more stable than performance scores, so a large swing is worth investigating rather than ignoring.
Does Google use the Lighthouse accessibility score for rankings?
Google has not said the Lighthouse accessibility score is a ranking factor. Clear headings, descriptive links and alt text help search engines as well as people, yet the score itself is only a diagnostic tool. Fix accessibility issues for the people using your site, not in the hope of a ranking change.
Should I run Lighthouse with mobile or desktop settings?
Both, if you can. The accessibility audits are the same, but many themes serve different markup at phone width, such as a hamburger toggle in place of the full menu or a hidden sidebar. A mobile run checks that version. PageSpeed Insights shows mobile and desktop results on separate tabs, so it is an easy way to compare them.
The score is a starting point. If you want someone to work through the unscored checks with a keyboard and screen reader, that is the job of our manual accessibility testing, and our overview of website accessibility services shows how it connects to fixing and monitoring.
Next in this series: Test a Website With NVDA: A Beginner’s Guide
