2.1.2 No Keyboard Trap (Level A) — WCAG 2.1
WCAG 2.1 Success Criterion 2.1.2 No Keyboard Trap (Level A): what it requires, a common e-commerce accessibility failure, and how to fix it.
This is educational technical reference content, not legal advice. It explains what WCAG 2.1 requires and how to meet it — not whether a specific site carries legal risk. Compliance with WCAG, the ADA, or any other accessibility law or standard is a legal determination; consult qualified counsel for legal risk assessment.
WCAG 2.1 guidelines hub → Operable → 2.1.2 No Keyboard Trap
2.1.2 No Keyboard Trap (Level A)
What it requires: If keyboard focus lands on something, the user has to be able to move focus away using standard keys (Tab, Shift+Tab, or Escape) — or be clearly told how, if the exit method is nonstandard.
Common failure: A modal or embedded widget (a chat plugin, a third-party payment iframe) traps focus once a keyboard user tabs into it, cycling only within the widget with no way to Tab back out to the rest of the page.
Fix it: For custom modals, implement a proper focus trap that’s intentional and complete (Tab cycles within the dialog, Escape closes it and returns focus to the trigger) — the bug here is usually an incomplete trap, not a missing one. Test third-party embeds specifically; they’re a frequent source of this failure.
In 2.1 Keyboard Accessible: ← 2.1.1 Keyboard · 2.1.3 Keyboard (No Exception) →
This is educational technical reference content, not legal advice. It explains what WCAG 2.1 requires and how to meet it — not whether a specific site carries legal risk. Compliance with WCAG, the ADA, or any other accessibility law or standard is a legal determination; consult qualified counsel for legal risk assessment.
This page was drafted with AI assistance and reviewed by a person for accuracy before publication.