Focus Order

In brief

When you press Tab, focus should move in the order that makes sense: usually top to bottom and left to right, following the content. If focus jumps from the first field to the last, or into a menu at the top of the page, keyboard users lose their place and may submit forms with the wrong data.

This criterion requires that if a page can be navigated sequentially and the order affects meaning or operation, focusable components receive focus in an order that preserves meaning and operability. There may be more than one valid order, but one must be provided.

What does it cover?

• Sequential navigation: Moving focus from element to element with Tab and Shift+Tab. Arrow-key navigation inside a widget such as a tree or a menu is not the sequence this criterion covers.
• Meaning and operability: The order should follow the logical relationships of the content. Focus order may differ from the reading order if users can still understand and operate the page.
• DOM order: The simplest way to get it right is to make the DOM order match the visual order (C27).
• Dialogs and menus: A non-modal dialog or menu should come right after its trigger in the focus order. A modal dialog takes focus when it opens, keeps the rest inert and returns focus to the trigger when closed.
• Dynamic content: Content inserted after an action should be inserted next to the control that triggered it (SCR26), or focus should be moved to it.
• Failures: Positive tabindex values that scramble the order (F44), and dialogs or menus that are not adjacent to their trigger (F85).
• Out of scope: Reading order is 1.3.2. Making focus visible is 2.4.7. Keyboard operation is 2.1.1.

Who does it affect?

Keyboard-only users and switch users, who follow the focus order. Screen reader users, who move through the page sequentially. People with low vision who use magnifiers and see only a part of the page, so a sudden jump takes focus out of view. People with cognitive disabilities, who need a predictable order.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. A logical focus order is part of "operable".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 2.4.3 by reference and turns it into separate clauses for each kind of ICT.

Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 2.4.3 is the same in WCAG 2.1 and 2.2.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. Make the DOM order match the visual order

CSS can move things visually without changing the order of focus.

.form { display: flex; flex-direction: column-reverse; }
/* Tab goes to the last field first */

.form { display: flex; flex-direction: column; }
/* DOM order and visual order are the same */

2. Do not use positive tabindex

tabindex values above 0 take elements out of the natural order and are very hard to maintain (F44).

<input tabindex="3">
<input tabindex="1">
<input tabindex="2">

<input>
<input>
<input>

3. Use tabindex="-1" only for scripted focus

A value of -1 lets a script focus an element, for example a heading, without adding it to the Tab sequence.

<div tabindex="0">Static paragraph</div>

<h2 id="results" tabindex="-1">Results</h2>
<script>document.getElementById("results").focus();</script>

4. A modal dialog

Move focus into the dialog when it opens, keep the page behind it inert, and put focus back on the trigger when it closes (H102).

<div class="modal">…</div> <!-- appended at the end of the page, focus stays behind -->

<button id="open">Edit profile</button>
<dialog id="profile">
  <h2>Edit profile</h2>
  …
  <button type="button" id="close">Close</button>
</dialog>
<script>
open.onclick = () => profile.showModal();
close.onclick = () => { profile.close(); open.focus(); };
</script>

5. Content that appears after an action

Insert dynamic content next to its trigger so that Tab leads straight into it.

document.body.appendChild(panel); // far from the trigger

trigger.insertAdjacentElement("afterend", panel);

6. No double focus

Do not wrap a focusable control in another focusable element. The control then receives focus twice.

<div tabindex="0" onclick="go()"><button>Open</button></div>

<button onclick="go()">Open</button>

Code examples for mobile

Screen readers and switch access follow a traversal order on mobile as well. It normally follows the layout, and you only adjust it when the visual layout and the logical order differ.

iOS (SwiftUI)

import SwiftUI

struct PriceCard: View {
    var body: some View {
        ZStack {
            // Visually the price sits on top, but the name should be read first
            Text("Trail running shoes")
                .accessibilitySortPriority(2)
            Text("$89")
                .accessibilitySortPriority(1)
        }
        // Group so that VoiceOver treats the card as one container
        .accessibilityElement(children: .contain)
    }
}

Android (Jetpack Compose)

import androidx.compose.foundation.layout.Box
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.semantics.isTraversalGroup
import androidx.compose.ui.semantics.semantics
import androidx.compose.ui.semantics.traversalIndex

@Composable
fun PriceCard() {
    Box(modifier = Modifier.semantics { isTraversalGroup = true }) {
        // The visual position and the reading order differ, so set the order explicitly
        Text("$89", modifier = Modifier.semantics { traversalIndex = 1f })
        Text("Trail running shoes", modifier = Modifier.semantics { traversalIndex = 0f })
    }
}

How to test

• Tab through the page: Press Tab from the top and follow the focus. Does it move in a logical order that matches the content?
• Go backwards: Press Shift+Tab. Is the reverse order logical as well?
• Check forms: Does focus go through the fields in the order users would fill them in?
• Check dialogs and menus: When one opens, does focus move into it? When it closes, does focus return to the trigger?
• Check dynamic content: After expanding a section or loading results, is the next Tab into the new content?
• Look for positive tabindex: Search the code for tabindex values above 0 and for CSS that reorders content visually.
• Check mobile: Swipe through screens with a screen reader. Does the order follow what a user would expect?
• Use a checker as a starting point: Automated tools can flag positive tabindex values but cannot say if an order makes sense. A person must walk through it.

Common mistakes

• Positive tabindex values: They create a custom order that nobody maintains.
• CSS that reorders content: order, column-reverse and absolute positioning separate focus from the visual layout.
• Modal dialogs added at the end of the DOM without moving focus: Focus stays behind the dialog.
• Focus not returned after closing: Users start from the top of the page again.
• Dynamic content inserted far from its trigger: Tab skips it or reaches it last.
• Double focus on wrapped controls: A focusable div around a button.
• Hidden items that remain focusable: Off-screen menus that keep receiving focus.
• A sticky banner or chat widget first in the DOM: It takes the first stop on every page.

Sources

• Understanding SC 2.4.3: Focus Order (W3C), opens in a new tab
• F44: Failure of Success Criterion 2.4.3 due to using tabindex to create a tab order that does not preserve meaning and operability (W3C), opens in a new tab
• H102: Creating modal dialogs with the HTML dialog element (W3C), opens in a new tab
• Directive (EU) 2019/882, European Accessibility Act (EUR-Lex), opens in a new tab
• EN 301 549 V4.1.1 (ETSI), opens in a new tab
• The European accessibility standard EN 301 549 has been updated (AccessibleEU), opens in a new tab

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.