What 2.4.3 requires
If a page can be navigated sequentially and the order affects meaning or operation, focusable components must receive focus in an order that preserves meaning and operability. The order doesn't have to match the visual layout exactly, but it can't scramble the task. And when content such as a dialog appears, focus has to go somewhere sensible. This is a plain-language summary. The normative text, including every exception, is in the W3C Recommendation, with the W3C's explanation in Understanding 2.4.3 (opens in a new tab) [1][2].
Exceptions and scope:
- Applies only where the navigation sequence affects meaning or operation. A set of unrelated links can be focused in more than one acceptable order.
Why it matters
A keyboard or screen-reader user only knows what has focus. If focus stays behind a cart drawer that just opened, the next Tab moves through a page they can no longer see. If focus jumps to the top of the page after closing a dialog, they have to find their place again from scratch. The W3C's own example for this criterion describes moving focus into a dialog when it opens and returning it to the trigger when it closes [1].
Common failures
Positive tabindex values
tabindex="1" and up pull elements to the front of the Tab sequence, out of reading order.
<!-- Fails -->
<input tabindex="3"> <input tabindex="1">
<!-- Better -->
<input> <input> <!-- DOM order = focus order -->Dialogs and drawers that don't take focus
The panel opens visually and focus stays on the page behind it.
/* Fails */
drawer.hidden = false;
/* Better */
drawer.hidden = false; drawer.querySelector("h2").focus();Focus lost after closing or a route change
Focus drops to <body> and the next Tab starts from the top.
/* Fails */
dialog.remove();
/* Better */
dialog.remove(); triggerButton.focus();CSS reordering
Flexbox order or grid placement puts content in a different visual order from the DOM.
/* Fails */
.cta { order:-1 } /* visually first, focused last */
/* Better */
change the DOM order insteadCan automated testing check 2.4.3?
Mostly no. Focus order only exists when someone moves through the page, so a static scan can't evaluate it.
| axe-core 4.13.0 rule | What it checks |
|---|---|
| (none mapped) | axe-core maps no rules to 2.4.3. Its tabindex best-practice rule flags tabindex values greater than 0, a common cause |
What automation can't decide: Whether the order makes sense, where focus goes when a dialog, drawer or menu opens or closes, and where focus lands after a single-page-app route change.
A clean automated result is never proof that 2.4.3 is met. See why sites pass axe-core but fail real screen reader users.
How to test it by hand
- Tab through the page from the top and note the order. Does it follow the reading order and the task?
- Open every dialog, drawer, menu and popover from the keyboard. Focus should move into it.
- Close each one (Escape, close button, Cancel, submit). Focus should return to the trigger, or to the next logical place.
- In single-page apps, navigate between routes and check where focus lands.
- Shift+Tab backwards through the same path and check the reverse order is still sensible.
New to screen readers? Start with how to test a website with a screen reader and how to test keyboard-only navigation.
How Accessible helps (and where it stops)
Journeys check where focus landed after every click or keystroke, so a cart drawer that opens without taking focus, or a dialog that dumps focus at the top of the page on close, is reported at the step where it happened. Our journey page lists "focus that goes nowhere" (2.4.3) among the failures it catches. Real-user monitoring includes observers for focus lost after route changes and for focus traps in real sessions.
Where it stops: Accessible reports where focus went. Whether a different order would be more logical for your content is still a design judgment. No automated tool, ours included, can certify that a criterion is met.
Related criteria
Sources
- Understanding Success Criterion 2.4.3: Focus Order (opens in a new tab). W3C Web Accessibility Initiative. Accessed October 18, 2026.
- Web Content Accessibility Guidelines (WCAG) 2.2, Success Criterion 2.4.3 (opens in a new tab). W3C Recommendation. Accessed October 18, 2026.
- axe-core rule descriptions (opens in a new tab). Deque Systems, axe-core 4.13.0. Accessed October 18, 2026.
- Focus management after a modal: a WCAG guide. Accessible guide. Accessed October 18, 2026.
Meeting a success criterion is not the same as legal compliance, which depends on the rules that apply to you. No automated tool can certify conformance.