Tab Order Tester

How the Tab Order Tester works

Tab order tester: tabindex and DOM order

Keyboard users move through a page with the Tab key, and where focus goes next is decided by two things: the order elements appear in the source and any tabindex attributes. Sighted mouse users never notice this order, which is why it so often goes wrong when a layout is rearranged with CSS or a widget is built from <div> elements.

What is focusable. Links with an href, buttons, form fields, <summary>, <iframe>, media with controls, editable regions and anything with a tabindex attribute. A link without href, a disabled field, an element inside hidden or display: none, and anything with tabindex="-1" is not in the sequence. The tool applies these rules to the pasted markup; it cannot see styles from external stylesheets, so a control hidden by a class will appear here although it would be skipped in the browser.

Sequence. Elements with a positive tabindex come first, in numeric order, before every element with tabindex="0" or no tabindex, which then follow source order. That is why positive values are almost always a mistake: a single tabindex="1" on a search box sends focus there before the skip link and the navigation, and every later addition to the page has to be renumbered. WCAG 2.4.3 requires that focus order preserves meaning, and source order that matches the visual order is the only reliable way to achieve that.

Names. Each Tab stop is announced with its accessible name, which the tool derives from aria-label, aria-labelledby, an associated <label>, the value of a submit button, the alt text of a contained image, or the text content. A stop with no name, such as an icon button, is announced as just "button". A field whose only name is its placeholder is flagged too, since placeholders vanish when typing starts.

Generic elements. A <div tabindex="0"> is reachable but announces nothing about what it is or how to use it. Focusable generic elements without a role are flagged; the fix is usually to use a <button> instead, or to add the correct role and keyboard handling.

aria-hidden traps. An element with aria-hidden="true" that is still focusable creates a ghost stop: the keyboard lands on it but the screen reader says nothing. The tool lists these separately as an issue.

Related tools