In accessibility, “focusable” UI elements are represented by two separate yet equally important concepts: the elements who can be focused sequentially and those who can only receive focus programmatically. These are their stories. Dun-Dun

While working for a client the other day, I found that Polypane¹ , which is excellent in locating accessibility issues, showed elements with tabindex="-1" as focusable in the Focus Order section of the Outline tool.

I contacted Kilian to see why that was happening, and he pointed me to the Accessibility Tree, which showed the element as focusable, too.

This is where I understood that there was a mix-up between two concepts: Sequentially focusable and programmatically focusable elements. The former are elements that can be reached with the tab key. Mixing these concepts is easy, as we use “focusable” because it is short and because the concepts are somewhat related. But for accessibility testing and understanding why we see certain behavior, understanding the difference is important.

What are sequentially focusable elements?

For elements without a tabindex attribute, the HTML spec has the following list of sequentially focusable elements:

• a elements that have an href attribute
• button elements
• input elements whose type attribute are not in the Hidden state
• select elements
• textarea elements
• summary elements that are the first summary element child of a details element
• Elements with a draggable attribute set, if that would enable the user agent to allow the user to begin drag operations for those elements without the use of a pointing device
• Editing hosts
• Navigable containers

In addition, elements with a tabindex attribute of 0 are also part of the sequentially focusable elements.

Elements with a positive tabindex attribute are also part of the sequentially focusable elements, but reorder the sequence² . There are almost no circumstances that warrant positive tabindex values³ .

Note: On macOS/Safari the tab-focusable elements are different from on other operating systems due to historical reasons. To test with a comparable experience, follow Browser keyboard navigation in macOS.

What are programmatically focusable elements?

Programmatically focusable elements not (only) receive the focus when the user presses the tab key, but can (in addition or exclusively) receive the focus through JavaScript’s focus() function or because a fragment identifier points at the element with a corresponding id.

All sequentially focusable elements can also receive the focus programmatically. In addition, a negative integer⁴ value for the tabindex attribute makes an element a programmatically focusable area but does not add the element to the sequentially focusable elements.

Programmatically focusable elements are useful when you need to direct users to a specific place in a website or app, especially after actions. A table of content might want to set the focus on the heading (a non-sequentially-focusable element) when using a skip link. Adding a negative tabindex to the heading makes it possible.

While programmatically focused, the focused element is treated as being the focus sequence as if its tabindex value was 0. It’s inserted in the sequence and tab will go to the next item in the sequence.

In addition, negative tabindex values also remove sequentially focusable elements from the sequence!

A link with a negative tabindex cannot be reached with the tab key, but most assistive technologies work around it. Screen readers, for example, can set “screen reader focus”⁵ to such a link when using arrow key navigation.

Some UI elements like tabs can use negative tabindex and programmatically assigned focus to control the interaction.

Demo

Here’s a demo with different permutations of elements and tabindex values: