Keyboard & focus
An Element Has a Tabindex Greater than Zero
A positive `tabindex` forces that element to the front of the Tab order, so keyboard users jump around the page in a confusing order.
tabindexBest practiceBest practice — not a WCAG requirement, but it helps people all the same.
- Status
- SeriousSerious — Significant friction, or information that is lost.CurrentScanners run this rule today.
- Owner
- DesignDevTest
- Audit
- Automated+ManualA scanner finds it; a person confirms the fix.
Why it matters
Keyboard users press Tab to move from one control to the next. Normally that follows the order of the page. A tabindex of 1 or more pulls that element ahead of everything else.
Focus then leaps around the page. People lose their place, miss content, or think controls are missing. It also breaks easily as the page changes, because every positive number must be kept in step by hand.
Who it affects
| Who | What they experience | Impact |
|---|---|---|
| Screen reader users | They hear controls out of order, out of context from the content around them. | High impact |
| Keyboard-only users | Pressing Tab jumps to odd places first, then back to the start, so the order makes no sense. | High impact |
| Motor and dexterity | Switch and keyboard users waste extra presses getting past the out-of-order items. | High impact |
| Low-vision users (magnification) | Zoomed in, focus jumps off screen to places they weren't looking. | Partial impact |
| Cognitive and neurodivergent users | An unpredictable order makes it hard to keep track of where they are. | Partial impact |
Business & product impact
| Area | Why | Impact |
|---|---|---|
| Legal | This rule is a best practice, not a WCAG requirement on its own. But a confusing focus order often fails WCAG 2.2 Level AA, which complaints under Australia's Disability Discrimination Act point to. | Moderate impact |
| Conversion | If Tab skips past form fields or the checkout button, keyboard users may give up. | Moderate impact |
| SEO | No search benefit at all. | Low impact |
| Brand trust | A page that is awkward to tab through feels broken to the people who rely on it. | Low impact |
| Cost to fix | Positive numbers must be renumbered every time the page changes. Removing them is cheap and saves upkeep. | High impact |
Fixing it in code
A search box pushed to the front
Don't
<input type="search" aria-label="Search" tabindex="1">A screen reader says: “Search, search field — reached first, before the logo and menu above it”
Do
<input type="search" aria-label="Search">A screen reader says: “Search, search field — reached in its place on the page”
Without tabindex, focus follows the page order, which matches what people see.
Making a custom control focusable
Don't
<div role="button" tabindex="3">Add to cart</div>A screen reader says: “Add to cart, button — reached out of order”
Do
<button type="button">Add to cart</button>A screen reader says: “Add to cart, button — reached in order”
A real button is focusable already. If you must use a div, use tabindex="0", never a higher number.
Designer's handoff note
Want something reached first? Put it first in the layout and the code. Don't ask developers to reorder focus with numbers.
Note the intended Tab order on your designs for complex screens.
Quick test
Tool
The keyboard alone
Checklist
- Pass
- Focus moves through the page in the same order you'd read it.
- Fail
- Focus jumps to a control further down, then back to the top.
What a green scan still misses
A scanner finds positive tabindex values. It can't judge whether the focus order makes sense in other ways, such as when CSS moves things around visually — tab through it yourself.
Reference
- Rule ID
tabindex- Raised by
- axe-core: “Elements should not have tabindex greater than zero”
- WCAG
- Best practice — not a WCAG requirement
- Last reviewed
- 14 October 2026