2.1.2 · Level A · WCAG 2.0 · Operable → Keyboard Accessible

No Keyboard Trap

If keyboard focus can move into a component, it can always move back out again using only the keyboard — no dead ends.

Why it matters

A modal, a rich text editor, or a custom date picker that captures focus and never releases it strands a keyboard user on that one component with no way to reach the rest of the page.

Detected by Openwell's judgement pass

This is an interaction-sequence problem — axe-core inspects a static DOM and cannot drive a keyboard through a widget to confirm focus escapes. Openwell's judgement pass uses the captured tab-order trace to check this.

Fails

// modal opens, focus moves inside, but Escape and Tab-past-last-element
// are never handled — focus can enter the modal but never leave it

Focus is trapped by omission: nothing closes the modal or returns focus to the page via keyboard alone.

Passes

modal.addEventListener("keydown", (e) => {
  if (e.key === "Escape") closeModal();
  // and: Tab past the last focusable element wraps to the first,
  // Shift+Tab from the first wraps to the last
});

Escape closes the modal and returns focus to the trigger; Tab is contained within the modal rather than leaking or dead-ending.

Openwell finds violations like this one across your whole site, clusters them by the component that caused them, and generates a fix that's re-validated before you see it.

Scan your site free