Tabindex Checker
Paste your page HTML and find tabindex values that yank keyboard focus out of source order — positive ranks fail WCAG 2.4.3.
What this tool gives you
Check tabindex
Paste your page HTML. Analysis runs locally in your browser — nothing is sent anywhere.
Positive tabindex values create a second tab sequence. Prefer DOM order, tabindex="0" for custom widgets, and tabindex="-1" only to make something programmatically focusable.
What this checker looks for
tabindex="1" is almost never the right fix — it is the most common way sites scramble keyboard order.
Positive values
Any tabindex greater than 0 hijacks focus order (WCAG 2.4.3).
Multiple ranks
tabindex="1", "2", "3" invent a second sequence nobody can see.
Custom widgets
tabindex="0" on a div/span needs a role and keyboard handlers.
Native controls
Links, buttons and inputs already tab — do not restamp them.
tabindex="-1"
Fine for skip-target containers and dialogs opened by script.
0–100 score
Track the cleanup across templates, not just the homepage.
How to fix scrambled tab order
Three rules cover almost every tabindex bug in the wild.
Delete positive values
Remove every tabindex greater than 0. Reorder the DOM if the visual order is the problem.
Use 0 for widgets
Custom controls get tabindex="0" plus a role and keyboard handlers — or become a real <button>.
Reserve -1 for script
tabindex="-1" is for skip targets and dialogs you focus in JavaScript, not for hiding buttons.
Why answer engines care about tab order
Predictable keyboard paths are a cheap-to-parse signal of overall accessibility discipline.
| Signal | What engines infer | Why it helps |
|---|---|---|
| No positive tabindex | The site trusts source order. | Correlates with other quality signals engines read. |
| Named custom widgets | Non-native controls were designed, not forgotten. | Consistent conventions make parsing predictable. |
| Working skip path | Keyboard users can jump past chrome. | Engagement quality feeds crawl and ranking models. |
| Matching visual order | What you see is what Tab visits. | Usable UI lowers abandonment on AI-referred visits. |
| WCAG 2.4.3 pass | The page meets a named accessibility criterion. | Citable, trustworthy pages get quoted more often. |
Related GEO pages
Tab order pairs with focus outlines and skip links to keep keyboard paths usable.
Focus Outline Checker
Find outline:none resets and missing keyboard focus indicators.
Skip Link Checker
Verify the skip-to-content link, its target id and tab order.
Duplicate ID Checker
Find colliding ids that break labels, skip links and fragments.
Tools Lab
More generators, calculators and GEO workflows.
Tabindex FAQs
Why is tabindex greater than 0 a problem?
Positive tabindex values pull those elements to the front of the keyboard sequence, ahead of everything that follows source order. Keyboard users jump to the stamped controls first, then fall into the rest of the page — a WCAG 2.4.3 (Focus Order) failure that also confuses skip links and forms.
When is tabindex="0" correct?
Use it only to put a custom widget into the natural tab order — a div that behaves like a button, a custom listbox, a canvas control. Pair it with a role and keyboard handlers. Native <a>, <button> and form fields already tab; restamping them is noise.
What about tabindex="-1"?
Negative tabindex removes an element from sequential tabbing but keeps it programmatically focusable. That is the right pattern for skip-link targets, dialog containers and elements you focus with script after an action. It is not a way to hide interactive controls from keyboard users.