keyboard-trap

Ensure that a keyboard trap does not restrict users from moving away from content.

Description

If a component can receive keyboard focus, users must be able to move focus away from that component using only a keyboard. If moving focus requires more than standard keys such as Tab, Shift+Tab, or arrow keys, the website must clearly inform this method to the users.

Why is it important?

Users who rely solely on a keyboard, including people with limited vision, have no alternative means of navigation. A keyboard trap prevents them from using the rest of the page and can make the entire experience inaccessible.

Examples

Consider the following examples:

Modal dialogs and embedded media

• Success:
  • A modal dialog traps focus within itself while open, and pressing Escape or activating the Close button returns focus to the page.
  • A widget that captures keystrokes displays instructions explaining how to exit before and within the widget.
• Failure:
  • A custom component captures Tab key presses and prevents focus from ever leaving it.
  • An embedded media player intercepts all keyboard input with no way to exit using the keyboard.

Sub-menus and multi-level navigation

Dropdown and flyout navigation menus that open sub-menus on hover or click are common sources of keyboard traps:

• Success:
  • A navigation bar contains a Products menu item. Pressing Enter or Space opens a sub-menu. Users can navigate sub-menu items with the Down and Up arrow keys, press Escape to close the sub-menu and return focus to the Products trigger, and press Tab to skip the sub-menu entirely and move to the next top-level item.
  • A mega-menu opens on focus of a top-level link. A visible tooltip reads: “Press Escape to close the menu.” Pressing Escape collapses the menu and returns focus to the trigger.
• Failure:
  • A flyout sub-menu intercepts all Tab key presses and loops focus indefinitely within the sub-menu items with no Escape key support or visible exit instruction.
  • A custom navigation widget overrides the browser’s default Tab behavior and offers no alternative key to move focus back to the parent menu or the rest of the page.

Calendar and date picker dropdowns

Date pickers open a calendar overlay, which must allow users to enter and exit the widget without a mouse:

• Success:
  • Pressing Enter on a date input opens an inline calendar. Users can navigate months with the Left, Right, Up, and Down arrow keys, select a date with Enter or Space, and close the calendar with Escape, which returns focus to the date input field.
  • A date range picker displays the instruction “Use arrow keys to navigate dates. Press Escape to close.” above the calendar grid before and while it opens.
• Failure:
  • A custom calendar widget captures arrow keys and Tab presses so that once focus enters the calendar grid, users cannot exit using the keyboard. The only way to close it is to click outside the widget with a mouse.
  • A date picker opens an overlay but does not respond to Escape. Pressing Tab from the last calendar cell cycles back to the first cell, trapping the user indefinitely.

Autocomplete and combobox dropdowns

Combobox components that show a suggestion list while typing can trap focus if the list is not handled correctly.

• Success:
  • An autocomplete search field opens a suggestion list as the user types. The user can navigate suggestions with the Down and Up arrow keys, select one with Enter, and dismiss the list with Escape while keeping focus in the input field.
  • A multi-select combobox keeps focus on the input while the list is open. Pressing Tab closes the list and moves focus to the next focusable element outside the widget.
• Failure:
  • A custom autocomplete moves focus into the suggestion list on the first keystroke and intercepts Tab so that users can never move focus outside the list or back to the input.
  • A combobox suggestion list does not respond to Escape, forcing keyboard users to navigate through every suggestion before reaching another part of the page.

Rich text editors

Embedded rich text editors (for example, code editors or WYSIWYG editors) often capture keystrokes for formatting shortcuts, which can trap focus:

• Success:
  • A WYSIWYG editor displays a visible notice: “Press Escape then Tab to move focus outside the editor.” Pressing Escape releases keyboard capture mode, and pressing Tab then moves focus to the toolbar or the next element outside the editor.
  • A code editor widget uses Escape to exit its keyboard capture mode. The editor announces “Keyboard navigation unlocked” to screen readers when capture mode is released.
• Failure:
  • An embedded code editor intercepts every Tab key press for indentation and never provides a way to exit focus using the keyboard or displays any instruction about how to do so.
  • A rich text editor captures Escape for its own dismiss actions, but those actions close internal dialogs without ever releasing focus back to the rest of the page.

How to fix?

Ensure users can always navigate away from any component using standard keyboard keys. If your component requires non-standard keys to release focus, display clear instructions describing the exit method before and within the component.

References

• WCAG 2.1.2: No Keyboard Trap