tabIndex defaults to −1 for non-tabbing elements

[annevk]

Fixes https://www.w3.org/Bugs/Public/show_bug.cgi?id=29093.

[domenic]

Can we check what browsers do here? I don't have a Mac to test with, but it seems like a normative change of this kind is somewhat of a big deal.

[annevk]

I figured @bzbarsky would have tested, but testing this for <a> in Chrome, Firefox, and Safari, which is focusable but not reachable through sequential focus navigation, I get 0, not -1.

I should probably add a clarifying note here (instead of changing the normative requirements) that sequential focus navigation is immaterial to whether or not tabIndex returns 0.

[bzbarsky]

Yeah, browsers are rather inconsistent in terms of when they follow the current spec and when not, and I'm not sure the spec's model of a boolean "focusable" value makes sense either; see below.

Some examples, on Mac, with default OS settings (i.e. "In windows and dialogs, press Tab to move keyboard focus between text boxes and lists only"):

<a>: Tabindex is always 0 in Firefox/Safari/Chrome, even when there is no href. Needless to say, <a> without href is not focusable in any of those browsers. Though in Safari an <a> with an href seems to also not be focusable either, as far as I can tell. Testcase:

data:text/html,<a%20href="%23">Click me; do I become activeElement?</a><pre><script>document.writeln(document.querySelector("a").tabIndex);%20onclick=function()%20{%20setTimeout(function()%20{%20alert(document.activeElement);}%20,%200)%20}</script>

An <a> with an href is focusable via mouse in Firefox/Chrome on Mac.

<input type="checkbox">: tabIndex is 0 in all three browsers. Is focusable via mouse and reachable via tab navigation in Firefox and Chrome. Is neither focusable via mouse nor reachable via tab navigation in Safari.

<input type="text">: tabIndex is 0 in all three browsers. Is focusable via mouse and reachable via tab navigation in all three. Hey, the spec actually matches implementations here.

<div>: tabIndex is -1 in all three browsers. Not focusable via mouse, not reachable via tab navigation. Again, this matches the current spec.

<div style="overflow: scroll"> with actual overflow: tabIndex is -1 in all three browsers. The <div> is not reachable via tab navigation in Chrome or Safari but is reachable in Firefox (and when reached is focused). On the other hand, it cannot be focused via mouse in any of the three browsers. This is one example of why a single boolean "is focusable" can't accurately describe things...

<video> with a "controls" attribute: tabIndex is 0 in all three browsers. Can be focused by mouse in Firefox but not Chrome or Safari. Can be reached via tab navigation in all three browsers, and when reached is focused. Another example of why a single boolean is not good enough...

<video> without a "controls" attribute: tabIndex is 0 in Firefox, -1 in Chrome/Safari. Can be focused with mouse and reached via tab navigation in Firefox. Can be neither focused with mouse nor reached via tab navigation in Chrome/Safari. Another case of browsers actually matching the current spec.

[annevk]

So that would mean we'd need "mouse focusable", "tab focusable", but then that probably varies per platform too? Touch?

User interaction depending on platform is why I've never been super thrilled to sort out how it works, since there's not really a canonical model.

Not sure what to do here.

[annevk]

On IRC bz mentioned: "the weirdness of how :focus and :-moz-focusring differ (and the fact that the latter has to exist), the fact that some things take focus without drawing focus rings, but it depends on OS and on how you focused them". That seems like another thing that needs to be defined.

[bzbarsky]

Note that the "what draws focus rings" behavior may be in flux in browsers still. See, for example, https://bugzilla.mozilla.org/show_bug.cgi?id=735251

[bzbarsky]

And in particular, some elements show a focus ring whenever they're focused, some only when they are focused via keyboard, and which ones are in which bucket may vary by platform and OS (accessibility) settings, just like which set of elements are tabbable can vary.

[annevk]

So what can we reasonably define? It sounds like we can define that there are different groups (tab focusable, mouse focusable, shows focus ring), but we cannot define what those groups consist of (although maybe we can say <input type=text> should usually be part of most). We can say how APIs use or ignore these groups.

[bzbarsky]

That doesn't seem unreasonable.

[annevk]

Closing this in favor of #1786 which has a more current discussion.