How do I test if my webshop is keyboard accessible?

Navigate the entire checkout using only Tab and Enter

You test this by putting the mouse away and going through the entire purchase process — from product page to confirmation screen — using only Tab, Shift+Tab, Enter, the spacebar and arrow keys. At each step, these should apply: it must be clearly visible which element has focus, the order must be logical, and no part of the interface should trap keyboard users so they cannot escape. Pay special attention to filters and sort menus, quantity selectors, the "add to cart" button, expandable product options, payment methods and the login form — these are precisely the places where JavaScript-based interface elements often work with a mouse but ignore the keyboard.

The login flow and checkout process deserve extra attention, because they often contain modal windows, step-by-step forms or pop-ups that feel intuitive with a mouse but turn out to be dead ends with a keyboard. An automated scan will flag some of these problems — missing focus indicators or labels, for example — but cannot determine whether the tab order remains logical throughout the entire checkout or whether a shopping cart pop-up traps focus. That remains something that must be checked manually, step by step. An overlay widget does not change that underlying tab order: the layer sits on top, the checkout process underneath continues to ignore the keyboard.

This follows from WCAG 2.1, criteria 2.1.1 and 2.4.3

That all functionality must be operable by keyboard is set out as criterion 2.1.1 (Keyboard) in WCAG 2.1, with criterion 2.4.3 (Focus Order) for logical order — the standard that EN 301 549 amounts to in practice. How often this goes wrong in practice is shown by research that the ACM carried out in March 2026 among roughly one hundred major Dutch web shops and sites of telecom and energy providers: at 33%, checkout required significantly more effort, and only 13% proved fully operable with a keyboard.