WCAG 2.1.1 — Keyboard

What this requires

All functionality must be available from a keyboard. That includes buttons, links, form controls, custom widgets, drag-and-drop interactions, hover-revealed menus, and any other interactive surface. The user has to be able to reach each control with Tab, activate it with Enter or Space, and escape from it without getting stuck. There are narrow exceptions for inputs that genuinely require continuous analogue motion (a freehand drawing canvas), but every other case must have a keyboard path.

How AI coding tools fail this

The most common failure: AI assistants generate <div onClick={...}> when asked for "a clickable card" or "a custom button". The element renders, the click handler fires for mouse users, and the assistant considers the task done. Keyboard users can't focus the element, can't press Enter to activate it, and have no way to know it's interactive.

The second pattern: hover-revealed menus, tooltips, or "show on hover" controls generated without a focus equivalent. A keyboard user tabs past the trigger and never sees the menu exists. AI tools rarely add the :focus-within or onFocus handler unless explicitly asked.

The third: custom drag-and-drop, sliders, or carousels assembled from mouse events (mousedown, mousemove, mouseup) with no keyboard fallback. The pattern is well-documented in ARIA APG, but the default generation is mouse-first.

Failing examples

A <div> posing as a button — no focus, no keyboard activation:

<div onClick={() => openModal()} className="cursor-pointer">
  Open
</div>

Hover-revealed menu with no focus path:

<div className="group">
  <span>Account</span>
  <ul className="hidden group-hover:block">
    <li>Settings</li>
    <li>Sign out</li>
  </ul>
</div>

Passing examples

Use a real <button> — focusable, keyboard-activatable, screen-reader recognised, all for free:

<button onClick={() => openModal()}>
  Open
</button>

Menu trigger and items reachable from the keyboard via Tab — each control is a real <button>, so Enter and Space activate them and focus is visible:

<div className="group">
  <button
    aria-expanded={open}
    aria-controls="account-menu"
    onClick={() => setOpen(!open)}
  >
    Account
  </button>
  {open && (
    <ul id="account-menu">
      <li><button>Settings</button></li>
      <li><button>Sign out</button></li>
    </ul>
  )}
</div>

This satisfies the bare 2.1.1 contract — every control is reachable and operable from the keyboard. For a production menu, use the ARIA APG menu pattern (opens in new tab): arrow keys move between items, Home/End jump to first/last, Escape closes the menu and returns focus to the trigger, and typing a character jumps to the next item starting with it. Libraries like Radix UI and Headless UI implement the full pattern out of the box.

Edge cases

Focus order matters. Tab order should match the visual reading order. CSS that visually reorders content (flex order, grid order) doesn't change DOM order — and the DOM order is what Tab follows.
Focus must be visible. A keyboard-reachable element with outline: none and no replacement style is reachable in name only. Focus visibility is a separate criterion (2.4.7) but the two are almost always failed together.
Custom widgets (combobox, tabs, tree, slider) need to follow the expected keyboard pattern from ARIA APG (opens in new tab). Inventing a new pattern means users have to learn it.
Modal dialogs must trap focus inside while open and return focus to the trigger on close.
Skip links for repetitive navigation are required when the page has a long header.

How Jeikin handles this

Jeikin's CLI scanner flags <div onClick> and other non-interactive elements with click handlers, then maps each finding to WCAG 2.1.1. The MCP server returns a focus-trap test prompt that the connected AI tool can run on rendered output to detect missing keyboard paths.

The dashboard tracks keyboard findings through resolution. For modals and menus specifically, Jeikin records that the keyboard path was verified, not just that the click handler works.