probeo

How to fix a tabindex greater than zero?

tabindex page

The issue

An element with tabindex="1" or higher takes focus before everything else on the page. A keyboard user pressing Tab lands on it first, then on any other positive values in ascending order, and only then on the rest of the page in source order. The focus order no longer follows what they see, so they jump from a footer link to a form field and back to the navigation.

The cause is usually an attempt to fix focus order without moving the markup. It works on the day it is set, and breaks as soon as the page changes, because every positive value has to be kept in step with every other one. WCAG 2.4.3 requires a focus order that preserves meaning, and positive tabindex is one of the easiest ways to break it.

Scope

Every visible element with a numeric tabindex is checked. Values above 0 are reported; 0 and -1 pass. A non-numeric value is skipped.

How to check you have it

  • In probeo: the page reports tabindex, “Elements should not have tabindex greater than zero”, as serious. It is a best practice rule rather than a WCAG criterion. The detail shows the value, such as tabindex="3".
  • By hand: search the page source for tabindex= followed by a number from 1 up, then press Tab from the top of the page and watch where focus goes.
  • With a tool: the Accessibility panel in Firefox DevTools can show the tabbing order on the page. axe DevTools has a rule with the same name.

The fix

Remove every positive tabindex and make the source order match the order people should move through the page.

If an element is out of place in the focus order, move it in the markup and position it visually with CSS. Use tabindex="0" to make a custom control focusable in its natural place, and tabindex="-1" for an element that should take focus only from a script, such as a dialog’s heading.

<!-- before -->
<input id="search" tabindex="1">

<!-- after: placed first in the markup instead -->
<input id="search">

Done when: no element has a tabindex above 0, focus moves through the page in reading order, and the check above comes back clean.

Do not

  • Do not renumber positive values to patch the order; remove them.
  • Do not make non-interactive text focusable with tabindex="0" just to have it read.
  • Do not use CSS to reorder content visually so far that it no longer matches the source order.

What the values mean

  • Above 0: focusable, and visited before everything else, in ascending order.
  • 0: focusable, in its natural place in the source order.
  • -1: focusable only from a script or a link to it, and skipped by Tab.

FAQ

Is tabindex 0 ever a problem?

Not for this rule. It is the right value for a custom control, such as a div acting as a button, though a real <button> is better.

Why not just number every element in order?

Because the numbers have to be maintained by hand. Any element added later without a number is visited after all the numbered ones, wherever it sits on the page.

Does a positive tabindex on a hidden element count?

No. Hidden elements are skipped, but the value still takes effect once the element is shown, so remove it anyway.

Which product detects this

Probeo checks this on every page of your site as part of Site Clarity. This page explains one instance; the product tells you every page that has it.