WCAG 2.1.3 Keyboard (No Exception): Full Keyboard Access for Every Function

What This Criterion Requires

WCAG 2.1.3 requires that all functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, with absolutely no exceptions. This is the enhanced, AAA-level version of criterion 2.1.1 (Keyboard, Level A), which allows exceptions for functions that require path-dependent input where the underlying function depends on the user's movement path rather than just endpoints. Criterion 2.1.3 removes even that exception, demanding that every single feature and interaction on a website or application be fully achievable using only a keyboard. This is the gold standard for keyboard accessibility. It recognizes that many assistive technologies operate by generating keyboard input: switch devices, sip-and-puff systems, eye-tracking systems, voice recognition software, and on-screen keyboards all typically interact with web content through the keyboard API. If any functionality requires mouse-specific gestures like freehand drawing, drag-and-drop positioning, or multi-touch interactions without a keyboard alternative, users of these technologies are completely locked out. Meeting this criterion requires creative design solutions: freehand drawing tools must offer coordinate input or stamp-based alternatives, drag-and-drop interfaces must provide keyboard-driven move commands, and drawing applications must support keyboard-based path creation. While challenging, the result is a truly universally operable interface.

Why It Matters

Keyboard accessibility without exception is the cornerstone of digital inclusion for people with severe motor disabilities. Users who rely on switch access systems, which may consist of a single button that cycles through options, depend entirely on keyboard-compatible interfaces. Sip-and-puff devices used by people with quadriplegia translate breath pressure into keyboard events. Eye-tracking systems and head-pointing devices ultimately generate keyboard or simulated keyboard input. For these users, there is no workaround if a function requires a mouse movement path. They simply cannot use that feature, period. The Level A exception for path-dependent input, while practical, creates a class of excluded functionality that disproportionately affects the most severely disabled users. Consider a person with ALS who communicates and works entirely through eye-tracking: if a collaborative whiteboard tool requires freehand drawing with no keyboard alternative, that person is excluded from team collaboration. If a data visualization tool requires drag-and-drop to build charts with no keyboard option, that person cannot perform data analysis. The AAA standard pushes designers and developers to find creative, inclusive alternatives that maintain functionality while enabling keyboard-only operation. This benefits power users as well, who often prefer keyboard shortcuts for speed and efficiency, and it ensures compatibility with the broadest possible range of assistive technologies, including future devices that have not yet been invented.

Common Failures and How to Fix Them

<div class="kanban-board">
  <div class="column" id="todo">
    <div class="card" draggable="true"
      ondragstart="drag(event)">Task 1</div>
  </div>
  <div class="column" id="done"
    ondrop="drop(event)"
    ondragover="allowDrop(event)">Done</div>
</div>
<!-- No keyboard interaction handlers -->

<div class="kanban-board" role="application"
  aria-label="Task board">
  <div class="column" role="group" aria-label="To Do">
    <div class="card" role="listitem" tabindex="0"
      aria-grabbed="false"
      onkeydown="handleCardKeyboard(event)">
      Task 1
      <button class="move-btn" aria-label="Move Task 1"
        onclick="openMoveDialog(this)">
        Move to...</button>
    </div>
  </div>
</div>
<!-- handleCardKeyboard supports Arrow keys to
     reorder, Enter/Space to grab, Escape to cancel -->

<canvas id="signature-pad" width="400" height="200">
</canvas>
<script>
  canvas.addEventListener('mousedown', startDrawing);
  canvas.addEventListener('mousemove', draw);
  canvas.addEventListener('mouseup', stopDrawing);
  // No keyboard alternative provided
</script>

<div role="application" aria-label="Signature input">
  <canvas id="signature-pad" width="400" height="200"
    tabindex="0"
    aria-label="Draw your signature or type it below">
  </canvas>
  <div class="keyboard-alternative">
    <label for="typed-sig">Type your signature:</label>
    <input type="text" id="typed-sig"
      style="font-family: 'Cedarville Cursive', cursive;
             font-size: 24px;">
    <button onclick="applyTypedSignature()">
      Use typed signature</button>
  </div>
</div>

<div id="venue-map" onclick="selectSeat(event)">
  <img src="seating-chart.png" alt="Venue seating chart"
    usemap="#seats">
  <!-- Click on the map to select your seat -->
</div>

<div id="venue-map" role="application"
  aria-label="Seat selection">
  <img src="seating-chart.png"
    alt="Venue seating chart showing sections A through F">
  <label for="section-select">Select section:</label>
  <select id="section-select">
    <option>Section A - Front Left</option>
    <option>Section B - Front Right</option>
  </select>
  <label for="seat-select">Select seat:</label>
  <select id="seat-select">
    <option>Row 1, Seat 1 - $45</option>
    <option>Row 1, Seat 2 - $45</option>
  </select>
  <button onclick="confirmSeat()">Select this seat</button>
</div>

How to Test

1. Unplug or disable your mouse and attempt to use every feature on the page using only the keyboard (Tab, Shift+Tab, Enter, Space, Arrow keys, Escape).
2. Identify any functionality that relies on mouse-specific interactions such as drag-and-drop, freehand drawing, click-to-position on maps, or hover-dependent actions.
3. For each mouse-dependent feature found, verify that a keyboard-accessible alternative exists that provides equivalent functionality.
4. Test with assistive technology such as a screen reader (NVDA, JAWS, VoiceOver) to confirm that keyboard-alternative controls are properly announced and operable.

CMS-Specific Guidance

This criterion commonly causes issues on these platforms:

• Wordpress Accessibility Checklist
• Shopify Accessibility Checklist
• Squarespace Accessibility Checklist
• Webflow Accessibility Checklist

Further Reading

• Keyboard Navigation Testing
• Accessible Navigation Guide
• Accessible Forms Guide

Related WCAG Criteria

• WCAG 2.1.1
• WCAG 2.1.2
• WCAG 2.4.7