2.1.3 Keyboard (No Exception)

Level: AAA | Principle: Operable | Since: WCAG 2.0 | Automation: Manual


What This Means

All functionality of the content must be operable through a keyboard interface, with absolutely no exceptions. This is the stricter version of the Level A criterion 2.1.1, which allows exceptions for functionality that "requires input that depends on the path of the user's movement and not just the endpoints."

At Level A, drawing applications and flight simulators can be exempt because they fundamentally depend on analog, path-based input. At Level AAA, even these must provide keyboard alternatives. A drawing tool might offer coordinate input, a flight simulator might offer discrete controls.

This criterion exists because some users physically cannot use any pointing device. For these users, the keyboard (or keyboard-emulating assistive technology like sip-and-puff devices or switch access) is the only input method available.

Who This Affects

  1. Users with motor disabilities — may only be able to use keyboard, switch access, or voice control
  2. Users of sip-and-puff devices — these emulate keyboard input
  3. Users with tremors — keyboard input is often more reliable than mouse control
  4. Power users — keyboard access improves efficiency for everyone

Common Pitfalls

1. Drag-and-drop with no keyboard alternative

<!-- Bad: drag-only reorder -->
<ul id="sortable">
  <li draggable="true">Item 1</li>
  <li draggable="true">Item 2</li>
</ul>

<!-- Good: drag-and-drop plus keyboard controls -->
<ul id="sortable" role="listbox" aria-label="Reorderable list">
  <li role="option" tabindex="0" aria-grabbed="false" draggable="true">
    Item 1
    <button aria-label="Move Item 1 up" onclick="moveUp(this)">Up</button>
    <button aria-label="Move Item 1 down" onclick="moveDown(this)">Down</button>
  </li>
</ul>

2. Canvas-based interactions without keyboard input

<!-- Bad: canvas drawing with mouse only -->
<canvas id="draw" onmousemove="draw(event)"></canvas>

<!-- Good: canvas with keyboard coordinate input -->
<canvas id="draw"></canvas>
<div role="group" aria-label="Drawing controls">
  <label>X: <input type="number" id="x-coord"></label>
  <label>Y: <input type="number" id="y-coord"></label>
  <button onclick="drawPoint()">Place point</button>
</div>

3. Gesture-only controls

<!-- Bad: pinch-to-zoom only -->
<div id="map" ontouchstart="handlePinch(event)"></div>

<!-- Good: zoom buttons alongside gesture support -->
<div id="map" ontouchstart="handlePinch(event)"></div>
<div role="toolbar" aria-label="Map controls">
  <button onclick="zoomIn()" aria-label="Zoom in">+</button>
  <button onclick="zoomOut()" aria-label="Zoom out">-</button>
</div>

How to Test

  1. Disconnect or disable the mouse entirely and navigate through every feature of the site using only Tab, Shift+Tab, Enter, Space, Arrow keys, and Escape.
  2. Test all custom widgets: sliders, drag-and-drop lists, canvas interactions, maps, color pickers, and drawing tools.
  3. Verify that every single interactive element is reachable and activatable with keyboard alone, with no exceptions.
  4. Check that drag-and-drop has keyboard alternatives (move buttons, keyboard shortcuts) and canvas tools have coordinate input or arrow-key movement.
  5. Pass: Every feature on the site is fully operable with keyboard alone, including custom widgets and path-based tools.
  6. Fail: Any functionality requires a pointing device with no keyboard alternative provided.

How to Fix

  1. Ensure every mouse-dependent interaction has a keyboard equivalent
  2. Add keyboard event handlers (keydown, keyup) alongside mouse/pointer events
  3. For drag-and-drop, provide buttons or keyboard shortcuts for moving items
  4. For canvas/drawing tools, provide coordinate input fields or arrow-key movement
  5. For map interactions, provide zoom/pan buttons that work with keyboard focus

Resources

  1. WCAG Understanding 2.1.3
  2. How to Meet 2.1.3