Focus order

Silktide finds elements that override the order in which keyboard users move through the page. By default, pressing Tab steps through links and form controls in the order they appear in the page's code; a positive tabindex attribute forces a custom order, which is almost always a mistake.

<!-- Forces this field to be reached before everything else on the page -->
<input tabindex="1" name="search">

Why this matters

Keyboard users expect the Tab key to move through a page in a predictable order that matches what they see. A positive tabindex hijacks that order: focus jumps to the numbered elements first, then back to everything else, which can send leaping around the page. It is also fragile - adding one new element later means renumbering everything - and it commonly breaks when pages change.

How to fix it

Remove positive tabindex values and let the natural order of the determine tabbing order.
If the natural order is confusing, reorder the elements in your HTML (using CSS for visual layout) rather than papering over it with tabindex.
The other tabindex values remain fine and are not flagged:
- tabindex="0" makes an element keyboard-focusable in its natural position, useful for custom controls.
- tabindex="-1" removes an element from Tab navigation, useful for elements focused by script, such as dialogs.

How Silktide tests this

Find every element on the page with an explicit tabindex attribute.
Flag each element whose tabindex is greater than 0, as a likely problem for you to confirm.
Values of 0 and below are not flagged.

Troubleshooting

We use positive tabindex deliberately

Rarely, a page's code order genuinely cannot match its logical order, and positive tabindex values are the only fix. If you have verified the tab order makes sense by tabbing through the page, you can mark the finding as checked.