Keyboard-only test of the e-commerce purchase flow: from catalog to order summary

Why a keyboard-only checkout test matters

A keyboard-only test of an e-commerce purchase flow answers a simple question: can someone move from catalog to order summary without a mouse, without getting stuck, and without having to guess how to use the page? W3C WAI states that all functionality should be available from a keyboard, and its forms guidance emphasizes clear labels, instructions, and correct grouping for controls. (Keyboard Accessible, Forms Tutorial)

This is a partial technical test, not a full accessibility audit. It does not claim certification or legal compliance. Its purpose is narrower: find obvious blockers in the shopping journey before payment.

Prerequisites

Before starting, prepare:

• a desktop or laptop computer;
• a physical keyboard;
• a browser;
• a staging site or other safe test environment;
• a real or near-real purchase flow with catalog, product page, cart, and order summary.

During the test, avoid the mouse. Use only Tab, Shift+Tab, Enter, arrow keys, Space, and any equivalent keyboard command required by a component. That keeps the test aligned with the keyboard-accessible principle described by WAI. (Keyboard Accessible)

Test procedure

1) Move from home page to catalog

Use Tab and Shift+Tab to observe the focus order.

What to check

• Is the focus visible at every step?
• Does the tab order follow the visual and logical structure of the page?
• Can you reach the catalog without unexpected jumps?

Expected result The user can move into the catalog without losing track of focus, and the navigation order feels predictable.

2) Open a product from the catalog

Move to a product card or product link and open it with Enter or Space, depending on the component.

What to check

• Is the product entry reachable by keyboard?
• If filters or sorting controls exist, can they be opened and used by keyboard?
• After opening a panel, where does focus go?

Expected result Filters, sorting, and product links work without a mouse, and focus enters the new content instead of remaining stranded on the trigger button.

3) Select product options and quantity

Test the minimum purchase actions inside the product page.

Concrete input example

• Product: T-shirt
• Variant: Size M
• Quantity: 2

What to check

• Can you change a variant with the keyboard?
• Can you adjust quantity without switching to the mouse?
• Can you activate the add-to-cart action with Enter or Space?

Expected result Each control has a clear name, a reachable state, and a keyboard path that does not create skips or traps. WAI’s forms material is relevant here because the issue is not only reachability, but also whether the control is understandable once reached. (Forms Tutorial)

4) Review the cart

Open the cart and repeat the same keyboard logic.

What to check

• Can you increase or decrease quantity?
• Can you remove an item?
• After each action, is focus still in a sensible place?
• Is the feedback understandable?

Expected result The cart remains operable by keyboard, and the interface does not hide or lose the current focus after updates.

5) Stop at the order summary

Go to the order summary page, but stop before final payment.

What to check

• Are address, delivery, notes, and other editable fields correctly labeled?
• Are instructions close to the field they describe?
• If an error appears, does it explain what to fix and where?

Expected result The summary is readable, the form fields are clearly named, and any validation message is attached to the right control. This is one of the strongest practical points in WAI’s forms guidance. (Forms Tutorial)

Example output from a completed run

A useful result is not just “pass” or “fail.” It should say:

• which page the test stopped on;
• which keys were used;
• what the operator saw;
• whether focus was visible;
• whether the issue was navigation, input handling, or feedback after an action.

Example of a short finding

The catalog is reachable by keyboard. The filter panel opens, but focus stays on the trigger button, so the next Tab leaves the panel instead of entering its controls.

Simulated defect log

These cases are simulated examples, not findings from a real site audit.

Acceptance checks

Treat the test as acceptable only when all of the following are true:

• the main purchase path is reachable with keyboard only;
• focus is always visible;
• there are no focus traps;
• essential controls have clear labels;
• validation messages identify the field to fix;
• the flow can stop at order summary without requiring payment.

Limits of this test

This procedure does not measure conversion, speed, or overall checkout quality. It does not prove full accessibility compliance, and it does not replace a broader accessibility review. What it can do is expose whether the purchase path is genuinely operable by keyboard or merely looks accessible at first glance. (Keyboard Accessible)

Sources

• https://www.w3.org/WAI/WCAG21/Understanding/keyboard-accessible.html
• https://www.w3.org/WAI/tutorials/forms/