tabindex and interactive content

[TimothyGu]

The spec says that

An element with the tabindex attribute specified is interactive content.

This designation is observable and testable through the following clause that applies to label elements:

The activation behavior of a label element for events targeted at interactive content descendants of a label element, and any descendants of those interactive content descendants, must be to do nothing.

However, it does not look like any browser actually considers tabindex interactive. With the following:

<label id=label>
  <button onclick="console.log('clicked')">Don't click me</button>
  <div tabindex=0>Click me</div>
  <!-- <details><summary>Click me</summary></details> -->
</label>

clicking on "click me" prints "clicked" to the console in all browsers I tested (Chrome, Firefox, and the WebKit-based GNOME Web aka Epiphany). But if we were to click on the details element instead, then "clicked" does not get printed.

Frankly, this could well be due to implementation negligence. WebKit and Chrome simply never implemented this, while in Firefox, the function label uses to check for interactive content opted out of the tabindex-as-interactive behavior seemingly without too much thought. It wouldn't be too difficult to fix this in implementations.

The question now is, is this behavior actually still something we want? This determines if we want to change the implementations or the spec.

[TimothyGu]

Chromium bug for this: https://crbug.com/1065048

[domenic]

In mildly in favor of changing implementations in this regard as it seems like authors would benefit from getting the label-clicking behavior for their custom controls using tabindex="0". I'm certainly in favor of this for custom elements that want to opt in to focus behavior; see WICG/webcomponents#762.

On the other hand, the custom elements proposal makes this slightly less urgent, if we want to avoid any compat issues, since we could say that the best way to create custom focusable controls is to use that proposal instead of using tabindex="0". So if implementers are wary of changing this behavior then we could live with the current one.

@whatwg/forms, @mfreed7, @rniwa, any thoughts?

[TimothyGu]

Chrome has been fixed.

Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1628500

WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=210223

[TimothyGu]

Unfortunately, this appears to be Web incompatible. According to https://crbug.com/1069615, websites are already depending on the behavior that tabindex is ignored for the purpose of determining label element activation behavior. Here’s what the website does:

<label for="billing-address" class="check-box-label">
<input type="checkbox" role="checkbox" data-talos="checkboxShipToBillingAddress" id="billing-address" name="billing-address" checked="">
<i class="check-box-icon" tabindex="0" role="checkbox" aria-checked="true" title="Same as shipping address" aria-labelledby="Same as shipping address"></i>
Same as shipping address</label>

Considering that I doubt this is the only website out there that does such a thing, I think we need to change the spec to accommodate. Two ways of doing this:

1. Change the definition of interactive content and omit the tabindex provision.

2. Change the label element’s activation behavior to use “interactive content except tabindex” as the measure for no-opness.

The first is cleaner and what implementations do, and is what I’d prefer. One can argue that it diminishes the semantic meaning of tabindex, but honestly in today’s world there are already too many divs with click event handlers (but without tabindex) that are no less interactive than buttons, so maybe that is already a lost cause. WAI-ARIA roles are probably already better for this purpose than tabindex.

What do people think?

[domenic]

Thanks to you and to Chromium for taking the hit and discovering this!

(1) does sound nicer, but the question is what impact it would have on conformance requirements. Interestingly the canvas element already includes an exception for tabindex. But e.g. this would start allowing <a href="foo">....<span tabindex="0">bar</span>...</a> in conformance checkers, which wasn't allowed before. The same for a <button> container. I think that's all the impact, though.

Your point about click-handler-having buttons already being allowed as <a> or <button> children is interesting...

Another point is that if we go with (2), then effectively the spec has two definitions of interactive content: one which affects user agent implementation requirements, and one which affects conformance checkers. This is prone to future inconsistency or misuse, e.g. if we add another feature which has user agent implementation requirements with regard to interactive content, which definition will we use?

I'll summon our usual conformance-requirement experts, @sideshowbarker and @zcorpan, to see what they think. I'm leaning a bit toward (1), but not strongly.

[TimothyGu]

As it turns out, there's already this clause for the canvas element:

Content model: Transparent, but with no interactive content descendants except … elements that would not be interactive content except for having the tabindex attribute specified.

So going with (1) would remove this special case, which IMO is a good thing.

[zcorpan]

tabindex making an element "interactive content" was specified in 2781765

The commit doesn't reference a bug, but this is likely the bug it fixed:

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

[zcorpan]

(1) does sound nicer, but the question is what impact it would have on conformance requirements. Interestingly the canvas element already includes an exception for tabindex.

canvas probably ought to have a clearer content model that lists all things that are allowed, instead of taking a big category and then making 8 exceptions...

But e.g. this would start allowing <a href="foo">....<span tabindex="0">bar</span>...</a> in conformance checkers, which wasn't allowed before. The same for a <button> container. I think that's all the impact, though.

Having stepped through all instances of "interactive content", I come to the same conclusion. We could keep the content model the same by disallowing descendants with tabindex in a and button. Is it serving any useful purpose? Maybe a section (or MDN page? @whatwg/documentation ) that explains what the general problem is with nesting interactive elements would be better?

[sideshowbarker]

I have no strong preference on what we should do here. That said, though, here are comments:

Another point is that if we go with (2), then effectively the spec has two definitions of interactive content: one which affects user agent implementation requirements, and one which affects conformance checkers. This is prone to future inconsistency or misuse, e.g. if we add another feature which has user agent implementation requirements with regard to interactive content, which definition will we use?

I agree that sounds suboptimal and we should avoid it if we can. However, it seems like that’d only be a problem for spec editors and maybe conformance-checker maintainers — and not for web developers. So in light of the priority of constituencies, if were were to judge it to be better for web developers even though it was a maintenance inconsistency for spec authors, then we should go with what’s better for web developers.

But regardless of that, I can’t say I have a good sense of what’s best for web devs in this case.

I can say that I can’t remember the last time (if ever) that anybody reported a bug against the HTML checker saying they took exception to the existing error checker message about the spec’s current restrictions on nesting of interactive content.

And as a general matter, pretty much nobody ever reports bugs against the checker saying that they want the checker to emit an error about something that it’s currently not already emitting an error for (that the spec doesn’t define as an error case). Similarly, in cases where the spec changes to make some case a non-error, and I change the checker to quit emitting an error for that case, no users ever complain about that error disappearing.

In other words, the only time where we’re ever likely to see reactions from users of the HTML checker is when we introduce new restrictions (and so, new checker error messages).

We could keep the content model the same by disallowing descendants with tabindex in a and button. Is it serving any useful purpose?

I guess that’s the question which really matters — the question of what class of user problems we’re trying to help web developers avoid inadvertently causing.

Maybe a section (or MDN page? @whatwg/documentation ) that explains what the general problem is with nesting interactive elements would be better?

That seems like something it’d be good to get written up regardless of how we resolve this issue.

[zcorpan]

Thanks @sideshowbarker. So the current rules aren't annoying enough to make people report bugs on the checker, that seems like a useful data point. I suggest we keep the rules for links and buttons (by special casing tabindex in their content model), and the conformance checker can link to documentation when it exists in the error message.