WCAG 2.1.1: Keyboard
Millions of people never touch a mouse — they drive the web with a keyboard, a switch, a sip-and-puff device, or their voice. This criterion asks for one thing: every function must be operable through a keyboard interface. It does not ask you to remove the mouse; it asks you to make sure the keyboard works too. Get this right and your whole interface opens up to the assistive technologies that speak the language of keystrokes.
The success criterion, in full
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints.
Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.
Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.
The “keyboard interface” is deliberately broad: it includes physical keyboards, on-screen keyboards, and any assistive technology that generates keystroke input — so meeting this criterion also serves speech-input and switch users who ultimately drive the page through keyboard events.
Who this helps
The keyboard is the universal input. Countless assistive technologies present themselves to the page as a keyboard, so “works with a keyboard” quietly means “works with all of these”:
Keyboard-only users
People who cannot or choose not to use a mouse — because of a tremor, repetitive strain injury, or simple preference — navigate entirely by Tab, arrow keys, Enter, and Space.
People with motor and mobility disabilities
Fine pointer control can be difficult or impossible. A keyboard interface offers discrete, forgiving key presses instead of precise mouse targeting.
Screen reader users
Blind and low-vision users drive their screen reader — and therefore the whole page — through keyboard commands. If a control isn't keyboard operable, it effectively doesn't exist for them.
Switch and sip-and-puff users
People with severe motor impairments operate the computer through one or two switches that emulate keystrokes. Everything they do arrives as keyboard input.
Voice-control users
Speech-recognition software often works by moving focus and issuing keyboard-equivalent commands, so keyboard operability is what makes 'click Save' actually work.
Keyboard power users
Developers, data-entry staff, and anyone working at speed keep their hands on the keyboard. Full keyboard support makes your product faster for everyone, not only people with disabilities.
What the requirement covers
“All functionality” is expansive: every link, button, form field, menu, tab set, slider, accordion, modal, drag-and-drop interaction, and custom widget on the page. If a sighted mouse user can do it, a keyboard user must be able to do it too. In practice this breaks down into three obligations for each interactive element:
- Reachable. The element must be in the keyboard tab order (or reachable via a documented key, such as an arrow key inside a menu). Native interactive elements are focusable automatically; custom widgets need tabindex="0".
- Operable. Once focused, the element must respond to the expected keys — Enter or Space to activate a button, Enter to follow a link, arrow keys to move within composite widgets like radio groups, tabs, and menus.
- Free of timing requirements. Activation must not depend on holding a key for a precise duration or pressing keys within a strict window. Users of switches and on-screen keyboards cannot guarantee that timing.
- Semantically announced. Custom controls must expose the right role (role="button", role="tab", etc.) so assistive technology tells the user what the focused element is and how to operate it.
The one exception: path-dependent input
The criterion carves out functionality whose input depends on the pathof the user’s movement rather than just its start and end points — freehand drawing, watercolor-style painting, and some continuous drag gestures where the exact route is the content. A keyboard cannot reproduce an arbitrary continuous stroke, so that specific input is exempt. The exception is narrow: the tools around the canvas (colour pickers, brush size, undo, save) are not path-dependent and must still be keyboard operable. Where a drag has a meaningful start and end but not a meaningful path, a keyboard alternative is expected — see 2.5.7 Dragging Movements. The stricter Level AAA sibling, 2.1.3 Keyboard (No Exception), removes even this allowance.
Pass and fail examples
✓ Passes 2.1.1
- Native
<button>,<a href>, and form controls, reachable by Tab and activated by Enter/Space. - A custom dropdown with
role="menu",tabindex, and arrow-key navigation. - Drag-and-drop that also offers a keyboard path (move buttons, or cut/paste with Enter and arrow keys).
- A canvas paint app whose tools and menus are keyboard operable, even though the freehand stroke itself is exempt.
- A modal you can open, operate, and close entirely from the keyboard.
✗ Fails 2.1.1
- A
<div onclick>with notabindexor key handler — Tab skips it entirely. - A menu that only opens on
mouseoverwith no focus or keyboard equivalent. - Drag-and-drop reordering that has no keyboard alternative at all.
- A control that only fires after a double-press within a fixed time window.
- A custom slider you can focus but not adjust, because it ignores the arrow keys.
Code examples
Prefer native elements
The simplest way to be keyboard operable is to use the elements the browser already makes focusable and activatable. A clickable <div> is invisible to the keyboard; a <button> is not.
<!-- ✗ Mouse-only: not in the tab order, ignores Enter/Space -->
<div class="btn" onclick="save()">Save</div>
<!-- ✓ Native button: focusable and operable for free -->
<button type="button" onclick="save()">Save</button>
<!-- ✗ A link faked from a span -->
<span class="link" onclick="location='/docs'">Docs</span>
<!-- ✓ A real link: Tab reaches it, Enter follows it -->
<a href="/docs">Docs</a>When you must build a custom control
If a native element genuinely will not do, you have to recreate three things the browser gave you for free: focusability, a role, and keyboard activation.
<!-- ✓ Custom button, made keyboard operable -->
<div
role="button"
tabindex="0"
onclick="toggleSidebar()"
onkeydown="if (event.key === 'Enter' || event.key === ' ') {
event.preventDefault();
toggleSidebar();
}"
>
Toggle sidebar
</div>The same pattern in React — note that both the pointer and keyboard paths call the same handler:
function ToggleButton({ onToggle, children }) {
const activate = () => onToggle()
return (
<div
role="button"
tabIndex={0}
onClick={activate}
onKeyDown={(e) => {
if (e.key === "Enter" || e.key === " ") {
e.preventDefault() // stop Space from scrolling
activate()
}
}}
>
{children}
</div>
)
}A keyboard alternative to dragging
Drag-and-drop is not path-dependent — the drop target is an endpoint, not a route — so it needs a keyboard route. A common pattern is arrow-key reordering on a focused list item.
<li
tabindex="0"
role="option"
aria-label="Task: Draft report. Use arrow keys to reorder."
onkeydown="handleReorder(event)"
>
Draft report
</li>
<script>
function handleReorder(e) {
if (e.key === 'ArrowUp') { e.preventDefault(); moveUp(e.target) }
if (e.key === 'ArrowDown') { e.preventDefault(); moveDown(e.target) }
}
</script>Interactive demo
Tab through the controls below. Four of them take focus in turn and show a visible focus ring; the mouse-only “Delete” div is skipped completely — a hands-on illustration of exactly what 2.1.1 prevents.
Tab-order playground
Click “Start”, then press Tab repeatedly to move through the controls. Watch the status line: four controls receive focus in turn, but the mouse-only “Delete” div is silently skipped — a keyboard user can never reach it.
Focused: nothing yet
Last activated: nothing yet
- Home (link). A real <a href> — in the tab order, activates with Enter.
- Save (button). A native <button> — focusable, fires on Enter and Space.
- Search field (input). A native <input> — focusable and editable from the keyboard.
- Menu (role=button, tabindex=0). A <div> made accessible with tabindex=0 and a keydown handler.
- Delete (div onClick only). A <div onClick> with no tabindex and no key handler — Tab skips it entirely, so keyboard users can never reach it.
Common failures
- Custom controls built from <div> or <span> with an onClick but no tabindex and no keyboard handler — Tab never reaches them.
- Mouse-only event handlers (onmouseover, onmousedown) with no onfocus/onkeydown equivalent, so hover menus and drag handles are unusable by keyboard.
- Widgets that are focusable but not operable — a custom slider or listbox you can Tab to but cannot change with the arrow keys.
- Drag-and-drop reordering, sorting, or file handling with no keyboard alternative provided.
- Functionality that requires specific keystroke timing, such as a double-press within a fixed window, with no untimed alternative.
- Scripts wired only to click or pointer events, so Enter and Space do nothing on interactive elements.
- Removing an element from the tab order with tabindex="-1" (or a positive tabindex that scrambles the order) on something the user needs to reach.
- Click targets that are images or icons with an onClick but no role, name, or keyboard behaviour.
How to test for 2.1.1
- 1
Put the mouse away
Physically move your mouse aside or commit to not touching it. Everything from here on must be done with the keyboard alone — that is the whole test.
- 2
Tab through the entire page
Press Tab (and Shift+Tab) from the top. Confirm you can reach every interactive element — links, buttons, form fields, custom widgets — and that nothing you need is skipped.
- 3
Activate every control
On each focused element, use the expected keys: Enter to follow a link, Enter or Space to press a button, and arrow keys to move within composite widgets like menus, tabs, radio groups, and sliders.
- 4
Check custom components in particular
Anything not built from a native element is where failures hide. Verify each custom control is focusable, exposes a role, and responds to keyboard activation — not just clicks.
- 5
Hunt for mouse-only functionality
Look specifically for hover-only menus, drag-and-drop, and click-only handlers. If a feature can only be triggered with the pointer, it fails — provide a keyboard route.
- 6
Watch for timing traps
Confirm no action depends on holding a key for a precise time or pressing keys within a strict window. Then run an automated scan (axe, WAVE, Lighthouse) as a floor — it catches unnamed and non-focusable controls, but only manual testing proves true operability.
While you are keyboard testing, keep an eye on the companion criteria: 2.1.2 No Keyboard Trap, 2.4.3 Focus Order, and 2.4.7 Focus Visible. For a full pass, work through the WCAG 2.2 checklist.
Related Success Criteria
Focus can be moved away from any component using standard keyboard methods.
All functionality is available from a keyboard interface without exception.
Single character key shortcuts can be turned off or remapped.
Users can turn off, adjust, or extend time limits.
Moving, blinking, or auto-updating content can be paused, stopped, or hidden.
Frequently asked questions
What does WCAG 2.1.1 Keyboard require?
It requires that all functionality of the content is operable through a keyboard interface, without requiring specific timings for individual keystrokes. In plain terms: anything a user can do with a mouse, tap, or other pointer must also be achievable using only a keyboard — reaching every interactive element, activating it, and moving through composite widgets. The one exception is functionality that inherently depends on the path of the user's movement rather than just its start and end points, such as freehand drawing. It is a Level A criterion and part of WCAG since 2.0.
Does 2.1.1 mean I have to remove mouse support?
No. The criterion is additive, not exclusive. You can — and should — keep mouse, touch, and pointer support; the requirement is simply that keyboard operation also works. A control that responds to a click must equally respond to keyboard focus and activation. Mouse-only interactions (a div with just an onclick, a hover-only menu, a drag that has no keyboard alternative) are what fail, not the presence of mouse support itself.
What is the 'path-dependent' exception?
The exception covers functionality that requires input based on the path of the user's movement and not just the endpoints — the classic example is freehand drawing in a paint program, where the exact route of the pointer is the content. A keyboard cannot reproduce an arbitrary continuous stroke, so that specific input is exempt. Note the exception is narrow: the surrounding tools (color pickers, brush selectors, save, undo) are not path-dependent and must still be keyboard operable. Related guidance appears in 2.5.7 Dragging Movements, which requires single-pointer alternatives to drag gestures.
How is 2.1.1 different from 2.1.3 Keyboard (No Exception)?
2.1.1 (Level A) allows the narrow path-dependent exception described above. 2.1.3 Keyboard (No Exception) is the Level AAA version of the same idea, but it removes that exception entirely — every function, including path-dependent ones, must be keyboard operable. Most teams target 2.1.1; 2.1.3 is relevant only when aiming for AAA conformance.
Does 2.1.1 require visible focus indicators or a logical tab order?
Not directly — those are handled by companion criteria. 2.1.1 is about operability: can you reach and use everything with a keyboard at all? 2.4.7 Focus Visible (Level AA) requires that the focused element is visually indicated, and 2.4.3 Focus Order (Level A) requires that the navigation order is meaningful. In practice you address all three together, because a control that is technically reachable but invisible when focused, or reached in a nonsensical order, is a poor experience even if it passes 2.1.1 on its own.
What about keyboard traps?
A keyboard trap — where focus enters a component and cannot leave using the keyboard — is a separate criterion, 2.1.2 No Keyboard Trap (Level A). It sits alongside 2.1.1 under Guideline 2.1 Keyboard Accessible. You need both: 2.1.1 ensures functionality is reachable and operable by keyboard, and 2.1.2 ensures the user can always move focus back out again.
Does the 'without specific timings' clause ban keyboard shortcuts?
No. It means a function must not require a keystroke to be held for a precise duration, or two keystrokes to be pressed within a strict time window, in a way a user cannot control. Ordinary shortcuts and key sequences are fine; what fails is functionality that only works if the user has particular motor timing — for example a 'double-press within 300ms' gesture with no untimed alternative. This protects users of switch devices, sip-and-puff systems, and on-screen keyboards who cannot guarantee fast, precise timing.