Level A

Focus order failures happen when the DOM source order stops matching the visual reading order -- positive tabindex, CSS order, and absolute positioning are the common causes

2.4.3 Focus Order

In Plain Language

2.4.3 Focus Order (Level A) requires that when a page is navigated sequentially with Tab and Shift+Tab, focusable elements receive focus in an order that preserves the meaning and operability of the content[1]. The sequence does not have to be identical to the visual layout, but it must not break how the content is understood or used.

In modern browsers the default sequential focus order follows DOM source order. Failures come from code that decouples the tab sequence from the source order -- positive tabindex, CSS that visually reorders elements away from their DOM position, or scripts that move focus to unexpected places. 2.4.3 is the keyboard-focus consequence of 1.3.2 Meaningful Sequence: if the DOM sequence is wrong for meaning, the tab sequence will be wrong too[2].

Why It Matters

  • Keyboard and switch users navigate with Tab and Shift+Tab. The focus sequence is their reading order -- when it stops matching the visual layout, they lose track of where they are in a form or widget and can miss required fields.
  • Screen-reader users who navigate with Tab hear elements in focus order. A mismatch between focus order and visual order means the spoken sequence no longer describes the page the sighted reviewer signed off on.
  • CSS layout techniques decouple visual order from DOM order: position: absolute, flex order, flex-direction: row-reverse, and grid-template-areas can all place an element visually in a position its DOM siblings do not predict. The tab sequence still follows the DOM, so the visual and keyboard orders diverge.
  • Positive tabindex values (tabindex="1", tabindex="5") pull elements to the front of the document tab sequence ahead of every element with tabindex="0" or a default value. The W3C lists this as failure technique F44[1].
  • Custom widgets that call element.focus() in response to interaction can drop focus outside the expected next stop -- for example, a menu that opens adjacent to its trigger in the DOM but programmatically sends focus to a closing button elsewhere in the tree (W3C failure F85)[1].

Examples

Do: DOM order matches visual order

✔ Tab order follows visual order: 1 → 2 → 3 → 4

<!-- DOM order matches visual layout -->
<form>
  <label for="fname">First Name</label>
  <input id="fname" type="text">

  <label for="lname">Last Name</label>
  <input id="lname" type="text">

  <label for="email">Email</label>
  <input id="email" type="email">

  <button type="submit">Submit</button>
</form>
Don't: Positive tabindex breaks natural order

✘ Tab order is 2 → 4 → 1 → 3 -- completely unpredictable

<!-- FAILS F44: positive tabindex jumps to the front of the sequence -->
<form>
  <input tabindex="3" id="fname" type="text">
  <input tabindex="1" id="lname" type="text">
  <input tabindex="4" id="email" type="email">
  <button tabindex="2" type="submit">Submit</button>
</form>
Do: Flexbox layout with matching DOM order
SidebarMainAside

✔ DOM order: Sidebar → Main → Aside matches the visual left-to-right layout

Don't: CSS order property breaks focus sequence
MainSidebarAside

✘ Visual order is Sidebar → Aside → Main, but Tab order follows DOM: Main → Sidebar → Aside

How to Fix It

  1. Write the DOM in reading order. Place elements in the HTML source in the sequence they should be read and operated. Let CSS style the layout without relocating elements past their siblings -- avoid rearranging content with flex order, flex-direction: row-reverse, grid-template-areas, or absolute positioning when the result is a visual order the DOM does not predict. This is also how 1.3.2 Meaningful Sequence is satisfied[2].
  2. Do not use positive tabindex. Any value greater than 0 pulls the element to the front of the sequential focus order ahead of elements with tabindex="0" or default tabbing -- the W3C lists this as failure F44[1]. Use tabindex="0" only to make a non-interactive element focusable in document order, and tabindex="-1" only for targets that must accept programmatic focus (for example, a container that receives focus after a route change) but must not appear in the tab sequence.
  3. Manage focus for dynamic content. When a modal opens, move focus into it and trap it there until it closes; when it closes, return focus to the element that opened it. When new content is inserted above the current focus position, verify the next Tab still lands somewhere meaningful. For composite widgets (menus, tabs, tree, grid) implement the roving-tabindex or aria-activedescendant pattern documented in the WAI-ARIA Authoring Practices[3].
  4. Test with the keyboard. Press Tab from the top of the page to the bottom and Shift+Tab back. Confirm every interactive element receives focus, the sequence preserves the meaning of the content, focus never jumps out of the current section unexpectedly, and it never lands on something that is off-screen or visually hidden.

References

  1. [1] W3C (2023). Understanding Success Criterion 2.4.3: Focus Order. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html ↩ ↩ ↩ ↩
  2. [2] W3C (2023). Understanding Success Criterion 1.3.2: Meaningful Sequence. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence.html ↩ ↩
  3. [3] W3C (2024). WAI-ARIA Authoring Practices Guide. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/ARIA/apg/ ↩