Elements not keyboard-accessible.

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

WCAG 2.1.1Level A10 min

The problem

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.

The fix

Fails 2.1.1
<!-- 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>
Passes
<!-- 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.

In your framework

// 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()}>

Questions

Does this apply to drag-and-drop?

Yes — WCAG 2.5.7 (Level AA, 2.2) requires a single-pointer alternative to dragging, such as move up/down buttons. Keyboard support is required separately by 2.1.1.

Find it on your site.

Scan a page and see every place this issue appears, with the element and the fix.

Scan your site