You Can Audit Keyboard Access Without a Screen Reader. Here Is the 15-Minute Version.

Unplug the mouse, tab through the storefront, and watch for three things: controls you cannot reach, focus you cannot see, and places where focus gets stuck or lost. Fifteen minutes of keyboard testing finds the failures that send demand letters.

The setup: unplug the mouse

The audit starts with a rule: no mouse, no trackpad, no touchscreen, for fifteen minutes. Tab moves forward, shift-tab moves back, enter activates, space toggles, escape closes, arrow keys move inside menus and tabs. That is the whole input set, and it is the input set a keyboard user lives with every day. If a task cannot be done with those keys, it cannot be done by a keyboard user, and no amount of ARIA on the page changes that. The scanner cannot run this test, because the scanner reads the DOM and the DOM does not know whether the focus indicator is visible or whether the tab order makes sense.

Pick three journeys: find a product and add it to the cart, apply a discount code, and complete checkout up to the payment step. Those three cover the header, the product page, the cart drawer, and the checkout form, which is nearly every interactive element on a storefront. Do not test the homepage in isolation, because the homepage is the page the theme author tested, and the failures live in the flows.

The five things to test

First, reach: can you tab to every control, including the cart, the search, the size selector, and the remove button on each line item? A control that is skipped by tab is a control that does not exist for a keyboard user. Second, visibility: is the focus indicator visible on every stop, or does it vanish under a sticky header or fade into a pale outline? A focus indicator the user cannot see is the same as no focus at all. Third, traps: does focus get stuck anywhere, in the mega menu, in the modal, in the date picker? Fourth, order: does tab follow the visual order, left to right and top to bottom, or does it jump across the page because the DOM order and the layout disagree? Fifth, the return: when a modal closes, does focus come back to the trigger, or does it land at the top of the page?

Write down every failure as a location and a behavior, not as a criterion number. The cart drawer close button never receives focus is a fixable sentence. Failure of 2.4.7 is a ticket nobody picks up. The audit is only useful if the person fixing it can reproduce the failure in thirty seconds, and the reproduction is the sentence, not the number.

What counts as a failure

A control you cannot reach is a failure. A focus indicator you cannot see is a failure. A trap you cannot escape without a mouse is a failure. A tab order that jumps across the page is a failure. A modal that strands focus at the top on close is a failure. None of these need a screen reader to confirm, and none of them need a criterion number to matter. They are failures because a person using a keyboard cannot complete the purchase, and the purchase is the point of the storefront.

What does not count as a failure is a tab order that visits elements in an order that is different from the visual order but still logical, or a focus indicator that is styled differently from the browser default but still clearly visible. The audit is about whether the task can be done, not about whether the implementation matches a preference. Over-reporting trains the team to ignore the audit, and an ignored audit is worse than no audit.

What the test cannot tell you

The keyboard test says nothing about whether a screen reader announces the right thing, because it tests the keyboard, not the announcement. A button can be reachable, visible, and correctly ordered, and still announce as bare button because it has no accessible name. That needs a screen reader pass, which is a different fifteen minutes with different tools. The keyboard test also says nothing about contrast, touch target size, or zoom, which are separate checks with separate criteria. Run the keyboard audit first, because it finds the failures that block the purchase outright, and schedule the screen reader pass for the same week, because a control that is reachable but unnamed is a failure too, just a quieter one.

Frequently asked questions

Do I need a screen reader to audit keyboard access?

No. The keyboard test is about reach, visibility, order, and traps, and all of those are visible to a sighted person using only the keyboard. A screen reader pass is a separate test for announcements and names, and it should follow, but it is not a prerequisite.

What keys do I need for the audit?

Tab, shift-tab, enter, space, escape, and the arrow keys. That is the full input set for a keyboard user, and if a task cannot be done with those keys, it cannot be done by a keyboard user at all.

Which pages should I test?

The three journeys that matter: find a product and add it to the cart, apply a discount code, and complete checkout up to payment. Those cover the header, product page, cart drawer, and checkout form, which is nearly every interactive element on the store.

How often should this audit run?

After every theme update, app install, or checkout change, and monthly as a routine. The failures it finds are introduced by changes, not by time, so the audit belongs in the release process, not on a calendar.