Definition: Focus order is the sequence in which links, buttons and form fields receive keyboard focus as you press Tab through a page. It must preserve meaning and operability, as WCAG 2.4.3 Focus Order requires at Level A [1].
German: Fokusreihenfolge · Also: tab order · Last reviewed: 27 September 2026
How the order comes about
By default, the browser follows the order of the source code – the DOM. The tabindex attribute changes that [3]:
tabindex="0"adds an element to the order, at its place in the DOM.tabindex="-1"makes it focusable by script but not by Tab.- A positive value such as
tabindex="3"pulls the element forward, ahead of everything else. It almost always scrambles the order.
CSS changes only what is displayed, not focus. Rearrange elements visually with order, grid placement or absolute positioning, and Tab will jump differently from how the eye reads. WCAG 1.3.2 Meaningful Sequence asks the same question of reading order.
Who depends on it
People who use a keyboard, a switch or a screen reader experience a page in sequence, one element at a time. If focus jumps from the header to the footer and back, they lose the thread. Screen magnifier users also lose their place on screen.
Examples
- A form: the "Next" button comes before the fields in the code. The first press of Tab lands on "Next".
- Two columns swapped with CSS: the filter appears on the left but sits on the right in the code. Tab reaches it only after all the products.
- A dialog: after opening, focus stays on the page behind it. After closing, it lands at the top of the page instead of on the button that opened the dialog [2].
- A collapsed menu: its links have been moved aside rather than hidden, so focus disappears into invisible elements.
In code
<!-- Positive tabindex: jumps ahead of all -->
<label>City <input tabindex="1"></label>
<label>Postcode <input tabindex="2"></label>
<button tabindex="3">Next</button><!-- Better: DOM order = reading order -->
<label>Postcode <input></label>
<label>City <input></label>
<button>Next</button>How to test it
Put the mouse away and Tab through the page. Does focus follow the order in which you would read it? After opening a dialog, does focus move into it, and after closing, back to what opened it? Does it vanish anywhere?
How Reviseberg handles it
The keyboard agent walks your most important user journey with Tab and records every step with the role and name of the focused element. That trail is the focus order as it actually happens. Whether it makes sense is not something automation decides – a person judges that from the trail. When focus lands on something invisible, the agent reports keyboard:focus-invisible. The axe-core rule tabindex finds positive tabindex values, which Reviseberg maps to WCAG 2.4.3. That criterion therefore counts as only partly automatable.
Related terms
Focus indicator · Keyboard accessibility · Keyboard trap · Skip link · Semantic HTML