Online Tool Store
· 4 min read
How to Check the Keyboard Tab Order of a Page
Manesh Jayawardhana
CIO & Co-founder
Press Tab on a page you built. If you can predict where the focus ring lands next, every time, for the whole page — you’re in a minority. On most sites the order eventually does something surprising: jumping to the footer, disappearing into a closed menu, or skipping the primary call to action entirely.
Keyboard order is invisible until someone depends on it, and then it’s the entire experience.
What determines tab order
By default, focus follows the DOM. Natively focusable elements — links, buttons, form fields — are visited in source order, and that’s it.
Two things break that.
tabindex with a positive value pulls an element to the front of the entire page’s tab order, ahead of everything natural. One tabindex="3" on one card reorders the whole document, and the effect is rarely what the author intended.
CSS layout is the other. Flexbox order, grid placement, and absolute positioning all change what the eye sees without changing the DOM. A sidebar that appears on the left but sits last in the source will be tabbed to last, which is disorienting for anyone navigating by keyboard while looking at the screen.
The WAI keyboard guidance covers why this matters beyond compliance: keyboard navigation is used by people with motor impairments, screen reader users, and anyone whose trackpad has just died.
Why people get stuck here
- Manual tabbing is tedious. Forty stops on a page, counted by hand, and you lose your place at stop twelve.
- Hidden focusable elements. A closed menu that’s
opacity: 0rather thandisplay: nonestill receives focus, sending the user somewhere invisible. - Focus traps. A modal you can enter but not leave with the keyboard alone.
- Positive tabindex inherited from a component library. Often added years ago for a reason nobody remembers.
What good focus order looks like
It matches the visual reading order
If someone can see the page, focus should move roughly the way their eye does: top to bottom, start to end. Any mismatch between visual and DOM order is a defect waiting to be reported.
No positive tabindex anywhere
tabindex="0" makes a custom element focusable in its natural position — fine. tabindex="-1" makes it focusable by script but not by tabbing — also fine, and useful. Anything positive is almost always a mistake.
Traps only where they belong
A modal dialog should trap focus while it’s open and release it on close, returning focus to whatever opened it. Anywhere else, a trap is a bug that makes the page unusable by keyboard.
| Value | Effect | Use It? |
|---|---|---|
tabindex="0" | Focusable in DOM order | Yes, for custom controls |
tabindex="-1" | Focusable by script only | Yes, for programmatic focus |
tabindex="1" or higher | Jumps to front of the page | Almost never |
Common mistakes to avoid
- Hiding elements with
visibilityoropacityand leaving them in the tab order. - Building a custom button from a
divwithout addingtabindexand key handling. - Removing the focus outline for aesthetics with no visible replacement — a keyboard user then has no idea where they are.
- Opening a modal without moving focus into it, so Tab continues through the page behind.
- Reordering cards visually with CSS grid and never checking what that did to the keyboard path.
How to do it with Focus Order Visualizer
The Focus Order Visualizer numbers the focus stops so you can read the sequence rather than count it.
- Provide the markup for the page or component you’re auditing.
- Choose whether to include elements made focusable with
tabindex. - Walk the numbered order and compare it against the visual layout.
- Fix any positive
tabindexfirst — a single one distorts everything after it. - Re-run after the fix, then confirm by tabbing through the real page.
Other accessibility and markup checks are in the tools directory.
Frequently asked questions
Why is a positive tabindex a problem?
Because it doesn’t reorder locally — it moves the element ahead of every element with tabindex="0" or none, across the whole document. One positive value effectively rewrites the page’s tab order, and adding more to compensate makes it worse.
What counts as a focus trap?
Any region a keyboard user can enter and can’t leave using the keyboard. Modals need a deliberate trap while open, released on close. Everywhere else it’s a defect, and it’s one of the most severe kinds because the user’s only escape is reloading the page.
Does focus order need to match visual order exactly?
It needs to match closely enough that focus never appears to jump backwards or across the page unexpectedly. Small deviations are tolerable; a focus ring that leaps from the header to the footer and back is not.
Final thought
Tab through your own page once, slowly, before shipping. It takes two minutes and finds the majority of keyboard problems — usually the hidden menu that still takes focus.