Posted on Thursday, 4 April 2024 by Graeme Coleman in Design and development

Tags: Assistive Technology, Code, WCAG

When tabindex="0" is applied to an HTML element, the content marked up using that element will become keyboard focusable, and is therefore a good starting point for supporting keyboard accessibility. However, applying this attribute haphazardly or unnecessarily can reduce the experience for people who use a keyboard or an equivalent input device to navigate web content.

What is meant by keyboard focus

When a web page includes interactive controls such as buttons, links, and form fields, it is important that they are focusable. Unless a keyboard accessible alternative is provided, these elements must be reachable using the keyboard alone. This is important for people browsing with a desktop screen reader and people browsing with a keyboard or other input device.

People navigate focusable controls on a web page using the Tab and Shift + Tab keys or, for some controls like radio buttons, the arrow keys. When they reach each control, that control is said to have focus. Subsequently, and assuming the control is coded correctly, a person can then interact with it.

Focus handling in HTML

Most HTML elements intended for identifying interactive controls, such as the <button> element for buttons, are already focusable by default. Therefore, developers do not need to include additional markup to achieve this.

On the other hand, HTML elements intended for presenting and organising static content, such as text and images, are not focusable. This is for good reason. Static content is not, by definition, interactive. For example, clicking or tapping on a paragraph of text generally has no effect, unless that text is part of a link.

However, the line between only using interactive HTML elements for marking up interactive content and only using static HTML elements for marking up static content has become increasingly blurred. Indeed, developers will often build their own custom interactive controls using static HTML elements, such as the <div> and <span> elements, and then attach an appropriate JavaScript method to the element to ensure that a related action is triggered when the control is clicked using the mouse.

However, remember that content generated using static elements isn't keyboard focusable by default. This is where tabindex="0" comes in.

Using tabindex="0"

Applying tabindex="0" to an HTML element will add the content marked up using that element to the page's focus order, even if the content itself is not interactive. The content will then receive focus when navigating the page's content using the Tab and Shift + Tab keys.

To illustrate, consider the following code sample, which shows a snippet of static text between two controls marked up using HTML elements that support keyboard focus by default:

<button>
    I am a button!
</button>

<p>
    I am static text!
</p>

<a href="#">
    I am a link!
</a>

When navigating through the page using the keyboard, the button will receive focus followed by the link, and the static text will be skipped. However, let's modify the markup by adding tabindex="0" to the <p> element.

<button>
    I am a button!
</button>

<p tabindex="0">
    I am static text!
</p>

<a href="#">
    I am a link!
</a>

Now all three items will receive focus when navigating through the page using the keyboard.

For reasons that will become apparent, this is not an appropriate use of tabindex="0". Before using this attribute, consider when it will be helpful and when it might be a hindrance.

tabindex="0" and the screen reader myth

There is a common misunderstanding surrounding the relationship between tabindex="0" and screen reader accessibility. We occasionally encounter web content where tabindex="0" is liberally applied to static elements that perform no additional functionality. This assumption is often based on the mistaken belief that since people browsing with a screen reader typically navigate web content using a keyboard, all page content must be made focusable to ensure it is not overlooked or skipped.

However, as discussed in the difference between keyboard and screen reader navigation by Léonie Watson, screen readers provide multiple additional commands that allow people to read and navigate page content without developers needing to make this content focusable.

Indeed, adding tabindex="0" could add confusion, as people using screen readers who cannot see the page may struggle to distinguish between what is and what isn't interactive. Furthermore, people who use the keyboard and don't use a screen reader will be required to perform additional, and unnecessary, keystrokes to navigate through the page, leading to frustration on particularly lengthy pages.

When not to use tabindex="0"

Except for a minority of cases, avoid applying tabindex="0" to static content.

Additionally, don't apply tabindex="0" to elements that are already keyboard focusable by default, such as the <button> element. Doing so leads to redundant markup that adds extra work in terms of maintainability.

For example, do this:

<button …>
    Play video
</button>

Instead of this:

<button tabindex="0" …>
    Play video
</button>

When to use tabindex="0"

Only apply tabindex="0" to HTML elements that:

• Are not keyboard focusable by default; and
• Are provided with an interactive role; and
• Have an action associated with them that requires them to be reachable using the keyboard

Custom controls marked up using traditionally static HTML elements represent an appropriate use case. Consider the following example of a custom button:

<span 
    role="button" 
    tabindex="0">
    I am a custom button!
</span>

Here, a static HTML element (<span>) is used to mark up the control, and is exposed as such to assistive technologies through the application of role="button". However, because it is marked up using a <span> element, it won't be focusable without tabindex="0".

Exceptions

As usual, there are exceptions to the rule.

In some cases, it may be necessary to apply tabindex="0" to an element, even if the element itself isn't intended to be interactive, in order to allow people using the keyboard alone to access the associated content.

Containers for certain scrollable content

You need to apply tabindex="0" to elements used as containers for content where the containing element includes the CSS overflow property. This is so that the container itself can receive keyboard focus and therefore allow people using the keyboard alone to scroll the content using the arrow keys. This is discussed in more detail in How to use the tabindex attribute by Eric Bailey.

In addition, you need to provide an appropriate role and accessible name to the container so that people using a screen reader are made aware of what the content represents and why the element has received keyboard focus. Providing an accessible name for the container is also important, otherwise assistive technologies will announce the entire contents of the container when it's focused, instead of just its name. This can be confusing and overwhelming for people.

The following example demonstrates how the role of the container is set to region, while the accessible name is provided by the aria-label attribute:

<div 
    style="overflow: auto; …"
    tabindex="0" 
    role="region" 
    aria-label="Privacy Policy">
    … Contents of a lengthy privacy policy that requires extensive scrolling …
</div>

Containers for carousels

Another reason to use tabindex="0" on a static element is for carousels. It helps ensure that the carousel's container gets focus. This enables keyboard users to navigate between slides using the left and right arrow keys.

Like the previous example, the container will require an appropriate role and accessible name so that people using a screen reader know what it represents. However, unlike the previous example, there is no HTML element or WAI-ARIA explicitly intended for marking up carousels. To get around this, we recommend using the aria-roledescription attribute, in addition to role="region" or role="group", to provide a more human-readable and understandable description of the related content.

<div tabindex="0" role="region" aria-roledescription="Carousel" aria-label="Our latest offers">
    … Carousel contents …
</div>

Remember that tabindex="0" only makes the container focusable; you will still need to add extra scripting to allow people to navigate through slides using the arrow keys.

Conclusion

Applying tabindex="0" to an element is a very robust way of ensuring that content rendered using that element is focusable using the keyboard alone, and is almost always necessary when implementing custom interactive elements. In most other cases, however, there is no need to include tabindex="0", and indeed applying it can have a negative impact on the user experience, particularly for people who use a screen reader to navigate page content.

In cases where it must be applied, you must provide an appropriate role and an appropriate accessible name so that the reason that the content is focusable is made apparent to people using screen readers, and therefore they will more easily be able to identify how to interact with the element.

More information

• Browsing with a keyboard, Henny Swan
• browsing with a desktop screen reader, Henny Swan
• The difference between keyboard and screen reader navigation, Léonie Watson
• Understanding screen reader interaction modes, Léonie Watson
• How to use the tabindex attribute, Eric Bailey
• Understanding 2.4.3 Focus Order (Level A), W3C
• Understanding 2.1.1 - Keyboard (Level A), W3C

Next steps

For more information about the Web Content Accessibility Guidelines, read our WCAG Primer, or find out how our Assessments and Usability testing services can help you review the accessibility of your products and test them with people with disabilities.