WCAG 2.4.3: Focus Order
A mouse user can click anything in any order. A keyboard user moves through the page one Tab at a time, and they depend on that sequence making sense. This criterion asks that focus moves through the page in an order that preserves meaning and operability — usually the same order you would read it.
The success criterion, in full
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.
The criterion does not demand one specific order — there may be several that work. It fails only when the order changes meaning or breaks operation, such as reaching a Submit button before the fields it submits.
Who this helps
Anyone who does not point-and-click their way around a page relies on a coherent focus sequence:
Keyboard-only users
People who cannot use a mouse move through the page with Tab. A scrambled order makes them hunt for the next control and easy to lose their place mid-task.
Screen reader users
Focus order and reading order together determine how the page is experienced. An illogical order can present information in a sequence that changes its meaning.
Switch and voice-control users
These users step through focusable elements one action at a time. An unexpected jump wastes actions and can trigger the wrong control entirely.
People with cognitive disabilities
A predictable, reading-order sequence reduces the effort of tracking where focus is and what comes next, especially in long forms and multi-step flows.
Screen magnifier users
At high zoom only a slice of the page is visible. If focus jumps to an off-screen element, the viewport lurches unexpectedly and orientation is lost.
Everyone filling in forms
A natural tab order between fields is simply faster and less error-prone for all users, not just those relying on assistive technology.
What breaks focus order
By default the browser follows source order, and source order that matches the visual layout is usually all you need. Focus order breaks when something decouples the tab sequence from what the user sees:
- Positive tabindex values. Any tabindex of 1 or more yanks an element to the front of the sequence, ahead of everything in natural order. One stray value forces you to hand-manage the whole page. Use only 0 and -1.
- CSS that reorders visually. flexbox order, grid placement, and absolute positioning move elements on screen without changing the DOM. Focus still follows the source, so the visual and focus order diverge.
- DOM-inserted content. Content added later in the source but shown near its trigger — dropdowns, tooltips, expandable panels — can place the next tab stop far from where the eye expects it.
- Unmanaged widgets and modals. Dialogs, menus, and custom components that don't move focus in on open, trap it while open, and restore it on close leave focus stranded in a nonsensical position.
The reliable fix for all four is the same principle: keep the DOM order matching the visual reading order and let focus follow the source. That also supports 1.3.2 Meaningful Sequence, and pairs with 2.4.7 Focus Visible so users can also see where focus lands.
Pass and fail examples
✓ Passes 2.4.3
- A form whose fields receive focus top-to-bottom, Submit last.
- DOM order matching the visual layout, with no positive
tabindex. - A modal that moves focus in on open, traps it, and returns it to the trigger on close.
- A dropdown whose revealed options are reached immediately after its trigger.
✗ Fails 2.4.3
- A Submit button with
tabindex="1"focused before any field. - CSS
orderthat visually reorders fields so tab jumps around. - A modal that opens but leaves focus behind it on the page underneath.
- An expandable menu whose options come last in the DOM, so focus skips the rest of the page first.
Code examples
Keep DOM order and visual order aligned
When CSS reorders elements visually, focus still follows the source and the two diverge. Order the DOM the way the page reads.
<!-- ✗ Visual order and DOM order disagree.
CSS moves the fields around, so tab order is scrambled. -->
<form style="display:flex; flex-direction:column">
<button type="submit" style="order: 3">Submit</button>
<input name="email" style="order: 1" aria-label="Email">
<input name="name" style="order: 2" aria-label="Name">
</form>
<!-- ✓ DOM order matches the visual reading order,
so tab order follows naturally. -->
<form>
<label>Name <input name="name"></label>
<label>Email <input name="email"></label>
<button type="submit">Submit</button>
</form>Use only tabindex 0 and -1
Positive tabindex values override natural order and scramble the sequence. Let the DOM drive the order instead.
<!-- ✗ Positive tabindex hijacks the whole page order.
Submit is focused first, then the rest jump around. -->
<form>
<input aria-label="First name" tabindex="2">
<button type="submit" tabindex="1">Submit</button>
<input aria-label="Last name" tabindex="5">
<input aria-label="Email" tabindex="4">
</form>
<!-- ✓ Only tabindex 0 and -1. Natural order is preserved. -->
<form>
<input aria-label="First name"> <!-- natural order -->
<input aria-label="Last name">
<input aria-label="Email">
<div tabindex="-1" id="status"></div> <!-- script-focusable only -->
<button type="submit">Submit</button>
</form>Manage focus in a modal dialog
Widgets that show and hide content must move focus deliberately: into the dialog on open, trapped while open, and back to the trigger on close.
// A modal must move focus in, trap it, and restore it out —
// otherwise focus is left behind the overlay in a broken order.
function openModal(dialog, trigger) {
const previouslyFocused = trigger; // remember where we were
dialog.hidden = false;
const focusables = dialog.querySelectorAll(
'a[href], button:not([disabled]), input, select, textarea, [tabindex]:not([tabindex="-1"])'
);
const first = focusables[0];
const last = focusables[focusables.length - 1];
first?.focus(); // move focus into the dialog
dialog.addEventListener('keydown', (e) => {
if (e.key !== 'Tab') return;
// Trap focus within the dialog
if (e.shiftKey && document.activeElement === first) {
e.preventDefault();
last.focus();
} else if (!e.shiftKey && document.activeElement === last) {
e.preventDefault();
first.focus();
}
});
dialog.addEventListener('close', () => {
previouslyFocused?.focus(); // restore focus on close
});
}Interactive demo
Tab through the two live forms below to feel the difference between a natural order and one scrambled by positive tabindex values, then use the buttons to step through each focus stop and see which ones break the expected sequence.
Logical order (DOM order)
Tab through this form: focus follows the visual top-to-bottom order.
Illogical order (positive tabindex)
Tab through this one: focus jumps to Submit first, then bounces around the fields out of order.
Watch the focus order
Press a button to step through each focus stop in order.
Common failures
- Positive tabindex values (tabindex="1" and higher) that pull elements to the front and scramble the whole page order.
- Using CSS flexbox order, grid placement, or absolute positioning to reorder content visually while leaving the DOM in a different sequence.
- Modal dialogs that open without moving focus in, so focus stays on the page behind the overlay.
- Modals that fail to trap focus, letting Tab escape into the obscured page underneath.
- Not returning focus to the triggering control when a dialog, menu, or popover closes.
- Dropdown and accordion content placed at the end of the DOM, so its options are reached long after the visible trigger.
- Off-screen or 'hidden' content that is still focusable, sending focus to elements the user cannot see.
- Reordering list or grid items with JavaScript for visual effect without keeping the DOM order in sync.
How to test for 2.4.3
- 1
Tab through the whole page
Starting at the top, press Tab repeatedly and watch where focus goes. It should move in the order you would read the page. Note any point where focus jumps somewhere unexpected or off-screen.
- 2
Shift+Tab back through it
Reverse the journey with Shift+Tab. The sequence should be the exact reverse of forward tabbing. A backward order that differs from the forward one is a red flag.
- 3
Search the code for positive tabindex
Grep the markup for tabindex values of 1 or higher. Almost every one is a bug. Confirm only tabindex="0" (add to natural order) and tabindex="-1" (script focus only) remain.
- 4
Open and close every widget
Trigger each modal, menu, popover, and accordion by keyboard. Check that focus moves into it, stays within it while open, and returns to the trigger when it closes.
- 5
Compare DOM order to visual order
Where CSS positions content (flex order, grid, absolute), verify the DOM sequence still matches what is shown. Run an automated scan too, but remember tools cannot judge whether an order 'makes sense' — that is a manual check.
For a structured audit, work through the full WCAG 2.2 checklist.
Related Success Criteria
A mechanism is available to bypass blocks of content that are repeated.
Web pages have titles that describe topic or purpose.
The purpose of each link can be determined from link text or context.
More than one way is available to locate a page within a set of pages.
Headings and labels describe topic or purpose.
Frequently asked questions
What does WCAG 2.4.3 Focus Order require?
It requires that when a page can be navigated sequentially — for example with the Tab key — and the order in which components receive focus affects meaning or operation, focus moves through those components in an order that preserves meaning and operability. In plain terms, tabbing through the page should follow a sensible sequence, usually matching the visual reading order, so a keyboard or screen reader user can understand and operate the page just as a sighted mouse user would. It is a Level A success criterion, part of WCAG since 2.0.
What is the difference between focus order and DOM order?
DOM order is the order elements appear in the HTML source; focus order (tab order) is the sequence in which they receive keyboard focus. By default the two are the same: the browser follows source order. Problems arise when the two diverge — for example when CSS (flexbox order, grid placement, absolute positioning) moves elements visually so they no longer match the source, or when positive tabindex values override the natural order. The safest strategy is to keep the DOM order matching the visual order and avoid anything that decouples them, so focus order simply follows the source.
Why are positive tabindex values a problem?
A positive tabindex (1 or higher) pulls an element to the front of the tab sequence, ahead of every element that relies on natural DOM order. As soon as you use one positive value you effectively have to manage the tab order of the entire page by hand, and a single stray tabindex=1 can send focus jumping to an unexpected control first. This almost always produces a confusing, illogical order. The correct values are tabindex=0 (include an element in the natural order) and tabindex=-1 (focusable only via script, not in the tab order). Reserve positive values for essentially never.
How does focus order relate to modals, menus, and other widgets?
Interactive widgets are where focus order matters most. When a modal dialog opens, focus should move into the dialog, stay trapped within it while it is open, and return to the triggering control when it closes — otherwise focus is left behind the overlay in an order that makes no sense. Similarly, custom menus, accordions, and comboboxes must manage focus so that revealing or hiding content keeps the sequence coherent. Content that is inserted into the DOM later (below the trigger) but appears visually near it is a classic source of illogical focus order.
Does 2.4.3 require a specific order, like strictly left-to-right?
No. The criterion does not mandate one particular order; it requires an order that preserves meaning and operability. There can be more than one order that does this. For most layouts that means following the visual reading order for the content's language (top-to-bottom, and left-to-right for languages written that way), because that is what users expect. The failure condition is an order that changes the meaning or breaks operation — for instance focusing a Submit button before the fields it submits, or reaching a confirmation before the choice it confirms.
How is 2.4.3 Focus Order different from 2.4.7 Focus Visible and 2.1.1 Keyboard?
They cover three distinct parts of keyboard access. 2.1.1 Keyboard (A) requires that all functionality can be operated with a keyboard at all. 2.4.3 Focus Order (A) requires that when you tab, the sequence of focus makes sense. 2.4.7 Focus Visible (AA) requires that the currently focused element has a visible focus indicator so users can see where they are. A page can be fully keyboard-operable (2.1.1) yet still fail 2.4.3 because the order is scrambled, or fail 2.4.7 because the focus ring is hidden. Aim to satisfy all three together.