Accessible keyboard navigation: the how-to guide for e-commerce
In short — everything must work with a keyboard
A large share of users don't use a mouse: blind people using a screen reader, people with limited hand mobility, users of voice control or adaptive keyboards. The European Accessibility Act (EN 301 549 / WCAG 2.1 AA), in force for e-commerce since 28 June 2025, requires a store to be fully usable with the keyboard alone. The key points:
- Everything is reachable and operable by keyboard — menus, filters, product page, basket, checkout (criterion 2.1.1);
- No keyboard trap: you can always leave an element with Tab or Esc (criterion 2.1.2);
- Logical tab order that follows the visual and reading order (criterion 2.4.3);
- Focus always visible: you can see where you are at all times (criterion 2.4.7);
- A skip link to jump the menu and go straight to the content (criterion 2.4.1);
- No surprise change of context just because an element receives focus (criterion 3.2.1).
Quick test: put the mouse away and complete a full purchase using only Tab, Enter and the arrow keys. If you get stuck, so do your customers.
The keyboard is the common denominator of accessibility: a screen reader, voice control, a switch device or an adaptive keyboard all rely on the same keyboard-navigation logic. If your store can be browsed entirely by keyboard, it clears a large part of the accessibility barriers at a stroke. Conversely, a single button that can't be reached by keyboard in the checkout flow, and the sale is lost. Here are the six WCAG rules the EAA requires, and how to check them in five minutes.
Why the keyboard is central
Many people cannot — or will not — use a mouse: users of screen readers (who move around by keyboard), people with motor impairments that make precise pointing impossible, users of voice control or adaptive devices (switches, ergonomic keyboards). All rely on the same basics: Tab to move to the next interactive element, Shift+Tab to go back, Enter / Space to activate, the arrow keys inside components (menus, lists, carousels).
The EAA doesn't create a separate "keyboard" rule: the reference remains EN 301 549, based on WCAG 2.1 level AA, applicable to e-commerce services since 28 June 2025. But keyboard accessibility is its foundation: it's the very first principle ("Operable") and the fastest test you can run yourself.
The 6 rules of keyboard navigation
Every function is reachable and operable without a mouse
Criterion 2.1.1 (Keyboard) requires that all functionality be usable with the keyboard alone: opening the menu, applying a filter, choosing a variant, adding to the basket, completing checkout. The classic trap: a "clickable" element built with a <div> or a <span> plus an onclick, which never receives focus. Use native elements (<a>, <button>) that are focusable and operable by default; otherwise, add tabindex="0", an ARIA role and handling for the Enter/Space keys.
<button>; filters as native checkboxes; a dropdown menu that opens with the keyboard.<div onclick> used as a button; a colour picker that only responds to the mouse.→ See also the accessible checkout & forms guide.
You can always leave an element
Criterion 2.1.2 (No Keyboard Trap) forbids a component from capturing focus with no way out via the keyboard. Frequent culprits: a modal window (a "newsletter" pop-up, a size selector) you can't escape, a video player or a third-party widget that holds onto Tab. Rule: you must be able to leave with Tab / Shift+Tab, and any modal must close with Esc, returning focus to where it started.
Tabbing follows the visual and reading order
Criterion 2.4.3 (Focus Order) requires that you move through elements in an order consistent with the visual layout: top to bottom, left to right, with no disorienting jumps. This is mostly decided by the order of the HTML (the DOM order), not the CSS that rearranges the display. Avoid positive tabindex values (tabindex="3"…): they scramble the natural order and almost always create inconsistencies.
You can see where you are at all times
Criterion 2.4.7 (Focus Visible) requires a visible focus indicator to mark the active element while navigating by keyboard. A very common mistake: an outline: none in the CSS that removes the browser's outline "to look tidy" — the person no longer knows where they are. Never remove it without a replacement: provide a well-contrasted :focus-visible style (a thick outline, a halo). Useful reminder: that indicator must itself have enough contrast (at least 3:1 with the background).
*:focus { outline: none } with no alternative; a barely visible focus (pale grey on a light background).→ On the focus indicator's own contrast, see the accessible colour contrast guide.
Jump the menu to reach the content directly
Criterion 2.4.1 (Bypass Blocks) asks for a way to skip repeated blocks — typically the header and the large navigation menu — to reach the content directly. The standard solution is a skip link ("Skip to content") placed right at the top, visually hidden but which appears on focus at the first tab. Without it, a keyboard user has to travel through dozens of menu links on every page before reaching the products. A structure using landmarks (<header>, <nav>, <main>) also helps this navigation for screen readers.
Merely receiving focus doesn't change the context
Criterion 3.2.1 (On Focus) forbids a change of context happening just because an element receives focus: opening a new window, submitting a form, navigating elsewhere or abruptly reorganising the page as soon as you land on a field. An important action must always require explicit confirmation (pressing Enter, clicking a button). This is common with poorly coded native dropdowns (<select>) that redirect the moment the value changes, with no "Apply" button.
<select> that reloads the page as soon as you move onto it by keyboard; a field that opens a new tab on focus.The keyboard criteria at a glance
| Point to check by keyboard | Level | WCAG criterion |
|---|---|---|
| Every function usable with the keyboard alone | A | 2.1.1 |
| No keyboard trap (you can get out) | A | 2.1.2 |
| Logical tab order | A | 2.4.3 |
| Visible focus indicator | AA | 2.4.7 |
| Bypass blocks (skip link) | A | 2.4.1 |
| No change of context on focus | A | 3.2.1 |
| Single-key shortcuts can be turned off / remapped | A | 2.1.4 |
outline: none "for aesthetics". That makes keyboard navigation invisible — the user no longer knows where they are. Never remove the outline without replacing it with a clearly contrasted :focus-visible style. Fixing it is often a handful of lines of CSS.
<div>, won't make focus visible and won't create a logical tab order — these are defects in your pages' code. Reminder: the US FTC fined one overlay vendor $1,000,000 over misleading compliance claims. See the compliance checklist for what actually counts.How to test keyboard navigation
The most useful test is also the simplest — it needs no tool at all:
- Put the mouse away and go through a whole page with Tab (forward), Shift+Tab (back), Enter / Space (activate), the arrow keys in menus and lists.
- Watch the focus indicator: can you always see where you are? Does it disappear anywhere?
- Check the order: does progress follow the reading order, with no surprising jumps?
- Complete a full purchase by keyboard — search, filters, product page, add to basket, checkout. All of it without touching the mouse.
- Open the pop-ups and modals: can you get out with Esc and Tab?
An automated scan (axe-core, WAVE, Lighthouse) catches some keyboard-related defects — an interactive element with no accessible name, a missing landmark structure, suspicious tabindex values — but it can't "feel" a keyboard trap, judge whether the tab order is logical, or confirm everything can be activated. The manual keyboard test stays essential: it takes five minutes and reveals the essentials. It then feeds straight into the express compliance test.
Check your store's accessibility for free
DeclareAccess scans one page of your store with the axe-core engine against WCAG 2.1 AA, flags the failures (keyboard, focus, structure, contrast, forms…) and generates the ready-to-publish accessibility statement — English, French (RGAA), German (BFSG), Italian or Spanish template. Free, no credit card.
WCAG report by email within 1 business day.
Got it. Your audit request is recorded — you'll receive your WCAG report by email within 1 business day.
Frequently asked questions
Does an automated scan detect keyboard problems?
Only partly. An engine like axe-core catches some defects (an interactive element with no accessible name, a missing landmark structure, suspicious tabindex values), but it can't "feel" a keyboard trap, judge whether the tab order is logical or verify that everything can be activated. The manual keyboard test remains indispensable: it takes five minutes and reveals the essentials.
What are tab order and tabindex?
The tab order is the sequence in which focus moves from one interactive element to the next when you press Tab. By default it follows the HTML source order. tabindex="0" makes a non-native element focusable in the right place; tabindex="-1" makes it focusable by script but out of the Tab sequence. Avoid positive values (tabindex="1", "2"…): they force an artificial order that almost always ends up creating inconsistencies.
Why should you never remove the focus outline?
Because the outline is, in many browsers, the only visual signal showing where the keyboard focus is. Removing it (outline: none) without a replacement makes keyboard navigation impossible to follow and breaches criterion 2.4.7. If you dislike the default style, replace it with a custom, well-contrasted :focus-visible indicator rather than deleting it.
What is a skip link, and is it mandatory?
A skip link ("Skip to content") is a link placed at the very start of the page, often hidden until it receives focus, which lets you skip the repeated blocks (header, menu) and go straight to the main content. It's the usual way to satisfy criterion 2.4.1 (Bypass Blocks), level A; a landmark HTML structure (<nav>, <main>) can also contribute. For a site with a large menu, it's effectively indispensable.
Is keyboard navigation enough to be compliant?
No. It's an essential foundation, but EAA compliance covers all of WCAG 2.1 AA: colour contrast, image text alternatives, properly labelled forms, screen-reader-readable content, and so on. A site perfectly usable by keyboard can still fail on other criteria. Keyboard navigation is nonetheless the best starting point, because many other barriers reveal themselves there.