WCAG Principle: Operable
Guideline 2.1: Keyboard Accessible (Make all functionality available from a keyboard)
Conformance Level: A (Minimal Requirement)
What is Success Criterion 2.1.2?
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.
A keyboard trap describes an area on a web page that is impossible to navigate without using a mouse. It forces a keyboard user to remain stuck within a subsection of the webpage with no way to get back to the main page except they use a mouse.
Keyboard traps often occur in input boxes, drop-down menus, or hyperlinks on embedded applications. These include spreadsheets, text editors, and media players. For example, users may be able to navigate into a built-in text editor on an online forum using the Tab key, In this case, a keyboard trap occurs when they cannot exit it using the Shift + Tab keys, which is intuitive for most users.
To comply with this success criterion, content on a Web page should not “trap” keyboard focus within subsections. Also, users should be aware if a webpage provides a non-intuitive keystroke (or series of keystrokes) to escape a keyboard trap.
In some cases, the functionality of a Web page may force the user to focus on a subsection of the content. This may be permissible as long as the user knows how to un-trap the focus.
How does it make your website accessible?
Keyboard traps pose a huge problem on your website because many assistive technologies (such as screen readers) use keyboard commands to function. Some users with mobility issues also prefer using the keyboard while browsing because it gives them more precise hand control than a mouse. Allowing keyboard users to freely move in and out of sections on your web pages provides them a better user experience and full access to your website’s contents.
How to Meet Success Criterion 2.1.2
Common mistake:
A user tabs into a webpage subsection and cannot return to content outside that subsection with the keyboard. To regain control and navigate to a new page, they must refresh the page using a mouse or restart their browser.
How to fix mistakes that cause keyboard traps:
- Ensure that the keyboard function for advancing focus within content (the tab key) exits the subset of content when it reaches the last navigation location.
- Provide a keyboard shortcut for moving the focus away from the subset of the content. Document the feature in an accessible manner within the subset.
- If the technology used in the subset of content provides a “move to parent” keyboard command, document that command before users enter the subset so they’ll know how to get out again.
Helpful tips for developers:
- If a user is trapped on a portion of the web page for a purpose, provide clear instructions to help the user exit the keyboard trap.
- Always stick to standard navigation methods, such as Tab, Shift+Tab, and the Arrow keys.
- Provide users with hints if custom keystrokes are required to operate a control.
- Make sure your third-party widgets are accessible, as they often cause keyboard operability issues.
How to test if you've met compliance:
- Using your tab button, navigate through the page you want to test.
- At the bottom of the page, check if you can move back up to the top of the page using the use shift-tab keystrokes.
- Check that your page allows you to complete a form without using a mouse. Try out different options on the form to ensure they’re all usable.
- Test all the features on your website thoroughly using only a keyboard.
If you can freely navigate the entire website and interact with all its elements using only the keyboard, your website passes this success criterion.
Bad and Good Examples (Developer Code)
BAD Code Snippet
<!-- HTML -->
<button id="openModal">Open Modal</button>
<div id="myModal" style="display: none;">
<h2>Modal Title</h2>
<p>Some content...</p>
<button id="closeModal">Close</button>
</div>
<!-- JavaScript -->
<script>
document.getElementById('openModal').onclick = function() {
document.getElementById('myModal').style.display = 'block';
};
document.getElementById('closeModal').onclick = function() {
document.getElementById('myModal').style.display = 'none';
};
</script>
In the example above, when the modal is open, the keyboard focus remains on the main page, and users can continue to tab through elements behind the modal. This can lead to a loss of context and can be disorienting for users who rely on keyboards or screen readers.
good Code Snippet
<!-- HTML -->
<button id="openModal">Open Modal</button>
<div id="myModal" tabindex="-1" style="display: none;">
<h2>Modal Title</h2>
<p>Some content...</p>
<button id="closeModal">Close</button>
</div>
<!-- JavaScript -->
<script>
document.getElementById('openModal').onclick = function() {
var modal = document.getElementById('myModal');
modal.style.display = 'block';
modal.focus(); // Move focus to the opened modal
};
document.getElementById('closeModal').onclick = function() {
document.getElementById('myModal').style.display = 'none';
document.getElementById('openModal').focus(); // Move focus back to the open button
};
</script>
In this improved example, when the modal opens, the keyboard focus is programmatically moved to the modal. This is thanks to the tabindex=”-1″ attribute which allows the normally non-focusable div to receive programmatic focus.
When the modal is closed, the focus is returned to the button that opened the modal. This way, we ensure that keyboard users don’t lose context and that they can’t accidentally tab into elements behind the modal.
Frequently Asked Questions
How does 'No Keyboard Trap' relate to other WCAG criteria?
No keyboard trap directly relates to other WCAG criteria related to keyboard accessibility such as 2.1.1 (Keyboard) and 2.4.3 (Focus Order). It is part of the guidelines which ensure that users can navigate and interact with web content using a keyboard.
Does this criterion apply only to websites? What about mobile apps and web applications?
Yes, this criterion applies to all web content, including websites, web applications, and mobile applications. Any digital product that can be accessed with a keyboard should meet this guideline.
What if there's a component that requires extensive data input via keyboard, like a spreadsheet?
If a component requires extensive data input via keyboard, WCAG 2.1 provides an exception for this. If a user interface has a mode of operation where entering and exiting requires more than an unmodified arrow or tab keys, then the user must be advised of the method for moving focus away.
What should I do if I encounter a third-party component that causes a keyboard trap?
If you don’t have control over the component’s code, reach out to the third-party developer and inform them of the issue. If possible, look for an alternative accessible component.
