Operable Guideline 2.1 Keyboard Accessible

2.1.2 No Keyboard Trap

Keyboard focus must never get stuck

Level A Needs a person to check

What it asks for, in plain English

If a keyboard user can move focus into a part of the page, they must be able to move it out again using only the keyboard, and with the ordinary keys: Tab, Shift+Tab, Escape or the arrow keys. If leaving needs some other key, the page has to tell them.

A trap is anything that swallows focus. Classic examples are a modal dialog with no close key, an embedded video player or map that loops focus inside itself, a rich text editor that captures Tab to indent, and a chat widget that re-focuses itself whenever you try to leave.

A keyboard trap is one of the few failures that can stop a person using the entire page, because there is no way past it.

This is an independent explanation. The binding wording is the W3C Recommendation, and the W3C's own Understanding 2.1.2 page has the full intent, techniques and definitions.

Who it affects

Someone using a screen reader tabs into an embedded map and finds every press of Tab cycles the same four map controls forever.

A person who cannot use a mouse opens a cookie dialog and cannot reach the page behind it or close it, so the site is unusable.

A sighted keyboard user gets stuck in a rich text editor where Tab inserts a tab character instead of moving on.

How to check it

  1. Tab through the whole page from top to bottom and then Shift+Tab back up. You should always be able to keep moving.
  2. Open every dialog, menu, dropdown and embedded widget with the keyboard, then try to leave with Tab, Shift+Tab and Escape.
  3. Pay special attention to embedded players, maps, chat widgets and editors from third parties.
  4. If something needs a special key to leave, check the page says so before you enter it.

What Websight checks for 2.1.2

Websight has no automated check for this criterion. It lists it in the manual checklist that comes with every report, so it is not forgotten.

Only a person can check this. A scanner does not press keys, so it cannot tell whether focus comes back out. Websight lists it in its manual checklist.

Practical tips

  • In modal dialogs, trap focus inside on purpose while open, but always close on Escape and return focus to the opener.
  • If an editor uses Tab for indenting, offer Escape then Tab to leave, and say so in the help text.
  • Test every third-party embed with the keyboard before shipping it.

Scan your page and see where 2.1.2 stands

Websight gives a score out of 100, explains each automated finding in plain English, and lists the checks a person still needs to do.

Add Websight to Chrome

Free scans, no account, nothing leaves your computer. Automated tools find only part of the problems; the extension says so on every report.