A checkout flow scores a perfect 100 on Lighthouse's accessibility audit. The team celebrates, ships with confidence, moves on to the next sprint. A real keyboard user, weeks later, gets stuck at the payment step, unable to escape a custom date picker that swallowed their focus the moment it opened, with no way to close it, tab past it, or complete the purchase. Both facts are true at once, and neither one is a mistake. The 100 score is accurate to what Lighthouse actually checked. The keyboard trap is real. The gap between them is not a testing failure, it is a structural limit in what automated testing was ever built to see.
The Stat: Automated accessibility scanners, including the engine behind Lighthouse's accessibility audit, can only reliably detect roughly 30-50% of WCAG success criteria; the rest, including keyboard trap, focus order, and meaningful sequence, require a real human test. (Source: Deque Systems / axe-core, published automated-coverage research)
What Lighthouse's Accessibility Audit Actually Checks
Lighthouse's accessibility category runs a set of automated rules built on the axe-core engine, the same engine behind many popular accessibility testing tools. These rules check things a script can reliably verify by inspecting the DOM and computed styles: whether images have alt attributes, whether form inputs have associated labels, whether color contrast ratios meet the minimum threshold, whether ARIA attributes are used in valid combinations, whether heading levels skip unexpectedly. Each of these is a real, valuable check, and a site failing them has real, fixable problems.
None of these checks require simulating an actual user interacting with the page over time. That is the specific boundary worth understanding clearly: Lighthouse's accessibility audit inspects the page's structure at a moment in time. It does not open a custom date picker, press Tab inside it, and confirm focus can escape. It does not verify that a modal traps focus correctly while open and releases it correctly when closed. It cannot, by design, simulate the sequence of interactions that a keyboard trap actually depends on to manifest.
The Specific Failure: A Date Picker That Swallows Focus
Here is precisely how a 100-scoring checkout flow traps a keyboard user in practice. A custom date picker widget, built for a billing-address or card-expiration field, opens correctly, its individual elements are all well-formed HTML with reasonable ARIA attributes, which is exactly what Lighthouse checks and exactly why it passes. The bug lives entirely in the interaction sequence: once open, Tab cycles through the calendar's day cells correctly, but Escape does nothing, and there is no keyboard path back to the field that opened it or the buttons that follow it in the page. A mouse user closes it by clicking anywhere else on the page, an action with no keyboard equivalent built in. The widget is not missing any attribute Lighthouse checks for. It is missing behavior no static analysis of the DOM can verify one way or the other.
Why This Specific Gap Matters More Than It Sounds
This is not an argument that Lighthouse or any automated tool is not worth running. It is worth running, consistently, because it reliably catches the roughly 30-50% of issues that are structurally detectable, and catching that share automatically, on every build, for free, is real, ongoing value no team should give up. The argument is narrower and more actionable: a 100 score is evidence the detectable half of the problem space is clean, not evidence the whole problem space is clean, and treating the two as equivalent is exactly what let this specific checkout bug ship undetected.
Other Interaction Sequences Automated Tools Routinely Miss the Same Way
The date-picker keyboard trap described above is one specific, concrete example of a much broader category: any bug that depends on a sequence of interactions over time, rather than a single moment's DOM state, sits outside what static automated analysis can verify. A multi-step form wizard that fails to move focus to the next step's heading when a user advances, a toast notification that appears and disappears before a screen reader has time to announce it, a modal that opens correctly but does not return focus to the triggering button when closed, all three pass a static DOM scan cleanly for the same structural reason the date picker did: every individual element involved is well-formed, and the failure lives entirely in the transition between states, not in any one state itself. Recognizing this category, sequence-dependent failures versus static structural ones, is the fastest way to build an intuition for what a clean automated score can and cannot promise, well before running into a specific instance of it.
Why This Is Not an Argument for Abandoning Lighthouse
It would be easy to overcorrect from this specific example into skipping automated testing altogether, and that would trade one real problem for a worse one. The roughly 30-50% of issues automated tools do reliably catch, missing alt text, insufficient contrast, malformed ARIA, unlabeled form fields, are real, common, and completely worth catching automatically on every single build without requiring a human to manually re-check them each time. The correct posture is additive, not substitutive: keep automated testing running continuously as the fast, cheap first layer, and treat a clean score as clearing that layer specifically, not as clearing the harder, sequence-dependent layer that only a real manual walkthrough can verify.
What Actually Catches This
The fix is not a better automated tool, because no automated tool, today, reliably simulates the exact sequence, open the widget, try every keyboard escape path, confirm focus lands somewhere sensible, that this bug depends on. The fix is the manual discipline covered in our one screen reader test every developer skips: unplug the mouse, and complete the actual checkout flow using only a keyboard, specifically testing every custom widget's open and close behavior, not just whether it opens correctly. Our five-minute keyboard test is a faster, lighter version of the same discipline, useful as a quick first pass on any flow that has not been manually tested since its last redesign.
We covered the broader version of this argument, why a clean automated score does not guarantee a usable real experience, in our earlier piece on why your perfect Lighthouse score still fails real users. This piece is meant to make that argument concrete with one specific, reproducible interaction bug rather than restate it in general terms.
If your checkout flow has a perfect Lighthouse score and has never been manually tested with a keyboard specifically on its custom widgets, that gap is worth closing before a real customer finds it the way our test flow did. Our free accessibility audit includes real manual testing beyond automated scanning, and our team is reachable directly at experts@wcag.world to walk through your specific flow. The research behind automated testing's real coverage limits and the W3C's guidance on evaluating accessibility are both worth reading directly for the full picture.