What 2.1.1 requires
All functionality must be operable through a keyboard interface, without requiring specific timings for individual keystrokes. That covers links, buttons, form controls, menus, dialogs, carousels, sliders, drag-and-drop and anything else a user can act on. This is a plain-language summary. The normative text, including every exception, is in the W3C Recommendation, with the W3C's explanation in Understanding 2.1.1 (opens in a new tab) [1][2].
Exceptions and scope:
- Functions where the underlying input depends on the path of the user's movement, not just the endpoints (freehand drawing, for example). The function itself must need path-dependent input, not just the way it was built.
Why it matters
Keyboard access is the foundation for screen-reader users, people who can't use a mouse, and people using switch devices, voice control or other software that emulates a keyboard. If a control only responds to a click, none of those people can use it, and if it's the "Place order" button, the task ends there.
Common failures
Clickable div or span
It responds to the mouse but isn't focusable and ignores Enter and Space.
<!-- Fails -->
<div class="btn" onclick="buy()">Buy now</div>
<!-- Better -->
<button type="button" onclick="buy()">Buy now</button>Menu that only opens on hover
Submenu items can't be reached from the keyboard.
/* Fails */
.nav li:hover > ul { display:block }
/* Better */
a disclosure button with aria-expanded that toggles the submenu on Enter/SpaceScrollable region that can't be focused
Content in an overflow box can't be scrolled without a mouse in some browsers.
<!-- Fails -->
<div style="overflow:auto;height:200px">…</div>
<!-- Better -->
<div style="overflow:auto;height:200px" tabindex="0" role="region" aria-label="Order summary">…</div>Drag-only interactions
Reordering or sliders that only work by dragging.
/* Fails */
a slider that only responds to pointer drag
/* Better */
also respond to arrow keys (and see 2.5.7 Dragging Movements)Can automated testing check 2.1.1?
Partly. A few patterns can be detected. Whether every function actually works from the keyboard needs someone (or something) to use it.
| axe-core 4.13.0 rule | What it checks |
|---|---|
scrollable-region-focusable | scrollable regions are keyboard accessible |
frame-focusable-content | frames with focusable content don't have tabindex="-1" |
server-side-image-map | server-side image maps aren't used |
What automation can't decide: Whether a custom control responds to Enter, Space or arrow keys; whether a hover-only menu can be opened; whether a click handler on a non-interactive element is the only way to do something. (axe-core's experimental focus-order-semantics best-practice rule flags focusable elements without an interactive role.)
A clean automated result is never proof that 2.1.1 is met. See why sites pass axe-core but fail real screen reader users.
How to test it by hand
- Put the mouse away. Start at the top of the page and press Tab repeatedly.
- Every link, button, field and custom control should receive focus. Note anything you'd click that Tab never reaches.
- Activate each control: Enter for links and buttons, Space for buttons and checkboxes, arrow keys for menus, tabs, radios and sliders.
- Open and close every menu, dialog, accordion and carousel from the keyboard.
- Complete the page's main task (sign up, add to cart, check out) using only the keyboard.
New to screen readers? Start with how to test a website with a screen reader and how to test keyboard-only navigation.
How Accessible helps (and where it stops)
Journeys run keyboard-only: a simulated screen-reader user tries to operate each control the task needs, so a clickable div or a hover-only menu on the path is reported at the step where the task stopped. Our journey-testing page lists "controls the keyboard cannot reach" (2.1.1) among the failures it catches. Real-user monitoring includes observers for focus traps and dead-end Tab presses in real sessions. The assistant tools keyboard walkthrough lists every Tab stop on one page and flags controls that look interactive but that Tab never reaches.
Where it stops: A journey tests the tasks you (or discovery) define, not every control on the site. Complex widgets still deserve a manual pass with real assistive technology. No automated tool, ours included, can certify that a criterion is met.
Related criteria
Sources
- Understanding Success Criterion 2.1.1: Keyboard (opens in a new tab). W3C Web Accessibility Initiative. Accessed October 18, 2026.
- Web Content Accessibility Guidelines (WCAG) 2.2, Success Criterion 2.1.1 (opens in a new tab). W3C Recommendation. Accessed October 18, 2026.
- axe-core rule descriptions (opens in a new tab). Deque Systems, axe-core 4.13.0. Accessed October 18, 2026.
Meeting a success criterion is not the same as legal compliance, which depends on the rules that apply to you. No automated tool can certify conformance.