2.1.3 Keyboard (No Exception)
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, with no exceptions.
What this rule means
WCAG 2.1.3 is the AAA-level version of 2.1.1 (Keyboard). While 2.1.1 allows exceptions for functionality that fundamentally requires path-dependent input (such as freehand drawing), 2.1.3 removes all exceptions. Every single piece of functionality must be fully operable through a keyboard interface, regardless of how the functionality is designed.
This is a significantly higher bar than 2.1.1. Meeting this criterion means that even features like freehand drawing, handwriting input, or flight simulator controls must provide keyboard-operable alternatives. Organizations targeting AAA conformance must design every feature with keyboard-only operation as a hard requirement from the start.
Why it matters
While 2.1.1 provides practical accommodations by allowing exceptions for inherently path-dependent input, this AAA criterion recognizes that for maximum inclusivity, even those edge cases should have keyboard alternatives. Some users physically cannot use any pointing device and depend entirely on keyboard input for all computer interaction.
Meeting this criterion ensures that no user is excluded from any functionality regardless of their input method. It represents the gold standard of keyboard accessibility and is particularly important for government, healthcare, and educational platforms where universal access is a core requirement.
Related axe-core rules
There are no automated axe-core rules specific to this criterion. Since it is an extension of 2.1.1 with no exceptions, testing requires comprehensive manual review of every interactive feature to ensure keyboard operability with no exceptions allowed.
How to test
Testing is the same as 2.1.1 but with stricter requirements — no exceptions are permitted.
- Perform a complete keyboard-only audit of every feature on the site. Identify all interactive functionality.
- For each feature, verify it is fully operable using only keyboard input (Tab, Shift+Tab, Enter, Space, Arrow keys, Escape).
- Specifically test features that might have been exempt under 2.1.1: drawing tools, drag-and-drop, gesture-based interactions.
- Verify that keyboard alternatives produce equivalent results — not degraded versions of the functionality.
- Document any functionality that lacks keyboard operability as a AAA failure.
How to fix
Provide keyboard alternatives for every interaction, including those that would be exempt under 2.1.1.
Drawing tool with keyboard alternative
<!-- Provide coordinate-based input as keyboard alternative -->
<canvas id="drawing-canvas" aria-label="Drawing area"></canvas>
<!-- Keyboard-accessible alternative -->
<div role="group" aria-label="Drawing coordinates">
<label for="x-coord">X coordinate:</label>
<input type="number" id="x-coord" min="0" max="500">
<label for="y-coord">Y coordinate:</label>
<input type="number" id="y-coord" min="0" max="500">
<button onclick="addPoint()">Add Point</button>
<button onclick="connectPoints()">Connect Points</button>
<button onclick="undoLast()">Undo</button>
</div>
Drag-and-drop with keyboard reordering
<!-- Sortable list with keyboard support -->
<ul role="listbox" aria-label="Reorderable list">
<li role="option" tabindex="0"
aria-grabbed="false"
onkeydown="handleReorder(event, this)">
Item 1
<button aria-label="Move Item 1 up"
onclick="moveUp(this)">▲</button>
<button aria-label="Move Item 1 down"
onclick="moveDown(this)">▼</button>
</li>
</ul>
<script>
function handleReorder(e, item) {
if (e.altKey && e.key === 'ArrowUp') {
e.preventDefault();
moveUp(item);
} else if (e.altKey && e.key === 'ArrowDown') {
e.preventDefault();
moveDown(item);
}
}
</script>
Common mistakes
- Assuming that path-dependent features (drawing, gesture input) do not need keyboard alternatives because they are exempt under Level A.
- Providing degraded keyboard alternatives that do not offer the same functionality as the mouse-based version.
- Omitting keyboard support for third-party components or embedded content, assuming exceptions apply.
- Not testing complex interaction patterns (multi-step workflows, drag operations) thoroughly with keyboard.
- Relying on 2.1.1 compliance and assuming AAA iş automatically met.
Resources
- WebAIM: Keyboard Accessibility— WebAIM
- Deque University: Keyboard Accessibility— Deque University
- W3C WAI: ARIA Authoring Practices— W3C WAI