In this WCAG Fix It guide, we’re looking at a serious accessibility problem: keyboard traps.

A keyboard trap occurs when a user navigates to an element using the keyboard but cannot move away from it using standard keyboard commands.

When this happens, users can become stuck inside a component with no way to continue navigating the page.

And when users lose control of navigation, the experience quickly becomes unusable.

What Is WCAG 2.1.2?

WCAG 2.1.2 – No Keyboard Trap requires that if keyboard focus can be moved to a component using the keyboard, focus must also be able to move away from that component using the keyboard.

In simple terms, users must never become trapped inside an element when navigating with the keyboard. If a special method is required to exit a component, the user must be clearly instructed on how to do so. This requirement ensures users always remain in control of their navigation.

What Is a Keyboard Trap?

A keyboard trap occurs when a user navigates into a component but cannot exit it using the keyboard.

Common examples include:

• Modals or popups that trap focus
• Dropdown menus that cannot be closed
• Custom widgets that intercept keyboard events
• Interactive elements that block Tab navigation

When this happens, users may be unable to reach other content on the page.

The Human Impact of Keyboard Traps

Imagine navigating a website using only the keyboard. You press Tab to move through the page.

You open a popup and your tab focus moves inside the popup, but when you press Tab again, the focus loops endlessly inside the pop-up.

You cannot reach:

• The page content
• The navigation menu
• The close button
  

You’re stuck and cant use the website anymore. For keyboard-only users, this can make the entire website unusable. Navigation should always allow users to move forward or backward freely.

Common WCAG 2.1.2 Failures

Here’s what we typically see when scanning websites:

• Modals that trap focus and cannot be closed using the keyboard
• Dropdown menus that cannot be exited with Tab or Escape
• Interactive widgets intercepting keyboard input
• Embedded media players trapping focus
• Custom navigation components that block normal keyboard navigation

All of these can fail WCAG 2.1.2.

How to Fix Keyboard Trap Issues

Ensure Users Can Exit Interactive Components

Users should always be able to move focus away using standard keyboard commands.

For example:

• Tab moves forward
• Shift + Tab moves backward
• Escape closes dialogs or menus

These behaviours are widely expected by keyboard users.

Implement Proper Modal Behaviour

For modal dialogs:

• Focus should move inside the modal when it opens
• Focus should return to the triggering element when it closes
• Users must be able to close the modal using the keyboard (usually Escape)
  

Example close button:

<button aria-label=”Close dialog”>Close</button>

Avoid Blocking Keyboard Events

Custom scripts sometimes block keyboard navigation unintentionally.

Developers should ensure components do not override standard keyboard behaviour unless necessary.

Interactive elements should respect expected keyboard interactions.

Use Accessible UI Components

Whenever possible, use native HTML elements or well-tested accessibility libraries.

Native elements such as <button>, <dialog>, and <input> already support proper keyboard behaviour.

This reduces the risk of keyboard traps.

If You’re Using a CMS or Website Builder

Keyboard traps often occur when:

• Popup plugins override keyboard navigation
  
• Custom menus intercept key events
  
• Embedded third-party widgets are poorly implemented
  

To fix:

• Test interactive elements using only the keyboard
  
• Check modal and popup behaviour
  
• Review plugin accessibility documentation
  
• Ensure Escape closes dialogs
  

Always retest after updates.

How to Test WCAG 2.1.2

The easiest test is simple.

Put your mouse aside and use only the keyboard.

Navigate the page using:

• Tab
• Shift + Tab
• Enter
• Escape
  

Ask:

• Can I move into every component?
• Can I move out of every component?
• Do modals and menus close correctly?
  

If you ever become stuck inside an element, the page fails WCAG 2.1.2. After fixing the issue, re-run your accessibility scan to confirm the problem is resolved.

Why WCAG 2.1.2 Matters Beyond Compliance

Preventing keyboard traps:

• Keeps navigation predictable
• Supports screen reader users
• Improves keyboard usability
• Reduces user frustration
• Improves overall interaction design
• Reduces legal risk
  

Users must always be able to move freely through a page. Accessibility is not just about reaching content, it’s about ensuring users never lose control of navigation.

WCAG 2.1.2 Quick Fix Checklist

Keyboard users can enter and exit all components
Modals can be closed using the keyboard
Escape key closes dialogs where appropriate
Dropdown menus allow normal keyboard navigation
Custom widgets do not block Tab navigation
Interactive elements tested using keyboard only
Issues re-tested after updates

WCAG 2.1.2 No Keyboard Trap Frequently Asked Questions

What is WCAG 2.1.2 No Keyboard Trap?

WCAG 2.1.2 requires that keyboard users can move focus into and out of all components without becoming trapped.

What causes keyboard traps?

Keyboard traps often occur when custom scripts intercept keyboard navigation or when modals and widgets do not allow users to exit using the keyboard.

Can modals trap focus?

Focus can remain inside a modal while it is open, but users must still be able to close the modal using the keyboard.

How do I test for keyboard traps?

Navigate the page using only the keyboard. If you become stuck inside an element and cannot move away using standard keys, the page fails this criterion.