Positive tabindex changes the focus order
keyboard/positive-tabindex
- WCAG success criterion
- 2.4.3 (level A)
- Outcome class
- Hint only. An automated check that by design reports review hints only: its findings are marked for manual review, never as confirmed violations.
- Area
- Accessibility, Navigation & Operation
- Default severity
- high
- axe-core rule
keyboard/positive-tabindex
Why we flag this
Keyboard users reach elements in an order that does not match the page layout.
tabindex value greater than 0.
What the rule checks
Scope. Rendered elements carrying a tabindex attribute that parses as an integer.
Expectation. A rendered element with tabindex greater than 0 is reported once as needs_review: a positive value moves it ahead of the natural order, which fails 2.4.3 only when the resulting order breaks meaning or operation (F44), and that the markup does not show. tabindex 0 and -1 keep the natural order and are not reported; the boundary is 1. A display:none element is in no tab order and is not reported. ARIA widgets (span role=button) and native controls count alike, so do elements in an open shadow root, a value set by script after load, and an element rendered on one viewport only.
Source. WCAG 2.2 SC 2.4.3 Focus Order; failure F44 (tabindex creating a tab order that does not preserve meaning); HTML §6.6.3 the tabindex attribute
Detection: shared; needs dom, computed_style.
This page is generated from the rule catalogue and the rule contracts; see therule overview for how the outcome classes are derived.