Originally published at AccessGuard.
Sooner or later a client, a manager or a colleague opens Chrome DevTools, runs Lighthouse, sees a green 100 in the Accessibility circle, and asks why anyone needs an audit. It is a fair question, and it deserves a better answer than "trust me". This guide explains what the Lighthouse accessibility score measures, what it cannot see, and gives you words to use in that conversation.
Short version: a 100 means the page passed every automated test Lighthouse ran on it. That is worth having. It does not mean people with disabilities can use the page, and the Lighthouse report says so itself, in the line directly under the score: "Automatic detection can only detect a subset of issues and does not guarantee the accessibility of your web app, so manual testing is also encouraged."
What the Lighthouse accessibility score actually measures
Lighthouse runs a set of automated audits against one URL. In Google's words, you "give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report" (Lighthouse overview). Three details in the Lighthouse accessibility scoring documentation matter for how you read the number:
- It is a weighted average. "The Lighthouse Accessibility score is a weighted average of all accessibility audits. Weighting is based on axe user impact assessments." The audits come from axe-core, Deque's open source testing engine, and each carries a weight of 10, 7 or 3.
- Each audit is pass or fail. A page with one unnamed button out of twenty scores the same zero on that audit as a page where all twenty are unnamed.
- Manual checks do not count. "Manual audits and low-impact / best-practices audits aren't included in the table because they don't affect your score."
Two more things follow from how the tool runs. It tests the page as it looks when it finishes loading, in the viewport you chose, so a menu that is closed, a modal that has not opened and an error message that only appears after submitting a form are never tested. And it tests one page, not the checkout, the account area or the other templates on the site.
The checks Google lists as manual
This is the most useful fact for the client conversation, because it comes from Google rather than from someone selling an audit. Below the score, every Lighthouse report has a section called "Additional items to manually check" with ten items, each described in the Lighthouse accessibility audits docs:
- Custom controls have ARIA roles
- Custom controls have associated labels
- User focus is not accidentally trapped in a region
- Interactive controls are keyboard focusable
- Interactive elements indicate their purpose and state
- The page has a logical tab order
- The user's focus is directed to new content added to the page
- Offscreen content is hidden from assistive technology
- HTML5 landmark elements are used to improve navigation
- Visual order on the page follows DOM order
None of these affect the score. A page can fail every one and still show 100. Most of them are about keyboard use, which is exactly where people who cannot use a mouse get stuck.
Four things a 100 cannot tell you
1. Whether the alt text is right
The scored audit is "Image elements have [alt] attributes". It checks that the attribute exists. It cannot tell whether the text describes the image. Both of these pass:
<!-- Broken: passes the audit, tells a screen reader user nothing -->
<img src="team.jpg" alt="IMG_2041.jpg">
<!-- Fixed: describes what the image shows in this context -->
<img src="team.jpg" alt="Our four support staff at the Leeds office">Whether a text alternative "serves the equivalent purpose" is the actual requirement in WCAG 1.1.1 Non-text Content, and that takes a person. An alt text checker finds the missing ones fast; our guide on how to write alt text covers the rest.
2. Whether keyboard focus gets trapped
"User focus is not accidentally trapped in a region" is on Google's manual list. Its own documentation tells you how to test it: "navigate to and from all page elements using only the keyboard", with Tab going forward and Shift + Tab going back (Lighthouse: trapped user focus). A date picker or chat widget that swallows focus fails 2.1.2 No Keyboard Trap while the score stays at 100. Our guide on how to test keyboard accessibility by hand walks through it, and the keyboard and focus checker flags the markup causes it can see.
3. Whether the reading order makes sense
CSS grid, flexbox order and absolute positioning can put things on screen in a different order from the HTML. A screen reader and the Tab key follow the HTML. If the "Add to cart" button comes before the product name in the source, it passes every automated audit and still confuses people. That is 1.3.2 Meaningful Sequence and 2.4.3 Focus Order, and "Visual order on the page follows DOM order" sits on the manual list.
4. Whether a control's name matches what people see
The scored audit "Buttons have an accessible name" passes if there is any name at all. It does not compare that name with the visible label:
<!-- Broken: has a name, but not the one on screen -->
<button aria-label="Submit form">Get my quote</button>
<!-- Fixed: the name contains the visible words -->
<button>Get my quote</button>A voice control user who says "click Get my quote" gets nothing, because the button is called "Submit form". That fails 2.5.3 Label in Name.
Checks that need a person, by WCAG criterion
This is not a complete list, but it covers what most reviews catch that automated scores miss.
WCAG criterionWhat a person checks
1.1.1 Non-text ContentAlt text describes the image; decorative images are empty
1.3.2 Meaningful SequenceReading order matches the visual order
2.1.1 Keyboard, 2.1.2 No Keyboard TrapEvery control works with Tab, Enter, Space and Escape, and focus can always leave
2.4.3 Focus OrderTab moves through the page in a sensible order, including into and out of modals
2.4.6 Headings and LabelsHeadings and labels describe their content, not just exist
2.5.3 Label in NameThe accessible name contains the visible label
3.3.1 Error IdentificationErrors after submitting are described in text and announced
4.1.3 Status MessagesMessages like "Added to cart" reach screen readers without moving focus
Every criterion links from the WCAG 2.2 specification to its Understanding document, which says what passing looks like.
What to say when someone points at the score
Keep it calm and give them Google's own words. The best ones are already on their screen, under the score: "Automatic detection can only detect a subset of issues and does not guarantee the accessibility of your web app, so manual testing is also encouraged." Something like:
"The 100 is real and it is good news: the page passes every automated test Lighthouse runs. The report itself says automatic detection only finds a subset of issues. It also lists ten things to check by hand, like keyboard traps and tab order, and Google's documentation says those don't affect the score. So a 100 tells us the basics are in place on this one page as it loaded. The audit is the part a tool can't do: someone using the site with a keyboard and a screen reader, across the templates that matter, like checkout and the contact form."
If they want evidence that tools miss things, the UK Government Digital Service built a page with 143 deliberate barriers and ran 10 automated tools against it in 2017. 42 of the barriers were missed by every tool. Tools have improved since, so treat it as a demonstration of the gap rather than a current measurement. Avoid quoting a single percentage of issues that automation catches unless you can name the study behind it.
Two things not to say: that an audit will make the site "compliant", or that the score is worthless. Neither is true, and the second one undermines the tools you will use yourself.
Where an automated scan still earns its keep
Automated checks are fast, repeatable and good at the problems they can decide: missing alt attributes, unlabelled fields, low contrast, invalid ARIA, missing page language. Run them first so the manual review is spent on judgement, not on counting empty alt attributes. Rerun them after every release so fixed problems stay fixed.
The limits of Lighthouse are one page at a time, in one state. A free AccessGuard scan runs axe-core plus its own checks in a real browser and reports failures against WCAG 2.2 AA, including some that axe alone does not catch (see the six checks most scanners miss). It is still an automated scan: it finds many problems, and it cannot confirm that a site conforms to WCAG. No automated tool can.
Your next steps
- Run Lighthouse or a free scan and fix every automated failure first.
- Open the "Additional items to manually check" section of the Lighthouse report and work through it.
- Tab through each key template: home, a content page, search, forms, checkout.
- Read the alt text on important images out loud: does it say what the image shows?
- Compare visible button labels with their accessible names in DevTools.
- Write down what you checked by hand, so the report shows the work behind the result, not just a score.
Top comments (0)