Operable · 2.4 Navigable

Focus Order WCAG 2.4.3 · Level A

If a page can be navigated sequentially and the order affects meaning or operation, focusable components must receive focus in an order that preserves meaning and operability. The order need not match the visual layout exactly, but it must make sense.

Level
A
Since
WCAG 2.0
Principle
Operable
Guideline
2.4 Navigable
Try the live demo All criteria Checklist

Live demo

Tab through the delivery form

The same task, done two ways: switch between the version that passes and the one that fails, or put them side by side. Everything in the box is live, so try it with a keyboard, a pointer or a screen reader.

Press Tab to move through the form, or turn on Show tab order to number each field. Compare the numbers with the order you would read the labels.

Live example

Passes

Delivery details

What happened

    Why it passes

    The fields are in the source in the order you read them, so focus goes from First name to Last name and then down the form row by row.

    Why it fails

    The form looks the same, but its source lists the left column first. After First name, focus jumps down to Email, so someone typing their names in order puts their last name in the wrong field.

    Examples

    Code that fails, and the fix

    Five examples, each one running: the usual ways this criterion fails, and code that passes. Listen to them, measure them, or copy the code.

    01What changes − tabindex="2" − tabindex="1" − tabindex="3"

    Fails

    Positive tabindex values reorder the form

    Live preview

    HTML
    <form>  <label for="email">Email</label>  <input id="email" type="email" tabindex="2">  <label for="name">Full name</label>  <input id="name" tabindex="1">  <button type="submit" tabindex="3">Subscribe</button></form>

    Focus goes to Full name before Email, against the reading order. Positive values also come before every other control on the page, so the first Tab skips the header and lands here (failure F44).

    Passes

    Source order with no positive tabindex

    Live preview

    HTML
    <form>  <label for="email">Email</label>  <input id="email" type="email">  <label for="name">Full name</label>  <input id="name">  <button type="submit">Subscribe</button></form>

    Without tabindex values, focus follows the source order, which matches the order people read the form (technique G59).

    02What changes 3 lines

    Fails

    Grid placement that scrambles the order

    Live preview

    CSS
    /* Source order: first name, email, town, last name, phone, postcode */.address {  display: grid;  grid-template-columns: 1fr 1fr;  grid-template-rows: repeat(3, auto);  grid-auto-flow: column;}

    The fields appear in pairs across each row, but focus follows the source order down the first column. After First name it jumps to Email instead of Last name.

    Passes

    Source order that matches the rows

    Live preview

    CSS
    /* Source order: first name, last name, email, phone, town, postcode */.address {  display: grid;  grid-template-columns: 1fr 1fr;}

    The markup lists the fields in reading order and the grid only wraps them into rows, so focus moves across each pair and then down (technique C27).

    Passes

    Focus moves into a dialog and back

    Live preview

    JavaScript
    const openButton = document.querySelector("#change-seat");const dialog = document.querySelector("#seat-dialog");openButton.addEventListener("click", () => dialog.showModal());dialog.addEventListener("close", () => openButton.focus());

    showModal() moves focus into the dialog and makes the page behind it inert. When the dialog closes, focus returns to the button that opened it, so the user carries on from the same place.

    Why it matters

    Who it helps

    Keyboard and screen reader users, and people using magnification who see only part of the screen, need focus to move in a predictable order that matches the content's meaning so they do not become disoriented.

    W3C: Understanding 2.4.3

    • Level A

      Level A is the minimum: failing it can shut some people out completely.

    • In WCAG versions

      Part of WCAG 2.0 since December 2008, and of every version after it.

      WCAG 1.0 checkpoints: 9.4

    • Where it is required

      Required where the law names WCAG 2.0 or later at this level: the United States, Canada, the European Union, the United Kingdom, France, Germany, Italy, Spain, the Netherlands, Ireland, Norway, Switzerland, India, Japan, Australia, New Zealand and Israel.

    How to test

    Checking it

    A few concrete steps. Automated tools find some failures; most need a person.

    1. Tab through the whole page and confirm focus follows a logical order that matches the reading and operating order.
    2. Open dialogs, menus and disclosure panels and confirm focus moves into them, then returns to a sensible place when they close.
    3. Look for positive tabindex values or content reordered visually with CSS that makes focus jump unexpectedly.

    Common failures

    Where it breaks

    • Positive tabindex values send focus to elements out of their logical sequence.
    • A modal dialog opens but focus stays on the page behind it, so the next Tab moves through content the user cannot see.
    • A layout reordered visually with CSS makes the tab order jump around the screen in a way that no longer matches the reading order.

    On the Accessibility Checklist

    Related