spec 2 linked patterns checked
WAI WCAG Understanding: No Keyboard Trap
Explains that keyboard focus must not become trapped inside a subsection unless users know how to leave that state and can do so with the keyboard.
Read with a purpose
What this source can teach
Use this source to check a technical or accessibility requirement against its exact wording and scope.
- Start with the original. Open the source and find the guidance or example relevant to your task.
- Trace the connection. Use the claim notes below to see how this site applies the source to specific patterns.
- Check the setting. Compare the source's platform, people, and constraints with your own decision.
Pattern Decisions This Source Supports
| Pattern | Supported decision | Required contract | Claim note |
|---|---|---|---|
| Drawer with no close or return path | Flag this anti-pattern when a temporary drawer has no visible close control, no Escape path, no back-route dismissal, no equivalent for gesture-only close, or no predictable focus return. | Opening the drawer records the opener or selected object as the return target. | Supports the need for keyboard users to have a reliable exit from temporary surfaces. |
| Focus traversal | Choose focus traversal when the design problem is the user's sequential path through focusable elements and dynamic state changes. | The sequential focus path follows DOM and reading order unless a well-tested component-specific model declares a different internal focus contract. | Supports avoiding keyboard traps and providing keyboard exits from constrained focus regions. |
Evidence Role
This source is treated as spec evidence. Its value comes from the specific claims and setting described above.
Publisher: W3C WAI. Last checked: .