WCAG 2.4.3 — Focus Order

What this requires

Components that receive focus must do so in an order that preserves meaning and operability. The natural focus order is the source order of the DOM. Visual rearrangement with CSS — Flexbox order, Grid placement, absolute positioning — leaves the focus order behind. The two must remain consistent, or fixed so they are.

How AI coding tools fail this

The most damaging failure: positive tabIndex values. An AI assistant asked to "make the submit button focus first" reaches for tabIndex={1} on the button, breaking the entire page's natural tab sequence in the process. Positive tabindex values fight every other element on the page; they almost never do what the author intended.

The second pattern: CSS that visually reorders without reordering the DOM. A two-column layout where the right column reads first visually but the markup puts the left column first. A keyboard user tabs through the left column then the right; a sighted user reads right then left. The experiences diverge.

The third: focus moved programmatically to elements that shouldn't receive focus, or not moved to elements that should. A modal that opens but doesn't move focus inside. A skip-link that points to an element with no tabIndex={-1}. A new section revealed by expanding an accordion that the user then has to tab back through the rest of the page to reach.

Failing examples

Positive tabindex breaking the page-wide tab sequence:

<input tabIndex={1} name="email" />
<input tabIndex={2} name="password" />
<button tabIndex={3}>Sign in</button>

Visual reorder with no DOM reorder:

<div className="flex">
  <aside className="order-2">Secondary content</aside>
  <main className="order-1">Primary content</main>
</div>

Passing examples

Source order matches focus order; no tabindex needed:

<input name="email" />
<input name="password" />
<button>Sign in</button>

Reorder the DOM, not just the CSS, when the visual order matters:

<div className="flex">
  <main>Primary content</main>
  <aside>Secondary content</aside>
</div>

Edge cases

tabIndex={0} makes an otherwise-non-focusable element focusable in the natural order. Use it sparingly — usually only for custom widgets following the ARIA APG.
tabIndex={-1} removes an element from the tab sequence but keeps it programmatically focusable (via .focus()). Useful for skip link targets and managed focus inside custom widgets.
Modal dialogs must move focus into the dialog on open and trap it there. See the accessible modal pattern.
Single-page app route changes should move focus to the new view's heading or main landmark, otherwise screen reader users have no signal that the page changed.
Visually-hidden links and buttons still appear in the tab order unless you also remove them with tabIndex={-1} or display: none.

How Jeikin handles this

Jeikin's CLI scanner flags positive tabIndex values (anything greater than zero) and maps each finding to WCAG 2.4.3. The MCP server reminds the AI assistant that focus order follows DOM source order — meaning the right fix is usually to reorder the markup, not to add tabindex.

The dashboard tracks each finding through resolution with a timestamped audit trail.