A team ships a feature, runs axe-core in CI as part of the pipeline, gets a clean pass, and merges with confidence. Two weeks later a real bug report comes in from a screen reader user who could not complete the exact flow that just passed automated testing. Nobody on the team is negligent. The CI check did its job. It just was never capable of catching what actually broke.
Automated scanners are excellent at catching a specific category of problem: missing alt text, insufficient color contrast, malformed ARIA attributes, missing form labels. They are structurally unable to catch a different category entirely: whether a real person, unplugging their mouse and turning on a screen reader, can actually complete the task the page exists for. That gap is not a tooling limitation someone will eventually patch. It is the difference between checking that pieces exist and checking that they work together.
The Stat: WCAG 2.1.1 Keyboard, the requirement that everything operable by mouse must also be operable by keyboard, is a Level A criterion, the lowest conformance bar in the standard, and it is also the single most common real screen reader failure teams encounter once they finally test with one. (Source: W3C WCAG 2.1, Success Criterion 2.1.1)
Why a Clean Automated Scan Is Not the Finish Line
Automated accessibility scanners work by inspecting the DOM: checking for the presence and shape of specific attributes, computing contrast ratios between colors, flagging images without alt attributes. They are pattern-matchers, not simulators. They can confirm a button has an accessible name. They cannot confirm that pressing Enter on that button, after tabbing to it from three fields earlier, actually does what a sighted mouse user expects it to do. That confirmation requires an actual keyboard and, ideally, an actual screen reader, actually running.
This is not a criticism of automated tools. They catch real, common problems quickly and cheaply, and skipping them would be a mistake. The point is narrower: a clean scan tells you the pieces are individually well-formed. It does not tell you the experience works end to end, and end-to-end is the only thing a real user ever actually experiences.
The Test Almost Nobody Runs
Here it is, stated plainly: unplug the mouse, turn on a screen reader (VoiceOver on Mac, NVDA on Windows, both free), and complete the single most important task on the page using only Tab, Shift+Tab, Enter, Space, and arrow keys, with the screen reader narrating out loud the entire time. Not a quick click-through with the mouse still in hand "just to check." The mouse has to actually be unavailable, because the moment it is available, muscle memory reaches for it the instant a keyboard path gets confusing, and the exact friction point that would break a real screen reader user's experience gets silently skipped over.
This test takes fifteen to twenty minutes for a typical checkout, signup, or booking flow. It is not a substitute for a full audit. It is the single highest-signal-per-minute test available, because it surfaces the class of bug that both automated tools and a rushed manual click-through both reliably miss.
What This Test Actually Catches
Four categories of failure show up almost every time this test is run on a flow that has never been tested this way before, regardless of industry or framework.
Focus that goes missing. A custom dropdown, modal, or date picker opens, and Tab either does nothing, cycles somewhere unexpected, or lands the user back at the top of the page. Nothing in a DOM scan flags this, because the elements involved are all individually well-formed; the problem is purely about what happens when they interact.
Order that does not match the visual layout. Tab order follows DOM order, not visual position. A page styled with CSS Grid or Flexbook can look perfectly logical to a sighted user and jump around unpredictably for a keyboard user, because the visual reordering happened in CSS, not in the underlying markup.
Actions with no keyboard equivalent. Drag-and-drop reordering, hover-triggered menus, swipe gestures, anything built assuming a pointing device, silently has no keyboard path at all unless one was deliberately added. This is exactly the gap covered in our keyboard alternative to drag-and-drop guide.
Announcements that never happen. A form submits, an error appears, a cart updates, and nothing gets spoken aloud, because the change happened in a part of the page with no live region and no focus movement to draw attention to it. A sighted user sees the change instantly. A screen reader user, mid-task, simply never learns it happened.
A Realistic Walkthrough of What Fifteen Minutes Looks Like
Concretely, here is what running this test on a checkout flow actually involves. Open the page, turn on VoiceOver or NVDA, and physically set the mouse aside, not just resist touching it. Press Tab once and listen: does focus land somewhere sensible, ideally a skip-to-content link or the first meaningful interactive element, not silently on the <body> tag or three levels deep in a hidden navigation menu? Continue tabbing through the entire flow, field by field, button by button, narrating out loud (even alone, saying it out loud forces attention) what the screen reader announces at each stop, and comparing that against what a sighted user would understand from looking at the same moment. Complete an actual test transaction, injecting a deliberate error (an invalid card number, a missing required field) partway through, specifically to hear whether the error gets announced automatically or silently appears only as a visual change.
The single most common moment this test breaks a team's assumptions is exactly at that injected error. A form that looks perfectly accessible for its happy path frequently goes completely silent the moment something goes wrong, because error-state announcements were never built at all, only the visual red-border-and-message pattern was.
Building This Into a Real Workflow
The test does not need to happen on every single pull request to be valuable. It needs to happen at two specific points: once on any new custom interactive component before it ships (a dropdown, a modal, a stepper, anything built from scratch rather than a native HTML element), and once on the site's core conversion flows on a recurring cadence, not just at launch. A component that passed this test once does not need retesting every time unrelated code changes around it, but a flow that has never been tested this way at all is carrying unknown risk regardless of how clean its automated scan looks.
This pairs directly with a narrower, keyboard-only version of the same discipline. Our five-minute keyboard test is the fast, no-screen-reader-required version of this same idea, and our visible focus guide covers the specific styling discipline that makes a keyboard-only pass like this one actually possible to follow with your own eyes, useful as a first pass before committing the extra time a full screen reader run takes. Running both, keyboard-only first to catch the obvious focus and tab-order problems, then keyboard-plus-screen-reader to catch what focus order alone does not reveal, covers the two failure classes automated tools consistently miss.
If your team has never run this test on your own core flows, that is worth changing before the next real user report arrives instead of after. Our free accessibility tools are a useful first automated pass, and our team is reachable directly at experts@wcag.world if you want a real manual screen reader walkthrough of a specific flow. For the broader methodology behind manual testing like this, the W3C's guidance on evaluating accessibility and WebAIM's screen reader testing guide are both worth reading in full.