WCAG 2.1.3 — Keyboard (No Exception)

What this requires

All functionality must be operable through a keyboard interface without requiring specific timings for individual keystrokes. The "specific timings" carve-out from 2.1.1 — which allows genuinely analogue inputs like freehand drawing — is removed at Level AAA. If a user can do it with a mouse, they must be able to do it from a keyboard, full stop.

How AI coding tools fail this

Where 2.1.1 lets a freehand canvas off the hook, 2.1.3 doesn't. AI tools that ship a "draw your signature here" widget, a slider controlled only by pointer drag, or a continuous-motion video scrubber fail this criterion unless they also provide a keyboard equivalent — typed coordinate input for a signature, arrow keys for a slider, J/L keystrokes for video scrubbing.

The second pattern: timing-dependent inputs like long-press, double-click within a window, or click-and-hold-to-confirm. The criterion bans those from being the only path to the function. A keyboard equivalent must exist, and it must not depend on timing between keystrokes.

Failing examples

A signature pad with no keyboard alternative:

<SignaturePad onCapture={save} />

A "press and hold to delete" button with no keyboard equivalent:

<button
  onMouseDown={startHoldTimer}
  onMouseUp={cancelHoldTimer}
>
  Hold to delete
</button>

Passing examples

Offer a keyboard-driven alternative for the signature:

<>
  <SignaturePad onCapture={save} />
  <details>
    <summary>Sign without drawing</summary>
    <label>
      Type your full name to sign:
      <input
        type="text"
        value={typedSignature}
        onChange={(e) => setTypedSignature(e.target.value)}
      />
    </label>
    <button onClick={confirmTypedSignature}>Sign</button>
  </details>
</>

A confirm-by-hold pattern with a keyboard equivalent:

<>
  <button onMouseDown={startHoldTimer} onMouseUp={cancelHoldTimer}>
    Hold to delete
  </button>
  <button onClick={openConfirmDialog}>
    Delete (with confirmation)
  </button>
</>

Edge cases

AAA target is rare. Most projects target AA and the looser 2.1.1 wording. Confirm with stakeholders before scoping for 2.1.3.
Drawing apps and creative tools that need freehand input as a primary mode typically meet 2.1.3 by offering a non-drawing alternative for the surrounding interactions (file open, save, share), but not for the drawing itself. The Understanding doc acknowledges essential cases.
Sliders and ranges must support arrow keys (and ideally Home / End / Page Up / Page Down). A native <input type="range"> gets this for free.
Video and audio scrubbing must be operable from the keyboard. J / K / L is the standard set, but Left/Right with seek-by-time also works.

How Jeikin handles this

This is a guided review per interactive widget. The dashboard records each non-standard input pattern (signature pads, drag handles, long press) and the keyboard alternative that's been provided. The evidence is the reviewer's confirmation of the keyboard path.

References

W3C — Understanding 2.1.3 Keyboard (No Exception) (opens in new tab)