Tabindex Management

The `tabindex` attribute controls whether an element can participate in keyboard focus navigation and, in some cases, its position in the sequential focus order. Frontend code should generally rely on native interactive elements and avoid positive `tabindex` values because they create a fragile custom focus sequence.

An element with `tabindex="0"` can participate in sequential keyboard navigation at its natural position in the document's focus order. This is useful when a custom interactive element genuinely needs keyboard focus, although using a native control such as `<button>` is usually preferable.

A negative value such as `tabindex="-1"` makes an element focusable by script with methods such as `element.focus()`, while excluding it from normal sequential keyboard navigation. This is commonly useful for programmatically focusing headings, dialogs, or other containers after an interface change.

Positive values such as `tabindex="1"` or `tabindex="2"` explicitly impose ordering among elements with positive tabindex values. This can conflict with the document's natural order and becomes difficult to maintain as the page changes, so it should generally be avoided.

Native interactive elements already have appropriate keyboard-focus behavior in normal circumstances. Before adding `tabindex`, prefer semantic HTML such as `<button>`, ``, `<input>`, and `<select>`, because focusability alone does not provide the expected keyboard interaction or accessibility semantics.

When focus needs to move programmatically, manage it deliberately and ensure that the resulting focus location is logical for keyboard and assistive-technology users. A good implementation keeps DOM order, visual order, and focus order aligned whenever practical.

Key points

• Prefer native interactive elements over adding `tabindex` to generic elements.
• Use `tabindex="0"` when a custom focusable element must join normal sequential keyboard navigation.
• Use `tabindex="-1"` for elements that need programmatic focus but should not enter normal Tab navigation.
• Avoid positive `tabindex` values because they create a custom focus sequence that is hard to maintain.
• Focusability does not automatically provide keyboard behavior or semantic meaning.

Interview questions

What does `tabindex` do?

`tabindex` controls an element's participation in keyboard focus navigation. A value of `0` allows sequential keyboard navigation, while a negative value can allow programmatic focus without normal Tab navigation. Positive values create an explicit ordering among positively indexed elements. The attribute does not by itself make a generic element behave like a button or link.

When would you use `tabindex="-1"`?

Use `tabindex="-1"` when an element needs to be focusable through script but should not be reached through ordinary Tab navigation. A common example is moving focus to a dialog container or status heading after an interface transition. Calling `focus()` can then place keyboard focus on that element. The implementation should still ensure that the new focus location is logical and understandable.

Why are positive `tabindex` values discouraged?

Positive values create an explicit focus sequence that can diverge from the document's natural order. As content is added or reordered, the manually assigned numbers can become inconsistent and require ongoing maintenance. They can also produce a confusing experience when visual, DOM, and keyboard orders disagree. In most cases, arranging the DOM correctly and using native controls avoids the need for positive values.

Is adding `tabindex="0"` to a `` enough to make it an accessible button?

No. `tabindex="0"` makes the `div` reachable through sequential keyboard focus, but it does not give the element button semantics or the expected keyboard activation behavior. A native `<button>` is normally the appropriate solution because the browser supplies the semantic role and interaction model. If a custom control is unavoidable, its keyboard behavior, semantics, state, and focus management all need to be implemented correctly.

How would you manage focus after opening and closing a modal dialog?

When opening the dialog, focus should move to an appropriate element inside the dialog, or to the dialog itself when that is the deliberate focus target. The dialog should constrain keyboard interaction appropriately while it is active, including handling Tab navigation according to the chosen dialog implementation. When it closes, focus should normally return to the control that opened it, provided that control still exists and is appropriate. The implementation should avoid leaving focus on a removed or hidden element.