Skip to main content
WCAGrules
Quick navigation

Glossary · Accessibility term

Tab order

Tab order is the sequence keyboard focus moves through when you press Tab, and it is field vocabulary rather than the standard's word. WCAG calls it focus order and HTML calls it sequential focus navigation order. It follows the source, and the thing that changes it is a positive tabindex, which pulls an element ahead of everything that has not been given one. CSS does something different and it is by far the more common trouble in current code. Flexbox ordering and grid placement move things on screen without moving them in the source, so the tab order stays exactly where it was and no longer matches what the reader is looking at. It is close to reading order and not the same thing, since reading order covers everything announced and tab order covers only what can take focus. Neither rule demands a particular order. Both bite only where the sequence affects meaning or operation.

In practice

Only some things are in the sequence. Links, buttons, form fields and anything given a tabindex of zero or more, because a negative tabindex makes something focusable by script and deliberately keeps it out of the tab sequence. The specification takes three more cases back out. A disabled control is not focusable. Neither is anything marked inert, which is the modern way to lift a background region out of the tab order while a dialog is open. Neither is anything not being rendered, which is why a skip link moved off screen is still a tab stop and one removed with display none is not.

The order runs through shadow trees rather than around them, so a component library rendering into a shadow root takes part in the page's sequence. One positive tabindex still rearranges everything around it, because inside its own navigation scope every element carrying a positive value is visited before every element carrying a zero, wherever the two sit in the markup. A shadow root is its own scope, which is exactly why the effect is hard to reason about once components are involved.

Neither rule asks for the order you would have chosen. Focus order applies where the navigation sequence affects meaning or operation. Reading order applies where the presentation sequence affects meaning. So a jump from the header to the footer is a usability problem worth fixing, and it is a conformance failure only where the jump changes what something means or stops somebody finishing a task. Writing the finding that way is what makes it survive a challenge.

Why it matters

The order is what turns a keyboard from operable into usable, and the failure underneath it is worse than an awkward sequence. If focus can go somewhere and cannot come back, the person is stranded, and that is a Level A failure under the no keyboard trap rule. Above that sits the tiring version. A long tab order through repeated navigation on every page is exactly what the bypass blocks rule exists to answer, so a finding about an exhausting tab order usually has a criterion behind it. And an order can be perfectly sensible while a sticky header hides the focused control completely, which is a Level AA failure of its own and easy to miss. Partly covering it is a failure too, at Level AAA rather than AA, so say which one you saw.

The two-minute check, and what it assumes

Press Tab from the top of the page and follow the focus ring. If the ring never appears at all, stop, because you cannot see where focus is and you are testing nothing. Check whether the site suppressed the indicator or something else is hiding it, fix that first, then run the check again.

Where this shows up on the site

Related terms

Knowing the word is the easy part.

Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.

Run the free scan

Go somewhere useful

Find tools, resources and your workspace.

29 destinations