WCAG 2.1 · Level A · Operable
WCAG 2.1.2 — No Keyboard Trap, explained with examples
Keyboard focus must never get trapped — users must always be able to navigate away using standard keys. 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.
- Number
- 2.1.2
- Level
- A
- Principle
- Operable
- Guideline
- 2.1 Keyboard Accessible
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.
Automated scanners catch this criterion most of the time, but never all of the time. Manual testing with the keyboard and a screen reader closes the gap.
A code fix you can copy
aria-modal="true" tells AT this is a modal, while Esc gives keyboard users a guaranteed exit.
The problem
<div role="dialog" tabindex="0">...</div>The fix
<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>aria-modal="true" tells AT this is a modal, while Esc gives keyboard users a guaranteed exit.
Frequently asked questions
What is the difference between a keyboard trap and intentional focus management?
Intentional focus management — such as keeping focus inside a modal while it is open — is required and correct. A keyboard trap is when the user cannot escape at all using standard keys. Modal dialogs should cycle focus within themselves (Tab, Shift+Tab) and close on Esc. The key distinction: the user must always have a documented, working way out.
Are cookie consent banners a common source of keyboard traps?
Very common. Many Consent Management Platforms (CMPs) render before the skip link, auto-focus on the banner, and do not return focus correctly when dismissed. The fix is to ensure the banner has a real close control that restores focus to the first interactive element on the page. Several EU-required CMPs have been flagged by accessibility auditors for exactly this failure.
How does 2.1.2 differ from 2.4.3 Focus Order?
WCAG 2.1.2 is about escaping a focus area at all — you must always be able to leave. WCAG 2.4.3 is about the sequence in which focus moves — the order must preserve meaning. A modal that lets you exit but sends you to the wrong place violates 2.4.3 but not 2.1.2. A modal you cannot exit at all violates 2.1.2.
Other Operable criteria
2.1.1 Keyboard
Operable · Level A
2.4.3 Focus Order
Operable · Level A
2.4.4 Link Purpose (In Context)
Operable · Level A
2.4.6 Headings and Labels
Operable · Level AA
All WCAG 2.1 criteria
Browse the full index by principle
Complete WCAG 2.1 guide
POUR principles, conformance levels, legal requirements
How to fix: keyboard trap in modal or widget
Fix recipe · 2.1.2
Find every accessibility issue on your site in 60 seconds.
Free public scan. No card. AI-generated fixes for every issue we find.