Tab Order Visualizer

Paste any HTML snippet and this tool computes the exact keyboard tab sequence a user would follow. It applies the WCAG focus-order algorithm: positive tabindex elements come first (ascending), then natural DOM order. Elements with tabindex=-1 are listed separately as script-focusable only. Anti-patterns like positive tabindex values and focusable elements with no accessible name are flagged so you can fix them before users encounter them.

How to use the Tab Order Visualizer

Paste the HTML of a form, modal, or page section into the text area and click Visualize Tab Order. The tool will:

  1. Parse the HTML safely with DOMParser (nothing is injected into the live page).
  2. Collect all natively focusable elements: <a href>, <button>, <input>, <select>, <textarea> (not disabled, not hidden), and any element with a tabindex attribute.
  3. Sort them by the WCAG tab-order rule: elements with a positive tabindex come first (sorted numerically, DOM order breaks ties), then the rest follow natural document order (tabindex=0 or absent).
  4. Elements with tabindex=-1 are excluded from the tab sequence but listed at the bottom as "script-focusable only".

The result shows a numbered sequence with each element's tag, id/name, and accessible name (derived from aria-label, associated <label>, alt, placeholder, or text content). Anti-patterns — positive tabindex values and focusable elements with no accessible name — are flagged in red with a suggested fix.

Tab order and why it breaks

The keyboard tab order is the sequence in which interactive elements receive focus when a user presses Tab. It is determined by the browser following a two-stage algorithm defined in the HTML specification: first, any element with a positive integer tabindex (1, 2, 3…) is visited in ascending numeric order; then all elements with tabindex="0" or no tabindex are visited in the order they appear in the DOM. Elements with tabindex="-1" are excluded from this sequence entirely — they can only receive focus via JavaScript (el.focus()), which is useful for custom widgets.

The most common anti-pattern is using positive tabindex values (e.g. tabindex="3") to "fix" a broken visual layout. This creates a maintenance nightmare: every time the page changes, the manual sequence must be re-audited. A far better approach is to fix the source order in the HTML to match the intended reading/interaction order, and then let the browser's natural algorithm do the right thing. WCAG 2.1 Success Criterion 2.4.3 (Focus Order) requires that the focus sequence preserve meaning and operability — a mis-ordered tab sequence is a Level A accessibility failure.

A second common failure is a focusable element with no accessible name — for example, an icon-only <button><img src="x.png"></button> with no alt, no aria-label, and no visible text. Screen readers will announce this as "button" with no description, leaving keyboard users unable to understand the control's purpose. WCAG 2.4.6 and 4.1.2 both address this.

Common use cases

  • Accessibility audits — confirm the tab sequence matches the visual reading order before submitting to WCAG or VPAT reviews.
  • Form review — catch inputs that are accidentally skipped (disabled by mistake) or arrive out of order due to CSS positioning tricks.
  • Modal / dialog QA — verify that focus is trapped inside a dialog and that all interactive controls inside are reachable.
  • Refactoring legacy HTML — discover lurking tabindex values left behind from an older layout, which can silently break keyboard navigation.
  • Component library review — paste a rendered component template and verify its internal focus management before merging.

Frequently asked questions

Why do positive tabindex values cause problems?
When any element on the page has a positive tabindex, the browser's first pass visits ALL such elements across the entire document before reaching tabindex=0 elements. If a component deep in the DOM has tabindex="1", it will receive focus before everything else — including the site header — which is almost never the intended behavior and is very difficult to maintain.

What is tabindex="-1" used for?
It removes the element from the natural tab sequence while keeping it programmatically focusable. Custom widgets (carousels, tree views, data grids) use this to manage focus internally with arrow keys, calling el.focus() on the active item while keeping all other items at tabindex="-1".

How does the tool determine an accessible name?
It checks, in priority order: aria-label attribute, aria-labelledby (text of the referenced element), a

Does the tool handle shadow DOM?
No — DOMParser produces a plain DOM tree without shadow roots. Shadow DOM encapsulates its internals and requires browser DevTools or a live-page audit tool (e.g. axe, Lighthouse) to inspect.

What WCAG criteria does tab order relate to?
Primarily 2.4.3 Focus Order (Level A), 2.1.1 Keyboard (Level A), and 4.1.2 Name, Role, Value (Level A). A correct, meaningful tab order is a prerequisite for any keyboard-accessible interface.