Short answer: tabindex decides whether an element can take keyboard focus and where it falls when people press Tab. Use 0 to add a custom control to the normal order and -1 for elements you focus with a script. Avoid positive values: they reorder the page.
What each tabindex value does
| Value | What it does | When to use it |
|---|---|---|
| tabindex="0" | Adds the element to the Tab order, in the order of the code | A custom control with no native element |
| tabindex="-1" | Takes it out of the Tab order; a script can still focus it | An error message or a section you send the focus to |
| tabindex="1" or more | Moves it ahead of every other Tab stop | Never; fix the order of the code instead |
| No tabindex | Links, buttons, form fields and summary keep their own place | Almost everything on a page |
From MDN, web.dev and WebAIM, read November 5, 2026.
Any valid tabindex value lets a script or a mouse click focus the element; the value decides whether Tab reaches it. MDN recommends using only 0 and -1.
Why positive values break the order
A positive tabindex puts the element ahead of everything without one, and higher numbers come later. WebAIM says these values must always be avoided, because the order then differs from what people see and what screen readers read.
web.dev adds that this is likely to fail WCAG success criterion 2.4.3, which asks for a focus order that preserves meaning and operability. The fix is in the HTML: put the elements in a logical order and let CSS handle the layout. MDN warns against CSS that reorders focusable elements, such as the order of flex items, for the same reason.
When tabindex="0" is right
tabindex="0" lets an element that can’t take focus, such as a div or a span, join the Tab order. web.dev keeps it for interactive controls: content doesn’t need focus to be read, even a key image.
WebAIM adds that an element presented as a button must also respond to Enter and Space, and usually needs an ARIA role so screen readers know what it is. MDN’s advice is simpler: use a real button, link or form field, which come with their roles and states. Our button or link guide helps you choose, and our what is ARIA guide covers the roles.
tabindex="-1" for focus you move with a script
A value of -1 keeps an element out of the Tab order but lets a script call focus() on it. MDN’s examples are a modal window that gets the focus when it appears and an error message focused after a form is sent with mistakes. A modal built with the dialog element is the exception: MDN says tabindex must not be used on it, and web.dev recommends dialog for modals. Our HTML dialog guide shows how to build an accessible one.
web.dev uses it on pages that swap sections without reloading: give the new section tabindex="-1" and focus it, so keyboard users land where the content changed. WebAIM warns the other way round: never put -1 on a link or button people need to reach. A skip link also moves the focus inside a page; our skip to main content guide shows how to add one.
Roving tabindex in widgets with arrow keys
Some widgets, like a set of tabs or a group of radio buttons, work as one Tab stop, and the arrow keys move the focus inside. The W3C technique for this is the roving tabindex: the active item has tabindex="0" and every other item has -1.
When an arrow key moves the focus, the script sets the old item to -1 and the new one to 0, then calls focus() on it. The W3C notes one benefit: the browser scrolls the newly focused item into view.
How to check the tabindex on a page
- Search the page’s code for tabindex and list each value you find.
- Remove every positive value and fix the order in the HTML instead.
- Take tabindex off links, buttons and form fields, unless it removes one on purpose.
- Replace any div or span with tabindex="0" that acts as a button with a real button.
- Keep -1 for elements you focus with a script, like an error message, and never put it on a dialog element.
- In widgets with arrow keys, check that only one item is a Tab stop at a time.
- Press Tab through the page and check that the order follows the reading order; the full test is in our keyboard navigation guide.
What we found on our own pages
On November 5, 2026, we searched our home page, a guide and the contact page for tabindex, in both languages, as each page loads for a first-time visitor. No element uses a positive value, and none uses tabindex="0" to make something focusable that wasn’t already.
Then we pressed Tab 15 times on each page, and on the home page at phone width too. Every stop came in the order of the page’s code. On a wide screen, the first ten were the two skip links, the logo, the four menu items, the two language links and the theme switch.
The theme switch is an example. It is a button element, so it takes its place in the Tab order without a tabindex.
Before you publish
- No element has a tabindex above 0.
- Links, buttons and form fields carry no tabindex unless one is removed on purpose.
- Every element with tabindex="0" is a control that works with the keyboard.
- Every element with tabindex="-1" is one a script sends the focus to.
- Widgets with arrow keys are a single Tab stop.
- The Tab order follows the reading order.
RememberMost pages need no tabindex at all. Write the HTML in a logical order, use real buttons and links, and keep 0 and -1 for the few places that need them.
We look after the Tab order of the pages we build in our web design service.
Quick answers about tabindex
What does tabindex="0" do?
It puts an element into the normal Tab order, in the order of the page’s source, and lets scripts focus it. Use it on a custom control that has no native element; for anything that acts like a button, a real button is better.
What does tabindex="-1" do?
It takes an element out of the Tab order but still lets a script focus it, for example an error message focused when a form is sent with mistakes. Don’t put it on a dialog element: MDN says tabindex must not be used there.
Why should I avoid positive tabindex values?
A positive value pulls the element ahead of everything else in the Tab order. WebAIM warns that the order then differs from what people see and what screen readers read, and web.dev says it’s likely to fail WCAG success criterion 2.4.3.
Do links and buttons need a tabindex?
No. Links with an href, buttons, form fields and the summary of a details element are already in the Tab order. MDN says to add tabindex to them only to change that, for example -1 to take one out on purpose.
What is a roving tabindex?
A way to make a group of items one Tab stop. The active item has tabindex="0" and the others have -1; the arrow keys move the 0 and the focus to the next item. The W3C notes that the browser then scrolls each focused item into view.
Sources
Read on November 5, 2026. MDN Web Docs: tabindex HTML global attribute. web.dev: Using tabindex. WebAIM: Keyboard Accessibility: Tabindex. W3C Web Accessibility Initiative: Developing a Keyboard Interface and Understanding Success Criterion 2.4.3: Focus Order. Our case: our own pages, read in a browser on November 5, 2026.