Reviewed November 2, 2026

A Keyboard Only Checkout Test You Can Run in 20 Minutes

Set a timer for 20 minutes, put the mouse out of reach, and complete a purchase using only Tab, Shift Tab, Enter, Space, and the arrow keys. You are testing four things: a visible focus indicator on every stop, a tab order that follows the visual order, no keyboard traps, and every control, including the cart drawer, discount field, and payment options, reachable and operable. Log each failure with the page and the control; that log is your remediation list, in user impact order.

Every accessibility audit eventually says test with a keyboard, and most store owners nod and never do it, because nobody gave them a script short enough to survive a busy week. Twenty minutes is enough to find the failures that matter at checkout, because checkout is a finite path: product, cart, information, shipping, payment. If a keyboard user cannot walk it, the store has a wall where its money enters.

You do not need a screen reader for this pass, and you do not need to be an expert. You need a mouse you cannot reach and the honesty to write down where you got stuck.

Minutes 0 to 7: product page to cart

Start on a product page. Tab forward and watch the focus indicator like a hawk: the moment you cannot tell where you are, that is failure one, and it is usually a theme that removed outlines for aesthetics. Check that you can choose a variant, change quantity, and add to cart, all from the keyboard, and that skip links, if present, actually move you past the navigation.

When the cart drawer slides in, focus must slide with it. If focus stays behind the drawer on the page while the drawer sits visually on top, you have found the classic trap's cousin: a keyboard user tabbing through a page they cannot see while the thing they need ignores them. Escape should close the drawer and return focus to the add to cart button. Note anything that opens but cannot be closed from the keyboard.

Minutes 7 to 15: the checkout form itself

Move into checkout. The tab order should walk the form the way eyes do: contact, address, shipping method, payment, pay. Hunt for the known offenders: address autocomplete dropdowns that need a mouse click to accept a suggestion, shipping options styled as cards that are not real radio inputs, and a discount code apply button placed before its field in tab order.

Error handling gets its own minute. Submit with a deliberate mistake and confirm you can find the error, reach the field, and fix it without sight of a red border. This is where most checkouts quietly fail WCAG 3.3.1, and you will feel it in your fingers before you can cite the criterion.

Minutes 15 to 20: pay, and write the list

Complete the payment with test details. Express payment buttons deserve a check: reachable, clearly labeled, and not stealing the first tab stop of the page for no reason. On the confirmation page, confirm the order summary and next steps are reachable and readable in tab order, because post purchase confusion generates the support emails nobody connects to accessibility.

Now rank your notes by position, not by elegance. A trap or a missing focus indicator anywhere from cart to payment outranks a cosmetic tab order quirk on a footer link. Fix in path order, retest the same script, and keep the script; run it after every theme update, because theme updates are where yesterday's fix goes to be overwritten.

Frequently asked questions

Which keys should I use in a keyboard checkout test?

Tab moves forward, Shift plus Tab moves back, Enter activates links and buttons in most cases, Space toggles checkboxes and activates buttons, and arrow keys move within radio groups, menus, and sliders. If a control needs a key outside that set, it is probably a custom widget that needs work.

What is a keyboard trap and how do I spot one?

A trap is any component you can tab into but cannot tab out of, so the only escape is refreshing the page. Modals, embedded payment frames, and chat widgets are the usual sources. If you tab twenty times and focus never leaves a component, you have found one.

My theme has no visible focus outline. How do I fix that?

Restore a focus-visible style in CSS: a clear outline, at least 2 to 3 pixels with good contrast, applied on :focus-visible so mouse users are unaffected. Removing outlines entirely is an aesthetic choice that breaks WCAG 2.4.7 Focus Visible and strands keyboard users immediately.

How often should I rerun this test?

After every theme change, app install that touches the product page or cart, and at least quarterly otherwise. It takes 20 minutes once the script is familiar, and it catches regressions that automated scanners miss, because scanners cannot feel a trap.