All interactive elements are keyboard accessible

A <div onClick={handler}> that renders as a clickable UI element with no keyboard equivalent shuts out every user who does not use a pointer device — keyboard-only users, switch access users, and users on devices with no pointing hardware. WCAG 2.2 SC 2.1.1 (Keyboard) requires all functionality to be operable via keyboard without requiring specific timings. Section 508 2018 Refresh 407.6 mandates keyboard operation for all standard functions. This is not a fringe scenario: approximately 26% of US adults with disabilities have a mobility disability affecting computer use. The most common failure patterns are custom dropdown menus that require hover/click, carousels that accept only swipe gestures, and custom select components built on <div> elements without role="option" and Arrow key handling.

Replace <div onClick> patterns with <button> elements wherever the element triggers an action. Use native form elements for inputs and selects. When a custom widget is unavoidable, implement the full ARIA authoring practices keyboard contract.

// Bad: Mouse-only
<div onClick={openMenu} className="menu-trigger">Menu</div>

// Good: Semantic button (keyboard support is built in)
<button onClick={openMenu}>Menu</button>

// Custom widget: implement keyboard contract per ARIA APG
<div
  role="combobox"
  tabIndex={0}
  aria-expanded={isOpen}
  aria-haspopup="listbox"
  aria-labelledby="country-label"
  onClick={toggle}
  onKeyDown={(e) => {
    if (e.key === 'Enter' || e.key === ' ') {
      e.preventDefault();
      toggle();
    }
    if (e.key === 'ArrowDown') {
      e.preventDefault();
      focusNextOption();
    }
    if (e.key === 'Escape') close();
  }}
>
  {selectedValue}
</div>

Reference the ARIA Authoring Practices Guide (APG) at aria.w3.org/apg/patterns/ for the correct keyboard contract for each widget type.