WCAG 2.1.3: Keyboard (No Exception)

What This Rule Means

WCAG 2.1.3 — Keyboard (No Exception) is a Level AAA success criterion under WCAG 2.1 and 2.2 that extends WCAG 2.1.1 (Keyboard, Level A) by removing every carve-out. Specifically, it states: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. The critical distinction from 2.1.1 is the absence of the exception clause that exempts functionality where the underlying function requires input that depends on the path of the user's movement, not just the endpoints.

Under 2.1.1, developers can legitimately exclude features like freehand drawing canvases, gesture-based painting tools, or path-sensitive drag interfaces from keyboard support, because the user's exact pointer path determines the output. WCAG 2.1.3 eliminates this exception entirely. Under this criterion, every single function—including drawing, dragging, path-dependent gestures, and any interaction that has historically relied on pointer movement—must be accessible by keyboard. This means developers must provide alternative keyboard mechanisms (for example, an accessible toolbar with shape tools, keyboard-controlled drawing modes, or form-based input alternatives) even for freehand or path-dependent tasks.

A pass requires that every operation on the page can be initiated, navigated, and completed using only the keyboard. This includes focus management, modal dialogs, drag-and-drop reordering, custom sliders, canvas drawing tools, map interactions, carousel navigation, and video playback controls. There must be no keyboard trap (also covered by 2.1.2), no function that can only be triggered by clicking, hovering, or using touch-based gestures without an equivalent keyboard path, and no reliance on mouse-pointer paths.

A fail occurs when any functionality—regardless of how niche or secondary it may seem—cannot be reached or completed through keyboard alone. Because this criterion has no exceptions, even a single non-keyboard-accessible function constitutes a full failure, making it one of the most demanding standards in WCAG.

Why It Matters

Keyboard accessibility is foundational for users with motor impairments who cannot use a pointing device. People with conditions such as Parkinson's disease, quadriplegia, cerebral palsy, repetitive strain injuries, or limb differences often rely exclusively on a physical keyboard, a switch device, a sip-and-puff controller, or eye-gaze technology that emulates keyboard input. According to the World Health Organization, approximately 1.3 billion people worldwide live with some form of significant disability, and motor or physical impairments represent a substantial portion of that population. In Turkey alone, data from the Turkish Statistical Institute (TÜİK) indicates that over 8.5 million people report at least one form of functional limitation.

Beyond motor disability, keyboard accessibility benefits blind and low-vision users who navigate with screen readers such as NVDA, JAWS, or VoiceOver—all of which rely on keyboard commands to traverse and interact with web content. Users with photosensitive conditions may avoid touchscreens, and users with cognitive disabilities often benefit from the predictable, linear navigation that keyboard interaction provides.

Consider a concrete real-world scenario: a graphic design platform that offers a freehand vector drawing tool. Under WCAG 2.1.1, this could be exempted because the pointer path defines the shape. Under WCAG 2.1.3, the platform must provide an alternative—perhaps a shape library, a series of keyboard-controlled anchor points, or a text-based SVG path editor—so that a user with a motor impairment can still create vector artwork without a mouse. Failing to do this shuts out a meaningful segment of creative professionals who rely on keyboard-only access.

From a usability and SEO perspective, properly keyboard-accessible interfaces typically feature cleaner focus management, more logical tab order, and well-structured DOM hierarchies—all of which contribute to better crawlability and a higher-quality user experience for everyone, including power users who prefer keyboard shortcuts for speed.

Related Axe-core Rules

WCAG 2.1.3 requires manual testing. Unlike many WCAG criteria, automated tools cannot reliably detect violations of this criterion because:

• Path-dependent functionality detection is beyond static analysis: Axe-core and Lighthouse inspect the DOM for structural patterns—missing tabindex, absent role attributes, or broken focus management—but they cannot simulate a user attempting every function on a page and determining whether a keyboard alternative exists. A canvas element may be present in the DOM with no ARIA attributes, yet an accessible keyboard toolbar nearby may fully satisfy 2.1.3. Conversely, a seemingly normal button may trigger a JavaScript action that itself launches a mouse-only widget, which automated tools would never flag. The logical equivalence of keyboard alternatives to mouse-driven paths requires human judgment.
• No dedicated axe-core rule maps to 2.1.3: The closest axe rules—such as scrollable-region-focusable (which checks whether scrollable content regions can receive keyboard focus) and tabindex (which flags positive tabindex values that disrupt natural focus order)—address related but narrower concerns under 2.1.1 and 2.4.3. They do not and cannot evaluate whether all functionality, including path-sensitive operations, has a keyboard equivalent.
• Interactive widget audits require runtime interaction: Custom drag-and-drop components, canvas-based editors, and gesture-driven carousels only reveal their keyboard inaccessibility when a tester actually attempts to use them without a mouse. Axe-core's static DOM scan cannot trigger event listeners, observe focus loss during async operations, or evaluate whether a drag operation can be completed via keyboard arrow keys and Enter/Space.
• What to look for during manual audit: Testers should specifically look for canvas elements used for drawing or interaction, drag-and-drop lists or file upload areas, custom map or data visualization controls, time-based sliders, and any component that responds to mousemove, pointermove, or touch gesture events without corresponding keyboard event handlers.

How to Test

1. Run an automated baseline scan: Use axe DevTools (browser extension or CLI) or Google Lighthouse against your page to identify any low-hanging keyboard accessibility failures—missing focusable elements, keyboard traps, or elements with pointer-events: none that should be interactive. While these tools won't catch 2.1.3 violations directly, they surface related issues and establish a clean baseline before manual testing begins.
2. Catalogue all interactive functionality: Before testing, create a full inventory of every interactive component on the page: buttons, links, forms, modals, accordions, carousels, maps, canvas tools, drag-and-drop areas, custom dropdowns, date pickers, video players, and any widget that responds to mouse or touch events. This inventory becomes your test checklist.
3. Keyboard-only navigation test: Disconnect or disable your mouse. Use Tab and Shift+Tab to move focus, Enter and Space to activate controls, Arrow keys for composite widgets (menus, sliders, tabs, radio groups), and Escape to close dialogs. Attempt to complete every function on your inventory list. Note any function you cannot initiate, complete, or exit using only the keyboard.
4. Screen reader testing with NVDA + Firefox: Launch NVDA (Windows) with Firefox. Navigate using the virtual cursor (H for headings, B for buttons, F for form fields, Tab for interactive elements). Attempt each function. Listen for announced role, name, and state. Identify any interactive region that is unreachable or produces no audible announcement.
5. Screen reader testing with JAWS + Chrome: Use JAWS on Windows with Chrome. Use the JAWS virtual cursor and Forms Mode (toggle with Enter). Verify that all functionality can be operated and that focus is managed correctly after each interaction—especially after modal dialogs open or AJAX content loads.
6. Screen reader testing with VoiceOver + Safari (macOS/iOS): Enable VoiceOver (Command + F5 on macOS). Use Control + Option + Arrow to navigate. On iOS, use swipe gestures. Confirm that all functions are reachable and operable. Pay special attention to custom touch-based widgets that may lack keyboard equivalents on the desktop version.
7. Path-dependent functionality audit: For any drawing canvas, map interaction, or gesture-driven component, verify whether an alternative keyboard mechanism exists. Attempt to create a shape, reorder a list item, or pan a map using only keyboard controls. If no keyboard path exists, this is a direct 2.1.3 failure.
8. Focus visibility check: While navigating with keyboard only, confirm that focus is always visible on screen and logically ordered. Invisible focus or focus that jumps to unexpected locations is a usability failure and likely also violates 2.4.7 and 2.4.3.

How to Fix

Canvas Drawing Tool — Incorrect

<!-- Freehand canvas with no keyboard alternative -->
<canvas id='drawingBoard' width='800' height='600'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'>
</canvas>

Canvas Drawing Tool — Correct

<!-- Canvas with keyboard-accessible shape toolbar as alternative -->
<div role='toolbar' aria-label='Drawing tools'>
  <button id='addRect' onclick='insertShape("rectangle")'>Add Rectangle</button>
  <button id='addCircle' onclick='insertShape("circle")'>Add Circle</button>
  <button id='addLine' onclick='insertShape("line")'>Add Line</button>
  <label for='shapeColor'>Color</label>
  <input type='color' id='shapeColor' value='#000000'>
</div>
<canvas id='drawingBoard' width='800' height='600'
  aria-label='Drawing canvas — use toolbar above to add shapes'
  tabindex='0'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'
  onkeydown='handleCanvasKey(event)'>
</canvas>
<!-- handleCanvasKey enables arrow-key movement and Enter to place shapes -->

Drag-and-Drop List Reordering — Incorrect

<!-- List that only supports mouse drag for reordering -->
<ul id='sortableList'>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item One</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Two</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Three</li>
</ul>

Drag-and-Drop List Reordering — Correct

<!-- List with ARIA listbox pattern and keyboard reordering via arrow keys -->
<p id='reorderInstructions'>Tab to an item, press Space to grab it, use Up/Down arrows to move, press Space again to drop.</p>
<ul id='sortableList' role='listbox' aria-labelledby='reorderInstructions'>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item One</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Two</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Three</li>
</ul>
<!-- handleReorderKey: Space = grab/drop, ArrowUp/Down = move, Escape = cancel -->

Interactive Map Controls — Incorrect

<!-- Map that only responds to mouse pan and scroll-to-zoom -->
<div id='mapContainer' style='width:100%;height:400px;'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'>
</div>

Interactive Map Controls — Correct

<!-- Map with keyboard controls and accessible zoom/pan buttons -->
<div id='mapContainer' tabindex='0'
  role='application'
  aria-label='Interactive map. Use arrow keys to pan, plus and minus to zoom.'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'
  onkeydown='handleMapKey(event)'>
</div>
<div role='group' aria-label='Map controls'>
  <button onclick='zoomIn()'>Zoom In</button>
  <button onclick='zoomOut()'>Zoom Out</button>
  <button onclick='panMap("north")'>Pan North</button>
  <button onclick='panMap("south")'>Pan South</button>
  <button onclick='panMap("east")'>Pan East</button>
  <button onclick='panMap("west")'>Pan West</button>
</div>
<!-- Arrow keys pan, + / - zoom, handleMapKey dispatches these actions -->

Common Mistakes

• Assuming the WCAG 2.1.1 path-dependent exception still applies: Developers familiar with Level A sometimes build freehand drawing or gesture tools without keyboard alternatives, not realizing that 2.1.3 explicitly removes this exception. Every function, including path-sensitive ones, must have a keyboard equivalent at this level.
• Attaching only onclick and onmousedown handlers to custom interactive elements: Custom widgets built with <div> or <span> elements that only listen for mouse events are completely unreachable by keyboard. Always add onkeydown or onkeyup handlers alongside mouse event listeners, and ensure the element has tabindex='0' and an appropriate ARIA role.
• Using tabindex='-1' on elements that should be in the tab order: Setting tabindex='-1' removes an element from the sequential tab order. This is appropriate only for elements managed programmatically (e.g., within a composite widget using roving tabindex). Applying it to standalone interactive controls makes them keyboard-inaccessible.
• Implementing drag-and-drop without a keyboard-based reorder mechanism: Libraries like SortableJS or custom drag implementations often provide no keyboard alternative out of the box. Developers must implement the ARIA drag-and-drop pattern or provide Up/Down arrow key reordering so that list reordering is fully keyboard operable.
• Relying on :hover CSS to reveal interactive controls: Dropdown submenus, tooltip-based action buttons, or revealed controls that appear only on hover are inaccessible to keyboard users unless :focus and :focus-within states are also handled. A keyboard user can never hover, so hover-only content is effectively hidden from them.
• Failing to manage focus after dynamic content changes: When a modal opens, an inline alert appears, or an AJAX-loaded widget replaces existing content, focus must be programmatically moved to the new content using element.focus(). Failing to do so leaves keyboard users stranded at the position where they triggered the change, with no awareness that new content exists.
• Building custom sliders with only onmousemove: Range-style sliders built from <div> elements that track mouse position for value changes must also implement ArrowLeft, ArrowRight, Home, and End key handling per the ARIA slider pattern, and expose the current value via aria-valuenow, aria-valuemin, and aria-valuemax.
• Placing keyboard focus inside iframes without providing a way out: Embedded iframes—especially those containing third-party widgets like maps, payment forms, or chat tools—can trap keyboard focus if the embedded content itself is not keyboard accessible and does not support the Escape key to return focus to the parent document.
• Omitting keyboard support from canvas-based data visualizations: Charts and graphs rendered on <canvas> are invisible to the keyboard and screen readers unless an accessible alternative (a data table, an SVG equivalent with ARIA, or keyboard-navigable data points) is provided alongside the canvas element.
• Testing keyboard accessibility only with Tab and Enter, ignoring composite widget key patterns: Many ARIA widget patterns—menus, trees, grids, tabpanels, listboxes—require Arrow key navigation within the widget, with only a single tab stop for the entire component (roving tabindex). Testing only Tab and Enter will not reveal failures in these composite patterns and will give a false sense of compliance.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette numbered 32933 on June 21, 2025, establishes a comprehensive web and mobile accessibility framework for a broad range of public and private entities operating in Turkey. The circular mandates conformance with standards aligned to WCAG 2.1 and 2.2, requiring covered organizations to ensure their digital services are perceivable, operable, understandable, and robust for all users, including those with disabilities.

The entities covered by this regulation include public institutions and agencies at all levels of government, e-commerce platforms, banks and financial service providers, hospitals and healthcare institutions, telecommunications companies with 200,000 or more subscribers, travel agencies, private transportation companies, and private schools operating under authorization from the Ministry of National Education (MoNE). For these organizations, compliance with Level A and Level AA success criteria is the minimum legal baseline.

WCAG 2.1.3 — Keyboard (No Exception) is a Level AAA criterion and is therefore not explicitly mandated as a baseline legal requirement under the circular. However, the regulation's spirit—ensuring equitable digital access for Turkey's millions of users with disabilities—strongly aligns with the intent of this criterion. Organizations in covered sectors that offer specialized services to users with motor impairments, or that operate government portals used by citizens who depend on assistive technology, are well advised to pursue AAA conformance for keyboard access.

Achieving WCAG 2.1.3 compliance signals a best-in-class accessibility commitment that goes beyond regulatory minimums. For Turkish organizations seeking to serve the widest possible user base, to demonstrate social responsibility, or to participate in European Union digital markets where higher accessibility standards may apply, implementing full keyboard operability with no exceptions is both a competitive and an ethical advantage. As Turkey's regulatory landscape evolves and enforcement mechanisms mature, early adopters of AAA-level criteria such as 2.1.3 will be well positioned to meet any future regulatory tightening without costly remediation.