Skip to main content
WCAGrules
Quick navigation

Glossary · Accessibility term

Focus order

Focus order is the sequence focus travels in as you press Tab, and by default it follows the order elements appear in the code rather than the order they appear on screen. Those two can be pulled apart completely by CSS, which is where the trouble starts. Flexbox and grid can move a block to the top of the page visually while leaving it last in the source, and a keyboard user then reaches it last. The rule is narrower than the folklore around it. What it asks for is an order that preserves meaning and operability, and W3C says plainly that focus order does not have to match the visual layout. More than one order can be right for the same content, so the test is never whether the order matches the picture. It is whether somebody moving through it can still understand the page and still finish the task.

In practice

The failure to look for is an order that costs somebody the task rather than one that merely surprises them. Focus reaching Submit before the last required field is a real finding. A two-column layout traversed down one column and then the other, where the visual reading runs across the rows, is a judgement call and often fine.

Positive tabindex values are the reliable way to make this worse. A positive number lifts an element out of the natural order and puts it ahead of everything with no tabindex at all. The positive numbers then run lowest first, so a 2 is visited before a 5 wherever the two sit in the markup. Keeping that consistent across a page anybody ever edits is close to impossible. Zero and negative one are the values worth using. Zero puts an element into the natural order, and negative one makes it focusable by script without putting it into the tab sequence at all.

Two things get reported as failures and should not. Making something non-interactive focusable, such as an error summary you move focus to, is not a focus order failure, because the rule assesses the order rather than the membership. And a modal dialog that wraps Tab round from its last control to its first is the correct pattern, not a scrambled order.

Why it matters

This is one of the failures a scanner is structurally poor at. A tool can see a positive tabindex and flag it, and it cannot tell whether an order preserves meaning, because that would mean knowing what the layout implies. So it takes a person with a keyboard, which is why it survives so many green dashboards. The other reason it matters is that it gets worse as a site gets better. The CSS that makes a layout adapt to a phone is the same CSS that can leave the tab order behind on the desktop. So tab it yourself.

Where it usually goes wrong

A sidebar written last in the HTML and positioned first with CSS. It reads as the first thing on the page and it is the last thing you reach by keyboard. Somebody tabbing sits through the whole of the main content before arriving at the filters they were told to start with. None of that shows up in a screenshot and none of it shows up in a scan.

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