What is a keyboard trap?

A keyboard trap (WCAG 2.1.2) happens when focus moves into a component — often a modal or widget — and cannot be moved out using the keyboard alone. Users who rely on Tab and Shift+Tab become stuck and cannot reach the rest of the page.

Why does the tool flag positive tabindex?

Any tabindex value of 1 or higher pulls an element to the front of the tab sequence, overriding natural DOM order. This almost always produces a confusing, illogical focus path, so the tool reports it as an error.

Does a clean result mean my page is accessible?

No. This is a static heuristic that catches common anti-patterns in markup. It cannot run your JavaScript or move focus, so a manual keyboard-only test and a screen-reader pass are still required for a real WCAG audit.

What makes a modal accessible for keyboard users?

An accessible modal uses role="dialog" (or the native element) with aria-modal="true", moves focus into the dialog when it opens, traps Tab inside it while open, closes on Esc, and returns focus to the element that opened it.

Is my HTML uploaded anywhere?

No. The markup is parsed with the browser's built-in DOMParser entirely on your device. Nothing is sent to a server, so you can safely paste internal or pre-release markup.

Logical Focus Order Checker

The Logical Focus Order Checker scans pasted HTML for the structural patterns most likely to break keyboard navigation: modals and drawers that do not trap focus, custom widgets with no keyboard affordances, and tabindex values that scramble the natural focus order. It is built for developers and accessibility testers who need a fast first pass before a full WCAG audit. Everything is parsed in your browser, so internal markup never leaves your device.

How it works

The tool loads your markup into the browser’s built-in DOMParser and runs a series of targeted queries against the resulting document:

Positive tabindex — any element with tabindex greater than 0 is flagged, because positive values override source order and create an illogical tab sequence (WCAG 2.4.3).
Modal-like containers — elements with role="dialog", a native <dialog>, or class names containing modal, drawer, overlay, or popup are checked for a dialog role and aria-modal="true".
Custom widgets — dropdowns, date pickers, carousels, tabs, and tooltips are inspected for at least one natively focusable child and ARIA state such as aria-expanded or aria-haspopup.
Click handlers on non-interactive elements — an onclick on a div, span, li, or img without both tabindex="0" and a role is reported, because keyboard users cannot reach it.

Tips and notes

A passing result is a starting point, not a certificate. Static analysis cannot execute your JavaScript, so it cannot confirm that focus is actually moved into a dialog or returned afterwards. Always finish with a real keyboard-only pass: open each interactive component, press Tab and Shift+Tab to confirm focus stays logical, and press Esc to confirm you can escape. For dialogs, verify focus lands inside on open and returns to the trigger on close.

When the tool flags an onclick on a div, the correct fix is usually to swap in a real <button>. Native elements come with focusability, role, and Enter/Space handling for free, which removes a whole class of focus-order defects.