Loading...
Loading content...
Loading content...
Users must be able to navigate away from any element using only the keyboard.
Why it matters: Keyboard users can become trapped in components, unable to access the rest of the page.
If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.
What This Means: This success criterion requires that if keyboard focus can be moved to a component (like a modal, menu, or custom widget), users must be able to move focus away from that component using only keyboard input. Users should never get 'trapped' in a component with no way to escape using the keyboard.
Why It's Important: Keyboard users can become trapped in components like modals, dropdown menus, or custom widgets if there's no keyboard way to exit. This creates a barrier that prevents users from accessing the rest of the page. Users who are blind or have motor disabilities rely entirely on keyboard navigation, so being trapped in a component makes the entire page unusable.
Ensure modals can be closed with Escape key or by focusing and activating a close button. Dropdown menus should close when Escape is pressed or when focus moves away. Custom widgets should provide clear keyboard exit methods. If a non-standard method is required to exit (like a specific key combination), inform users of this method. Test by navigating into components and verifying you can always navigate out using only the keyboard.
This criterion ensures that keyboard users can access and understand the content, improving their overall experience and ability to use the website effectively.
This criterion ensures that blind users can access and understand the content, improving their overall experience and ability to use the website effectively.
This criterion ensures that users with motor disabilities can access and understand the content, improving their overall experience and ability to use the website effectively.
Impact: When this criterion is properly implemented, it removes barriers for these user groups and creates a more inclusive web experience for everyone.
A modal dialog opens but there's no way to close it with keyboard, trapping the user.
<div class="modal" tabindex="-1">Content</div>A modal can be closed with Escape key or by focusing and activating a close button.
<div class="modal" tabindex="-1" onKeyDown="if(e.key==='Escape') closeModal()">Content</div>This success criterion benefits the following user groups:
Tip: Use this checklist during development and testing to ensure all requirements for 2.1.2 No Keyboard Trap are met. Check off items as you complete them.
To meet this success criterion, ensure the following requirements are met:
While meeting the minimum requirements ensures compliance, consider these enhancements for a better user experience:
If users can click outside to close, keyboard trap is okay.
Keyboard users need keyboard-accessible ways to exit. Clicking outside requires a mouse, which keyboard users don't have.
Focus trapping in modals is always bad.
Temporary focus trapping within modals is acceptable and even recommended, but users must be able to close the modal with Escape key.
Modal dialogs that can't be closed with keyboard.
Add Escape key handler and ensure close button is keyboard accessible. Use proper ARIA attributes (aria-modal='true').
Custom dropdown menus that trap focus.
Ensure dropdowns close when Escape is pressed or when focus moves outside. Don't prevent default Tab behavior.
Focus trapped in iframes or embedded content.
Ensure iframes have proper tabindex and keyboard navigation. Consider providing a way to exit iframe content.
Focus doesn't return after closing modals.
Store the element that opened the modal and return focus to it when closing. Use focus() method programmatically.
Note: These are official W3C resources for 2.1.2. For the most up-to-date information and detailed technical guidance, always refer to the official W3C documentation.
Implementing 2.1.2 No Keyboard Trap correctly requires understanding your specific context. Code solutions vary significantly based on multiple factors:
HTML, React, Vue, Angular, PHP, Python, and other frameworks each have different patterns and best practices.
Server-side rendering, client-side rendering, static generation, and hybrid approaches require different solutions.
Your existing components, styling approach, and UI library influence how accessibility must be implemented.
Your specific user base, content type, and interaction patterns determine the most appropriate implementation.
We provide tailored implementation guidance by analyzing your specific technology stack, coding patterns, design system, and project requirements. Our team reviews your codebase and provides custom solutions that integrate seamlessly with your existing architecture.
Get Custom Implementation HelpPart of
Operable PrincipleGuideline
2.1 Keyboard Accessible