WCAG 2.4.3 — Focus Order

Incorrect Focus Order

What is this issue?

Incorrect focus order occurs when the tab order of interactive elements does not follow a logical and predictable sequence that matches the visual layout. WCAG Success Criterion 2.4.3 (Level A) requires that when content can be navigated sequentially, focusable components receive focus in an order that preserves meaning and operability.

The most common cause of incorrect focus order is the misuse of CSS positioning. When visual layout is rearranged using flexbox order, CSS grid placement, or absolute/fixed positioning, the visual order may differ significantly from the DOM order. Since keyboard focus follows the DOM order, users may experience focus jumping unpredictably across the page -- from a footer element to a header element, then to a sidebar, then back to the main content.

Another common cause is the misuse of positive tabindex values (tabindex="1", tabindex="2", etc.). These override the natural DOM order and create a separate tab sequence that is difficult to maintain and often becomes inconsistent as the page evolves. Dynamically inserted content (modals, tooltips, AJAX-loaded sections) also frequently breaks focus order when new elements are inserted at the wrong position in the DOM.

Impact on users

For keyboard users, an unpredictable focus order makes navigation disorienting. Instead of moving naturally from left to right and top to bottom (in LTR languages), focus jumps around the page in an illogical sequence. Users lose their place, miss important content, and accidentally interact with the wrong elements.

Screen reader users who navigate by Tab key are doubly affected because they cannot see where focus has moved. They hear an element announced but have no visual context to understand why focus moved from the navigation to the footer. This creates cognitive overhead and slows down every interaction.

Incorrect focus order can also have functional consequences. If a confirmation button receives focus before the terms and conditions checkbox in a checkout form, users may confirm without having had the opportunity to review the terms. This is both an accessibility failure and a usability problem.

Code example

Before (non-compliant)

<!-- CSS reorder breaks tab order -->
<div style="display: flex; flex-direction: column;">
  <button style="order: 3;">Submit</button>
  <input style="order: 1;" placeholder="Name">
  <input style="order: 2;" placeholder="Email">
</div>

<!-- Positive tabindex creates chaos -->
<input tabindex="3" placeholder="Phone">
<input tabindex="1" placeholder="Name">
<input tabindex="2" placeholder="Email">

After (compliant)

<!-- DOM order matches visual order -->
<div style="display: flex; flex-direction: column;">
  <input placeholder="Name">
  <input placeholder="Email">
  <button>Submit</button>
</div>

<!-- Natural tab order (no positive tabindex) -->
<input placeholder="Name">
<input placeholder="Email">
<input placeholder="Phone">

How Scrutia detects this issue

Scrutia simulates keyboard navigation through every page and compares the tab order of focusable elements against their visual position. It detects cases where focus jumps to a visually distant element, where CSS order or flexbox/grid reordering creates a mismatch, and where positive tabindex values override the natural flow. Each finding includes a visual map showing the expected vs. actual focus sequence.

Check your site for this issue

Scrutia audits your site against WCAG criteria in minutes.

Free audit

Frequently Asked Questions

Is it ever okay to use a positive tabindex?

It is almost never recommended. Positive tabindex values create a separate tab sequence that overrides the DOM order and is fragile to maintain. Use tabindex="0" to make elements focusable in DOM order, or tabindex="-1" to make them programmatically focusable without adding them to the tab order.

Does CSS flexbox order affect tab order?

Yes. CSS order, flex-direction: row-reverse, and grid placement change the visual order without changing the DOM order. Since tab order follows the DOM, this creates a mismatch. The solution is to ensure DOM order matches the intended visual order.

How should I handle focus order in modals?

When a modal opens, move focus to the first interactive element inside it (or the modal container itself). Trap focus inside the modal while it is open. When it closes, return focus to the element that triggered it. This maintains a logical focus flow.

Does your site have this issue?

Scrutia scans your pages against WCAG success criteria and delivers actionable fixes. Results in 5 minutes.

Run a free audit