Why Your Accessibility Scan Says 0 Errors and a Keyboard User Still Can't Check Out

The scan comes back green: zero errors, zero contrast failures, zero missing labels. Then a keyboard user tries to check out and cannot get past the date picker, because the calendar traps focus and the close button is unreachable. The scan was not lying. It was blind.

What a scanner can actually see

An automated checker like axe-core or WAVE tests the rendered page against a set of machine-checkable rules: missing alt text, empty buttons, contrast ratios, duplicate ids, invalid ARIA. Those rules map to part of the standard, and the part they cover is real. A zero-error scan means those specific defects are absent, which is worth having. It does not mean the page conforms to WCAG, because most of the standard is not machine-checkable.

WCAG 2.2 has 86 success criteria. A scanner can test the ones that reduce to a property of the markup: is there an alt attribute, does the ratio clear 4.5:1, is the label present. It cannot test whether the label makes sense, whether the focus order follows the visual order, whether the error message tells the user how to fix the problem, or whether a keyboard user can complete the task at all. Those judgments need a person, a keyboard, and ten minutes.

The failures a scan never finds

Focus order is the biggest blind spot. A scan sees that every element is focusable; it cannot see that tabbing jumps from the shipping form to the footer and back to the payment section, which is a 2.4.3 failure a human finds in one pass. Keyboard traps are the same: the date picker that swallows focus is valid markup, and the scan has no way to know the user cannot leave it. Our earlier post on the same gap, Monitoring Focus Order After a Mega-Menu Rebuild, walks through how a rebuild quietly reordered the tab sequence.

Meaning is the second blind spot. A button labelled with a single word, a link that says click here, an image alt text that reads image123: all pass the machine check for presence and fail the human check for purpose. A scan counts the attribute; it cannot read it. The same goes for error messages: an error that says invalid input satisfies the presence test and fails 3.3.3, because it never tells the user what to fix.

A scan counts the attribute; it cannot read it. The same gap appears in headings: a page can have a perfect heading outline that says nothing, with three H2s that all read Learn More, and the scan will pass it because the levels are correct. A screen reader user navigating by headings gets a map with no labels. The fix is editorial, not technical, and it is the reason the manual pass includes reading the page aloud: labels, headings, and error text are content, and content is where conformance is decided for a human.

The test that replaces the green checkmark

Run the scan, then put it aside and do the keyboard pass. Tab through checkout from the first field to the order button without touching the mouse. Can you reach everything, see where focus is at all times, get out of every modal and picker, and submit the order? That pass takes ten minutes per template and finds the failures that matter most, because they are the failures that stop a purchase.

Then run the screen reader pass on the same flow, listening for the things a scan cannot hear: does the cart count announce when it changes, does the error get read when it appears, does the order confirmation actually say the order went through. A site that passes both passes and the scan is in decent shape. A site that passes only the scan is a site that has tested its markup, not its users. For the contrast half of the manual pass, see Your Dark Mode Toggle Just Broke Contrast. Nobody Is Watching..

Frequently asked questions

Does a zero-error scan mean my site is WCAG conformant?

No. Automated tools test the subset of WCAG that can be checked by machine. A clean scan means those specific defects are absent, not that the site conforms. Keyboard, focus order, and meaning all need manual testing.

How much of WCAG can automated testing cover?

Only a fraction. WCAG 2.2 has 86 success criteria, and the machine-checkable ones are the minority. The rest, including focus order, error suggestions, and whether labels make sense, need a person testing with a keyboard and a screen reader.

What is the fastest manual test after a scan?

Tab through checkout from the first field to the order button without a mouse. If you can reach everything, see focus at all times, escape every modal and picker, and submit, the keyboard pass is clean. It takes about ten minutes per template.

Why do scanners miss keyboard traps?

A keyboard trap is valid markup. The scan sees focusable elements and valid attributes; it cannot simulate tabbing through a date picker and discovering that focus never leaves. Only a keyboard pass finds that.