Skip to lesson content
WCAG 2.1.1 · Level AMedium10 min readKeyboard

Elements Not Keyboard-Accessible

Overview

All interactive functionality must be operable with a keyboard alone. Users who can't use a mouse depend entirely on keyboard navigation.

Many people can’t use a mouse—users with motor disabilities, tremors, RSI, or those relying on screen readers and switch devices. For them the keyboard is the only way in. If a control can be clicked but not reached with Tab or activated with Enter/Space, that feature simply doesn’t exist for them. Keyboard operability (WCAG 2.1.1) is foundational: nearly every other accessibility feature depends on it working first.

WCAG Criterion:2.1.1
Conformance Level:Level A
Difficulty:Medium
Time to fix:~10 min
Category:Keyboard

The Problem

This pattern is inaccessible — avoid it.

[ AVOID ]
<!-- Click handler on a div — not keyboard-accessible --> <div onclick="openMenu()">Menu</div> <!-- Custom slider with no keyboard support --> <div class="slider" onmousedown="startDrag()"></div>

The Fix

Use this accessible pattern instead.

[ CORRECT ]
<!-- Use native interactive elements --> <button onclick="openMenu()">Menu</button> <!-- Or add keyboard support explicitly --> <div class="slider" role="slider" tabindex="0" aria-valuenow="50" aria-valuemin="0" aria-valuemax="100" onkeydown="handleKey(event)"> </div>

Step-by-step

  1. Test your page by unplugging your mouse and using Tab, Shift+Tab, Enter, Space, and arrow keys.

  2. Replace div/span click handlers with <button> or <a> elements.

  3. If you must use a custom widget, add role, tabindex="0", and keydown handlers.

  4. Ensure every interactive element can be reached and activated by keyboard.

  5. Don't use tabindex values > 0 — they create confusing tab order.

Common Mistakes

  • Putting click handlers on <div>/<span> instead of <button>/<a>.

  • Building custom widgets (menus, sliders, modals) with no keyboard support.

  • Positive tabindex values that scramble the natural tab order.

  • Focus traps in modals that the user can’t Tab or Escape out of.

How to Test for It

  • Unplug your mouse and operate the whole page with Tab, Shift+Tab, Enter, Space, and arrows.

  • Confirm focus is always visible and never gets trapped.

  • Run an automated scan, then manually verify every custom widget.

Framework Notes

How to apply this fix in your stack.

[ REACT ]
// Prefer native elements <button onClick={openMenu}>Menu</button> // If you must use a div: <div role="button" tabIndex={0} onClick={handleClick} onKeyDown={e => (e.key === 'Enter' || e.key === ' ') && handleClick()}>

FAQ

Related lessons