• Success Criterion 2.4.3
  • Conformance level A

Toolbar With a Broken Roving Tabindex Pattern

2.4.3 — Focus Order

Scenario

Setting

A photo-sharing app's upload screen

What’s wrong

Toolbars where roving tabindex (a toolbar keyboard pattern) is broken, scattering stops.

Example 

<div role="toolbar" aria-label="Edit photo">
  <button tabindex="0">Crop</button>
  <button tabindex="0">Rotate</button>
  <button tabindex="0">Filter</button>
  <button tabindex="0">Delete</button>
</div>
<!-- arrow-key handler moves focus but never updates tabindex, so Tab still stops at all four -->

Why it matters

Tab now stops at all four toolbar buttons individually instead of once, and arrow keys don't reliably track which one is active.

How to test

Tab through a toolbar: if the roving tabindex pattern is broken (each button is its own tab stop instead of one stop with arrow-key navigation inside), it fails.

How to fix

Roving tabindex means exactly one item in the group is a Tab stop at any time; keep the values in sync with focus.

function moveTo(newBtn, oldBtn) {
  oldBtn.tabIndex = -1;
  newBtn.tabIndex = 0;
  newBtn.focus();
}

Outcome

A user tabs into the toolbar once, then arrows between crop, rotate, and filter with no extra Tab stops.

Who is affected

Keyboard users editing photos get an unpredictable mix of Tab and arrow-key behavior instead of a single, consistent toolbar stop.

Learn more

Related scenarios