WCAG 2.4.3 Focus Order

Success criterion 2.4.3 makes sure that keyboard and screen reader users meet the page's interactive elements in an order that makes sense, so they understand the page and can operate it. It is level A and part of EN 301 549 (clause 9.2.4.3).

What the criterion requires

If a web page can be navigated sequentially (for example with Tab) and the navigation sequence affects meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

The focus order does not have to copy the visual layout pixel by pixel. It fails when the order makes content confusing or impossible to use. Failures documented by W3C include:

• using tabindex to create an order that breaks meaning or operation;
• placing dialogs or menus far from the control that opens them in the focus order.

Typical failures on an online shop

• tabindex="1", "2" … on header elements, so focus jumps around before reaching normal order;
• a CSS layout (flexbox order, grid placement) that shows "Add to cart" next to the price but puts it last in the DOM, after reviews and related products;
• a size-guide or quick-view popup appended at the end of the page, so focus does not move into it and the user must tab through the whole page to reach it;
• after closing the cart drawer, focus jumps to the top of the page instead of returning to the cart button;
• checkout fields in an order different from the visible one (postcode before street).

How to check it

Automated: there is no axe-core rule for this criterion. Whether an order "preserves meaning" is a judgement about the page, so it needs a manual check. (Positive tabindex values are reported by our checker as a best-practice warning, not as a 2.4.3 failure.)

By hand: press Tab from the top of the page and follow the focus indicator. Does it move through the header, main content and footer in a sensible order? On product pages: variant, quantity, "Add to cart". Open each popup and drawer: focus should move into it, stay there while open and return to the trigger when closed. Fill in the checkout form using only Tab.

How to fix it

• Let the DOM order follow the visual and logical order; avoid reordering with CSS when it changes meaning.
• Remove positive tabindex values; use 0 for custom focusable elements and -1 for elements that receive focus by script.
• When opening a dialog, move focus into it; when closing, return focus to the trigger.
• Insert dynamic content (popups, error messages) next to the control it belongs to in the DOM.

Related criteria

• 2.1.1 Keyboard — every function must work from the keyboard.
• 2.4.7 Focus Visible — users must see where focus is.
• 2.4.11 Focus Not Obscured (Minimum) — focused elements must not be hidden.

Frequently asked questions

Does the focus order have to match the visual order?

Not exactly. WCAG asks that the order preserves meaning and operability. Small differences are fine; jumps that make a form or dialog confusing or impossible to use fail.

Is a positive tabindex a WCAG failure?

Not automatically, but W3C lists using tabindex to create a focus order that breaks meaning or operation as a common failure. Values above 0 almost always cause that, so avoid them.

Where should focus go when a popup opens?

Into the popup, and back to the button that opened it when it closes. W3C lists dialogs placed far from their trigger in the focus order as a failure of 2.4.3.