Tab Order Visualizer
Your markup is parsed and analyzed locally; it is never rendered, executed, or sent anywhere.
How it works
仕組みKeyboard users experience your page in the order the Tab key visits it, and that order can silently diverge from the visual layout, especially once tabindex attributes creep in. Paste any HTML fragment and this analyzer parses it locally (never rendering or executing it), finds every focusable element (links, buttons, form fields, and anything carrying a tabindex), and lists the exact tab sequence: positive tabindex values first in ascending order, then document order. It flags positive tabindex as the anti-pattern it usually is and notes tabindex placed on non-interactive elements.
Elements with tabindex of 1 or higher jump ahead of everything else on the page, creating a shadow ordering that’s brutal to maintain and confusing to keyboard users. The lasting fix is to arrange elements in the source in the order they should be reached, using only tabindex="0" or none at all.
Almost never for tabindex="0" unless you’re building a genuine custom widget with full keyboard handling and an ARIA role. tabindex="-1" is the common valid case: it lets scripts move focus to a container (like a route change heading) without adding it to the Tab sequence.
It follows the core rules: positive tabindex ascending, then document order, skipping disabled and tabindex="-1" elements. Real browsers also account for CSS (display: none removes elements from the sequence) and shadow DOM, which static analysis of a pasted fragment can’t see, so treat the result as a strong first check.