How to test an online shop with a keyboard
You do not need developer tools for a basic keyboard-accessibility check. Put the mouse aside and try to complete an important journey using only the keyboard. This form of interaction is used, for example, by people with limited motor skills, blind users working with a screen reader and people who temporarily find a mouse difficult to use.
A common problem: focus is lost or trapped
A form that works visually may be unusable without a mouse. Focus skips an important button, is not visible, remains behind a modal window or becomes trapped in a window that cannot be closed without a mouse. A simple manual walkthrough helps reveal these problems.
How to proceed
Open the home page, take your hands off the mouse and use these keys:
- Tab moves focus to the next control, while Shift + Tab moves it back;
- Enter activates a link or button, while the Space bar selects a checkbox;
- the arrow keys move between options in a drop-down list or a group of radio buttons;
- Escape is commonly used to close a modal window when it has been designed that way.
Now try to complete a purchase: find a product, add it to the basket, open the basket, enter delivery details, select delivery and payment, and reach the point where the order can be submitted. Nothing more.
What to look for along the way
Can you see where you are? The element that currently has focus must be clearly indicated with a border, outline or other highlight. If you press Tab and nothing changes on screen, focus may be invisible. A common cause is removing the default outline without providing an adequate replacement.
Does focus move in a logical order? It should reflect the meaning and visual arrangement of the content. If it suddenly jumps from the header to the footer and then back to the middle of the page, the order in the code probably does not match the expected journey.
Can you reach the content quickly? A common solution is a “Skip to content” link that appears after the first press of the Tab key. WCAG also permits other mechanisms for bypassing repeated blocks; what matters is that the user does not have to move through the entire menu again every time a page loads.
Does a modal window trap you? Open a genuinely modal dialog, such as sign-in, size selection or confirmation that an item has been added to the basket. Focus should move inside it and remain there while the window is open. The dialog must have a keyboard-accessible way to close it; the Escape key is a conventional option. A problem exists if content “behind” the window can receive focus or the dialog cannot be closed without a mouse.
Do custom controls work? The elements that fail most often are those a developer has built instead of using standard HTML controls: a star rating, quantity selector or custom delivery selection. Frequently, they cannot even receive focus.
Can you complete the basket journey? If you become stuck and cannot continue without a mouse, you have found a barrier that may prevent a purchase from being completed.
What this test will not reveal
This test is valuable, but it shows only one layer. It does not tell you what a blind customer hears: whether a screen reader announces a field’s label, whether it announces a form error or remains silent while a red border appears visually. It does not assess whether alternative text is meaningful, whether contrast is sufficient or the order in which content is actually read.
Some keyboard scenarios and focus traps can be checked with automated functional tests. The result must nevertheless be supplemented by a manual walkthrough, because a scanner alone cannot assess the entire usability of the interface or the screen-reader experience. The topic what a scanner can and cannot detect explains this in more detail.
What this test gives you
You identify the precise point where a journey without a mouse stops and obtain reproducible steps for a developer. It is not a complete audit, but it is a practical first filter before more in-depth testing.
Next step
If you became stuck while tabbing through the page, record the page, the step and the expected behaviour. During a no-obligation consultation, we can determine what should be checked manually and what is worth monitoring with an automated test.