Keyboard

How to recognize it

Put the mouse away and try to complete the same task using only Tab, Shift+Tab, Enter, Space, and the arrow keys. Custom controls (the same <div>-instead-of-<button> pattern from 4.1.2) are the usual cause: if it has no tabindex, Tab skips right over it and you can never reach it at all. A menu, tab strip, or dropdown that opens on mouse click but does nothing when you press Enter or Space on it is failing. Drag-and-drop interactions — reordering a list, moving a card between columns — fail if dragging is the only way to do it, since there's no keyboard equivalent for a mouse drag. That's a real failure, not the criterion's narrow exception: the exception only covers input where the path of movement itself matters (freehand drawing, signing your name) — reordering a list only cares about the start and end position, so a keyboard alternative is required and possible.

How to fix it

Reach for the native element first — <button>, <a>, <select>, <input> — and keyboard support comes for free. When a custom widget is unavoidable, give it tabindex="0" so Tab can reach it, and add a keydown handler that responds to Enter and/or Space the same way the click handler does; for composite widgets like tabs or menus, arrow keys are the expected pattern instead. You don't have to match a specific platform's exact key convention — WCAG only requires that the interface be operable by keyboard, not that it use one particular key for one particular action. For drag-and-drop, don't try to make the drag itself keyboard-operable — add a separate keyboard-usable equivalent instead, like 'move up' / 'move down' buttons next to each item.

Example

<div class="menu-toggle" onclick="toggleMenu()">Menu</div>

<div class="tab" onclick="selectTab(2)">Settings</div>

<li draggable="true" ondragstart="handleDrag(event)">Item</li>

<button onclick="toggleMenu()">Menu</button>

<div class="tab" role="tab" tabindex="0" onclick="selectTab(2)" onkeydown="if(['Enter',' '].includes(event.key)) selectTab(2)">Settings</div>

<li draggable="true" ondragstart="handleDrag(event)">Item <button aria-label="Move item up">↑</button> <button aria-label="Move item down">↓</button></li>

Resources

• W3C: Understanding Success Criterion 2.1.1 (Keyboard)

See also

• 2.1.2 No Keyboard Trap

  Two halves of full keyboard access: this criterion requires that everything can be reached and operated by keyboard in the first place; 2.1.2 requires that once focus is somewhere, it can always leave again. A component can satisfy one and fail the other.

• 4.1.2 Name, Role, Value

  Both criteria push you toward the same fix — native elements, or custom widgets rebuilt by hand. 4.1.2 is about the widget being named and announced; 2.1.1 is about it being reachable and operable without a mouse at all. A widget can pass one and fail the other.

• 2.4.3 Focus Order

  2.1.1 only asks whether a control can be reached and operated by keyboard at all; it says nothing about what order controls are reached in. That's 2.4.3's job.

• 2.4.7 Focus Visible

  2.1.1 only asks whether a control is reachable and operable by keyboard; it says nothing about whether you can see that it's focused. That's 2.4.7's job.

• 2.5.8 Target Size (Minimum)

  Two different accommodations for motor impairment: 2.1.1 makes sure everything works without a pointer at all; 2.5.8 makes sure that when a pointer is used, the target is big enough to hit reliably. Different input modality, overlapping group of users.

• 2.5.7 Dragging Movements

  For drag-to-reorder specifically, these two criteria want the exact same fix: 'move up' / 'move down' buttons. 2.1.1 needs them for keyboard access; 2.5.7 needs them for anyone who can't perform a precise drag. One pair of buttons satisfies both at once.