WCAG 2.1.3: Keyboard (No Exception)

Who this helps

The keyboard interface is the universal adapter of assistive technology. People who cannot use a mouse — because of tremor, paralysis, missing limbs, chronic pain, or low vision that makes tracking a pointer impossible — almost always operate the web through something that emits keyboard events:

For these users, a feature that is pointer-only is not merely inconvenient — it does not exist. 2.1.3 says that at the highest conformance level, nothing on the page is allowed to not exist for them.

2.1.3 vs. 2.1.1: what actually changes

Under 2.1.1, a “path-dependent” function — one where the route the pointer travels matters, not just where it starts and ends — is exempt. Classic examples: freehand drawing in a paint tool, a handwritten signature pad, steering in a driving game. Everything else already had to be keyboard-operable at Level A.

2.1.3 removes the exemption. Three things follow:

• →Drag-and-drop was never exempt — dragging a card between columns depends only on start and end points, so it already needed a keyboard alternative under 2.1.1. 2.1.3 changes nothing there; it just makes the requirement easier to remember: everything, always.
• →Genuinely path-dependent features now need an equivalent. A signature pad needs a typed-signature option; a freehand annotation tool needs keyboard-placeable shapes or text notes that serve the same purpose.
• →The keystroke-timing clause stays. Neither criterion allows interfaces that require specific timings for individual keystrokes — that protection exists at Level A and simply carries through.

Also related but distinct: 2.1.2 No Keyboard Trap (A) ensures focus can always leave a component, and 2.5.7 Dragging Movements (AA) requires a single-pointer alternative to dragging. 2.1.3 sits above all of them: total keyboard operability.

Pass and fail examples

Code examples

Keyboard alternative to drag-and-drop reordering

The grab-and-move pattern: Space (or Enter) picks up the item, arrow keys move it, Space drops it, Escape cancels. Announce each move to a live region so screen reader users hear the result.

<ul role="listbox" aria-label="Task order">
  <li role="option" tabindex="0" aria-describedby="reorder-hint">
    Write launch email
  </li>
  <!-- … -->
</ul>
<p id="reorder-hint" class="sr-only">
  Press Space to grab, arrow keys to move, Space to drop, Escape to cancel.
</p>
<div aria-live="polite" class="sr-only" id="move-status"></div>

<script>
  let grabbed = null;
  list.addEventListener("keydown", (e) => {
    const item = e.target.closest("[role='option']");
    if (!item) return;
    if (e.key === " ") {
      e.preventDefault();
      grabbed = grabbed ? null : item; // grab / drop
      status.textContent = grabbed
        ? `${item.textContent} grabbed`
        : `${item.textContent} dropped`;
    }
    if (grabbed && e.key === "ArrowUp" && item.previousElementSibling) {
      item.parentNode.insertBefore(item, item.previousElementSibling);
      item.focus();
      status.textContent = `Moved up to position ${position(item)}`;
    }
    if (grabbed && e.key === "ArrowDown" && item.nextElementSibling) {
      item.parentNode.insertBefore(item.nextElementSibling, item);
      item.focus();
      status.textContent = `Moved down to position ${position(item)}`;
    }
  });
</script>

A typed alternative to a path-dependent signature

Keep the canvas for pointer users; make the keyboard route a first-class equal, not a degraded fallback.

<fieldset>
  <legend>Sign this document</legend>

  <div role="radiogroup" aria-label="Signature method">
    <label><input type="radio" name="sig-mode" value="draw" /> Draw signature</label>
    <label><input type="radio" name="sig-mode" value="type" checked /> Type signature</label>
  </div>

  <!-- Pointer path (optional enhancement) -->
  <canvas id="sig-pad" width="400" height="120" hidden></canvas>

  <!-- Keyboard path (always available) -->
  <label for="sig-text">Type your full legal name</label>
  <input id="sig-text" type="text" autocomplete="name" />
  <p>Your typed name will be rendered as your signature.</p>
</fieldset>

Never rely on hover or pointer events alone

/* ✗ Reveal only on hover — keyboard users never see it */
.card .actions { display: none; }
.card:hover .actions { display: flex; }

/* ✓ Reveal on hover AND keyboard focus within the card */
.card:hover .actions,
.card:focus-within .actions { display: flex; }

Common failures

• ✗Treating the 2.1.1 path exception as permanent — shipping a drawing, sketching, or signature feature with no keyboard-operable equivalent and still claiming AAA.
• ✗Drag-only interactions: file dropzones, sortable lists, sliders, or map pins that respond to pointer drags but ignore the keyboard entirely.
• ✗Custom widgets built from <div> and <span> with click handlers but no tabindex, no keydown handling, and no focus styles.
• ✗Actions that appear only on mouse hover (row action buttons, tooltips, mega-menus) with no focus-based equivalent.
• ✗Requiring rapid or precisely-timed key presses — double-tap shortcuts with tight windows, or hold-to-confirm patterns with no alternative.
• ✗Canvas- or WebGL-based UI that paints its own controls and never exposes them as focusable, operable elements.
• ✗Keyboard alternatives that exist but are hidden behind a pointer-only affordance, such as an options menu that itself opens only on right-click.

How to test for 2.1.3

1. 1

   Unplug the mouse

   Literally, if you can. Put the pointer away and attempt to complete every task the page offers using only Tab, Shift+Tab, Enter, Space, arrow keys, and Escape. Anything you cannot do is a candidate failure.

2. 2

   Inventory every function, not every element

   The unit of testing is functionality: 'reorder tasks', 'sign the contract', 'crop the image'. For each function, ask whether some keyboard-only route achieves the same outcome — it does not have to be the same mechanics.

3. 3

   Hunt the path-dependent features specifically

   Drawing surfaces, signature pads, annotation tools, gesture inputs, games. These pass 2.1.1 without a keyboard route, so they are exactly where 2.1.3 failures hide. Each needs an equivalent alternative.

4. 4

   Check for timing dependence

   Operate slowly. Press keys one at a time with long pauses. If any interaction requires speed — chorded keys within a window, hold durations, rapid double-presses — it fails unless an untimed alternative exists.

5. 5

   Verify with a screen reader

   Run through the same tasks with NVDA or VoiceOver. This confirms the keyboard routes are also perceivable: focus is visible and announced, state changes are reported, and instructions for custom key patterns are exposed.

Automated scanners can flag missing tabindex or click-only handlers, but only a human can judge whether a keyboard route truly accomplishes the same function. Work through the full WCAG 2.2 checklist alongside this criterion.

Frequently asked questions