WCAG 2.4.3 (A)
Elements use positive tabindex values
What this failure is
The tabindex attribute controls the order in which pressing Tab moves focus between elements. Values of 0 and -1 are useful and safe: 0 puts an element into the natural tab order, -1 keeps it focusable by script but out of the tab order. Positive values (1, 2, 3...) are almost always a mistake. They rip the element out of the natural DOM order and insert it into a special "positive tabindex" queue that runs before everything else. That means a form field with tabindex="1" will be tabbed to before your header logo, and if you set tabindex="1" through tabindex="5" on five fields, the user's Tab key jumps between them and skips over any Save button that lives at tabindex="0". This is confusing for everyone and disastrous for anyone who cannot use a mouse.
Reference: WCAG 2.4.3 (A) — the authoritative spec.
Who it affects
- Keyboard-only users: Focus jumps to unexpected elements out of visual order; users lose track of where they are, and controls that should be reachable become effectively hidden.
- Screen reader users: Reading order and focus order diverge — the screen reader reads the page in DOM order but Tab jumps around, so the two mental models never match.
- Switch and voice users: Assistive tech that walks the tab order (switch scanning, voice control's number overlay) exposes the broken sequence to users, who then cannot predict what any command will do.
How to fix it
Concrete steps for the four platforms most small e-commerce sites run on. If you use a different stack, the underlying HTML change is the same.
Shopify
Search your theme's liquid files for the string tabindex=" and remove any tabindex value greater than 0. In Online Store > Themes > Edit code use the search box in the top-right and search for tabindex="1 (repeat for 2, 3, 4, 5). The correct fix is almost always to delete the whole attribute; if you actually need to reorder focus, reorder the elements in the DOM instead. Positive tabindex most often appears in old contact forms and popup templates copied from decade-old code snippets.
WooCommerce
Search your theme and any custom snippets for tabindex=. Open your active theme in Appearance > Theme File Editor, click each file, and use the browser's find-in-page shortcut. Third-party plugins that add complex forms (Gravity Forms, WPForms) sometimes offer a per-field tabindex setting — set them all to 0 or leave them blank. Never use positive tabindex to force a specific order in a form; reorder the fields in the form builder instead.
Wix
The Wix editor does not expose a tabindex control, so positive tabindex on a Wix site almost always comes from Custom Code injected via Settings > Custom Code, or from an Embed HTML element containing pasted JavaScript. Remove or fix that code. Wix's built-in tab order follows the visual layout, which is what you want.
Squarespace
Squarespace does not expose tabindex in the UI, so if this rule fires it is code you pasted into a Code block or into Settings > Advanced > Code Injection. Edit the offending block and either delete the tabindex attributes or set them all to 0. Reorder the elements in the DOM if you need a specific focus sequence — that fixes the problem for both sighted and non-sighted users. Squarespace's own generated markup does not use positive tabindex anywhere, so a positive-tabindex finding on a Squarespace site is always custom code.
Notes
tabindex="-1" is fine and often correct — it makes an element focusable via JavaScript (for example when opening a dialog) without adding it to the tab order. tabindex="0" is fine on custom widgets that need to be tabbable. Anything above zero should almost never appear in production HTML. The one narrow exception is a page with a genuinely custom interaction pattern that a specialist has justified with user testing — if you did not write that user testing yourself, you almost certainly do not have the exception.
Check your own site
Our accessibility statement scan is free and reports findings only — we do not certify sites.