# When a Scan Passes but the Keyboard Test Fails: The Checks Scanners Cannot Run

Source: https://accessignal.com/blog/2026-11-15-scan-passes-keyboard-test-fails.html

November 15, 2026

*The scanner reports zero errors and the dashboard is green. A keyboard user tabs through checkout, reaches the payment step, and cannot move forward, because the card number field is inside a container the keyboard cannot enter.*

## The scanner tests the page. The user tests the task.

Automated accessibility checks are good at what they do, and what they do is narrow. They test the DOM: does this image have alt text, does this button have a name, does this contrast ratio meet 4.5 to 1. They do it fast and consistently, and a team that runs them in CI catches real regressions. What they cannot do is the thing that matters most: sit down as a keyboard user and try to buy something.

The gap is structural. A scanner can confirm that an element is focusable. It cannot confirm that the focus order makes sense, that focus is visible, that a modal returns focus when it closes, or that a keyboard user can reach the submit button at all. Those are interaction checks. They require a person doing the interaction, in order, with the same tools the user has. The WebAIM keyboard accessibility guidance has said this for years: keyboard testing is a manual activity, and no scanner replaces it.

The evidence is in the error counts. The WebAIM Million 2026 report found a third of form inputs unlabeled, which is a scanner finding, and at the same time the failures that actually block a purchase are usually invisible to scanners entirely. A payment field inside a container with tabindex minus one. A date picker that traps the Tab key. A custom dropdown that opens on hover and never on focus. None of these produce an error in axe or Lighthouse, because the DOM looks fine. The page is broken and the dashboard is green, and that combination is worse than a red dashboard, because nobody is looking.

## The four checks the scanner will never run

First, the focus trap. Open every modal, menu, and date picker on the site, and Tab through it. If focus escapes into the page behind the modal, or never enters the modal at all, the pattern is broken, and no scanner will tell you. The [route change announcement](2026-11-13-spa-route-change-announcement.md) problem is the same class of failure in a different shape: the tool reports what is on the page, not what the user experiences when the page changes.

Second, the focus order. Tab through checkout and watch where focus lands. If it jumps from the shipping form to the footer, then back to the payment form, the DOM order and the visual order disagree, and the keyboard user is navigating a maze the mouse user never sees. Third, the visible focus indicator. A custom theme that removes the outline for sighted mouse users also removes it for keyboard users, and the scanner reports nothing, because the outline is a style, not a structure.

Fourth, the escape hatch. Every overlay needs a way out that works from the keyboard: Escape closes it, focus returns to the element that opened it, and the user is not left stranded. Test it with the keyboard alone, not with a mouse click on the close button, because the close button is exactly the element a keyboard user may not be able to reach.

## The check that belongs in the release, not the calendar

Tie the manual keyboard test to the release, not to a monthly reminder. The failures arrive with the changes: a new modal, a new checkout step, a redesigned navigation, a third-party widget that injects its own focus behavior. A team that tests on a calendar tests the old site. A team that tests on a release tests the site that is about to ship.

The test itself is short. Tab through the critical path, checkout or signup or contact, with a keyboard and no mouse. Complete the task. If you cannot, file it at the same severity as a broken payment gateway, because for the user who hits it, that is what it is. The scanner will keep doing its job, and it will keep reporting zero errors on the page that just blocked a customer. Both facts can be true at once, and the team that understands that is the team that catches the failure before the customer does.

## Frequently asked questions

### Why do scanners miss keyboard failures?

Because automated checks test the DOM, not the experience. A scanner can confirm an element has a name and a role. It cannot confirm that a keyboard user can reach the element, operate it, and get back, or that the focus order makes sense. Those are interaction checks, and only a person doing the interaction can run them.

### What should I test by hand if I can only test one thing?

Start with the task, not the page. Tab through checkout with a keyboard, complete a purchase with a screen reader, open every modal and escape out of it. The critical paths are where users lose money and time, and they are where the scan is blindest.

### Does a zero-error scan mean the site is accessible?

No, and treating it as one is how teams ship broken checkouts with green dashboards. A clean scan means the page has no detectable violations. It does not mean the page works. The two statements are different, and confusing them is the most expensive mistake in accessibility monitoring.

### How often should the manual keyboard test run?

Every time the page changes in a way that affects interaction: a new modal, a new checkout step, a redesigned navigation, a third-party widget. Tie the manual test to the release, not the calendar, because the failures arrive with the changes.