tabIndex
This example uses the tabIndex property to specify the tab order for three text fields. In addition, the Submit button is removed by specifying a negative value.
This example uses the tabIndex property to assign a tab order to an unordered list. To cycle through the list’s tab order, the user presses the TAB key. Since the list items can have focus, the focus rectangle surrounds each item the user selects.
Notes
Remarks
The tabIndex value determines the tab order as follows:
- Objects with a positive tabIndex are selected in increasing p order and in source order to resolve duplicates.
- Objects with an tabIndex of zero are selected in source order.
- Objects with a negative tabIndex are omitted from the tabbing order.
An element can have focus if the tabIndex property is set to any valid negative or positive integer. The following elements can have focus and are tab stops by default: a, BODY, button, frame, iframe, img, input, isIndex, object, select, textArea. The following elements can have focus by default but are not tab stops. These elements can be set as tab stops by setting the tabIndex property to a positive integer. applet, div, frameSet, span, table, td. Setting the tHead and tFoot elements to participate in the tab order will not cause the focus rectangle to display when either receives focus. Elements can become part of the accessibility hierarchy if the TABINDEX attribute is set as follows:
- For Microsoft Internet Explorer 5.01 and later, set the TABINDEX attribute to any value.
- For Microsoft Internet Explorer 5, set the TABINDEX attribute to a positive value.
For Internet Explorer 5.01 or above, the attribute may be set to any value in the valid range of -32767 to 32767 . Content of elements with a closing tag can have focus by default, but are not tab stops. As of Internet Explorer 5, you can set the tabIndex property to a valid positive integer to force the content to have a tab stop. Elements that receive focus can fire the onblur and onfocus events as of Microsoft Internet Explorer 4.0, and the onkeydown, onkeypress, and onkeyup events as of Internet Explorer 5.
tabindex
Глобальный атрибут tabindex — целое число, определяющее должен ли данный элемент участвовать в последовательной навигации по всей странице с помощью клавиатуры, в каком порядке. Содержит одно из нескольких видов значений:
- если представлено отрицательное значение – элемент может быть выделен, однако не участвует в последовательной навигации;
- если представлен 0 – элемент может быть выделен и достигнут с помощью последовательной навигации, однако порядок навигации определён платформой;
- если представлено положительное целое значение – элемент будет достигнут (и выделен) с помощью последовательной навигации, а порядок навигации определён этим самым значением. В случае, если несколько элементов содержат одно и то же значение tabindex, их порядок навигации определён относительным расположением в документе (DOM).
Элементы со значением 0, некорректным значением, или элементы с отсутствующим значением tabindex должны быть расположены после элементов с положительным целым числом.
Для более полного объяснения навигации смотри данную статью (en-US) .
What is the HTML tabindex attribute?
![]()
In my mind the second thing is even more important than the first one. There are very few elements that are focusable by default (e.g. <a> and form controls). Developers very often add some JavaScript event handlers (like ‘onclick’) on not focusable elements (<div>, <span> and so on), and the way to make your interface be responsive not only to mouse events but also to keyboard events (e.g. ‘onkeypress’) is to make such elements focusable. Lastly, if you don’t want to set the order but just make your element focusable use tabindex=»0″ on all such elements:
Also, if you don’t want it to be focusable via the tab key then use tabindex=»-1″ . For example, the below link will not be focused while using tab keys to traverse.
![]()
When the user presses the tab button the user will be taken through the form in the order 1, 2, and 3 as indicated in the example below.
![]()
The tabindex is used to define a sequence that users follow when they use the Tab key to navigate through a page. By default, the natural tabbing order will match the source order in the markup.
The tabindex content attribute allows authors to control whether an element is supposed to be focusable, whether it is supposed to be reachable using sequential focus navigation, and what is to be the relative order of the element for the purposes of sequential focus navigation. The name «tab index» comes from the common use of the «tab» key to navigate through the focusable elements. The term «tabbing» refers to moving forward through the focusable elements that can be reached using sequential focus navigation.
W3C Recommendation: HTML5
Section 7.4.1 Sequential focus navigation and the tabindex attribute
The tabindex starts at 0 or any positive whole number and increments upward. It’s common to see the value 0 avoided because in older versions of Mozilla and IE, the tabindex would start at 1, move on to 2, and only after 2 would it go to 0 and then 3. The maximum integer value for tabindex is 32767 . If elements have the same tabindex then the tabindex will match the source order in the markup. A negative value will remove the element from the tab index so it will never be focused.
If an element is assigned a tabindex of -1 it will remove the element and it will never be focusable but focus can be given to the element programmatically using element.focus() .
If you specify the tabindex attribute with no value or an empty value it will be ignored.
If the disabled attribute is set on an element which has a tabindex , the element will be ignored.
If a tabindex is set anywhere within the page regardless of where it is in relation to the rest of the code (it could be in the footer, content area, where-ever) if there is a defined tabindex then the tab order will start at the element which is explicitly assigned the lowest tabindex value above 0. It will then cycle through the elements defined and only after the explicit tabindex elements have been tabbed through, will it return to the beginning of the document and follow the natural tab order.
In the HTML4 spec only the following elements support the tabindex attribute: anchor, area, button, input, object, select, and textarea. But the HTML5 spec, with accessibility in mind, allows all elements to be assigned tabindex .
For example
because regardless of the fact that they are all assigned tabindex=»1″ , they will still follow the same order, the first one is first, and the last one is last. This is also the same..
because you do not need to explicitly define the tabIndex if it’s default behavior. A div by default will not be focusable, the anchor tags will.
Use the tabindex attribute
By: Eric Bailey . Published: January 28, 2021 .
Table of Contents
tabindex is a global attribute that allows an HTML element to receive focus. It needs a value of zero or a negative number in order to work in an accessible way.
When tabindex ’s value is set to zero or a positive number, the element can be navigated to via the keyboard’s Tab key. When it is set to a negative number, its element can be programmatically focused via JavaScript.
Common mistakes
Unfortunately, the tabindex attribute is often misunderstood and consequently misused. Following are some common examples of tabindex use that have a negative impact on accessibility:
Using a positive tabindex value
Using tabindex with a value of 1 , 2 , 3 , etc. places the element the tabindex is applied first in the keyboard tabbing order. This can create a confusing experience for anyone who relies on the keyboard’s Tab key to navigate.

Setting a manual tab order
You don’t need to manually set tab order for every page or view on a website or web app. Not only is this extra, unnecessary work that is difficult to maintain, it may deviate from someone’s expected or desired way to navigate. This results an annoying, confusing, and potentially inaccessible experience.

Instead, use appropriate interactive elements ( a for links, button for buttons, etc.) and put them in the reading order of the document. Interactive elements come with native browser behavior already built in that allows them to be navigated to via Tab without the need for a tabindex declaration.
Making non-interactive elements focusable
There is a myth that applying tabindex="0" to non-interactive elements (paragraphs, headings, lists, etc.) helps “improve” accessibility by providing a way for a person who uses a screen reader to focus on all the content present in a webpage or web app. Unfortunately, this well-intentioned idea actually does not create a good assistive technology experience.
In the same way that you don’t need to add a tabindex attribute declaration to native interactive elements, you also don’t need to add a tabindex attribute to non-interactive elements for them to work with assistive technologies.

The reason for this is that assistive technologies such as screen readers have other, expected ways of navigating through, and consuming this content. Because of this, adding a tabindex attribute to non-interactive elements creates a few problems. It:
- Adds confusion about what is and what is not actually interactive, especially if you cannot see the screen.
- Requires extra work for people using keyboards to navigate (and in particular, people who use keyboards who are not using assistive technologies), especially those who have have a motor control disability.
- May not announce the element’s name and role, which creates additional confusion about what the element is, how it is supposed to work, and whether or not it has been coded properly.
tabindex declared on a non-interactive element nested inside of an interactive element
You do not need to declare tabindex on a child element, provided its parent element is an interactive element. An example of this would be a span element nested inside of a button :

The presence of the tabindex attribute in this code example would affect the order of interactive elements in an illogical way. This creates an annoying and potentially confusing experience for people using keyboards or assistive technology.
Acceptable uses for tabindex
Following are some of the more common cases where you do need to use tabindex . In these scenarios it enables the content to be accessible.
Interactive JavaScript widgets and charts
Declarations of tabindex="-1" can sometimes be found on interactive widgets and components that manage focus internally, such as comboboxes or trees, as it allows JavaScript to focus on the element via the focus() method.

Scrollable overflow containers
tabindex="0" should be applied to any non-interactive element that has had CSS’ overflow property applied to it. This will allow people using a keyboard to navigate to, and scroll around the overflowed content.

You will also need to provide:
- A label that concisely describes the contents placed within the non-interactive element. The label can either be provided by:
- An id / aria-labelledby association if it has a visible heading, or
- An aria-label , if not.
- An applicable sectioning element, or
- A Landmark Role if the content is important enough that people need a quick and easy way to return to it.
- A group role can also be used if there isn’t a need for quick access.
This satisfies WCAG criterion 4.1.2: Name, Role, Value. It allows people to scroll using a keyboard, as well as providing an indication on why they should scroll, and what content they can expect to find within.
When there is not an applicable HTML element
Interactive controls that don’t have a relevant HTML element need a declaration of tabindex="0" . An example of this would be a listbox, a widget that “presents a list of options and allows a user to select one or more of them.”

Hopefully this provides enough information to treat tabindex in a responsible, accessible way.