Skip to main content
HTML

tabindex Attribute

  • HTML attribute
  • keyboard navigation
  • focus management
  • interactive elements
  • tab order

The tabindex attribute is a global HTML attribute that can be applied to any element to influence how it participates in keyboard navigation. By default, only interactive elements like <a>, <button>, <input>, <select>, and <textarea> are included in the tab order. The tabindex attribute gives developers the ability to make non-interactive elements focusable, remove elements from the tab order, or programmatically manage focus — all of which are critical for building accessible web experiences.

The attribute accepts an integer value, and its behavior varies significantly depending on whether that value is negative, zero, or positive. Understanding these three modes is essential for anyone working with keyboard accessibility, as misuse of tabindex is one of the most common sources of confusing and inaccessible tab order on the web.

Why the tabindex attribute matters

Keyboard navigation is foundational to web accessibility. Users who rely on keyboards, switch devices, or screen readers depend on a logical and predictable tab order to move through a page. The tabindex attribute directly controls this experience, making it a powerful but potentially dangerous tool.

When used correctly, tabindex enables developers to create custom interactive widgets — such as dropdown menus, modals, and tab panels — that are fully operable via keyboard. Without it, custom components built from <div> or <span> elements would be completely unreachable by keyboard users, violating WCAG 2.1 Success Criterion 2.1.1 (Keyboard) and Success Criterion 2.4.3 (Focus Order).

When used incorrectly — particularly with positive values — tabindex can create a disjointed, unpredictable tab order that confuses all keyboard users, including those using assistive technologies. A page where focus jumps erratically between unrelated sections is disorienting and can make content effectively unusable for people with motor or cognitive disabilities.

How the tabindex attribute works

tabindex="0" — Add to natural tab order

Setting tabindex="0" on an element makes it focusable and places it in the natural document tab order (determined by its position in the DOM). This is the most common and recommended use of tabindex for making custom interactive elements keyboard-accessible.

tabindex="-1" — Programmatically focusable only

A value of -1 (or any negative integer) makes an element focusable via JavaScript using the focus() method, but removes it from the sequential tab order. Users cannot reach the element by pressing Tab. This is useful for managing focus in components like modals and focus traps, where you need to move focus to an element without placing it in the regular tab flow.

Positive tabindex values — Avoid these

A positive value (e.g., tabindex="1", tabindex="5") places the element ahead of all elements with tabindex="0" or no tabindex in the tab order. Elements with positive values are visited first, in ascending numeric order, before the natural DOM order takes over. While this might seem useful, it almost always leads to a confusing and fragile tab order. The WCAG and WAI-ARIA authoring practices strongly discourage using positive tabindex values.

Interaction with semantic HTML

Interactive HTML elements like <button> and <a href="..."> are natively focusable and already included in the tab order — there is no need to add tabindex="0" to them. Relying on semantic HTML whenever possible reduces the need for tabindex altogether and ensures built-in keyboard behavior, focus indicators, and screen reader announcements work without extra effort.

Code examples

Bad example — Positive tabindex creating unpredictable order

In this example, positive tabindex values force the "Submit" button to be focused before the input fields, which is confusing for users:

<form>
  <label for="name">Name</label>
  <input type="text" id="name" tabindex="2">

  <label for="email">Email</label>
  <input type="email" id="email" tabindex="3">

  <button type="submit" tabindex="1">Submit</button>
</form>

A keyboard user pressing Tab would focus "Submit" first, then "Name", then "Email" — the opposite of the visual and logical order.

Good example — Using natural DOM order with tabindex="0"

Let the DOM order determine the tab sequence. If you need a custom element to be focusable, use tabindex="0":

<form>
  <label for="name">Name</label>
  <input type="text" id="name">

  <label for="email">Email</label>
  <input type="email" id="email">

  <button type="submit">Submit</button>
</form>

No tabindex is needed here because all elements are natively interactive. The tab order follows the DOM naturally.

Bad example — Non-focusable custom button

A <div> styled to look like a button is unreachable by keyboard:

<div class="btn" onclick="submitForm()">
  Submit
</div>

Good example — Making a custom widget focusable

If you must use a non-interactive element as a control, add tabindex="0" along with the appropriate ARIA role and keyboard event handlers:

<div class="btn" role="button" tabindex="0" onclick="submitForm()" onkeydown="handleKeydown(event)">
  Submit
</div>

Even better, use a semantic <button> element instead to get focus, keyboard interaction, and screen reader support for free:

<button type="button" class="btn" onclick="submitForm()">
  Submit
</button>

Good example — Using tabindex="-1" for focus management

When opening a modal dialog, move focus to the dialog container without adding it to the tab order:

<div id="modal" role="dialog" aria-labelledby="modal-title" aria-modal="true" tabindex="-1">
  <h2 id="modal-title">Confirm Action</h2>
  <p>Are you sure you want to proceed?</p>
  <button type="button">Yes</button>
  <button type="button">No</button>
</div>

<script>
  document.getElementById("modal").focus();
</script>

The tabindex="-1" allows JavaScript to move focus to the modal container when it opens, while the user's subsequent Tab presses move naturally to the interactive elements inside.

Help us improve this glossary term

Was this guide helpful?

Scan your site

Rocket Validator scans thousands of pages in seconds, detecting accessibility and HTML issues across your entire site.

🌍 Trusted by teams worldwide

Validate at scale.
Ship accessible websites, faster.

Automated HTML & accessibility validation for large sites. Check thousands of pages against WCAG guidelines and W3C standards in minutes, not days.

Scheduled Reports
API Access
Open Source Standards
$7 / 7 days

Pro Trial

Full Pro access. Cancel anytime.

Start Pro Trial →

Join teams across 40+ countries