Focus Order: Logical Tab Order Explained (WCAG 2.4.3)
Also called: Tab order, Tabbing order, Keyboard focus order
Definition
Focus order is the sequence in which interactive elements receive keyboard focus when a user presses Tab. WCAG 2.4.3 requires that this sequence preserves the meaning and operability of the page.
Focus order is the sequence in which links, buttons and form fields receive keyboard focus as someone presses Tab. When the focus order follows the logic of the page, keyboard users move through it the way everyone else reads it. When it jumps around, a simple form or menu becomes a puzzle.
What it means
WCAG 2.4.3 Focus Order is a Level A criterion of WCAG 2.2. It applies when a page can be navigated sequentially and the order affects meaning or operation. In that case, focusable components must receive focus in an order that preserves meaning and operability.
In HTML, the tab order (also called tabbing order) comes from the order of elements in the source code. Two things change it: positive tabindex values and scripts that move focus or insert content. W3C notes that more than one order can be correct – a table can be read row by row or column by column – and that the focus order does not have to match the visual layout pixel for pixel. It must not confuse people, though.
Who is affected: people who use keyboard navigation, screen reader users, people with switch devices and anyone who fills in forms with Tab instead of the mouse. If the order is wrong, they enter data in the wrong field, miss content or lose track of where they are.
| Situation | Typical result |
|---|---|
| Source order matches visual order | Passes |
| Sidebar after main content in HTML, placed left with CSS | Passes (W3C example) |
Positive tabindex values that jump between sections |
Fails (F44) |
| Dialog or menu not next to its trigger in the tab order | Fails (F85) |
| Modal dialog keeps focus and returns it to the trigger on close | Passes |
Examples
A newsletter form where positive tabindex values send the cursor from the first name straight to a checkbox at the bottom:
<!-- Wrong: positive tabindex breaks the natural order -->
<input id="first" tabindex="1">
<input type="checkbox" id="news" tabindex="2">
<input id="last" tabindex="3">
<!-- Right: source order = reading order, no tabindex needed -->
<input id="first">
<input id="last">
<input type="checkbox" id="news">A menu or dialog should be inserted in the DOM right after the button that opens it (technique SCR26), so the next Tab lands inside it. A modal dialog built with the HTML dialog element (H102) keeps focus inside while open.
Keep the HTML order the same as the reading order. Put pop-up content right after its trigger. Return focus to the trigger when a dialog closes. Add a skip link so keyboard users can jump past repeated navigation.
Use tabindex="1" or higher to "fix" a layout. Reorder content only with CSS (order, flex-direction: row-reverse, absolute positioning) so the visual and tab order drift apart. Append dialogs at the end of body without moving focus.
How to check the focus order
Questions
What is the difference between focus order and tab order?
In everyday use they mean the same thing: the order in which elements receive focus with the Tab key. "Focus order" is the WCAG term; "tab order" describes how keyboard users experience it.
Should I use tabindex to set the focus order?
Only tabindex="0" and tabindex="-1". Positive values create a separate order that comes before everything else and is hard to maintain – W3C lists this as failure F44 when meaning or operability is lost.
Does the focus order have to match the visual layout exactly?
No. W3C says the order does not have to follow the layout exactly, but it must make sense. A sidebar placed after the main content in the HTML is fine; a form that jumps between unrelated fields is not.
Which laws require a logical focus order?
2.4.3 is a Level A criterion, so it is part of every standard based on WCAG AA – including EN 301 549 clause 9.2.4.3, which the European Accessibility Act relies on.
How can I find focus problems on my website?
Tabbing through the page is the most reliable test, because tools cannot judge whether an order makes sense. For the issues a tool can detect, the free WCAG scanner checks your homepage against WCAG 2.2 AA.
Related terms
Keyboard Navigation: WCAG 2.1.1 Explained
Keyboard navigation means that every function of a website can be reached and operated with a keyboard alone – usually with Tab, Shift+Tab, Enter, Space and the arrow keys. WCAG 2.1.1 requires it at Level A.
Read definition: Keyboard Navigation: WCAG 2.1.1 ExplainedFocus Visible: WCAG 2.4.7 and Visible Focus Styles
Focus visible means that a website shows a visible indicator – usually an outline – on the link, button or field that currently has keyboard focus. WCAG 2.4.7 requires it at Level AA.
Read definition: Focus Visible: WCAG 2.4.7 and Visible Focus StylesKeyboard Trap: WCAG 2.1.2 Explained and Fixed
A keyboard trap is a part of a page that keyboard focus can enter but not leave using the keyboard alone. WCAG 2.1.2 No Keyboard Trap forbids it at Level A.
Read definition: Keyboard Trap: WCAG 2.1.2 Explained and FixedSkip Link: Jump Straight to the Main Content
A skip link is a link at the very top of a page that jumps to the main content, so keyboard and screen reader users do not have to pass the whole menu on every page. It is a sufficient technique for WCAG 2.4.1.
Read definition: Skip Link: Jump Straight to the Main Content