WCAG 2.4.3 Focus Order Explained

WCAG 2.4.3 Focus Order requires that when someone navigates a page in sequence — usually by pressing Tab — focusable components receive focus in an order that preserves meaning and operability. The order doesn’t have to match the visual layout, but it must stay logical enough to complete tasks without confusion.

What 2.4.3 actually requires

The normative wording from the W3C is precise: “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.”

Two ideas matter here. First, meaning — focus should move through content in the order it makes sense to read or use it. Second, operability — you should be able to finish what you started (fill a form, open and close a dialog, work through a wizard) without focus stranding you or doubling back unexpectedly.

A crucial nuance: there is no single “correct” order. The Understanding document notes that several focus orders may all preserve meaning; you only have to implement one of them. And focus order is allowed to differ from visual position — a left-hand navigation column can be coded after the main content in the DOM and positioned with CSS, which often produces a better focus order than reading the sidebar first.

Who a broken focus order hurts

Focus order is unusual among WCAG criteria in that the harm is disorientation — losing your place — rather than not being able to reach something at all. The W3C Understanding document is explicit that the people it protects are the ones who can’t take in the whole page at once and so depend on focus to tell them where they are:

• Keyboard-only users with motor or mobility impairments experience every out-of-sequence tab stop as wasted travel. On a checkout form where Tab jumps from the card-number field to a “remember me” checkbox at the bottom and then back up to the expiry field, they must over-shoot and reverse repeatedly — and each correction is a deliberate, effortful keystroke, not a cheap mouse flick.
• Blind screen reader users (JAWS, NVDA, VoiceOver) hear the page one focused element at a time, so the tab sequence is their mental map. The Understanding document notes that people “can become disoriented when tabbing takes focus someplace unexpected.” When focus silently lands in a footer widget mid-form, there is no visual cue to recover from — they just hear an unrelated control and lose the thread.
• Screen-magnifier users see only a small slice of the page at high zoom, which the Understanding document calls out specifically. Because the magnified viewport snaps to wherever focus goes, an illogical jump physically yanks their view to a far corner of the layout, and they have to pan back to find what they were doing.
• People with reading or cognitive disabilities are named in the Understanding document as becoming disoriented “when tabbing takes focus someplace unexpected.” A predictable, reading-order tab path is what lets them keep a multi-step task — a sign-up wizard, an address block — in working memory.

This is part of the Operable principle in the POUR framework, and it sits next to keyboard navigation and how screen readers move through a page as a foundation of non-mouse use.

Concrete failure examples (and the fix)

1. Positive tabindex jumps the queue

The most common failure is documented as F44: using tabindex values of 1 or higher to “fix” order. Any positive value yanks that element to the front of the tab sequence, ahead of everything with tabindex="0" or no tabindex at all — so focus starts mid-page and lurches around.

<!-- FAIL: positive tabindex forces an illogical order -->
<input name="email"  tabindex="3">
<input name="name"   tabindex="1">
<input name="phone"  tabindex="2">

<!-- FIX: order the DOM correctly, let tabindex stay 0/none -->
<input name="name">
<input name="email">
<input name="phone">

The fix is almost always to order elements correctly in the source and remove the positive values, per technique C27 (matching DOM order to visual order).

2. A modal whose focus is left behind

F85 covers dialogs and menus that aren’t adjacent to the control that opened them. You click “Edit profile,” a modal appears over the page — but pressing Tab keeps moving through the page behind the dialog instead of into it. The fix is to move focus into the dialog when it opens, trap focus inside while it’s open, and return focus to the trigger on close:

dialog.showModal();              // native <dialog> makes the rest inert
dialog.querySelector('input')?.focus();
// on close:
triggerButton.focus();           // hand focus back to where the user was

The native HTML <dialog> element (technique H102) handles much of this for you.

3. A form that zig-zags

The Understanding document gives a marketing-form example that fails: focus goes name → a checkbox at the bottom → street address → another checkbox, instead of moving cleanly through the address block. Reorder the markup so related fields are contiguous and the checkboxes sit where they logically belong. This pattern shows up constantly in accessible forms work.

4. CSS that lies about order

Flexbox order, CSS grid placement, and absolute positioning can move an element visually without changing its DOM position — so what you see and what Tab does diverge. The DOM is the source of truth for focus; rearrange the markup, not just the pixels.

How to test it

Automated scanners are nearly useless for 2.4.3 — a tool can confirm elements are focusable but can’t judge whether the order is sensible. This is a hands-on, manual check:

1. Click the very top of the page (the URL bar, then Tab into the page) so you start from a known point.
2. Press Tab slowly and watch the focus ring. It should move left-to-right, top-to-bottom in a way that mirrors how you’d read and use the page.
3. Watch for jumps — focus leaping to the footer, the header, or an off-screen element mid-task is a fail.
4. Open every dialog, menu, and dropdown and confirm focus moves into it, stays trapped, and returns to the trigger on close.
5. Shift+Tab back the other way to confirm reverse order is just as logical.
6. Confirm you can see focus the whole time — logical order is meaningless if the ring is invisible, which is the related 2.4.7 Focus Visible criterion.

Because this needs a human at the keyboard, it’s a core part of any thorough accessibility audit rather than something a widget can detect.

Why focus order shows up in legal claims

Focus order is one of the easiest failures for a plaintiff’s tester to document, because the test is the experience: they tab through your checkout or sign-up flow, and if focus lurches backward or strands them outside an open dialog, that’s a recorded barrier in under a minute — no specialised tooling required. It is also genuinely common in the wild. WebAIM’s 2024 Million study found home pages carrying an average of 23.1 instances of tabindex="0" or tabindex="-1", up 16% from the prior year and 95% since 2020 — a steady rise in exactly the kind of manual focus-management code that produces F44 and F85 failures when it’s authored carelessly (WebAIM Million 2024).

Because 2.4.3 is Level A, a failure here is hard to wave away — Level A is the floor, and every Level A criterion is also part of WCAG 2.1 AA, the benchmark U.S. courts and the DOJ treat as the practical standard for ADA Title III web claims. Litigation volume stays high: UsableNet tracked over 4,000 ADA-related digital lawsuits in 2024, roughly a 60/40 split between federal court and the New York and California state courts (UsableNet 2024 report).

Crucially for focus order, an overlay can’t save you. UsableNet found more than 1,000 businesses were sued in 2024 despite having an accessibility widget installed — over a quarter of all cases. A widget runs after the page loads and cannot rewrite the DOM sequence the browser already used to build the tab order; the only thing that fixes focus order is editing the source or the focus-management script that controls it. See why overlays don’t work for the mechanism.

This is general information, not legal advice. For your specific exposure, consult a qualified attorney.

Fixing focus order the right way

Focus order can’t be patched from outside the code, which is why our remediation for 2.4.3 is specific and hands-on rather than a setting you toggle. We tab the whole keyboard path ourselves, then fix it at the source: reorder the DOM so the markup reads in the same logical sequence a sighted user would, strip out positive tabindex values (F44) so the natural document order takes over, and rewire every dialog and menu to move focus inward on open, keep it contained while open, and return it to the trigger on close (F85). Where the visual layout legitimately differs from source order — a sidebar coded after the main content — we confirm the tab path still preserves meaning rather than forcing a one-size order.

This is also why we’re deliberately anti-overlay: an overlay loads after the browser has already built the tab sequence, so it can annotate controls but cannot re-order them; only changing the DOM or the focus script does that. When you need to evidence the fix, we capture the tested keyboard path and conformance in a VPAT.

Not sure where your tab order breaks? Start with a free scan — then we’ll walk the keyboard path by hand and fix exactly where focus goes off the rails with manual remediation.