Extending Element-level focus APIs

For the last couple of months (yes, sorry…) I’ve investigated the domain of “sequential navigation” (what you do, when you hit Tab). What follows are a couple of ideas regarding the Element-level focus APIs from an author’s (“web developer”) perspective.

1. There is no simple way to find out if an element is focusable or tabbable (i.e. accessible through sequential navigation). Since user agents already maintain internal focusable flags per element and the sequential navigation list, exposing the readonly boolean properties focusable and tabbable looks like a small feat.
2. Additionally to (1) the flags could be made accessible via CSS pseudo-classes :focusable and :tabbable.
3. Alternatively or additionally to (1) the ElementCollections of focusable and tabbable child elements should be made available per element. This is useful to do things like (4) manually. user agents vary on what is focusable/tabbable and figuring this out accurately is cumbersome.
4. WAI ARIA Authoring Practices for Modal Dialogs says “Tab Focus must be held within the dialog until it is cancelled or submitted”. This is true for Chrome’s implementation of the <dialog> element. While it is possible for JavaScript to keep focus within a given element, that interception will always prevent the user from reaching the user agent’s UI (like address bar) via Tab. For author’s the best solution would be to add the “trap-focus” attribute to the element in which focus must be held (container). That way the user agent can limit the sequential navigation list to the tabbable elements of the container element and allow normal passing of focus to user agent UI upon Tab. As a bonus authors don’t have to employ loads of JavaScript to achieve the same thing.
5. The document-wide nature of positive tabindex attributes (e.g. [tabindex=“3”]) make localized re-ordering of the navigation sequence painfully hard. The ShadowDOM can be used to localize the effects of positive tabindex attributes, and the CSS property order is being petitioned to affect navigation order. Both approaches come with restrictions and side-effects. It might help thinking of the author’s need more along the lines of how the radio button works. Specifically the grouping mechanism. Along this line of thinking, the element <input … tabindex="3" tabgroup="gustav"> would still be taken out of the dom-orderd document’s navigation sequence, but not sorted to the beginning of the navigation sequence like now. Instead, the new (inert) element <tabgroup name="gustav"> would be replaced with the captured taborder sequence, in dom order of its occurrence.

I consider 1-3 easy requests and 4 a simple enough request. 5 is an idea I’ve been toying with and wanted to get some feedback on.

I’m not sure I 100% understand option 5, the <tabgroup>, whatever it is, is confusing me

Are you saying that it would be useful to give elements a grouping mechanism and if a group of elements use that, then their tabindex becomes scoped to the group?

That’s how I read it, and that would be an improvement in that authors could specify a more useful tab order more reliably.

But I think a more useful approach would be allowing for non-linear navigation - Hyojin’s spatial navigation proposal (discussed earlier in this discourse) was discussed at TPAC - rough notes from breakout, slides.

There are interesting combinations beyond horizontal/vertical. In effect we already have this in some cases like menus, aria-flowto, screenreader special navigation modes, etc., and making it work consistently would be helpful. This is especially useful for graphics - flowcharts, circuit diagrams and so on often need it to make sense.

Current approaches are pretty clumsy for both authors and users. In particular they lack predictability for users, and authors are stuck trying to pick an existing paradigm where there isn’t an obvious match or doing stuff that is extra baroque…

That’s what I meant when I wrote this 3 years ago.

These days I don’t think it would solve problems like countering out-of-visual-sequence orders potentially caused by flexbox and grid in any useful way. I.e. I think the taborder should be controllable by CSS to align with the visual order (also controlled by CSS).

I’d like to see spatnav become a thing, but I it’s not clear to me how it will aid linear navigation.