In Shadow DOM v1, tabIndex=-1 makes all elements inside the shadow tree to be no tab-focusable

[hugoholgersson]

An inconsistency in Shadow DOM v1 has started to confuse web developers:

From crbug.com/906729:

... it seems that there is a spec bug now. tabindex -1 behaves differently on a non-Custom Element (like a <div>) than it does on a Custom Element.

Custom Element: tabIndex -1 removes "tab focusability" for everything inside the custom element.
A [scrollable] <div>: tabIndex -1 removes "tab focusability" for the [scrollable] <div> itself but not its content.

[annevk]

Is this with a shadow tree or not?

[freshp86]

Is this with a shadow tree or not?

With a shadow tree. Also note that this behavior changed from Shadow DOM v0 to v1. See minimal examples at https://bugs.chromium.org/p/chromium/issues/detail?id=896624#c5 (the examples use Polymer, but they can be made without Polymer as well if it helps).

[annevk]

In that case this is really about delegatesFocus and the various focus related issues already on file: whatwg/html#2013.

[hugoholgersson]

I guess I don't understand how delegatesFocus is supposed to work and why the introduction of delegatesFocus changed tabIndex's semantics. I read #399 changed tabIndex's semantics because we wanted a feature "make everything of this custom element/shadow tree non-tab-focsable"? But isn't that what delegatesFocus=false does for us?

My intuition:

• If I want a custom element where neither the host nor its shadow content are tab-focusable: tabIndex=-1 on the host and delegatesFocus=false on the root.

• If I want a custom element where the host isn't tab-focusable but its shadow content is:
  tabIndex=-1 on the host and delegatesFocus=true on the root.

The shadow host could then be a <div> where Shadow DOM content overflows (a scrollable div). Still, an author could decide to eject the <div> from the tab order but leave its [shadow] content in.

[annevk]

Your intuition matches mine, but I haven't looked at focus in a while. What goes amiss?

[hugoholgersson]

Because of #399, an author can not decide to eject the host <div> from the tab order but leave its [shadow] content in.

[annevk]

That issue doesn't seem to consider delegatesFocus though (and delegatesFocus isn't defined in detail). It seems to me it discusses the default (when delegatesFocus is false).

[freshp86]

/cc @hayatoito

@annevk According to the comment at https://bugs.chromium.org/p/chromium/issues/detail?id=896624#c15, and the tests at https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/shadow-dom/focus-navigation-with-delegatesFocus.html?l=106-138, delegatesFocus has no effect on whether the children of a shadow root are in the tab order. Notice that the assertions are the same for both test cases.

[hayatoito]

@freshp86, yeah, I think that is intentionally done in v1.

if the shadow host has -1 tab index, any node in a shadow root is skipped, as far as I can read.

[caridy]

if the shadow host has -1 tab index, any node in a shadow root is skipped, as far as I can read.

I want to stress that the semantics described by @hayatoito is what we believe is the right model. This should not be about delegatesFocus, this is about tabindex. It is also not about -1 or 0, it is about the possibility of using any other value. If you make this about delegatesFocus, it will become really easy for anyone to create a component without delegatesFocus flag for its shadow, and any arbitrary tabindex value that will disrupt the page where this component is used. E.g.:

<template>
     <input tabindex="1" />
</template>

That should never disrupt the page, no matter what, it is bound to whatever tabindex value its host has, independently of the delegatesFocus, otherwise authors can bypass what the consumer of the component is attempting to define. This matches the semantics of the native components.

[freshp86]

@caridy: Thanks for this explanation, it does make sense. There is still the following problem though:

The combination of the described tabindex behavior along with the "Keyboad accessible scroll containers" as implemented here (which I assume also follows some other spec?) make it impossible to have a CustomElement where

• its shadowRoot is a scrollable container and
• the shadowRoot itself is not in the tab order and
• its children are in the tab order.

Is that not considered a valid use case? Are authors forced to always wrap their contents with a div and add tabindex -1 to achieve that?

@hugoholgersson: Are the scrolling containers changes based on a spec or is it just matching Firefox's behavior but not explicitly specced? Perhaps treating shadowRoots differently in the "keyboard accessible scroll containers" implementation is the right approach here? Such that they are not added in the tab order silently?

it will become really easy for anyone to create a component without delegatesFocus flag for its shadow

Just a thought about this: Perhaps providing a way for consumers of a component to modify this behavior would alleviate this problem? Even if an author created a "bad" component, consumers could "fix" that behavior on their end, for example <my-element delegates-focus>...</my-element>?

[hugoholgersson]

@freshp86 The current HTML spec does not require tab-focusable scrollers but I hope WebKit and Edge pick it up so we can spec it (it has clear accessibility benefits).

[annevk]

@caridy there's a difference between enabling elements inside a shadow tree being "tab-focusable" and letting that tree override the tab order of the light tree, no?