Keyboard
All page functionality must be operable through a keyboard interface, without requiring specific timings for individual keystrokes.
What it requires
Every interactive element on the page — links, buttons, dropdowns, modals, sliders, tabs, accordions — must be reachable and operable using only the keyboard. The required interaction model is platform-conventional: Tab to move focus, Shift+Tab to move backwards, Enter to activate links, Enter or Space to activate buttons, Arrow keys for radios and tabs, Escape to close modals.
The most common failure is interactive elements built from `<div>` or `<span>` without `tabindex="0"` and without a keyboard event handler. The element looks clickable but cannot receive focus.
Common Shopify failure
Image carousels with custom previous/next arrows implemented as `<div>` with `onclick` handlers — keyboard users cannot reach them. Variant pickers built from styled `<div>` swatches without role or tabindex.
How to fix it
Replace `<div onclick>` patterns with `<button type="button">`. For custom widgets that genuinely need a non-button host, add `role="button" tabindex="0"` and a keyboard event handler that responds to Enter and Space.
Merchant QA checklist
- Scan the storefront page where this pattern appears: product pages, collection pages, cart drawer, customer-account pages, and any landing page built with theme sections.
- Confirm the issue is fixed in the rendered browser output, not only in the Liquid file. Shopify section settings, app blocks, and third-party scripts can reintroduce the same 2.1.1 failure after a theme edit.
- Re-test the affected component with keyboard navigation and a screen-reader accessibility tree before publishing the theme, especially when the fix changes markup or ARIA attributes.
How AccessComply handles it
AccessComply uses automated rules to check supported patterns in the pages reached during a scan. Some WCAG requirements need human judgment, assistive-technology testing, or access to third-party content and cannot be established by an automated scan. This criterion is generally treated as a guided or hands-on fix pattern. If the app can safely match the issue to supported source code, the merchant must review and approve the suggested change before anything is written, and the result is checked afterward. Otherwise the merchant should use the guidance above and independent hands-on testing. The label is not a guarantee of detection, a fix, WCAG conformance, or legal compliance.
Primary source: W3C — WCAG 2.0 Understanding 2.1.1