SeoGuard
Noticea11y.tabindex

The tab order has been rearranged

Why it matters

Pressing Tab moves through a page's links, buttons and fields in the order they are written, which is the order they are read in. A tabindex of 1 or more pulls that element to the front of the queue, ahead of everything without one. Focus then jumps from the newsletter box in the footer to the logo to somewhere in the middle, and a keyboard user loses their place; add one more positive tabindex anywhere and the whole sequence shifts again.

tabindex="0" (make this focusable, in its natural place) and tabindex="-1" (focusable from script only) are both fine, and are not flagged.

A notice because a positive value is not a failure in itself: the failure is a focus order that stops making sense, which takes a person with a keyboard to judge. It is just very rarely what anyone meant.

Source: WCAG 2.2, 2.4.3 Focus Order (Level A); failure F44.

How to fix it

Remove the positive values and put the elements in the HTML in the order they should be reached; CSS can still place them anywhere on the screen.

<input type="email" name="email">
<button type="submit">Sign up</button>

Examples

These are the rule's own test pages, and what it says about each. They are run on every change to the rule book.

<form>
<input type="email" name="email" aria-label="Email" tabindex="1">
<button tabindex="2">Sign up</button>
</form>

Notice2 elements have a tabindex above 0, which puts them ahead of everything else when someone tabs through the page: input[name="email"], button.

fail-positive
<div class="card" role="button" tabindex="0">Open the gallery</div>

PassedNothing on the page changes the order that Tab moves in.

pass-zero