Free Online Focus Order Visualizer
List focusable elements in keyboard order and find tabindex problems.
The analysis follows DOM order. Real browser tab order can also be affected by CSS that hides elements, shadow DOM, and browser UI, so verify important flows with the keyboard.
Focus order
| Tab | DOM | Element | Name / text | Tabindex | Flags |
|---|
About the Focus Order Visualizer
Keyboard users move through a page with the Tab key, and the sequence they follow is the focus order. When that sequence jumps around, skips controls, or lands on something invisible, the page becomes difficult or impossible to operate without a mouse. This visualizer takes pasted HTML, finds the elements that can receive focus, and lists them in the order the browser is likely to reach them. It also flags common causes of confusion: positive tabindex values, elements removed with tabindex="-1", hidden or disabled controls, and controls without an accessible name.
How the order is calculated
Browsers build the tab sequence from elements that are focusable by default, such as links with an
href, buttons, inputs, selects, and textareas. Any element with a tabindex value can join them.
Positive tabindex values are visited first, from the smallest number to the largest, regardless of where they
appear in the document. After that, the browser proceeds in DOM order through elements with tabindex="0" or no
tabindex at all. Negative values are focusable by script or pointer but are not part of the Tab sequence. The
tool reproduces that ordering and labels each row.
Why positive tabindex is discouraged
A positive tabindex seems convenient because it lets you put a control first. In practice it creates a separate ordering system that must be maintained forever. Add a new component with a larger number and the sequence changes; remove a component and the remaining numbers may leave a gap. It also breaks the expectation that Tab follows the visual reading order. The robust approach is to keep the DOM in the intended order and use CSS for layout, reserving tabindex="0" and tabindex="-1" for specific component patterns.
Hidden, disabled, and unnamed controls
Disabled controls and elements hidden with the hidden attribute, aria-hidden="true",
or an inert ancestor are skipped by the browser. They still appear in this table so you can see that they were
found and intentionally excluded. A control without an accessible name is announced only by its role, which
tells the user very little. Names come from visible text, a label element, aria-label, or aria-labelledby.
Placeholders are not a substitute for a persistent label because they disappear once typing begins.
Frequently asked questions
Does the visualizer render my page?
No. It parses the HTML into an inert document and inspects attributes and element types. CSS is not applied, so an element hidden by a stylesheet will not be detected as hidden. Use the browser's accessibility inspector to confirm computed visibility.
What is the difference between tabindex 0 and tabindex -1?
tabindex="0" places an element in the natural Tab order at its DOM position. tabindex="-1" makes an element focusable by script, such as when a dialog opens, but removes it from the Tab sequence. Use -1 deliberately for managed focus, not as a way to hide an interactive control.
Why is my custom div button not listed?
A plain div is not focusable. Add tabindex="0", an appropriate role, keyboard handlers for Enter and Space, and a visible focus style. Better still, use a native button element, which provides all of that behavior automatically.