How does the browser actually decide tab order?

Sequential focus navigation runs in three groups. First, every element with a positive tabindex is visited in ascending order of that value (when two share a value, DOM order breaks the tie). Next come elements with tabindex="0" or that are natively focusable (links with href, buttons, form fields), in DOM order. Finally, elements with a negative tabindex such as tabindex="-1" are skipped entirely by Tab — they can only be focused programmatically with element.focus(). This tool implements exactly that algorithm, so the map reflects what a real keyboard user experiences.

Why is positive tabindex considered an anti-pattern?

A positive tabindex pulls its element to the front of the whole document’s focus order, ahead of everything that relies on natural DOM order. To keep the sequence sensible you would then have to assign and maintain a positive value on every focusable element on the page — and renumber them all whenever the layout changes. In practice this produces a tab order that contradicts the visual reading order, which fails WCAG 2.4.3 Focus Order. The reliable fix is to remove the positive values and order the DOM the way you want users to tab through it.

What does “DOM #5 → Tab #1” mean on the map?

It means the element that appears fifth in your source markup is the first place focus lands when the user presses Tab. That gap is the signature of a positive tabindex (or a script-managed order) overriding source order. When DOM position and tab position match, focus flows predictably; when they diverge, the row is highlighted and the audit explains the jump.

When is tabindex="-1" a problem and when is it fine?

tabindex="-1" removes an element from the Tab sequence while still allowing element.focus() to move focus there with script. That is exactly right for things like a route-change target, an error summary you focus after validation, or the inactive items in a roving-tabindex widget. It becomes a problem when it lands on a control users are expected to reach by keyboard, because they simply cannot Tab to it. The tool lists removed elements separately and only raises a note when a clearly interactive control has been pulled out.

What is a “ghost” tab stop?

A ghost tab stop is a focusable element that is visually hidden — via the hidden attribute, display:none, visibility:hidden, or being positioned offscreen — yet still sits in the tab order. Keyboard users hit a stop where nothing appears to be focused, which is disorienting. The validator warns when an element looks hidden but remains in the sequence; the fix is to hide it in a way that also removes it from focus (display:none or the hidden attribute), or to set tabindex="-1" while it is offscreen.

Does this replace testing with a real keyboard?

No — it’s a fast static check that catches the structural problems you cannot see by eye, especially positive tabindex and order mismatches. It analyses markup with a tokenizer and cannot know about focus moved by JavaScript, dynamically inserted content, or CSS that visually reorders elements (flexbox order, grid placement) without changing the DOM. Use it to clean up the source, then Tab and Shift+Tab through the rendered page to confirm the order matches the reading order and every stop shows a visible focus indicator.

Focus Order Validator

Reading the DOM top-to-bottom doesn’t tell you the tab order — a single positive tabindex silently reorders focus. Paste your HTML and this tool computes the real keyboard tab sequence the browser builds, draws a numbered focus-order map, and shows exactly where the tab order leaves the DOM order. It flags positive-tabindex anti-patterns, backward focus jumps, ghost tab stops, and elements pulled out of the order with tabindex=-1, all against WCAG 2.4.3 Focus Order.

About this ToolHow it works, benefits & use cases

Reading your HTML top to bottom does not tell you what order the keyboard will visit elements — a single positive tabindex silently jumps to the front and reorders the entire page. This validator parses your markup and computes the real sequential focus order the browser builds, then draws a numbered focus-order map showing each tab stop with its DOM position alongside its actual tab position. When the two diverge it highlights the jump so you can see focus leaping around the page. It applies the exact HTML rule browsers use: elements with tabindex greater than zero come first (ascending by value, DOM order breaking ties), then tabindex="0" and natively focusable elements in DOM order, while tabindex="-1" elements are pulled out of the sequence. It flags positive-tabindex anti-patterns, backward focus jumps, ghost tab stops on hidden elements, and interactive controls removed from the order — all against WCAG 2.4.3 Focus Order — and gives you a copyable report and a shareable URL.

How to Use

1Paste your HTML into the editor, or load the built-in mismatched or clean example.
2Read the focus-order map on the left — it lists every tab stop in the order Tab actually visits them.
3Watch for highlighted rows and the “DOM #n → Tab #n” badge: those are stops the tab order reaches out of DOM sequence.
4Check the audit panel for positive-tabindex errors, backward jumps, and tabindex="-1" notes, each with a concrete fix.
5Copy the plain-text focus-order report or share the URL, then verify by tabbing through the rendered page.

Key Benefits

Computes the real browser tab order, not just a list of focusable elements
Visual focus-order map contrasts each element’s DOM position with its actual tab position
Catches positive tabindex — the most common and most damaging Focus Order anti-pattern
Detects backward focus jumps and reports the exact step where focus leaps
Flags ghost tab stops on hidden-but-focusable elements and interactive controls removed via tabindex="-1"
Maps every finding to WCAG 2.4.3 Focus Order with an actionable fix
Pure client-side analysis — nothing is rendered, executed, or sent anywhere; shareable URL for handoff

Common Use Cases

Auditing a form where inputs were given tabindex="1", "2", "3" and now skip the rest of the page
Proving to a teammate that a positive tabindex reorders focus, with a side-by-side DOM-vs-tab map
Checking that a modal’s close button and route landmarks aren’t accidentally removed from the tab order
Spotting offscreen menus or hidden panels that still trap a keyboard user on an invisible focus stop
Reviewing a component’s markup before testing keyboard navigation in the browser

Focus-order map

In the order Tab visits them

1
<input>textboxtabindex=1
“Last name”
DOM #3Tab #1
2
<button>buttontabindex=2
“Submit”
DOM #5Tab #2
3
<input>textboxtabindex=3
“First name”
DOM #2Tab #3
4
<a>link
“Skip to content”
DOM #1Tab #4
5
<select>combobox
“United States”
DOM #4Tab #5
6
<button>button
“Cancel”
DOM #6Tab #6

The highlighted stops are reached in a different order than they appear in the DOM — focus jumps around the page.

3 issues to fixpositive tabindex

<input> at DOM position 3 uses tabindex="1". Positive tabindex pulls it ahead of the natural flow and forces you to manage the order of every other focusable control.· 2.4.3 Focus Order (A)Fix: Remove the positive tabindex (use tabindex="0" or none) and reorder the DOM so source order matches the visual/reading order.
<button> at DOM position 5 uses tabindex="2". Positive tabindex pulls it ahead of the natural flow and forces you to manage the order of every other focusable control.· 2.4.3 Focus Order (A)Fix: Remove the positive tabindex (use tabindex="0" or none) and reorder the DOM so source order matches the visual/reading order.
<input> at DOM position 2 uses tabindex="3". Positive tabindex pulls it ahead of the natural flow and forces you to manage the order of every other focusable control.· 2.4.3 Focus Order (A)Fix: Remove the positive tabindex (use tabindex="0" or none) and reorder the DOM so source order matches the visual/reading order.
Tab order jumps backward: focus moves from DOM element 5 to element 2 on tab step 3. Keyboard users will feel focus leap around the page.· 2.4.3 Focus Order (A)Fix: Make the tab sequence follow the DOM, then make the DOM follow the visual reading order.
Tab order jumps backward: focus moves from DOM element 2 to element 1 on tab step 4. Keyboard users will feel focus leap around the page.· 2.4.3 Focus Order (A)Fix: Make the tab sequence follow the DOM, then make the DOM follow the visual reading order.

How to fix the order

Remove the positive tabindex from elements #3, #5, #2. Replace with tabindex="0" only if the element is a custom control that isn't natively focusable.
Reorder the source so the elements appear in the DOM in the same order users should tab through them — the browser then handles focus order for free.

Focus-order report

Plain-text summary of the computed tab sequence

Focus Order Report
==================

Tab stops: 6
Positive tabindex: YES — anti-pattern
Tab order matches DOM order: NO — focus jumps around

Sequence (in the order Tab visits them):
  Tab #1  ←  DOM #3   <input> textbox "Last name"  [tabindex=1]
  Tab #2  ←  DOM #5   <button> button "Submit"  [tabindex=2]
  Tab #3  ←  DOM #2   <input> textbox "First name"  [tabindex=3]
  Tab #4  ←  DOM #1   <a> link "Skip to content"  [auto]
  Tab #5  ←  DOM #4   <select> combobox "United States"  [auto]
  Tab #6  ←  DOM #6   <button> button "Cancel"  [auto]

Issues:
  [ERROR] [2.4.3 Focus Order (A)] <input> at DOM position 3 uses tabindex="1". Positive tabindex pulls it ahead of the natural flow and forces you to manage the order of every other focusable control.
  [ERROR] [2.4.3 Focus Order (A)] <button> at DOM position 5 uses tabindex="2". Positive tabindex pulls it ahead of the natural flow and forces you to manage the order of every other focusable control.
  [ERROR] [2.4.3 Focus Order (A)] <input> at DOM position 2 uses tabindex="3". Positive tabindex pulls it ahead of the natural flow and forces you to manage the order of every other focusable control.
  [WARNING] [2.4.3 Focus Order (A)] Tab order jumps backward: focus moves from DOM element 5 to element 2 on tab step 3. Keyboard users will feel focus leap around the page.
  [WARNING] [2.4.3 Focus Order (A)] Tab order jumps backward: focus moves from DOM element 2 to element 1 on tab step 4. Keyboard users will feel focus leap around the page.

HTML

Paste markup to validate its tab order

Analysed live with a tokenizer — nothing is rendered or executed. Positive tabindex, backward jumps, and ghost stops are flagged below.

Tab stops: 6Positive tabindex: yesOrder matches DOM: no

How the browser builds the tab order

Pressing Tab doesn’t simply walk the page top to bottom. The browser builds the sequential focus order in three groups: first every element with a tabindex greater than zero, sorted ascending by that number (ties broken by DOM order); then everything with tabindex="0" or that’s natively focusable, in DOM order; and elements with a negative tabindex are dropped from the sequence entirely (they can still be focused with script). The map on the left runs exactly this algorithm.

Why positive tabindex is an anti-pattern

A single positive tabindex jumps to the front of the whole page, so to keep focus sensible you’d have to put a positive value on every focusable element — and renumber them all whenever the layout changes. It’s brittle and almost always produces a tab order that contradicts the visual order, failing WCAG 2.4.3 Focus Order. The fix is nearly always the same: delete the positive values and put the elements in the DOM in the order you want people to reach them.

Was this tool helpful?

Share Your Experience

Help others discover this tool!

Share on

Focus Order Validator

How to Use

Key Benefits

Common Use Cases

Focus-order map

HTML

How the browser builds the tab order

Why positive tabindex is an anti-pattern

Was this tool helpful?

Share Your Experience

Related tools

Frequently Asked Questions - Focus Order Validator