Goal
You’ll understand how keyboard-only navigation actually works in a browser, and be able to identify and fix the most common HTML mistake that breaks it.
Learn
Many users don’t or can’t use a mouse at all — some due to motor disabilities, some due to screen reader use (which is often paired with keyboard navigation), and some simply by preference or circumstance. For these users, the Tab key moves focus between interactive elements on a page, in a specific order.
By default, this order follows the actual HTML source order — the sequence elements appear in the markup, not their visual position on screen (which can differ due to CSS positioning or layout changes). This is exactly why building interactive elements from genuine native HTML (covered throughout Part 3’s forms lesson, and Part 5.2’s ARIA lesson) matters so much: native interactive elements like <button>, <a>, and form inputs are automatically part of this keyboard tab order, while a div styled to look like a button is not, unless explicitly given tabindex=”0″ as covered in the previous lesson.
The tabindex attribute can adjust this behavior, but requires real care:
tabindex="0"— adds an otherwise non-focusable element into the natural tab order, at its normal source-order position.tabindex="-1"— makes an element programmatically focusable (via JavaScript) but removes it from the regular Tab-key order entirely.tabindexwith a positive number (like “1” or “2”) — forces a specific, custom tab order, overriding natural source order entirely.
That last option, positive tabindex values, is genuinely risky and generally discouraged: it’s extremely easy to create a confusing, inconsistent tab order that doesn’t match visual layout, especially as a page evolves and new elements get added without every positive tabindex value being carefully re-coordinated. The far more reliable approach is simply structuring your actual HTML source order to match the intended logical/visual flow in the first place, letting the natural default tab order work correctly without needing manual overrides at all.
Decision Task
A developer wants a specific element to receive keyboard focus earlier in the tab order than its natural HTML position would provide, and considers using a positive tabindex value like “1” to force it. Before reading on: what’s the generally safer alternative this lesson recommends?
Show Answer
Reordering the actual HTML source to match the intended logical tab flow, rather than using a positive tabindex value to force a custom order. Positive tabindex values are genuinely risky to maintain consistently as a page evolves, while fixing the underlying source order solves the problem more reliably and permanently, letting the natural default tab behavior work correctly without special-case overrides.
Common Mistake
Using positive tabindex values (like tabindex=”1″, tabindex=”2″) to manually force a custom tab order, rather than fixing the actual HTML source order to match the intended flow. This is fragile and hard to maintain consistently, especially as new interactive elements get added later without every positive value being carefully re-coordinated relative to the others — a page can end up with a confusing, inconsistent tab order that doesn’t match visual expectations at all.
Practice Questions
1. What determines the default keyboard tab order on a page, if no tabindex values are used at all?
Show Answer
The actual HTML source order — the sequence elements appear in the markup, not necessarily their visual position on screen.
2. What does tabindex=”0″ do to an otherwise non-focusable element, like a styled div?
Show Answer
Adds it into the natural keyboard tab order, at its normal source-order position, making it keyboard-focusable like a native interactive element.
3. What does tabindex=”-1″ do, and how is it different from tabindex=”0″?
Show Answer
Makes an element programmatically focusable via JavaScript, but removes it from the regular Tab-key order entirely — unlike tabindex=”0″, a user tabbing through the page with the keyboard alone would never reach it.
4. Why are positive tabindex values (like “1”, “2”) generally discouraged, according to this lesson?
Show Answer
They’re fragile and hard to maintain consistently as a page evolves, easily creating a confusing tab order that doesn’t match visual/logical expectations, especially once new elements are added later.
5. Why does using genuine native interactive elements (button, a, form inputs) reduce the need to think about tabindex at all, in most cases?
Show Answer
They’re automatically part of the natural keyboard tab order by default, requiring no manual tabindex management, unlike custom-styled generic elements which need it added explicitly.
Try It Yourself
Without looking back, explain in your own words why fixing HTML source order is generally a more reliable fix for a tab-order problem than adding positive tabindex values to force a specific order.
Show Answer
Source order determines the natural default tab flow permanently and predictably as the actual structure of the page; positive tabindex values are a manual override that must be carefully coordinated across every element and re-checked whenever the page changes, making them fragile to maintain consistently over time, while fixing source order solves the root cause directly and permanently.
Quick Check
1. What determines the default keyboard tab order on a page?
Show Answer
The HTML source order.
2. What does tabindex=”0″ do?
Show Answer
Adds an otherwise non-focusable element into the natural tab order.
3. What does tabindex=”-1″ do?
Show Answer
Makes an element programmatically focusable via JavaScript, but removes it from the regular Tab-key order.
4. Why are positive tabindex values generally discouraged?
Show Answer
They’re fragile to maintain consistently and easily create a confusing tab order as a page evolves.
5. What’s the generally safer alternative to using positive tabindex for controlling tab order?
Show Answer
Structuring the actual HTML source order to match the intended logical/visual flow directly.