accessibility-guidelines

This document is in beta. Help us by reporting issues via Github or email

Back to the overview page

No keyboard trap

On this page:

• Summary
• Requirements
• Guidance for Design
• Guidance for iOS
• Guidance for Android
• Guidance for Web
• More info

---

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.

---

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.

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.

Why?

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

Official wording in the Web Content Accessibility Guidelines

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)

See the W3C’s detailed explanation of this guideline with techniques and examples.

---

Guidance for Design

• 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).

More guidance for Design

• Modal dialog example in the ARIA Authoring Practices Guide
• See the W3C’s detailed explanation of this guideline with techniques and examples.

---

Guidance for iOS

This section needs more content. Contribute via Github or email.

---

Guidance for Android

This section needs more content. Contribute via Github or email.

---

Guidance for Flutter

This section needs more content. Contribute via Github or email.

---

Guidance 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">   

More guidance for Web

• See the W3C’s detailed explanation of this guideline with techniques and examples.
• Keyboard accessibility article by WebAIM
• Accessible JavaScript article about JavaScript event handlers by WebAIM

---

More info

Sources

• W3C Web Content Accessibility Guidelines 2.1
• Government Digital Service WCAG 2.1 Primer
• Barclays’ Accessibility Design Standards

Contribute

This document is in beta. Help us by reporting issues via Github or email

This site is open source. Improve this page.