Ensure Keyboard Navigation

Why this matters

Not everyone uses a mouse. Users with motor disabilities use keyboard navigation, switch devices, or voice control — all of which rely on the keyboard interaction model. Users with repetitive strain injuries, broken trackpads, or even power users who prefer keyboard shortcuts all depend on Tab/Enter/Space/Escape working correctly.

When interactive elements are not keyboard-accessible, these users are completely locked out. They cannot click a button, open a dropdown, dismiss a modal, or submit a form. The application is unusable.

This is also a legal requirement. WCAG 2.1 Level A criterion 2.1.1 (Keyboard) states that all functionality must be operable through a keyboard interface. Failure to meet this is the basis for most web accessibility lawsuits.

The rule

Every interactive element must be reachable via Tab, activatable via Enter or Space, and dismissible via Escape where applicable. Focus must be visible at all times. No keyboard traps — users must be able to Tab away from any element.

Bad example

// Not focusable, not keyboard-activatable
<div className="dropdown-trigger" onClick={() => setOpen(!open)}>
  Select an option
</div>
 
{open && (
  <div className="dropdown-menu">
    {options.map(opt => (
      // Not focusable, no keyboard handler
      <div key={opt.id} onClick={() => selectOption(opt)}>
        {opt.label}
      </div>
    ))}
  </div>
)}

Good example

// Focusable, keyboard-activatable, proper ARIA
<button
  aria-haspopup="listbox"
  aria-expanded={open}
  onClick={() => setOpen(!open)}
  onKeyDown={(e) => {
    if (e.key === 'Escape') setOpen(false);
    if (e.key === 'ArrowDown' && !open) setOpen(true);
  }}
>
  Select an option
</button>
 
{open && (
  <ul role="listbox" aria-label="Options">
    {options.map((opt, i) => (
      <li
        key={opt.id}
        role="option"
        tabIndex={0}
        aria-selected={selected === opt.id}
        onClick={() => selectOption(opt)}
        onKeyDown={(e) => {
          if (e.key === 'Enter' || e.key === ' ') selectOption(opt);
          if (e.key === 'Escape') setOpen(false);
        }}
      >
        {opt.label}
      </li>
    ))}
  </ul>
)}

How to detect

Manual testing is the most reliable method:

1. Put your mouse in a drawer
2. Navigate the entire application using only Tab, Shift+Tab, Enter, Space, Escape, and Arrow keys
3. Every action you cannot perform is a keyboard accessibility failure

Automated: search for click handlers on non-interactive elements:

grep -rn 'onClick' --include="*.tsx" | grep '<div\|<span\|<li'

Remediation

1. Replace <div onClick> and <span onClick> with <button> or <a> elements
2. Add onKeyDown handlers for custom interactive widgets (dropdowns, modals, tabs)
3. Ensure all focusable elements have visible focus styles (never use outline: none without a replacement)
4. Test modal dialogs for focus trapping — focus must stay inside the modal and return to the trigger on close
5. Add skip links to bypass repetitive navigation

References

• WCAG 2.1: Keyboard (Level A)
• WebAIM: Keyboard Accessibility
• MDN: Keyboard-navigable JavaScript widgets