Part of the Accessibility audit
Check your tab order for keyboard users
Positive tabindex values force elements to the front of the tab queue. This makes keyboard navigation jump around the page in confusing ways.
No signup required. Results in under 60 seconds.
What this check does
SiteCurl scans every element on your pages for tabindex attributes with positive values (1, 2, 3, and so on). These values override the natural tab order, which follows the order elements appear in the HTML. Positive tabindex forces an element to the front of the tab queue, regardless of where it sits on the page.
The check reports how many elements have positive tabindex values and shows up to five examples with their tag name and tabindex value. This tells you exactly which elements are overriding the natural order.
Elements with tabindex='0' (adds to normal order) and tabindex='-1' (focusable by script only) are fine and not flagged. Only positive values are a problem.
How this shows up in the real world
Keyboard navigation follows a predictable pattern. The user presses Tab, and focus moves to the next interactive element in the order it appears in the HTML source. Top to bottom, left to right (in left-to-right languages). This matches what users see on screen and is easy to follow.
Positive tabindex breaks this pattern. An element with tabindex='1' receives focus before everything else on the page, regardless of where it appears in the source. An element with tabindex='2' comes next. After all positive values are exhausted, the browser returns to normal source order for elements with tabindex='0' or no tabindex.
The result is a tab order that jumps around the page: maybe a search box in the sidebar first, then a button in the footer, then finally the navigation at the top. The user cannot predict where focus will go next. Every Tab press is a surprise.
This problem gets worse as pages grow. A developer adds tabindex='1' to one element. Later, another developer adds tabindex='2' to a different element on a different page. Over time, the tab order becomes a maze that no one understands and no one can follow without reading the source.
Why it matters
Keyboard users rely on a predictable tab order to navigate pages. When focus jumps around, they lose track of where they are on the page. They may tab past the element they need without realizing it, or end up in a section they did not expect to visit.
Screen reader users are affected the most. They cannot see where focus moved to. They only know the current element. If Tab jumps from the header to the footer, they do not know they skipped the main content unless they go back and check manually.
Maintaining positive tabindex values across a site is also a developer burden. Every time the page changes, someone has to update the tabindex numbers. This is fragile, error-prone, and rarely worth the effort. The natural source order is almost always the right tab order.
Who this impacts most
Sites built with legacy code are the most likely to have positive tabindex values. Older development practices sometimes used tabindex to control form field order instead of rearranging the HTML. These values often persist through redesigns and template changes.
Sites using older form builders or page editors may inject positive tabindex values automatically. Some WordPress plugins from the early 2010s set tabindex on form fields as a default behavior.
Custom web applications that tried to create specific keyboard workflows sometimes used positive tabindex to force a particular focus path. This made sense for the original design but breaks when the page is updated or used in ways the developer did not expect.
How to fix it
Step 1: Remove positive tabindex values. For most elements, simply removing the tabindex attribute is the fix. The element will fall into the natural tab order based on its position in the HTML. If you need an element to be focusable, use tabindex='0' instead.
Step 2: Reorder the HTML source. If the tab order feels wrong after removing tabindex, the HTML source order does not match the visual layout. Fix the source order so it follows the visual flow. Use CSS (flexbox order, grid placement) for visual positioning instead of relying on tabindex for focus order.
Step 3: Use tabindex='0' for custom interactive elements. If you have a div or span that needs to be focusable (because it has an ARIA role), use tabindex='0'. This adds it to the natural tab order at the point where it appears in the source.
Step 4: Use tabindex='-1' for programmatic focus. If an element should only receive focus from JavaScript (like a modal dialog that opens on button click), use tabindex='-1'. This makes it focusable by script but keeps it out of the Tab sequence.
Common mistakes when fixing this
Using tabindex to fix a layout problem. If elements tab in the wrong order, the problem is the HTML source order, not the tabindex values. Fix the source so it matches the visual layout. Positive tabindex is a patch that creates more problems than it solves.
Setting tabindex='1' on a 'priority' element. Developers sometimes add tabindex='1' to an important element like a search box. This makes it first in the tab order, but it also pushes every other element down. The user has to Tab through everything else in an unexpected order.
Incrementing tabindex across the page. Setting tabindex='1', '2', '3' on consecutive elements feels organized but is extra. If the HTML source order is correct, these elements would already tab in that order with no tabindex at all.
Mixing positive and zero tabindex. Elements with positive values go first. Elements with tabindex='0' or no tabindex go after. This creates two groups with an confusing boundary between them. Stick to tabindex='0' and '-1' only.
How to verify the fix
After removing positive tabindex values, run another SiteCurl scan. The positive tabindex count should drop to zero. For a manual check, press Tab repeatedly on your page and confirm that focus moves in a logical order from top to bottom, following the visual layout.
Open your browser's developer tools, go to the Elements panel, and search for tabindex. Check that no element has a value greater than 0. Values of 0 and -1 are fine.
The bottom line
Positive tabindex values break the natural tab order and make keyboard navigation confusing. Remove them. Use the HTML source order to control focus sequence, tabindex='0' to add custom elements to the tab order, and tabindex='-1' for elements that should only be focused by script.
Example findings from a scan
3 elements with positive tabindex values on /contact
input[tabindex='2'] found on /signup
div[tabindex='1'] overrides tab order on /
Related checks
Frequently asked questions
What is wrong with positive tabindex values?
Positive tabindex values force elements to the front of the tab queue, regardless of where they are on the page. This makes focus jump around unpredictably for keyboard users.
What is the difference between tabindex='0' and tabindex='1'?
tabindex='0' adds an element to the natural tab order at the position where it appears in the HTML. tabindex='1' forces the element to receive focus before all elements with tabindex='0' or no tabindex. Use 0, never positive values.
When should I use tabindex='-1'?
Use tabindex='-1' for elements that should only receive focus from JavaScript, not from Tab key navigation. Common uses: modal dialogs that receive focus when opened, error messages that get focus after form submission, and headings that receive focus from skip links.
Can I check tabindex without signing up?
Yes. The free audit checks for positive tabindex values in a full seven-category scan. No signup needed.
Check your tab order now