Level AAA

2.1.3 (AAA) removes the path-dependent exception that 2.1.1 (A) allows, so any freehand, handwriting, or gesture interaction must also ship a keyboard alternative

2.1.3 Keyboard (No Exception)

In Plain Language

2.1.3 Keyboard (No Exception) is the Level AAA form of 2.1.1 Keyboard. The Level A rule carries one carve-out: content whose underlying function depends on the path of the user's movement, not just the endpoints, is exempt from the keyboard requirement[1]. 2.1.3 deletes that carve-out.

At AAA, a freehand drawing canvas, a handwriting capture field, or a pressure-sensitive music performance control cannot ship with mouse or stylus input alone. Each must expose a discrete keyboard path that reaches the same result -- a coordinate entry panel for the canvas, a typed-text fallback for handwriting, a stepper or option list for pitch selection.

Why It Matters

  • Keyboard-only operators include switch users, sip-and-puff users, head-tracker and eye-gaze users whose devices emit keystrokes, and voice-control users whose commands resolve to key events. None of them can produce a continuous analog path across a canvas. 2.1.1 acknowledges the physical reality that some functions (signature capture, freehand sketching) genuinely cannot be reproduced stroke-for-stroke from a keyboard; 2.1.3 responds by requiring a discrete-input alternative that reaches the same end state[1].
  • The mechanism is: decompose the analog task into endpoints and parameters, then let the keyboard user enter those directly. A curve picker becomes an (x, y) input. A drag-to-crop becomes four numeric fields. A drag-to-reorder becomes Move Up / Move Down buttons bound to the list items via the WAI-ARIA APG listbox pattern[2].
  • 2.1.3 is rarely a contractual requirement -- most procurement targets Level AA[3]. It is the goal for educational platforms, government products under voluntary AAA commitments, and inclusive-design work where "usable by the mouse user" is not the ceiling. Teams that already pass 2.1.1 can reach AAA by auditing every function they previously excluded under the path-dependent clause and shipping a keyboard twin for each.
  • Passing 2.1.3 also strengthens automation: a function reachable through discrete keyboard input is reachable through scripted testing, assistive-tech macros, and voice commands without the operator ever touching a pointing device.

Examples

Do: Drawing tool with keyboard coordinate entry

<canvas> with keyboard coordinate input panel

✔ Users can draw freehand with a mouse or enter exact coordinates via keyboard -- both paths produce the same result

<div class="drawing-tool">
  <canvas id="draw-area" tabindex="0"
    aria-label="Drawing canvas"></canvas>

  <!-- Keyboard alternative for freehand drawing -->
  <fieldset>
    <legend>Add point by coordinates</legend>
    <label>X: <input type="number" id="coord-x" /></label>
    <label>Y: <input type="number" id="coord-y" /></label>
    <button>Add point</button>
  </fieldset>
</div>
Don't: Drawing tool with mouse only

<canvas onmousedown='startDraw()'> -- mouse events only

✘ No keyboard alternative exists -- keyboard users cannot draw at all

<!-- FAILS 2.1.3: mouse-only drawing, no keyboard path -->
<canvas id="draw-area"
  onmousedown="startDraw(event)"
  onmousemove="continueDraw(event)"
  onmouseup="endDraw()">
</canvas>

<!-- No keyboard-based alternative provided.
     Under 2.1.1 (Level A) this might pass the
     path-dependent exception, but under 2.1.3
     (Level AAA) it fails -- all functionality
     must be keyboard-operable. -->
Do: Drag-and-drop list with keyboard reorder

<li draggable='true'> with arrow-key reorder buttons

✔ Items can be dragged with a mouse or reordered with keyboard arrow keys and move buttons

<ul role="listbox" aria-label="Task priority">
  <li role="option" draggable="true">
    Task A
    <button aria-label="Move Task A up">Up</button>
    <button aria-label="Move Task A down">Down</button>
  </li>
  <li role="option" draggable="true">
    Task B
    <button aria-label="Move Task B up">Up</button>
    <button aria-label="Move Task B down">Down</button>
  </li>
</ul>

<!-- Keyboard alternative: arrow keys or buttons
     reorder items, achieving the same result
     as mouse drag-and-drop. -->
Don't: Gesture-only image crop

<div class='crop-handle'> -- drag handles only, no numeric inputs

✘ Crop region can only be set by dragging handles -- no keyboard alternative to enter crop dimensions

How to Fix It

  1. Enumerate the functions you excluded under 2.1.1. The path-dependent exception in 2.1.1 is narrow: it covers functions where the shape of the movement, not just the start and end points, is the information being captured. Freehand drawing, signature capture, handwriting recognition, painting with pressure, and live musical performance typically qualify. Anything you exempted under 2.1.1 is the work list for 2.1.3[1].
  2. Decompose each path-dependent interaction into discrete parameters. A drawing tool exposes primitives (line, curve, shape) with coordinate inputs. A crop region exposes top, left, width, height as numeric fields. A music picker exposes pitch, duration, and velocity as selects or steppers. The keyboard path does not have to feel like the mouse path -- it has to reach the same output state.
  3. Implement the roving-tabindex or arrow-key pattern for reorder interactions. Drag-and-drop lists, kanban columns, and ranked selects should expose Move Up and Move Down (or Home / End / Page Up / Page Down) bound to the focused item, following the APG listbox or grid pattern[2].
  4. Expose the keyboard alternative in the same DOM region as the pointer control. A hidden "accessible mode" toggle is a failure path -- users should not have to discover or opt in to the keyboard interface. Place the numeric inputs, move buttons, or coordinate panel next to the canvas or drag surface.
  5. Test with the pointing device disconnected. Unplug the mouse, disable the trackpad, and walk every task on the page using Tab, Shift+Tab, arrow keys, Enter, and Space. Any task that cannot be completed fails 2.1.3 -- and, if it does not qualify for the path-dependent exception, also fails 2.1.1.
  6. Do not claim AAA on a page that still relies on onmousedown / onmousemove without a keyboard twin. 2.1.3 is a whole-page commitment. A single un-remediated canvas blocks AAA conformance for the page it sits on[3].

References

  1. [1] W3C (2023). Understanding Success Criterion 2.1.3: Keyboard (No Exception). W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/keyboard-no-exception.html ↩ ↩ ↩
  2. [2] W3C (2024). WAI-ARIA Authoring Practices Guide. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/ARIA/apg/ ↩ ↩
  3. [3] W3C (2023). Web Content Accessibility Guidelines (WCAG) 2.2. W3C, Accessed 2026-04-07. https://www.w3.org/TR/WCAG22/ ↩ ↩