Success Criteria

WCAG 2.4.3 Focus Order

Success Criterion 2.4.3 requires that if content can be navigated sequentially, the order in which elements receive keyboard focus follows a sequence that preserves meaning and operability. It's a Level A criterion under Guideline 2.4 (Navigable) — the interactive-focus counterpart to 1.3.2 Meaningful Sequence's requirement for reading order.

What a broken focus order feels like

Tabbing through a page should move through interactive elements in a sequence that makes logical sense given what's visually on screen — generally top to bottom, left to right (or right to left for RTL languages), following the visual/logical structure a sighted user would naturally follow. When focus instead jumps unpredictably — from a footer link straight to a header field, or skips over visually-adjacent controls in a scrambled sequence — a keyboard user loses any sense of "where am I, and what comes next," turning simple navigation into a confusing guessing game.

The most common cause

CSS-based visual repositioning (flexbox/grid order, absolute positioning) that changes where something appears without changing its actual position in the DOM — since focus order generally follows DOM order regardless of CSS visual placement, a mismatch between the two creates exactly this kind of confusing, illogical tab sequence. This is the identical underlying mechanism that causes 1.3.2 failures; the two criteria are often violated by the same root cause, just observed through two different lenses (reading order vs. focus order).

The other common cause: manual tabindex manipulation

Positive tabindex values (tabindex="1", tabindex="5", etc.), used to try to manually control tab order, create their own numeric sequence that overrides natural DOM order — and in practice, this almost always produces a WORSE, harder-to-predict order than simply leaving tabindex at its default. This is exactly why axe-core flags any positive tabindex value as a violation risk.

The fix

Keep the DOM order matching the intended logical/visual sequence in the first place, rather than trying to reconcile a scrambled DOM with CSS repositioning or manual tabindex overrides after the fact. If a visual layout genuinely needs to differ from logical reading/focus order, that's usually a sign the underlying markup structure needs to change, not just be patched with tabindex.

Common questions

What is WCAG 2.4.3 Focus Order?

A Level A criterion requiring keyboard focus to move through the page in a logical order that preserves meaning and operability.

What causes focus order problems?

Positive tabindex values, CSS that visually reorders content away from DOM order, or modals that don't manage focus, causing focus to jump unpredictably.

How is focus order tested?

Largely manual: tab through the page and confirm focus follows the visual and logical flow. Automated tools can flag risky patterns like positive tabindex but can't fully verify it.