Focus Order

How to recognize it

Tab through the page from the top and watch where focus lands each time, without touching the mouse. Three patterns fail this: focus jumping from a form's first field to an unrelated part of the page before coming back to the second field; a modal dialog that opens without focus moving into it, so Tab keeps walking through the page hidden behind it; and dynamically injected content — an autocomplete list, an expanded accordion panel — that's placed at the end of the DOM even though it visually appears in the middle of the page, so focus order visually teleports. None of this requires the tab order to match left-to-right, top-to-bottom reading order exactly — the actual bar is lower than that: does the sequence stay logical enough that you're not left disoriented about what you just interacted with?

How to fix it

The most common cause is DOM order silently drifting away from visual order — CSS (flexbox/grid order, absolute positioning) can make something appear first without it being first in the markup, and Tab always follows DOM order, not the visual one. Fix the DOM order itself rather than patching the visual result with CSS. For dialogs and other content that appears dynamically, move focus into it programmatically the moment it becomes visible, and return focus to whatever triggered it when it closes. A modal also needs role="dialog" (or role="alertdialog") and aria-modal="true" on its container — that's a 4.1.2 requirement, not a 2.4.3 one, but the two go hand in hand in practice: moving focus into a container that has no role tells a screen reader user where they landed but not that they're now inside a dialog. Test this the same way a keyboard user would: by actually tabbing through, not by reading the code.

Example

<form>
  <input name="email" style="order: 2">
  <input name="name" style="order: 1">
</form>

<div id="modal" hidden>
  <h2>Confirm delete</h2>
</div>

function openModal() {
  modal.hidden = false;
  // no role, and focus never moves — Tab keeps walking through the page behind it
}

<div id="page-content">...</div>
<div id="accordion-panel-2" hidden>Revealed in the middle of the page, but rendered at the very end of the DOM</div>

<form>
  <input name="name">
  <input name="email">
</form>

<div id="modal" role="dialog" aria-modal="true" aria-labelledby="modal-title" hidden>
  <h2 id="modal-title">Confirm delete</h2>
</div>

function openModal() {
  modal.hidden = false;
  modal.querySelector('h2').focus();
}

<div id="page-content">
  ...
  <div id="accordion-panel-2" hidden>Rendered right where it visually appears, in DOM order</div>
</div>

Resources

• W3C: Understanding Success Criterion 2.4.3 (Focus Order)

See also

• 2.1.1 Keyboard

  2.1.1 asks whether every control can be reached and operated by keyboard at all; 2.4.3 only matters once that's true — it asks whether the order you reach them in makes sense.

• 4.1.2 Name, Role, Value

  Moving focus into a dialog is a 2.4.3 concern; the dialog having role="dialog" and an accessible name is a 4.1.2 concern. A dialog needs both — focus with no role tells a screen reader user where they are but not what they're in.

• 2.4.7 Focus Visible

  2.4.3 is about the sequence focus moves in; 2.4.7 is about whether you can see where it currently is. Both matter even when the other is handled correctly.

• 1.3.2 Meaningful Sequence

  Close cousins: 2.4.3 is specifically about the order focus moves through interactive elements; 1.3.2 is about the reading order of content in general. A page can get one right and the other wrong.

• 4.1.3 Status Messages

  Easy to mix up the mechanisms: a modal dialog gets focus moved into it (this criterion's territory); a status message deliberately does not move focus and relies on a live region instead (4.1.3). Using the wrong one for the wrong situation is a common real mistake.