Level AWCAG 2.2

2.1.2 No Keyboard Trap

Keyboard focus can be moved away from any component using only a keyboard.

Why it matters

Inoperable

When focus is trapped, the rest of the page becomes inaccessible.

Keyboard users

Users who cannot use a mouse have no way to escape the trap.

Frustration

Users are forced to reload the page and may lose any data they have entered.

Modals and widgets

Rich UI components can unintentionally trap focus. Make sure they can be dismissed with Esc.

Live demo

Keyboard trap demo

Tab Use the Tab key to move through the form.

You cannot escape the textarea with Tab

NameComment

If a modal or custom widget hijacks keydown users can become trapped inside that component. Always provide a way out with Esc or Tab.

Understanding through personas

Nakamura (45) — Repetitive strain injury (RSI)

Prolonged mouse use is difficult, so I work primarily with the keyboard. I got stuck in a rich text editor with no way out and had to force-quit the browser. A long email I was writing was lost.

Checkpoints

Tab can move away from every componentModals can be closed with EscWhen focus trapping is needed, the way to escape is clearly indicatedThird-party widgets are also checked for trapsFocus can escape from content inside iframes

References

→ Understanding SC 2.1.2 (W3C)

→ Related: 2.1.1 Keyboard, 2.4.3 Focus Order