tab-order
Web validation
Keyboard users move between the controls on a page by pressing the Tab key. By default, focus moves in the order of the elements in the DOM. When the order in which controls receive focus does not match their visual order on screen, keyboard users may become disoriented and struggle to navigate the interface correctly. This issue is usually caused by one of the following:
- Elements with positive
tabindexvalues that don't match the visual order on the screen. - Elements or their parent elements using absolute positioning in a way that disrupts the natural tab sequence.
- Elements or their parent elements using CSS that visually reorders them, such as the flexbox
orderproperty,flex-direction: row-reverseorcolumn-reverse, or grid placement, leading to a visual order different from the code order.
To fix the issue:
- Remove positive
tabindexvalues. The values0and-1are valid. - Avoid using CSS to visually rearrange controls, or elements that contain controls.
- Ensure elements are positioned according to the natural DOM flow.
Note: This validation is about the order in which keyboard focus moves between interactive elements. The order in which assistive technologies read the content is covered by the related screen-reading-order validation, and positive tabindex values on their own are covered by the tabindex validation.
Pass Patterns
Controls in DOM order
The fields and button have no tabindex, so focus follows the DOM order, which matches the visual order.
<form>
<label for="first-name">First name</label>
<input type="text" id="first-name" />
<label for="last-name">Last name</label>
<input type="text" id="last-name" />
<button type="submit">Continue</button>
</form>Flex layout that keeps the DOM order
The buttons are laid out with flexbox, but they are not reordered, so the focus order matches what users see.
<div style="display: flex; gap: 1rem;">
<button>Back</button>
<button>Next</button>
</div>Fail Patterns
Positive tabindex values
The positive tabindex values move focus from the first field straight to the button, skipping the second field.
<form>
<label for="first-name">First name</label>
<input type="text" id="first-name" tabindex="1" />
<label for="last-name">Last name</label>
<input type="text" id="last-name" />
<button type="submit" tabindex="2">Continue</button>
</form>Control moved with absolute positioning
The "Save" button is shown at the top of the form, but it is last in the DOM, so keyboard users reach it only after all the fields.
<form style="position: relative; padding-top: 3rem;">
<label for="title">Title</label>
<input type="text" id="title" />
<label for="description">Description</label>
<textarea id="description"></textarea>
<button type="submit" style="position: absolute; top: 0; right: 0;">Save</button>
</form>Controls reordered with flexbox order
"Back" is shown first on screen, but "Next" comes first in the DOM, so the Tab key moves right to left.
<div style="display: flex; gap: 1rem;">
<button style="order: 2;">Next</button>
<button style="order: 1;">Back</button>
</div>WCAG techniques
Sufficient techniques
- G59: Placing the interactive elements in an order that follows sequences and relationships within the content
- C27: Making the DOM order match the visual order
Failure techniques
Try It Yourself
Using a keyboard
- Load the page and place focus at the top of the page.
- Press Tab repeatedly to move through the interactive elements, and Shift+Tab to move back.
- Compare the order in which elements receive focus with their visual order on screen.
Expected results: Focus moves through the interactive elements in a logical order that matches the visual layout.
Actual results: Focus jumps around the page, skips elements, or reaches them in an order that does not match the visual layout.
Inspecting the browser dev-tools
- Search the page's elements for
tabindexattributes with a value greater than0. - For the elements that receive focus out of order, check their CSS and their parents' CSS for
position: absoluteorfixed,order, reversedflex-direction, or grid placement. - In Chrome's dev tools, you can also open the Accessibility panel and turn on Show source order to compare the DOM order with the layout.
Expected results: No element has a positive tabindex, and the DOM order of the interactive elements matches their visual order.
Actual results: Positive tabindex values or CSS reordering make the focus order differ from the visual order.
FAQ
How does this issue relate to 2.4.3 Focus Order?
SC 2.4.3 requires that when a page can be navigated sequentially, focusable elements receive focus in an order that preserves meaning and operability. When positive tabindex values or CSS reordering make the focus order differ from the visual and logical order, keyboard users may reach controls out of context, so the criterion is not met.
Why is this issue marked as Serious?
When focus moves in an unexpected order, keyboard users may lose their place, miss fields, or activate controls before completing the steps that come before them. This makes forms and multi-step processes difficult to complete, so it is rated serious.
Does the focus order have to match the visual order exactly?
Not always. SC 2.4.3 requires an order that preserves meaning and operability, so small differences are acceptable as long as the order is still logical. Problems arise when the focus order contradicts the way users read and use the page.
Standards and Regulations
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 2.4.3 Focus Order (A) | 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. |
| EN 301 549 | 9.2.4.3 Focus Order | Same as the WCAG text. |
| 508 Trusted Tester | 2.4.3-focus-order-meaning, 4.F | The focus order preserves the meaning and operability of the web page. |