A: The user focus is not accidentally trapped in one region (WCAG 2.1.2)
focus-traps
What this means
Users must be able to navigate freely through all interactive elements of a page using the keyboard. The focus must not get “stuck” in one area—for example, in a dialog box, modal window, or embedded widget. Users must be able to tab in and out of each region without losing focus.
Impact
If the focus is stuck in one area, users can no longer reach other parts of the page. This particularly affects people who navigate exclusively with the keyboard or use screen readers. This significantly restricts usability and violates WCAG 2.1.2 (A) No keyboard trap.
Recommendation
- Implement modal dialogs or overlays in such a way that the focus is set to the dialog when it is opened and returns to its previous position when it is closed.
- The tab order must not be interrupted or blocked by scripts.
- The focus must not be “trapped” within embedded components (e.g., videos, widgets, forms).
- After each interaction, check whether the focus control is working correctly.
Examples
Problematic:
<div tabindex="0" onkeydown="event.preventDefault()">...</div>
In this case, the script prevents any keyboard interaction. The user can no longer leave the area.
Better:
<div role="dialog" aria-modal=“true”>
<button>Close</button>
</div>
A correctly configured dialog allows navigation between interactive elements using the tab key. After closing, the focus is returned to its original position.
Note
Avoiding focus traps is particularly relevant for modal windows, form widgets, and interactive overlays. Always test the operation with the keyboard before publishing content.
Related WCAG criterion:
WCAG 2.1.2 – No keyboard trap