@accessible/tabbable
v1.1.2
Published
A function that returns an array of all tabbable DOM nodes within a containing node.
Downloads
7,749
Maintainers
Readme
Returns an array of all* tabbable DOM nodes within a containing node. (* "all" has some necessary caveats, which you'll learn about by reading below.)
The following are considered tabbable:
<button>
<input>
<select>
<textarea>
<a>
withhref
orxlink:href
attributes<audio>
and<videos>
withcontrols
attributes[contenteditable]
elements- anything with a non-negative
tabindex
Any of the above will not be considered tabbable, though, if any of the following are also true about it:
- negative
tabindex
disabled
- either the node itself or an ancestor of it is hidden via
display: none
orvisibility: hidden
- it's an
<input type="radio">
and a different radio in its group ischecked
If you think a node should be included in your array of tabbables but it's not, all you need to do is add tabindex="0"
to deliberately include it. (Or if it is in your array but you don't want it, you can add tabindex="-1"
to deliberately exclude it.) This will also result in more consistent cross-browser behavior. For information about why your special node might not be included, see "More details", below.
API
tabbable(rootNode: HTMLElement, includeRootNode: boolean = false): HTMLElement[]
Returns an array of ordered tabbable node within the rootNode
.
Summary of ordering principles:
- First include any nodes with positive
tabindex
attributes (1 or higher), ordered by ascendingtabindex
and source order. - Then include any nodes with a zero
tabindex
and any element that by default receives focus (listed above) and does not have a positivetabindex
set, in source order.
More details
- Tabbable tries to identify elements that are reliably tabbable across (not dead) browsers. Browsers are stupidly inconsistent in their behavior, though — especially for edge-case elements like
<object>
and<iframe>
— so this means some elements that you can tab to in some browsers will be left out of the results. (To learn more about that stupid inconsistency, see this amazing table). To provide better consistency across browsers and ensure the elements you want in your tabbables list show up there, try addingtabindex="0"
to edge-case elements that Tabbable ignores. - (Exemplifying the above ^^:) The tabbability of
<iframe>
,<embed>
,<object>
,<summary>
, and<svg>
is inconsistent across browsers, so if you need an accurate read on one of these elements you should try giving it atabindex
. (You'll also need to pay attention to thefocusable
attribute on SVGs in IE & Edge.) But you also might not be able to get an accurate read — so you should avoid relying on it. - Radio groups have some edge cases, which you can avoid by always having a
checked
one in each group (and that is what you should usually do anyway). If there is nochecked
radio in the radio group, all of the radios will be considered tabbable. (Some browsers do this, otherwise don't — there's not consistency.) - Although Tabbable tries to deal with positive tabindexes, you should not use positive tabindexes. Accessibility experts seem to be in (rare) unanimous and clear consent about this: rely on the order of elements in the document.
- Safari on Mac OS X does not Tab to
<a>
elements by default: you have to change a setting to get the standard behavior. Tabbable does not know whether you've changed that setting or not, so it will include<a>
elements in its list.
Why fork?
The creator is looking for a new maintainer and @accessibile
packages don't need some of the features
in the original, so I can make a smaller package with TypeScript types by forking :P
Credit
This library is forked from tabbable
LICENSE
MIT