WCAG 2.4.3 Focus Order

What it asks

Pressing Tab moves keyboard focus from one control to the next. The order is set by the order of elements in the code, unless the author changes it. This rule asks that, where the order matters to understanding or using the page, focus follows an order that keeps that meaning. Usually that means following the visual reading order: left to right, top to bottom, in the language of the page.

Two patterns cause most failures. The first is layout that reorders things visually but not in the code, so the keyboard jumps around the screen in a way the eye cannot follow. The second is content that appears and disappears: a dialog opens but focus stays on the page behind it; a dialog closes and focus falls to the top of the page, or to nowhere at all; a menu slides off screen but its links stay in the tab order, so the keyboard disappears into them.

The rule does not require the tab order to match the visual order exactly. A skip link at the start, a form ordered by field groups, or focus moving into a dialog as soon as it opens all change the order on purpose and keep the meaning. Content that has no meaningful order, such as a row of unrelated icons, can be in any order. It is Level A.

Its official name is success criterion 2.4.3 Focus Order, at Level A. It was added in WCAG 2.2, under guideline 2.4 Navigable and the principle Operable. The W3C’s normative text says, in part:

“If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.”

From WCAG 2.2, W3C. Full explanation: Understanding 2.4.3 Focus Order.

Who it helps

Keyboard users and switch users, who have no way to reach a control except in sequence. If the sequence is confusing, they cannot build a picture of the page. If focus is lost, they have to start again from the top.

Screen reader users, who experience the page as a sequence in any case, and people with low vision using magnification, who see only the part of the page around the focused control and are lost if focus jumps somewhere unexpected.

What passes and what fails

These pass

• A form where Tab moves through the fields in the order they appear on screen, then to the submit button.
• A dialog that takes focus when it opens, keeps it inside until it closes, and returns it to the button that opened it.
• A skip link that is first in the tab order and jumps to the main content.
• A two-column layout where the code order follows the reading order: the left column, then the right.
• A menu that is removed from the tab order when it is closed, so the keyboard cannot wander into links nobody can see.

These fail

• A dialog that opens without moving focus, so the keyboard is still on the page behind it while the dialog covers the screen.
• A dialog that, when closed, drops focus back to the body, so the next Tab press starts from the top of the page.
• A grid of cards reordered with CSS so the visual order differs from the code order, and the keyboard jumps diagonally across the grid.
• A navigation panel slid off screen that keeps its links focusable, so focus disappears for several presses.
• Fields given tabindex="1", tabindex="2" and so on, pulling them ahead of everything else on the page regardless of where they sit.

How to test it by hand

1. Start at the top of the page and press Tab through every control, watching where the focus indicator goes. It should follow the reading order, or an order you can explain.
2. Open every dialog, drawer and menu from the keyboard. Check that focus moves into it, stays inside it while it is open, and returns to a sensible place when it closes, usually the control that opened it.
3. Close a menu or panel and keep pressing Tab. If focus vanishes for a few presses, something hidden is still in the tab order.
4. In the browser’s developer tools, search the page for tabindex values above zero.
5. Repeat at a narrow width, where layouts often reorder.

What automated testing can decide

What a machine can decide

Automated testing can find positive tabindex values in the code, which are the usual cause of a broken order. It can also record the order in which controls receive focus and point out where that order and the visual layout disagree, and it can notice when focus lands on the body or on something that cannot be seen.

What it cannot

Whether a disagreement between tab order and visual order changes the meaning is a judgement, and the same divergence can be a defect on one page and a deliberate pattern on another. A positive tabindex is a strong sign of trouble, not proof of it. And automated testing only sees the dialogs, menus and states it managed to open.

How Dreven handles it

Dreven records the keyboard focus order of every page in an audit and shows you where it looks wrong, including where focus went when a dialog or menu opened and closed, with the page and the controls involved.

A reviewer decides whether each departure keeps the meaning or breaks it, and the report says how each result was decided.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

Related criteria

• 2.4.7 Focus Visible (Level AA). The focus indicator must be visible, or nobody can see the order at all.
• 2.4.11 Focus Not Obscured (Minimum) (Level AA). The focused control must not be hidden behind sticky content.
• 1.3.2 Meaningful Sequence (Level A). The reading order of the content itself must make sense. Focus order is the same idea for controls.
• 2.1.1 Keyboard (Level A). Every control must be reachable from the keyboard in the first place.
• 2.4.1 Bypass Blocks (Level A). A skip link changes the focus order on purpose, and is allowed to.

Questions people ask

All WCAG 2.2 criteria, in plain words