Skip to content

Keyboard Trap Detector

Analyze HTML for keyboard traps, positive tabindex anti-patterns, focusable elements inside aria-hidden, missing skip links, and modal focus management.

FreeNo SignupNo Server UploadsZero Tracking

We fetch the page client-side. Some sites may block external access — use "Paste HTML" as a fallback.

Enter a URL or paste HTML above to detect keyboard traps and analyze tab order.
Embed code
<iframe src="https://wcagkit.com/embed/keyboard-trap-detector" width="100%" height="600" frameborder="0" title="Keyboard Trap Detector - wcagkit"></iframe>
<p style="font-size:12px;text-align:center;margin-top:4px;">
  <a href="https://wcagkit.com/tools/keyboard-trap-detector" target="_blank" rel="noopener">Powered by wcagkit</a>
</p>
Attribution preview

Powered by wcagkit

How to Use Keyboard Trap Detector

  1. 1

    Paste your HTML

    Copy the HTML source code of the page you want to analyze for keyboard traps and focus issues.

  2. 2

    Click Analyze

    Press the Analyze button to parse all focusable elements and detect potential keyboard traps.

  3. 3

    Review tab order

    View the visual tab order flow diagram to understand how keyboard focus moves through your page.

  4. 4

    Fix issues

    Address errors like focusable elements inside aria-hidden and warnings like positive tabindex values.

Frequently Asked Questions

A keyboard trap occurs when a user navigating with the keyboard gets stuck in a component and cannot move focus away using standard keyboard interactions (Tab, Shift+Tab, Escape, or arrow keys). WCAG 2.1.2 requires that if keyboard focus can be moved to a component, it can also be moved away using only the keyboard.

Positive tabindex values (tabindex='1', tabindex='2', etc.) override the natural DOM order for tab navigation. This creates confusing and unpredictable focus behavior, especially as pages change over time. Best practice is to use tabindex='0' to add elements to the natural tab order and tabindex='-1' for elements that should be programmatically focusable but not in the tab order.

When an element is inside an aria-hidden='true' container, it is hidden from assistive technology but can still receive keyboard focus. This means a screen reader user would focus on an element that is invisible to their assistive technology, creating a confusing ghost focus experience. Either remove the element from the tab order with tabindex='-1' or remove the aria-hidden attribute.

A skip link is a link, typically the first focusable element on the page, that allows keyboard users to bypass repetitive navigation and jump directly to the main content. WCAG 2.4.1 (Bypass Blocks) requires a mechanism to skip repeated content blocks, and a skip link is the most common implementation.

No. All analysis is performed entirely in your browser using JavaScript. Your HTML source code never leaves your device.

Related Tools

Focus Order Visualizer

Visualize keyboard tab order

Try it

Touch Target Checker

Check touch target sizes

Try it

ARIA Validator

Validate ARIA attributes

Try it
Fo

Form Analyzer

Check form accessibility

Try it

Keyboard Accessibility: A Fundamental Requirement

Keyboard accessibility is one of the four foundational principles of WCAG and affects more users than many developers realize. Beyond screen reader users, keyboard navigation is essential for users with motor impairments who cannot use a mouse, power users who prefer keyboard shortcuts, users with temporary injuries, and users of alternative input devices that emulate keyboard input. When keyboard traps exist, these users become completely blocked from completing their tasks.

How Keyboard Traps Occur

Keyboard traps most commonly occur in modal dialogs that capture focus without providing an Escape key handler, custom widget implementations that use JavaScript to redirect focus back to themselves, embedded content like iframes or third-party widgets that do not properly manage focus, and auto-focus behaviors that override user-initiated focus changes. Less obvious traps include components that visually disappear but retain focus, and roving tabindex implementations that fail to handle edge cases.

Understanding Tab Order

The tab order of a page is determined by the DOM order of focusable elements, modified by tabindex values. Elements with positive tabindex values are focused first (in order of their tabindex value), followed by elements with tabindex='0' or no tabindex in DOM order. Elements with tabindex='-1' are removed from the tab order but can receive focus programmatically. The natural DOM order should match the visual reading order, and positive tabindex values should be avoided because they create maintenance challenges and confusing navigation patterns.

Best Practices for Focus Management

Always ensure modal dialogs trap focus within the dialog while it is open and restore focus to the triggering element when closed. Provide Escape key handling for any component that traps focus. Use aria-modal='true' on dialog elements. Never place focusable elements inside aria-hidden containers. Add skip links as the first focusable element on every page. Test keyboard navigation regularly by unplugging your mouse and attempting to complete all user journeys using only the keyboard.