Positive tabindex values disrupt focus order
Automated check tabindex, run with axe-core
- WCAG
- Best practice: a recommendation, not a WCAG success criterion
- Severity
- Serious: completable, but painful
- Typical effort
- Moderate, 1 to 4 hours
- Category
- Keyboard
Who this affects
Keyboard-only users.
Why it matters
Any tabindex above 0 pulls the element to the front of the tab order across the whole page, producing a focus sequence that jumps unpredictably and does not match the visual layout.
How to fix it
Use only tabindex="0" (focusable, in natural order) or tabindex="-1" (focusable by script only). Fix ordering by changing DOM order instead.
Check your own website
The free scan tests 3 pages against WCAG 2.2 A and AA in about 30 seconds. No sign-up.
Related checks: Keyboard
- Duplicate access keys
- Hidden elements can still receive keyboard focus
- Elements with role="text" contain focusable content
- No way to skip repeated navigation
- Focusable elements have no suitable role
- Frames with interactive content cannot be reached by keyboard
- Scrollable areas cannot be reached by keyboard
- Skip links point to nothing