Your Accessibility Score Is Fine. Your Site Still Isn’t.

A 100 on Lighthouse’s accessibility audit feels like a finished checklist. It’s closer to a first pass. The audit is automated, and automated testing can only catch what’s mechanically detectable, which is a smaller slice of real accessibility than the clean round number suggests.

What Lighthouse’s accessibility score actually checks

Lighthouse’s accessibility category runs on axe-core, the same open-source engine behind most automated accessibility scanners, checking a subset of rules that can be verified programmatically: whether images have alt attributes, whether form inputs have labels, whether color contrast ratios meet a minimum threshold, whether ARIA attributes are used in valid combinations.

Those checks are genuinely useful, and a low score usually does mean something is wrong. The problem is the reverse assumption, that a high score means the rest is fine. It’s the same trap we’ve written about with Lighthouse score history generally: a single number invites more confidence than the thing being measured actually supports.

What a perfect score doesn’t check

Deque, the company that builds axe-core, studied its own tool’s coverage across more than 13,000 pages and found automated testing identifies about 57% of accessibility issues by volume, a genuinely strong number for what’s mechanically possible. But that figure hides how unevenly it’s distributed. In the same research, keyboard navigation failures had an automated detection rate of roughly 2.5%.

That gap matters because keyboard navigation is one of the most fundamental accessibility requirements there is. Lighthouse can confirm an image has alt text without knowing whether the alt text is “image047.jpg” or an actually useful description. It can confirm a button has an ARIA label without confirming that the tab order through the page makes any sense, that a modal dialog properly traps and releases keyboard focus, or that a dropdown menu is operable without a mouse at all. None of that is a flaw in Lighthouse. It’s the boundary of what a script can check without a person actually trying to use the page.

Two specific patterns account for a lot of the gap. Lighthouse checks contrast on the page as it renders by default, not on :hover or :focus states, so a button that’s perfectly legible at rest can become unreadable the moment someone interacts with it, invisibly to the audit. And a <div> styled and ARIA-labeled to look like a button can pass structural validation, correct role, correct attributes, while having no actual keydown handler for Enter or Space behind it, meaning it’s structurally a button and functionally inert for anyone not using a mouse.

Why this specific gap keeps showing up

The checks automated tools handle well tend to be structural: does an element exist, does an attribute have a valid value, does a contrast ratio clear a number. The checks they handle badly tend to require judgment: is this description meaningful, does this interaction make sense to someone who can’t see the screen, can someone actually complete this task using only a keyboard.

Keyboard navigation sits firmly in the second category. Confirming it works means actually tabbing through a page and checking that focus moves in a sensible order, that nothing gets visually or functionally trapped, and that every interactive element is reachable. That’s a testing process, not a static property of the HTML, which is exactly why it’s the kind of thing a 100 score can miss entirely.

Screen reader compatibility has the same shape. An element can carry every ARIA attribute Lighthouse checks for and still announce itself in a way that makes no sense read aloud, out of order, missing context, or duplicating information the visual layout conveys for free. Automated tools can confirm the attributes exist and are validly formed. Whether the result actually communicates anything useful is a judgment call no script is making.

Does a 100 accessibility score mean my site is compliant?

No. It means the mechanically checkable portion of accessibility is in good shape, which is a real and worthwhile thing to have, but it isn’t the same claim as “an actual person using a screen reader or a keyboard can use this site.” Treat a high score as clearing the floor, not as clearing the bar.

A quick self-audit

Unplug your mouse and tab through your actual conversion funnels, sign-up, checkout, contact forms, not just the homepage. Confirm you can see where focus is at all times, and that modals open and close using only Tab, Enter, and Escape.
Read your alt text out loud. “Image047.jpg” and “screenshot” pass an automated check and communicate nothing.
Check contrast on hover and focus states specifically, not just the resting state. A button can be legible until the moment someone actually interacts with it.
Test any custom-built control, a <div> acting as a button, a custom dropdown, specifically for keyboard operability. These are exactly where automated coverage is weakest.
Don’t treat a 100 as a finish line. Treat it as confirmation that the easy, mechanical part is done.

A score is context, not a verdict. kant.au tracks your Lighthouse accessibility score over time alongside the rest of your site’s health, so a 100 shows up as one data point among many rather than an isolated number that quietly implies more than it checks. Want to see where your score actually stands? Start a free 14-day trial and find out.

Deque: Automated Testing Study Identifies 57% of Digital Accessibility Issues
Deque: The Automated Accessibility Coverage Report