Focus order and tabindex (WCAG 2.4.3)

The route Tab and Shift+Tab take through a page follows the order of the HTML unless something overrides it, so a confusing order is best fixed in the markup. The order matters because W3C's Understanding document for 2.4.3 lists who benefits from a logical route: people with mobility impairments who depend on the keyboard, people with disabilities that make reading difficult or with visual impairments, who can become disoriented when focus lands somewhere unexpected, and screen magnifier users, who at high magnification may see only a small part of the page.

You rarely have to build the order yourself. With no tabindex attribute and no scripting, focus follows the order of the source. The tabindex attribute does two jobs, as W3C's note on technique C27 explains: it makes an element focusable, and it can give the element a position in the focus order. Checking the order is one step of our keyboard accessibility test.

What WCAG 2.4.3 requires

Success criterion 2.4.3 Focus Order is Level A. When 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." W3C's Understanding document sets four boundaries:

• Several orders can pass. A table can be traversed row by row or column by column.
• The order need not match the layout exactly. In a two-column layout with independent columns, the right column may come first, though W3C says as a best practice focus should reinforce the visual reading order.
• Confusion fails. The criterion fails if the order impedes meaning or operation or creates confusion. W3C's example is a control that takes focus twice because focusable elements are nested, such as a div with tabindex="0" around a button.
• It does not decide what is focusable. Static text may be focusable, and arrow-key movement inside a component such as a tree control is outside the criterion.

Reading order is a separate requirement, 1.3.2 Meaningful Sequence. W3C says focus order may differ from the programmatic reading order if people can still understand and operate the page. In our reading, one fix usually serves both: make the source order match what people see. Structure carried by the markup is also what 1.3.1 Info and Relationships asks for, and it gives the browser a sensible default order to work from.

What sets the order: the source, not the screen

Where no tabindex or script changes it, W3C says, the navigation order is the order in which components appear in the content stream. For HTML that is the source order as it stands in the DOM, the browser's live tree of the page, which scripts can change after load.

The element type decides what takes part. MDN lists the elements focusable by default: links and areas with an href, buttons, form fields, iframes and the summary of a details element, among others. A div with a click handler is not one of them, so it never receives focus unless someone adds a tabindex. MDN recommends native interactive elements instead; see our guide to buttons versus links.

What each tabindex value does

MDN and WebAIM give the same two examples of moving focus with a negative value: a modal that should receive focus when it appears, and an error message focused after a failed submission. W3C's example modal dialog puts it on the dialog's heading. WebAIM's warning is the one to remember: never give tabindex="-1" to anything a keyboard user must reach.

Why a positive tabindex breaks the order

A positive value pulls an element out of the source order. In W3C's failure technique F44, four links (a home page and chapters 1, 2 and 3) have tabindex values of 1, 4, 3 and 2, so Tab visits home, chapter 3, chapter 2, then chapter 1. In a second example every form field has a tabindex, and a field added later without one lands at the end of the order. F44 applies when the order the values set does not follow the relationships in the content, and it notes that edits to the content easily leave the values out of step.

The numbers count across the whole page, so one positive value is enough to cause trouble. By MDN's ordering rule, an element with tabindex="1" is reached before elements that have none, including a skip link with no tabindex. That consequence is our reading of the rule. MDN says to write the document with the elements in a logical sequence, and WebAIM says to adjust the source order and use CSS only for the visual layout. Delete the values, then fix the markup.

How CSS breaks focus order without any tabindex

The source order and the order on screen are separate, and CSS can pull them apart. MDN's guide to ordering flex items says the order property and the reverse values of flex-direction change only how items are drawn, while the tabbing and speech order follow the source, so a person tabbing through the layout can jump around in a confusing way. MDN quotes the flexbox specification, which says authors must not use these features as a substitute for correct source ordering.

W3C's technique C27, making the DOM order match the visual order, is listed as sufficient for 1.3.2 and, when focus follows the content's sequences and relationships, for 2.4.3. The same page notes that tabindex values which depart from the DOM order can leave the order incorrect for assistive technology users, largely because tabindex is specified in HTML and not in CSS.

A difference between the two orders is not automatically a failure. In its Understanding document for 2.4.3, W3C gives a passing example: a left-hand navigation placed after the main content in the HTML and moved left with CSS, so focus reaches the main content first. It cautions that more complex positioning may not pass.

Test a narrow window as well as a wide one: media queries can change a layout so that the visual order differs from the source order, as MDN's page on the reading-flow property notes. That property can make a container's tab order follow the visual order, but MDN marked it experimental and not Baseline when we read the page in October 2026, so keep the source order sensible.

Menus, dialogs and content added after load

Scripts add content after the page loads, and where they put it decides where focus goes next.

• Insert new content straight after its trigger. W3C's technique SCR26 does this for a menu or dialog, so the next Tab reaches it. It is sufficient for 2.4.3 when a page changes dynamically.
• Move focus into content that is not next in line. Failure F85 describes a dialog added at the end of the DOM with no script to move focus into it, so keyboard users must tab through the rest of the page to reach it.
• Return focus when it closes. F85's second example sends focus to the document when a menu is dismissed, so the user must tab from the start of the page to find the opener again. The ARIA Authoring Practices Guide warns that if focus is not set back on the button that opened a dialog, browsers move focus to the body element, effectively losing focus within the interface.
• Use the native dialog element for modals. W3C's technique H102 says the browser moves focus into a dialog opened with showModal(), returns it to the opener on close if the opener is still on the page, keeps it within the dialog and the browser's own controls, makes the rest of the page inert and closes it on Escape.

Our guides to accessible modals and accessible menus cover the patterns.

Widgets with several parts: roving tabindex

Tab moves between components, and arrow keys move inside one. The ARIA Authoring Practices Guide says a composite such as a tab list, radio group, menu or grid should put only one of its parts in the tab sequence. With a roving tabindex, the active item gets tabindex="0" and the others get tabindex="-1". When an arrow key moves focus, a script swaps the values and calls focus() on the new item. The alternative, aria-activedescendant, keeps focus on the container. Our guides to accordions and tabs and ARIA basics cover the widgets.

Common focus order problems and fixes

Check it yourself

Run this test on each page template:

1. Tab through the page. Reload, click in the address bar, put the mouse aside and press Tab, then Shift+Tab to go back. At each stop, ask whether the next one is where you expected.
2. Watch the sequences that carry meaning: a form's fields in order with the submit button last, a row of cards in reading order, navigation where you intend it.
3. Repeat at a narrow width, where responsive styles can change the visual order.
4. Open every menu and dialog with the keyboard. The next Tab should go into it, and closing it should return focus to its trigger, or to the next logical control if the trigger is gone. Those are the tests in F85 and H102.
5. Search the source for tabindex, looking for values above 0 and for -1 on anything people need to reach.
6. Optional: log the order. Paste this into the browser console and press Tab. Each stop prints the element that took focus, because the focusin event bubbles, as MDN notes.

document.addEventListener("focusin", (event) => console.log(event.target));

The free accessibility bookmarklet checks the page as your browser has rendered it, including content a script added. It does not check tab order or tabindex values, and its limits list says it cannot tell whether a page works with a keyboard. It does report links and buttons with no accessible name and form fields with no label, which are stops a screen reader user would meet without a name.

Scan my site for free reads the HTML your server sends and flags a positive tabindex value as a 2.4.3 issue. It also flags aria-hidden on a link, button or form field, which hides the control from screen readers while Tab can still reach it (see aria-hidden and focus). Where focus lands depends on rendered layout and real key presses, which it cannot see. What we check and why scanners miss issues explain the limits.

Focus order is one of several keyboard checks. A skip link passes repeated navigation, landmarks let screen reader users jump between regions, and a focus indicator shows where focus is. Our keyboard accessibility test puts them in one routine.

Keep it checked

A tab order that is right at launch can change at the next release. GotAlt checks the pages you monitor every week, runs its rule checks (a positive tabindex value is one of them), opens monitored pages in a browser for contrast and other checks that need a rendered page (see what we check), and reports what changed. It does not press keys, so keep the manual test for the order itself. Plans are from $69 a month. Audit my whole site from $69/mo.