WCAG 2.1.2 — No Keyboard Trap

What this requires

If keyboard focus can be moved to a component, it must be possible to move it away again using only the keyboard. If the component uses keys other than Tab (an editor that uses Tab to indent, for example), the user must be informed how to leave. There is no exception: even authored content embedded in a page must release focus.

How AI coding tools fail this

The most common failure: a modal dialog implemented as a div with role="dialog", focus moved inside, and no logic for Escape or Tab cycling. Keyboard users tab past the last control and into the background, or press Escape and nothing happens. Worse: when the modal is built without proper focus trapping it leaks focus into the page underneath, which is technically not a trap but is operationally broken.

The second pattern: custom code editors, rich-text editors, or spreadsheet widgets that intercept every key and never release focus on Tab. Without a documented exit key (typically Escape or Ctrl+M), the user is stuck.

The third: embedded iframes — third-party widgets, payment forms, maps — that capture focus and don't return it on the next Tab. The container has to manage focus return; AI-generated embeds rarely do.

Failing examples

A modal with no focus management:

{open && (
  <div role="dialog">
    <h2>Confirm delete</h2>
    <button onClick={confirm}>Yes, delete</button>
    <button onClick={() => setOpen(false)}>Cancel</button>
  </div>
)}

(No focus trap inside the modal, no return to the trigger on close, no Escape handler.)

A rich-text editor that captures Tab with no documented exit:

<TipTapEditor extensions={[TabHandler]} />

Passing examples

Use a dialog primitive that handles focus correctly:

import * as Dialog from "@radix-ui/react-dialog";

<Dialog.Root>
  <Dialog.Trigger asChild>
    <button>Delete</button>
  </Dialog.Trigger>
  <Dialog.Portal>
    <Dialog.Overlay />
    <Dialog.Content>
      <Dialog.Title>Confirm delete</Dialog.Title>
      <Dialog.Description>This action cannot be undone.</Dialog.Description>
      <button onClick={confirm}>Yes, delete</button>
      <Dialog.Close>Cancel</Dialog.Close>
    </Dialog.Content>
  </Dialog.Portal>
</Dialog.Root>

For a Tab-capturing editor, document the exit key and surface it in the UI:

<>
  <label htmlFor="snippet">Code snippet</label>
  <p id="snippet-help">
    This editor uses Tab to indent. Press <kbd>Escape</kbd>, then
    <kbd>Tab</kbd>, to leave the editor.
  </p>
  <CodeEditor id="snippet" aria-describedby="snippet-help" />
</>

Edge cases

Focus trap inside a modal is correct and expected. The criterion bans traps the user cannot escape; modals with a clear Escape + Close button are not traps in the prohibited sense.
Browser dev tools, iframes, and third-party widgets are common sources. The page that hosts them is responsible.
The "leave key" exception (when keys other than the standard navigation keys exit a widget) requires informing the user. A visible hint or aria-describedby works.
Focus return when a modal closes must land back on the trigger that opened it. Skipping that is poor UX, not strictly a trap.
2.1.2 and 2.1.1 are paired. Keyboard reachable and keyboard releasable are both required.

How Jeikin handles this

axe-core flags some patterns (focusable elements inside aria-hidden regions, for example). Confirming a modal traps and releases focus correctly is a runtime check; Jeikin's guided review provides a keyboard-walk script that opens each modal, attempts to Tab and Escape, and records the result. The dashboard tracks focus management per component.