WCAG 2.1.2 — No Keyboard Trap, explained with examples

Why this criterion exists

A trapped user cannot complete forms, exit modals, or leave the page. The most common offenders are custom modals without Esc handling and embedded iframes that capture Tab.

If you only remember one thing: keyboard focus must never get trapped — users must always be able to navigate away using standard keys. Everything else on this page is detail.

Who feels it when this fails

Accessibility criteria sometimes feel abstract until you see who pays the cost when a site ignores them. No Keyboard Trap affects:

• Keyboard-only users

• Screen reader users

• Switch device users

How sites typically fail it

These are the patterns we see week after week. None are intentional — they are accidents of how teams build interfaces under deadline. Knowing the failure modes is the fastest path to writing them out of your component library.

• Modal dialog without Esc to close

• Cookie banner that auto-focuses and traps Tab

• <iframe> from a third party that captures keyboard

How to test for it

• Tab into every section; ensure you can Tab back out.

• Open every modal; Esc must close.

A code fix you can copy

aria-modal="true" tells AT this is a modal, while Esc gives keyboard users a guaranteed exit.

<div role="dialog" tabindex="0">...</div>

<div role="dialog" aria-modal="true">
  <button aria-label="Close" onclick="close()">×</button>
</div>
<script>
document.addEventListener('keydown', e => {
  if (e.key === 'Escape') close();
});
</script>

Other Operable criteria