Check your tab order for keyboard users

SiteCurl scans each tag on your pages for tabindex values above zero (1, 2, 3, and so on). These values override the natural tab order, which follows how tags appear in the HTML. A positive tabindex forces a tag to the front of the tab queue, no matter where it sits on the page.

The check reports how many tags have positive tabindex values and shows up to five samples with their tag name and tabindex value. This tells you exactly which tags are overriding the natural order.

Tags with tabindex='0' (joins normal order) and tabindex='-1' (focusable by script only) are fine and not flagged. Only positive values are a problem.

Keyboard nav follows a clear pattern. The user presses Tab, and focus moves to the next item in the order it appears in the HTML source. Top to bottom, left to right. This matches what users see on screen and is easy to follow.

Positive tabindex breaks this flow. A tag with tabindex='1' gets focus before all else on the page, no matter where it sits in the source. A tag with tabindex='2' comes next. After all positive values are used up, the browser goes back to normal source order for tags with tabindex='0' or no tabindex.

The result is a tab order that jumps around: maybe a search box in the sidebar first, then a button in the footer, then the nav at the top. The user cannot guess where focus will go next. Each Tab press is a surprise.

This gets worse as pages grow. One dev adds tabindex='1' to a tag. Later, a second dev adds tabindex='2' to a new tag on a new page. Over time, the tab order turns into a maze that no one grasps and no one can follow without reading the source.

Keyboard users rely on a stable tab order to move through pages. When focus jumps around, they lose track of where they are. They may tab past the tag they need without knowing it, or end up in a section they did not mean to visit.

Screen reader users are hit the hardest. They cannot see where focus moved. They only know the current tag. If Tab jumps from the header to the footer, they do not know they skipped the main content unless they go back and check.

Keeping positive tabindex values across a site is also a dev burden. Each time the page changes, someone has to update the numbers. This is fragile, error-prone, and rarely worth the work. The natural source order is almost always the right tab order.

Sites built with old code are most likely to have positive tabindex values. Older dev habits used tabindex to control form field order instead of fixing the HTML. These values often live on through redesigns and template changes.

Sites using older form builders or page editors may inject positive tabindex values on their own. Some WordPress plugins from the early 2010s set tabindex on form fields as a default action.

Custom web apps that tried to build exact keyboard flows used positive tabindex to force a focus path. This made sense for the first design but breaks when the page is changed or used in ways the dev did not plan.

Step 1: Remove positive tabindex values. For most tags, just delete the tabindex prop. The tag will fall into the natural tab order based on its spot in the HTML. If you need a tag to be focusable, use tabindex='0' instead.

Step 2: Fix the HTML source order. If the tab order feels wrong after removing tabindex, the HTML source order does not match the visual layout. Fix the source so it follows the visual flow. Use CSS (flexbox order, grid) for visual placement instead of tabindex for focus order.

Step 3: Use tabindex='0' for custom live tags. If you have a div or span that needs focus (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 script-only focus. If a tag should only get focus from JS (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.

Using tabindex to fix a layout problem. If tags 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 issues than it solves.

Setting tabindex='1' on a 'top' tag. Devs may add tabindex='1' to a key tag like a search box. This makes it first in the tab order, but it also pushes all other tags down. The user has to Tab through all else in a strange order.

Counting up tabindex across the page. Setting tabindex='1', '2', '3' on tags in a row feels tidy but is overkill. If the HTML source order is right, these tags would already tab that way with no tabindex at all.

Mixing positive and zero tabindex. Tags with positive values go first. Tags with tabindex='0' or no tabindex go after. This creates two groups with a confusing split. Stick to tabindex='0' and '-1' only.

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.

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.