WCAG Focus Order (2.4.3): Tab Order Tests And Fixes

The WCAG focus order rule, success criterion 2.4.3, says that when someone moves through a page with the Tab key, links, buttons and fields must receive focus in an order that keeps the meaning and lets them operate the page. It is Level A, and positive tabindex values and badly managed dialogs cause most failures.

Read on for a real scenario, who is affected, the tabindex trap, a table of failures, a manual test, the dialog pattern and how this rule relates to others. A refresher on conformance tiers is on our levels page.

Quick facts

Level
A
Added in
WCAG 2.0
Principle
Operable, guideline 2.4 Navigable
Usual cause
Positive tabindex, CSS reordering, unmanaged dialogs
Safe tabindex values
0 and -1 only
Fast test
Tab through the page and say where focus lands each time

Where does focus go next?

You press a Delete button and a confirmation dialog appears in the middle of the screen. You press Tab. Focus moves to a link in the footer, behind the dialog, which you cannot see. You press Tab again and land in the site search. The dialog is still waiting for an answer, and you have no idea how to reach it. That is a focus order failure, among the most disorienting things a keyboard user can meet.

The wcag focus order rule in plain words

When people move through a page with Tab and Shift+Tab, the items must receive focus in an order that keeps the meaning and lets them operate the page. W3C phrases the goal as an order that "preserves meaning and operability" (WCAG 2.2, 2.4.3).

The order does not have to match the visual layout pixel for pixel. A header search box reached before the main menu is fine. What fails is an order that confuses: focus jumping from the first form field to the footer and back, skipping a dialog, or landing on hidden items no one can see.

Focus order only concerns items that can take focus, such as links, buttons, fields and custom controls. The order of plain text is checked under meaningful sequence.

Who loses the thread when order breaks

Sighted keyboard users follow the focus ring with their eyes. If it leaps across the screen they have to search for it every time. Screen magnifier users see a small area at high zoom; a jump to a far corner can take them out of view completely. Screen reader users hear items one by one and build a mental map from the order, so a field announced before its section heading or a dialog that never receives focus leaves them lost. Switch users step through every item in order and pay for each wasted step with time and effort.

Positive tabindex: the usual culprit

Any tabindex above zero moves an element ahead of everything else on the page, in number order, before the natural order resumes. On a page built by several people, those numbers soon collide and produce a strange path.

Fails: Submit is reached first, before the fields it submits.

<label for="q">Search</label>
<input id="q" type="search" tabindex="2">
<button type="submit" tabindex="1">Submit</button>

Passes: no tabindex at all, so focus follows the code order, which matches the layout.

<label for="q">Search</label>
<input id="q" type="search">
<button type="submit">Submit</button>

Use only two values: 0 to add a custom control to the natural order, and -1 for elements that you move focus to with a script, such as a dialog heading. Fix order problems by changing the HTML order.

Common 2.4.3 failures we report

Focus order problems and repairs
Problem	Effect	Repair
Positive tabindex values	Focus jumps around in number order	Remove them and fix the HTML order
CSS grid or flex order that differs from the code	Tab moves in a zigzag	Make the HTML order match the visual order
Dialog opens without moving focus	Users stay behind the overlay	Move focus into the dialog when it opens
Dialog closes and focus goes to the top	Users lose their place	Return focus to the button that opened it
Hidden off-screen menu still focusable	Invisible stops in the tab path	Hide it with `hidden` or `display: none` until opened
New content appended after the footer	Users must Tab through everything to reach it	Insert it next to the control that revealed it

Testing focus order wcag style

This test needs a person and a keyboard. Automated tools can only point at suspects, such as positive tabindex.

Start from the address bar. Load the page, click the address bar once, then use only the keyboard.
Tab and say what you see. Press Tab one item at a time and say out loud where focus lands, so you notice any jump that feels wrong.
Compare with the reading flow. Check that focus follows the visual layout well enough that each step makes sense: header, navigation, main content, sidebar, footer.
Open every overlay. Open menus, dialogs, drawers and cookie banners and check that focus lands inside each one and remains there until it closes.
Close and check return. Close each overlay and confirm focus returns to the button that opened it, not to the top of the page.
Search the code for tabindex. Look for tabindex values above zero and treat each one as a likely failure to investigate.

Some browser extensions draw numbered lines between focus stops, which makes a zigzag obvious at a glance. They are handy for reports, but always confirm by tabbing yourself.

Dialogs, menus and drawers done right

Most focus order bugs today come from overlays. The pattern that works:

When the overlay opens, move focus into it, usually to its first control or its heading.
While it is open, keep Tab inside it. The native dialog element opened as a modal does this for you; for custom overlays, the inert attribute on the rest of the page stops focus escaping.
Let Escape close it.
When it closes, send focus back to the control that opened it.

The ARIA Authoring Practices Guide shows this pattern for modal dialogs, menus and disclosure widgets.

How 2.4.3 wcag relates to its neighbours

1.3.2 governs reading order for every word on the page; 2.4.3 cares only about focusable items.
2.1.2 says focus must never get stuck, which is the opposite risk from a dialog that leaks focus.
2.4.7 asks that you can see where focus is, and 2.4.11, added in version 2.2, requires that sticky headers or banners do not cover it. See focus visible and focus not obscured.
3.2.1 On focus forbids big context changes, like opening a new page, just because an item received focus.

The W3C notes with examples are in Understanding Focus Order, and the keyboard basics are on our keyboard page.

Questions people ask

What is wcag 2.4.3 focus order?

It is the Level A rule that the Tab key visits links, buttons and form fields in an order that keeps the meaning and lets people use the page. WCAG 2.0 introduced it. The order must make sense; it does not have to match the layout exactly.

Does focus order have to go left to right, top to bottom?

Not strictly. It must be logical for the content. Most pages naturally follow the reading direction of the language, and big departures from it are usually what fails.

Is any positive tabindex a 2.4.3 wcag failure?

Not automatically, but it nearly always causes one, because it pulls items out of the natural order. Auditors flag every positive value and check the resulting path. Removing it and fixing the HTML order is the reliable fix.

Where should focus go when a modal dialog opens?

Into the dialog, usually the first control or the dialog heading. It should stay inside while the dialog is open and return to the opening button when it closes.

How is focus order different from reading order?

Reading order (1.3.2) covers all content, including plain text. Focus order covers only items that receive keyboard focus. CSS that reorders content can break both at once.