Never trap keyboard focus inside a widget
Focus goes into a component and cannot get back out, so Tab cycles inside it forever and the rest of the page is gone. G21 is the technique for making sure that cannot happen, and it carries unusual weight. W3C lists exactly one sufficient technique for the no-keyboard-trap rule and this is it, with a single documented failure facing it from the other side. Three mechanisms satisfy it. Tab keeps going and leaves the component after its last stop, or a key is provided that moves focus out, or, where a non-standard key is needed, the page says which key that is before the reader arrives. The last part is the one that gets forgotten. A trap with a documented way out is fine. A trap with an undiscoverable one is not.
How we find it in an audit
A reviewer tabs the whole page from the address bar to the end of the document, then tabs backward to the start, and anywhere the focus stops moving is the finding. Embedded third-party content gets the closest look, since a chat widget, a video player, a payment iframe and a map are the four that usually do it. Modal dialogs are their own case, because a modal is supposed to hold focus while it is open. What makes that legal is Escape closing it and returning focus to whatever opened it, so we test exactly that.
How affected users experience it
A keyboard user caught in a trap has one move left, which is closing the tab. Everything past that point is unreachable, including the checkout button, the phone number and the way back to the homepage. Screen-reader users usually meet it inside an embedded player, where the browse commands go quiet and the reading cursor stops answering. Nothing announces a trap, so the first minute goes on assuming the keyboard has broken. The second minute goes on leaving.
Passes vs. fails
Passes
The chat widget cycles focus internally while open, and Escape closes it and returns focus to the button that opened it.
Fails
A third-party chat widget captures Tab in a loop, so once focus is inside it, the rest of the page is gone.
How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- Focusable element has no keyboard trapA tool can check this
- Focusable element has no keyboard trap via standard navigationNothing implements this yet
- Focusable element has no keyboard trap via non-standard navigationA tool can check this
Other ways to satisfy this rule
2 guides on this site are filed under 2.1.2 No Keyboard Trap. W3C lists this one as sufficient for that rule on its own. Implement it correctly, in a way your readers' software actually supports, and the rule is met.
This guide is our interpretation of W3C technique G21: Ensuring that users are not trapped in content. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.