Operable Guideline 2.4 Navigable

2.4.3 Focus Order

Keyboard focus must move in an order that makes sense

Level A Needs a person to check

What it asks for, in plain English

When someone tabs through the page, focus should move in an order that keeps the meaning and lets them operate things. Usually that is top to bottom, left to right, following the reading order. A form should go field by field, a dialog should take focus when it opens and give it back when it closes, and a hidden menu should not be tabbable while hidden.

The order does not have to be identical to the visual layout, but it must not be confusing. Jumping from the header to the footer and back to the content is confusing.

The usual failures are positive tabindex values that force an arbitrary order, CSS that visually reorders a form, and dialogs or drawers that open without moving focus, so the keyboard user is still back on the page behind them.

This is an independent explanation. The binding wording is the W3C Recommendation, and the W3C's own Understanding 2.4.3 page has the full intent, techniques and definitions.

Who it affects

A sighted keyboard user presses Tab and watches focus leap to somewhere else on the page, then loses track of where it went.

Someone using a screen reader opens a dialog and hears nothing, because focus stayed on the button behind it.

A person with a cognitive impairment finds a form that jumps from Name to Postcode to Email and cannot predict where they will land next.

Example

Broken
<label for="n">Name</label> <input id="n" tabindex="1">
<label for="e">Email</label> <input id="e" tabindex="3">
<label for="p">Phone</label> <input id="p" tabindex="2">
<button tabindex="4">Send</button>

Positive tabindex values make focus go Name, Phone, Email, Send, which is not what the eye expects.

Fixed
<label for="n">Name</label> <input id="n">
<label for="e">Email</label> <input id="e">
<label for="p">Phone</label> <input id="p">
<button>Send</button>

Remove the tabindex attributes and focus follows the code order, which here matches the visual order.

How to check it

  1. Tab through the page and say out loud where focus goes. It should follow the reading order without surprises.
  2. Open every dialog, drawer and menu with the keyboard. Focus should move into it, and come back to the trigger when it closes.
  3. Tab while a menu or panel is closed. Hidden controls should be skipped, not focused invisibly.
  4. Search the source for tabindex values greater than 0 and remove them.

What Websight checks for 2.4.3

Websight has no automated check for this criterion. It lists it in the manual checklist that comes with every report, so it is not forgotten.

Only a person can check this. A scanner can see tabindex values but cannot judge whether the resulting order makes sense or whether a dialog manages focus properly. Websight lists it in its manual checklist.

Practical tips

  • Never use a positive tabindex. Fix the order in the HTML instead.
  • When a dialog opens, move focus to its heading or first control; when it closes, put focus back on the button that opened it.
  • Hide closed menus with display: none or the hidden attribute, not just by moving them off-screen, so they leave the tab order.

Scan your page and see where 2.4.3 stands

Websight gives a score out of 100, explains each automated finding in plain English, and lists the checks a person still needs to do.

Add Websight to Chrome

Free scans, no account, nothing leaves your computer. Automated tools find only part of the problems; the extension says so on every report.