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.
Related terms
Help us improve this glossary term
Scan your site
Rocket Validator scans thousands of pages in seconds, detecting accessibility and HTML issues across your entire site.