Topic: ARIA Deep Dive call - focusability and tabindex=-1

Notes

  *   these discussions will be undertaken with light minuting.
  *   The expected outcome is comments in github issues or new issues being logged. Other outcomes might also occur.
  *   No decisions (other than updating issues or creating notes) will be taken.
  *   Please only attend if the topic interests you.

The background of this discussion is on the w3c slack in the #focusability channel - https://w3ccommunity.slack.com/archives/C012QQXV1EH

The thread with more details is at https://w3ccommunity.slack.com/archives/C012QQXV1EH/p1588180882001300


I have pasted the first 3 posts in this thread at the bottom of this mail in case you don’t have access to the w3c slack.

Call Details:

San Francisco (U.S.A. - California)
Thursday, May 14, 9:00 AM PDT
Boston (U.S.A. - Massachusetts)
Thursday, May 14, 12:00 PM EDT
London (United Kingdom - England)
Thursday, May 14, 5:00 PM GMT+1
Paris (France)
Thursday, May 14, 6:00 PM GMT+2
Tokyo (Japan)
Friday, May 15, 1:00 AM GMT+9
Corresponding UTC (GMT)
Thursday, May 14, 4:00 PM UTC

Duration: 45 mins

Chair: JamesNurthen

Scribe:

IRC: irc.w3.org<http://irc.w3.org/>:6665 #aria

Call Details:
1.      Meeting Details including passcode<https://www.w3.org/2017/08/telecon-info_aria>

To join the audio conference only:
US Toll Number: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 101 412 589
Mobile Auto Dial:+16699006833,,101412589#
International Numbers: https://mit.zoom.us/u/aeoFNqVybP

Join by SIP: 101412589@zoomcrc.com<mailto:101412589@zoomcrc.com>
Join by Skype for Business: https://mit.zoom.us/skype/101412589


Excerpts from the slack conversation:
Initial Post:

if there is a good reason to keep the following behavior: Setting tabindex -1 makes things focusable on mouse click. Why? Was this an implementation detail in Firefox/IE during the initial ARIA implementation? Is there a good reason to keep it?

There are several standards issues that are now affected by this: tree inclusion in ARIA, focusability of custom elements, etc. The disparate behavior of tab-focusable in browsers makes things even more complicated.

Straw Man proposal: Rather than tab-focusable, click-focusable, or script-focusable, it might be simpler to track focusability as a simple boolean: is it focusable or not? -1 could be not.

That said, changing it now may be difficult. Gecko, Chromium, and WebKit have click focusability on -1 in most scenarios. And because they do, the HTML spec now lists this as standard behavior.

Response:
The history of this beast goes back to old Internet Explorer. When we were first developing ARIA, I found that IE had supported tabindex=-1, which at the time was their special sauce and not spec’d anywhere. Note that this was very, very early, even before aria-activedescendant was a thought.

Joining IE in this, and supporting tabindex=-1 in Gecko and specs meant that if someone developed an ARIA widget, they could use tabindex=-1 / tabindex=0 for keyboard navigation, and develop a widget that was at least keyboard navigable in IE (the browser with by far the major market share a the time). It was possible to use the “roving tabindex=0 method”, and move around the tabindex=0 in a complex container widget, and get keyboard behavior similar to native widgets. For example in a grid, a mouse clicker needs to be able to randomly click any cell and focus it.

The script also needs to be able to focus any cell. By default, most HTML elements like <div>, <span>, <td> do not support the .focus() method, but putting any tabindex on them makes them support focus().

There are several standards issues that are now affected by this: tree inclusion in ARIA, focusability of custom elements, etc. The disparate behavior of tab-focusable in browsers makes things even more complicated. Rather than tab-focusable, click-focusable, or script-focusable, it might be simpler to track focusability as a simple boolean: is it focusable or not? -1 could be not.

Focusable or not is not granular enough, because in a container widget, such as a grid or tree, you don’t want every single item in the tab order. When you tab in, you want the previously focusable subwidget to be active, and be able to arrow around from there. These days it is also possible to develop this experience with aria-activedescendant, but before that, it was not possible.

As you say, it’s too late to change this now. It would break tons of pages. Let’s talk about what we’re trying to address. Are you trying to apply markup to an element to make it not focusable at all? There used to be a proposed CSS property called user-focusable, which could be set to none. (edited)

Response from Original Poster:

> putting tabindex on them allows them to support focus()


I should have conveyed the other part of this straw man: that perhaps it’s okay to allow focus() on any rendered element, regardless of whether it has a tabindex content attribute.



[Adobe Logo]
James Nurthen
415.832.2734 (tel)
601 Townsend Street
Accessibility Engineer
415.987.1918 (cell)
San Francisco, CA, 94103, USA
Adobe. Make It an Experience.
nurthen@adobe.com
www.adobe.com