When a keyboard user navigates a web page by pressing the Tab key, the browser moves focus from one interactive element to the next in a specific sequence. This sequence is the tab order. By default, it follows the order in which focusable elements — links, buttons, form controls, and elements with a tabindex — appear in the HTML source code. A logical, predictable tab order is essential for users who rely on keyboards, switch devices, or assistive technologies to interact with a page.
Tab order is closely tied to the visual layout of a page. When the tab order matches the visual reading order, users can form a mental model of where they are on the page and predict where focus will move next. When the two diverge — due to CSS repositioning, misuse of tabindex, or other layout tricks — users can become disoriented, miss content, or struggle to complete tasks.
Why tab order matters
A meaningful tab order is a foundational requirement of web accessibility. WCAG 2.2 Success Criterion 2.4.3 (Focus Order) states that if a web page can be navigated sequentially, focusable components must receive focus in an order that preserves meaning and operability. Failing this criterion can make a page partially or completely unusable for several groups of people:
- Keyboard-only users who cannot use a mouse due to motor impairments depend on a logical tab sequence to reach every interactive control.
- Screen reader users hear elements announced in tab order; an illogical sequence creates confusion about page structure and relationships.
- Users of switch devices and voice control also rely on a coherent focus progression.
When tab order is broken, users may tab past critical form fields, miss navigation links, or land on elements that appear nowhere near the current visual focus — all of which erode trust and usability.
How tab order works
Default (source order)
Browsers automatically include natively focusable elements — <a> with an href, <button>, <input>, <select>, <textarea>, and <summary> — in the tab order based on their position in the DOM. Writing semantic HTML in a logical source order is the simplest and most reliable way to ensure a correct tab order.
The tabindex attribute
The tabindex attribute lets authors modify the default behavior:
-
tabindex="0"— Adds a non-focusable element (like a<div>) to the natural tab order. The element is focused in its DOM position. -
tabindex="-1"— Removes an element from the tab order but allows it to be focused programmatically via JavaScript’selement.focus(). Useful for managing focus in modals and single-page applications. -
Positive values (
tabindex="1",tabindex="2", …) — Force an element to appear earlier in the tab order. Elements with positivetabindexvalues receive focus before all elements withtabindex="0"or notabindex. This is almost always harmful because it creates a tab order that diverges from the DOM order, is hard to maintain, and surprises users.
CSS layout and tab order
CSS properties like flexbox order, grid-area, position: absolute, and float can rearrange the visual presentation without changing the DOM order. When the visual order and the DOM order disagree, the tab order (which follows the DOM) no longer matches what users see on screen. The fix is to restructure the HTML so the source order matches the intended visual sequence.
Skip navigation links
A skip navigation link placed at the very beginning of the page lets keyboard users jump past repetitive header and navigation content. This complements good tab order by reducing the number of Tab presses needed to reach the main content.
Code examples
Bad example — positive tabindex values
In the following form, positive tabindex values force the “Submit” button to receive focus before the input fields, creating a confusing experience:
<form>
<label for="name">Name</label>
<input type="text" id="name" tabindex="2">
<label for="email">Email</label>
<input type="email" id="email" tabindex="3">
<button type="submit" tabindex="1">Submit</button>
</form>
A keyboard user tabbing through this form would land on the Submit button first, then the Name field, then the Email field — completely out of visual order.
Good example — natural source order
By removing positive tabindex values and placing elements in a logical source order, the tab sequence matches what users see:
<form>
<label for="name">Name</label>
<input type="text" id="name">
<label for="email">Email</label>
<input type="email" id="email">
<button type="submit">Submit</button>
</form>
Bad example — CSS reordering breaks tab sequence
<div style="display: flex;">
<button style="order: 3;">Third visually</button>
<button style="order: 1;">First visually</button>
<button style="order: 2;">Second visually</button>
</div>
The visual order is “First visually → Second visually → Third visually,” but the tab order follows the DOM: “Third visually → First visually → Second visually.”
Good example — source order matches visual order
<div style="display: flex;">
<button>First visually</button>
<button>Second visually</button>
<button>Third visually</button>
</div>
Good example — using tabindex="-1" for programmatic focus
A modal dialog can move focus to a heading that isn’t natively focusable:
<div role="dialog" aria-labelledby="dialog-title" aria-modal="true">
<h2 id="dialog-title" tabindex="-1">Confirm Deletion</h2>
<p>Are you sure you want to delete this item?</p>
<button type="button">Cancel</button>
<button type="button">Delete</button>
</div>
<script>
document.getElementById("dialog-title").focus();
</script>
Here tabindex="-1" keeps the heading out of the normal tab order while allowing JavaScript to place focus on it when the dialog opens, giving screen reader users immediate context.
By relying on semantic HTML, avoiding positive tabindex values, and ensuring the DOM order mirrors the visual layout, you can maintain a tab order that is logical, predictable, and accessible to everyone.
Related terms
Help us improve this glossary term
Scan your site
Rocket Validator scans thousands of pages in seconds, detecting accessibility and HTML issues across your entire site.