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
<!-- 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><!-- 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
- Test your page by unplugging your mouse and using Tab, Shift+Tab, Enter, Space, and arrow keys.
- Replace div/span click handlers with
<button>or<a>elements. - If you must use a custom widget, add role,
tabindex="0", and keydown handlers. - Ensure every interactive element can be reached and activated by keyboard.
- 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