No Keyboard Trap

What it means and how to fix it

Of that, one failure is detectable automatically, and these are what the rates on this page measure. Each needs its own fix. The percentage is the share of all 609 scanned sites affected. These do not sum to the 10.3% above: a site can fail more than one of them, and most that fail any fail several.

• The keyboard gets stuck on an element10.3%

  A keyboard trap prevents users from tabbing past an element, stranding keyboard-only users on part of the page.

// Tab is swallowed and focus is forced back to the start, with no way out
dialog.addEventListener("keydown", (e) => {
  if (e.key === "Tab") {
    e.preventDefault();
    firstControl.focus();
  }
});

dialog.addEventListener("keydown", (e) => {
  if (e.key === "Escape") return close();
  if (e.key !== "Tab") return;
  // Cycle inside the dialog while it is open, but Escape always leaves
  const atEnd = document.activeElement === lastControl && !e.shiftKey;
  const atStart = document.activeElement === firstControl && e.shiftKey;
  if (atEnd) { e.preventDefault(); firstControl.focus(); }
  if (atStart) { e.preventDefault(); lastControl.focus(); }
});

For what the criterion formally requires, read the W3C Understanding document.

How often it fails

What the numbers do not say

The CMS pattern that runs through this corpus shows up here too, though less sharply: 5 of 20 Drupal city sites carry a suspected keyboard trap, against 0 of 32 on CivicPlus. Traps come from custom interactive code, and a platform that ships its own menu and dialog components leaves less room for it than one assembled per site.