2.4.3 Focus Order

Level A
Operable
Since WCAG 2.0

Summary

Keyboard users, switch users, and screen reader users who move through a page sequentially experience the interface as a single path: whatever order focus travels in is the interface. When that path zigzags across the layout, skips the button that a just-completed action logically leads to, or strands the user at the top of the page after a dialog closes, sighted mouse users notice nothing while sequential users lose the plot entirely. This criterion (Level A, in WCAG since 2.0) requires that focus moves in an order that preserves the meaning and operability of the content.

The auditor's mental model has a deliberate softness in it: the criterion does not demand the one perfect order, or even a fully intuitive one. It fails only when the order actually damages meaning or operability. An order that is mildly surprising but leaves every relationship understandable and every task completable passes; an order that separates a label from its field, tabs into content behind an open dialog, or drops focus somewhere that makes the next step incomprehensible fails. Grade the consequence, not the aesthetics of the sequence.

Official wording

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.

Success Criterion 2.4.3 Focus Order, Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, 5 October 2023 (updated 12 December 2024). Copyright © 2023-2024 World Wide Web Consortium. https://www.w3.org/copyright/document-license-2023/. Reproduced unmodified under the W3C Document License.

EN 301 549 mapping

Web pages: Clause 9.2.4.3
Software and native apps: Clause 11.2.4.3 (via Table 11.7)

Clause 9.2.4.3 applies this criterion to web pages unchanged. For software, clause 11.2.4.3 carries the requirement through a word-substitution table (Table 11.7) that restates it for application user interfaces.

Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.

In practice

Web

Put the mouse away and run a tab sweep: from the address bar, press Tab repeatedly through the entire page and write down the path focus takes (pairing the sweep with a visible-indicator check is efficient, but the indicator itself is SC 2.4.7 Focus Visible). Compare the path against the visual layout and against task flow: does focus move through a form's fields in the order the form reads, does it reach the submit button after the fields it submits, does a multi-column layout traverse column by column rather than ricocheting between them?

The classic web fail is positive tabindex. In devtools, search the DOM for tabindex values greater than zero: any element with tabindex="1" or higher jumps the queue ahead of everything else on the page, and the sequence degrades further every time content changes around it. Also compare DOM order against visual order: CSS that reorders content (order in flexbox or grid, absolute positioning, float) moves things visually while the tab sequence still follows the source. A small divergence can be harmless; grade it as a fail when the resulting path breaks relationships or task flow.

Dialogs deserve their own pass. Open every modal, drawer, and popover with the keyboard and check three moments: on open, focus must move into the dialog (if Tab keeps walking the page underneath, sequential users never reach the dialog they supposedly opened); while open, the sequence should stay within it; on close, focus must land somewhere sensible, normally back on the triggering control. Focus dumped on body after close (verify with document.activeElement in the console) restarts the user from the top of the page and is a routine fail. The same applies to focus that jumps to an unrelated region after any action, such as an "add to basket" click that throws focus into the site header.

iOS

The European standard carries this requirement through to native apps by restating it for application user interfaces, so grade iOS apps against the same test: sequential navigation order must preserve meaning and operability.

Test with Full Keyboard Access (Settings, Accessibility, Keyboards, Full Keyboard Access) on a device with a hardware keyboard, or the on-screen equivalent. Full Keyboard Access navigates by focus groups: Tab moves between groups and arrow keys move within one, so audit both levels: do the groups come in an order that matches the screen's structure, and does within-group movement follow the layout? Authors shape this with focusGroupIdentifier and the UIKit focus system (or focusable and focusSection in SwiftUI); custom container views that never define sensible groups are where order most often collapses. Xcode's Accessibility Inspector helps confirm which elements are focusable and in what sequence.

Apply the dialog test to sheets, alerts, and popovers: presenting one should move keyboard focus into it, and dismissing it should return focus to the control that opened it. Custom modal overlays that leave focus in the covered content behind them are the native mirror of the web dialog fail.

Android

The European standard applies here too: the same requirement, restated for application user interfaces.

Test with a hardware keyboard or d-pad (a TV remote, a Bluetooth keyboard, or the emulator's d-pad controls). Tab and the arrow keys traverse focusable views; by default Android derives the order from layout position, and authors override it with nextFocusForward, nextFocusDown, nextFocusUp, nextFocusLeft, and nextFocusRight in views, or with Modifier.focusProperties { } (setting next, down, and so on, often paired with FocusRequester) in Compose. Stale overrides are the platform's version of positive tabindex: a nextFocusDown pointing at a view that was later moved or removed sends focus somewhere arbitrary, and it only shows up under keyboard traversal, never under touch.

Sweep each screen and note the path, then check the usual failure spots: custom dialogs and bottom sheets that do not take focus on open or return it on dismiss, RecyclerView and lazy lists whose item internals traverse in an odd order, and screens where a keyboard user can tab into content behind an open sheet. Layout Inspector in Android Studio helps confirm which views are focusable when the on-screen path looks wrong.

Pass and fail examples

Passes:

A checkout form where Tab moves through name, address, and payment fields in reading order and reaches the "place order" button last.
A modal dialog that receives focus on open and returns focus to its trigger button on close.
A two-column article layout where focus completes the main column's links before moving to the sidebar: the path follows the structure, even though a strict left-to-right reading would interleave them.
A page with no tabindex values above zero, where the DOM source order matches the visual order.
An Android settings screen where d-pad navigation walks each row top to bottom, including into each row's toggle.

Fails:

A form using tabindex="1" through tabindex="5" on some fields: focus visits those first, then jumps back to the top for everything else, splitting the form into two confusing passes.
A cookie consent dialog that opens without receiving focus, so Tab keeps moving through the page content behind it and the keyboard user cannot reach the buttons the dialog demands they use.
Closing a modal returns focus to body, forcing the user to tab from the top of the page back to where they were.
A CSS grid that visually reorders pricing cards so the recommended plan sits in the middle, while focus jumps middle, left, right: the order no longer matches the comparison the layout communicates.
An app screen where activating "edit" moves keyboard focus into the toolbar rather than the field that just became editable.

Not a fail under this criterion:

A focus order that is unexpected but harmless, for example a search button reached before the filters beside it, where every element remains reachable and the task is unaffected: the criterion only bites when meaning or operability suffer. Note it as a usability recommendation.
Focus moving in a logical order but with no visible indicator: that is SC 2.4.7 Focus Visible.
A focused element scrolled behind a sticky header, so the (correctly ordered) focus is hidden: that is SC 2.4.11 Focus Not Obscured (Minimum).
A screen reader announcing non-interactive content in a nonsensical order: reading order of content is SC 1.3.2 Meaningful Sequence, not focus order.

Commonly confused with

SC 1.3.2 Meaningful Sequence. 1.3.2 covers the reading order of content, including non-interactive text; 2.4.3 covers the order in which focusable components receive focus. A paragraph announced mid-sentence-first is 1.3.2; a form tabbed through backwards is 2.4.3. The same DOM-versus-visual divergence can trigger both, but file them by whether the affected content takes focus.
SC 2.4.7 Focus Visible. 2.4.7 asks whether you can see where focus is; 2.4.3 asks whether focus moves somewhere sensible. A perfectly ordered sweep with an invisible indicator fails 2.4.7 only, and a clearly indicated but chaotic sweep fails 2.4.3 only. Auditors test both in one sweep, then must file the evidence separately.
SC 2.4.11 Focus Not Obscured (Minimum). If focus lands in the right place but that place is hidden behind a sticky banner or cookie bar, the order is fine and the obscuring is the finding. Do not report a hidden-but-correct focus position as an order problem.
SC 2.1.2 No Keyboard Trap. A dialog that focus can never leave is a trap under 2.1.2. A dialog that focus never enters, or that dumps focus to body on close, is an order failure under 2.4.3. The two often co-occur in poorly built modals; grade the entry and exit behaviour here, the inability to escape there.
The "illogical but operable" line. Not a sibling criterion but the most common grading dispute: WCAG deliberately scopes this criterion to orders that affect meaning or operation. Resist filing every imperfect sequence as a fail; document the odd order, show whether a task or relationship actually breaks, and grade on that evidence.

How AUDITSU tests this

AUDITSU's audit walkthrough puts a keyboard sweep on every screen you review. The walkthrough prompts you to tab through the screen and record the path focus takes, compare it against the visual layout and the task the screen supports, and separately exercise every dialog, sheet, and overlay for the three focus moments: into the dialog on open, contained while open, back to the trigger on close. For native apps the same questions run under Full Keyboard Access on iOS and hardware keyboard or d-pad traversal on Android.

Each question records a pass, fail, or not applicable result per screen with your evidence attached, so an order finding lands in the report tied to the exact screen, the observed focus path, and the point where meaning or operability broke down. Because the criterion is restated for software in the European standard, the same walkthrough evidence supports both WCAG and EN 301 549 conformance claims.

For the full guided workflow, see the audit platform.