accessibility · keyboard
Tabbable
also called focusable vs tabbable (community), programmatically focusable (community), sequentially focusable (html)
Reachable by the Tab key, as opposed to merely focusable: an element with tabindex of -1 can take focus from script but never from Tab.
Two properties, one attribute, and endless confusion. Focusable means an element can hold focus
at all. Tabbable, which the HTML specification calls sequentially focusable, means the Tab key
will stop there while walking the page. Every tabbable element is focusable; plenty of focusable
elements are not tabbable. tabindex="-1" is precisely the pair “yes to focus, no to Tab”, and
tabindex="0" is “both, in document order”.
The distinction earns its keep as soon as you manage focus yourself. A dialog’s heading, a panel
that has just opened, an error summary, the results region a search updated, the target of a skip
link: all of these want .focus() pointed at them so the next thing a screen reader reads is the
thing that changed, and none of them wants to be an extra Tab stop for everybody else forever
after. tabindex="-1" is how initial focus is placed on something that is not
a control. It is also how a composite widget hides its inactive parts from Tab while the arrow
keys still reach them, which is the whole mechanism behind a roving tabindex.
Two neighbours mark the boundaries. Positive tabindex is the failure on the
other side of zero: it does not just add an element to the sequence, it jumps it to the front of
the whole page and breaks focus order for every element around it.
Inert is the stronger tool for the opposite job: tabindex="-1" removes an element from
the Tab sequence but leaves it clickable and still findable by a screen reader in browse mode,
while inert takes the whole subtree out of interaction and out of the accessibility tree.
Removing something from the Tab sequence is not the same as hiding it.
The mistake this word exists to prevent is a check that reads “can it be focused?” and concludes
“then it is reachable”. element.focus() succeeding proves nothing about whether a keyboard user
can ever get there. Walk the interface with Tab and count the stops. Anything you can only reach
by script is something a keyboard user cannot reach at all, and if it is a control, that is a
2.1.1 failure however focusable it is.
Which word?
| If you want | say |
|---|---|
| distinguishing script focus from Tab reachability | tabbable |
| counting how many Tab presses a widget costs | tab stop |
| someone proposes tabindex="1" to fix an order | positive tabindex |
| a disabled control still needs to be discoverable | focusable disabled |
Related
See also: Focusable scroll region