The Keyboard-Only Checkout Test: Time It, Film It, Fix What Blocks It

Put the mouse in a drawer and buy something from your own store. Time it. A sighted mouse user checks out in two minutes. A keyboard user on the same store can take nine, and most of that time is not typing, it is tabbing through a header, a promo carousel, and a footer they never asked to visit.

The test, step by step

Start on the homepage with a stopwatch running and your hands off the mouse. Tab to a product, open it, choose a variant, add it to the cart, and check out. Write down every stop that is not part of the task: the nav links, the search box, the newsletter signup, the footer links that appear before the checkout button because the focus order does not match the visual order. Then write down every stop where you cannot see focus at all, and every control you reach that does nothing when you press Enter.

Three minutes is a reasonable target for a keyboard checkout on a store that sells a single item, and most stores miss it by a wide margin. The point of the number is not the number. It is the comparison: run the same flow with a mouse, run it with a keyboard, and the gap is the tax your site charges keyboard users. A gap of two or three times is normal on a first test. A gap of five times means the focus order is broken, not just slow.

What the clock usually finds

The first finding is almost always the variant picker. A color swatch or size selector built from divs with click handlers is invisible to a keyboard unless someone added roles, names, and focus handling, and most theme pickers were built for a mouse. The picker is also the place where an accessible name matters most: a swatch with no name is announced as button, and a shopper choosing between eight identical buttons is guessing. Our earlier readiness post on the same component, Readiness: Accessible Names on Payment Method Selectors, covers the payment half of this flow.

The second finding is the modal that traps focus or the date picker that swallows it. A delivery date picker that opens a calendar and never lets focus out is a 2.1.2 failure, and it is also a lost order, because the shopper cannot reach the place order button. The third finding is the error message that appears in red text and is never announced, so the shopper submits, nothing happens, and they submit again. All three are found in one timed pass, and all three are fixed at the component level.

Film it, then fix in order

Record the test. A two-minute screen recording of a keyboard checkout that takes nine minutes is the most persuasive document in accessibility work, because it makes the tax visible to people who will never run the test themselves. Send it to whoever owns the theme, with the timestamps of each blockage marked.

Fix in the order the test found them: focus order first, because it touches every page, then the variant picker, then the modal and picker traps, then the error announcements. Re-run the test after each fix and watch the time fall. When the keyboard checkout lands within a minute or two of the mouse checkout, the flow is ready, and the test becomes a regression check you run after every theme change. For the contrast half of readiness, see Color Contrast: Why 4.5 to 1 Is the Number That Matters.

Ask the tester to narrate as they go, because the narration is where the meaning failures surface. A tester who says I do not know whether this button will submit the order or clear the form is reporting a label problem the scan cannot see. Keep the recording short, five minutes or less, and keep it, because the same recording becomes the before in the before-and-after when the fix ships. The point of filming is not surveillance. It is evidence that the problem is real, and it is the thing that gets the fix prioritized over the next feature.

Frequently asked questions

How long should a keyboard checkout take?

A single-item keyboard checkout should land within a minute or two of the mouse checkout. A gap of five times usually means the focus order is broken, not just slow.

What do I need to run the test?

A keyboard, a stopwatch, and a screen recording. No tools and no audit budget. Tab through the whole purchase flow without touching the mouse and note every stop that is not part of the task.

What does the test usually find first?

Variant pickers built from divs with no accessible name, modals and date pickers that trap focus, and error messages that appear visually but are never announced to a screen reader.

Why film the test?

A recording makes the keyboard tax visible to people who will never run the test themselves. Timestamps of each blockage turn a vague complaint into a fix list the theme owner can act on.