2.1.2 No Keyboard Trap: 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. (Level A)

Requirements

• No item traps the keyboard focus. Upon reaching any item on the page, it is possible to move to the item that precedes or follows it using the keyboard.

Why is it important?

This ensures that people who use a keyboard do not get stuck on any part of the page.

Summary

Make sure that keyboard-only users don’t get trapped within any element. When someone using a keyboard to navigate content moves to an element, they must be able to move away from it again.

Common mistakes

A modal dialogue opens but cannot be closed with the keyboard, preventing the user from accessing the original content underneath;
Content is presented in an infinite scroll, so a keyboard user is forced to tab through everything before they can exit the scroll area.

Design Guide

• On your designs, indicate the order in which interactive elements should receive keyboard focus.
• Also indicate when actioning a button should move the keyboard focus somewhere else. This will help make sure that components such as dialogs can be closed easily by users.

Example: Designing a modal dialog for the Web

• Opening a modal dialog should move the keyboard focus to an element inside the modal dialog, rather than keeping the keyboard focus outside it. It’s best to move the keyboard focus to the ‘Close’ button inside the modal dialog, or to the main header within the dialog.
• The keyboard focus should stay within the modal dialog when users press the ‘Tab’ key several time, rather than go back to content behind the modal dialog.
• There should be a button to close or dismiss the modal dialog. Pressing that button should return the keyboard focus to the button that triggered modal dialog in the first place (so that the user go back to where they were on the page before opening the modal dialog).

No Keyboard Trap Examples for Web

• Do not trap focus via JavaScript onBlur, onChange or onFocus events, or other custom focus code.
• Do not embed elements that may trap focus.

Example:

<!-- JavaScript updates field label to indicate an error but does not trap focus -->
<script type="text/javascript">
function check() {
  if (isValid()) {
    // update field label to explain that field is in error but do not trap focus
   var s = createElement("span");
   s.innerText = "(Invalid name)";
   document.getElementById("l1").appendChild(s);
  }
}
</script>

<label id="l1" for="name1"> First name</label>
<input onBlur="check();" type="text" id="name1">  

Failure example:

<!-- JavaScript keeps returning focus to a field until a user enters data correctly -->
<script type="text/javascript">
function check() {
  if (isValid()) {
    document.getElementById("name1").focus();
  }
}
</script>

<label for="name1"> First name</label>
<input onBlur="check();" type="text" id="name1">  

References

1. Modal dialog example in the ARIA Authoring Practices Guide
2. W3C’s detailed explanation with techniques and examples.
3. Keyboard accessibility article by WebAIM
4. Accessible JavaScript article about JavaScript event handlers by WebAIM
5. Accessibility Guidelines- Github.io