WCAG 2.1.1 — Keyboard
Everything a customer can do with a mouse must also be possible with a keyboard alone.
What this means for a store
This is the failure that ends a sale outright. If the size selector, the cart drawer or the payment step cannot be reached with Tab and operated with Enter or Space, the customer does not get a degraded experience — they get no way to buy at all. It affects far more people than screen reader users: anyone with a motor impairment, anyone using voice control or a switch device, and anyone whose trackpad has failed. Keyboard support is also what makes the rest of accessibility testable, so a keyboard failure usually indicates several others.
The failures we see most often
Custom dropdowns for size, colour or quantity built from div elements that only respond to click.
Why it happens: A native select is hard to style, so it is replaced with a scripted component. Focus management and arrow-key handling are the parts that get skipped.
The cart drawer or quick-view modal opens but focus stays behind it on the page.
Why it happens: The modal is shown with CSS while focus is never moved into it. A keyboard user tabs through the hidden page underneath and never reaches the checkout button.
A modal cannot be closed without a mouse — Escape does nothing and the close control is not reachable.
Why it happens: The close affordance is an icon with a click handler and no focusability, and no key handler was added.
Mega menus that open only on hover.
Why it happens: The dropdown is triggered by CSS :hover, which has no keyboard equivalent. Entire product categories become unreachable.
A keyboard trap: focus enters an embedded widget (a review carousel, a chat box, a map) and cannot get out.
Why it happens: Third-party embeds manage their own focus badly. This is worse than an unreachable control, because it strands the user on the page.
How to check it yourself
- Unplug the mouse. Genuinely — do not just decide not to use it.
- From the top of a product page, complete a purchase using only Tab, Shift+Tab, Enter, Space and the arrow keys.
- Open the cart drawer and confirm focus moves into it, that Escape closes it, and that focus returns to the control that opened it.
- Tab through the whole page once and confirm focus never gets stuck in an embedded widget.
Fixing it, by platform
- Shopify — Keyboard Theme JavaScript: the custom elements in assets/global.js — menu-drawer, modal-dialog, quantity-input, variant-selects.
- WooCommerce — Keyboard Theme templates and, more often, the variation swatch and quick-view plugins.
- Webflow — Keyboard Interactions-driven dropdowns and modals; custom code embeds.
- Wix — Keyboard Built-in components generally handle this; failures usually come from Velo-driven custom interactions and third-party embeds.
- Squarespace — Keyboard Code block components and third-party embeds.
What this page covers
What follows is the practical meaning of a WCAG 2.2 success criterion. Automated tests catch only a portion of accessibility issues, so a clean scan result does not mean compliance. Platform paths vary by version and theme.
Source
The formal definition of this criterion: W3C — Understanding Keyboard