WCAG 2.4.3 Focus Order — Testing Guide

WCAG 2.4.3 Focus Order (Level A) requires that the order in which keyboard focus moves through interactive elements is logical and preserves meaning. For keyboard and screen reader users, focus order

WCAG 2.4.3 Focus Order (Level A) requires that the order in which keyboard focus moves through interactive elements is logical and preserves meaning. For keyboard and screen reader users, focus order is the navigation sequence. Random order is disorienting and destroys UX for assistive tech users.

What 2.4.3 requires

The focus order must match the visual and logical order of content. Moving from focus to focus should feel predictable — usually top-to-bottom, left-to-right (RTL reversed for RTL languages).

For multi-column layouts, the order should make sense within reading order, not jump between columns arbitrarily.

Common violations

1. tabindex used to manipulate order

<input tabindex="1">
<input tabindex="3">
<input tabindex="2">  <!-- focus goes here second -->

Using tabindex > 0 is almost always wrong. It overrides natural order, invites bugs.

Fix: Restructure DOM to match desired order. tabindex="0" only if making non-interactive focusable.

2. Absolute-positioned element out of source order

Visually positioned in a different location than its DOM order. Keyboard follows DOM; visual and logical disagree.

Fix: DOM reflects logical order. CSS positioning adjusts visual without changing order.

3. Flexbox / grid reorder

.item:nth-child(3) { order: 1; }
.item:nth-child(1) { order: 3; }

Visual order changes; DOM and focus order do not. User tabs in original DOM order while seeing different visual.

Fix: Reorder in DOM; or accept this is a trade-off and test for usability.

4. Modal / dialog adds focusable but doesn't trap

Focus leaves modal into page behind. User loses context.

Fix: Focus trap within modal until closed.

5. Sidebar after main content in DOM

Header → Main → Sidebar → Footer. But visually, sidebar is alongside main. Focus goes through all of main before sidebar.

Fix: Usually acceptable (screen readers know this pattern). If confusing, restructure or use ARIA landmarks to give users navigation shortcuts.

Testing

Manual

Unplug your mouse. Press Tab repeatedly. Note the order focus moves. Does it match visual order?

Write down the first 20 focus stops. Compare to the order a sighted user would visually scan. Mismatches are violations.

Automated

• axe-core has limited focus-order checks
• Custom tests: script that Tabs through page, recording focused elements; assert order matches spec

Screen reader

VoiceOver rotor / TalkBack reading order should match visual. Test with screen reader; if order feels random, fix.

Fix patterns

Source order matches visual order

The most reliable fix. DOM order → focus order → visual order. One sequence.

Avoid tabindex > 0

Only tabindex="0" (make focusable, keep natural order) or tabindex="-1" (remove from tab order; focus programmatically only).

ARIA landmarks