Focus Order

Why it matters

Keyboard users learn the page from the order focus travels, because that sequence is the layout as far as they can perceive it. When focus jumps somewhere unrelated, the map tears. Somebody using magnification at high zoom sees a small window of the page and can read a field in completely the wrong context, answering a question that belongs to another section. People with reading difficulties become disoriented when tabbing lands somewhere unexpected and lose the thread of what they were doing. And the order has two audiences at once. A screen reader user meets the reading order the code defines, while a sighted keyboard user meets the visual one, so a good order has to make sense to both.

Who this rule protects

This affects keyboard and screen-reader users moving through the page in sequence, magnification users at high zoom who can read a field in the wrong context entirely, and people with reading or cognitive disabilities who lose their place when focus lands somewhere unexpected.

How to check it yourself

1. 1Tab through the page and say out loud where focus lands. Ask whether the sequence preserves the relationships the page is showing, not whether it traces the visual layout exactly.
2. 2Open every dialog and menu and check it sits next to the control that opened it in the tab sequence. That is where the requirement actually bites, and it is the most common way this rule breaks.
3. 3Close each dialog and watch where focus goes. Landing on the trigger conforms, and landing on the element right after it conforms. Landing back at the top of the page does not.
4. 4Watch for a control that appears to take focus twice. A wrapper carrying tabindex="0" around a real button produces exactly that, and it is a common component-library pattern.
5. 5Treat positive tabindex values as a signal, then judge the order they produce, because the order is what the rule measures.

Failures we see most often

• A dialog whose fields sit at the end of the document, so opening it sends focus nowhere near the button that opened it and the sequence stops making sense.
• A form whose tab order crosses between sections, moving from the name field to a checkbox, then to the street address, then to another checkbox.
• A wrapper element made focusable around a control that was already focusable, so keyboard users hit the same thing twice and cannot work out why.
• A modal that opens while focus stays behind it, on content the user can no longer reach.

Who this one is for

Read from this rule's own note above, so the grouping and the note cannot disagree.

• Blind and screen reader userspeople who cannot see the screen
• Low visionpeople who can see the screen but not easily
• Motor and keyboard-onlypeople who cannot use a mouse, or cannot use one precisely
• Cognitive and learningpeople for whom the difficulty is understanding, remembering, or staying with it

How to fix it

• Keep the markup order and the reading order aligned and let CSS handle the visual arrangement. Getting the order right in the document is the documented fix, and it needs no script at all.
• For a non-modal disclosure, insert the new content into the document immediately after the control that opened it. The order then takes care of itself, both opening and closing.
• For a modal, use the native <dialog> element, which is a documented technique here. It moves focus in, makes the rest of the page inert, and hands focus back when it closes.
• Avoid positive tabindex values. They set a page-wide order that every future edit has to be rechecked against, and the same result comes free from the document order.

Passes vs. fails