focus-trap

A keyboard trap happens when keyboard focus enters a component and cannot leave it. Users can move into the component with Tab, but pressing Tab, Shift+Tab, Escape, or the arrow keys never takes them back out, so the rest of the page becomes unreachable. Keyboard traps can be created intentionally or by accident. Common causes include scripts that override the default behavior of Tab or Escape without offering another way out, and complex or non-standard components, such as custom widgets, embedded editors, or third-party content, that capture every key press. For people who rely on a keyboard or a screen reader, a trap can lock them into a single component and block the rest of the page entirely.

Pass Patterns

Tab and Shift+Tab move focus freely

The component uses native, focusable elements and does not override Tab, so focus can enter it and leave it in both directions.

<div class="toolbar">
    <button>Bold</button>
    <button>Italic</button>
    <button>Underline</button>
</div>
<a href="/next">Next page</a>

A modal dialog that can be closed with Escape

Focus is intentionally kept inside the open dialog, but Escape and the Close button always provide a standard way out.

<div role="dialog" aria-modal="true" aria-labelledby="dialog-title">
    <h2 id="dialog-title">Edit profile</h2>
    <button id="close-dialog">Close</button>
</div>


<script>
    const dialog = document.querySelector('[role="dialog"]');
    dialog.addEventListener("keydown", (event) => {
        if (event.key === "Escape") closeDialog(); // Standard way out
    });
    document.getElementById("close-dialog").addEventListener("click", closeDialog);
</script>

Fail Patterns

Tab is blocked inside a component

The script prevents Tab's default behavior and keeps moving focus back into the same field, so keyboard users can never leave it.

<input id="search" type="text" aria-label="Search" />


<script>
    document.getElementById("search").addEventListener("keydown", (event) => {
        if (event.key === "Tab") {
            event.preventDefault(); // Focus can never move on
        }
    });
</script>

Focus is forced back when it leaves

A blur handler returns focus to the field every time the user tries to move away, trapping them in place.

<input id="email" type="email" aria-label="Email" />


<script>
    const email = document.getElementById("email");
    email.addEventListener("blur", () => email.focus());
</script>

WCAG techniques

Sufficient techniques

• G21: Ensuring that users are not trapped in content

Failure techniques

• F10: Failure of Success Criterion 2.1.2 and Conformance Requirement 5 due to combining multiple content formats in a way that traps users inside one format type

Try It Yourself

Using a keyboard

1. Load the page.
2. Press Tab to move focus into each component, then keep pressing Tab and Shift+Tab to move away from it.
3. If focus does not leave, try Escape and the arrow keys.

Expected results: Focus can always move away from the component using standard keys, or the component tells users how to leave it.

Actual results: Focus stays stuck inside the component, and the rest of the page cannot be reached with the keyboard.

Using a screen reader

1. Load the page and open a screen reader.
2. Move through the page with Tab and Shift+Tab.
3. Listen for whether announcements keep repeating the same component.

Expected results: The screen reader announces each component in turn, and you can move past every one of them.

Actual results: The screen reader keeps announcing the same component, because focus cannot leave it.

FAQ

Standards and Regulations

Personas impacted by this issue

• Keyboard
• Screen Reader
• Braille
• Motor and Mobility
• Switch Access

Learn More

• Understanding SC 2.1.2 No Keyboard Trap

Related Issues

• keyboard-accessible
• focus-kept-within-the-modal
• modal-dismissed-on-esc