I'm not immediately clear why this would be unexpected...

A couple of scenarios:

- A date picker should have a tabindex at its root, so this doesn't arise.

- A sound mixer may well begin with a bunch of non-interactive material, and be the main component on a page. So it seem logical that it doesn't have a tabindex at the root (although it might well be a landmark, in screen reader navigation terms).

Am I missing something obvious? (That seems quite possible)

Let me explain an example.

Suppose I have an component (which is out of control of mine)
2 focusables contained in a shadow.

<login-extras>
 |#shadow-root
 | <input type=checkbox> save cookie
 | <a href="http://example.com/help">Help</a>
</login-extras>

I put it in some form:

<form>
 Name: <input>
 Password: <input type=password>
 <login-extras></login-extras>
 <input type=submit value="login">
</form>

And want to skip <login-extra> for typical cases, only require
name and password then user can hit login button.
So I put tabindex=-1 in <login-extras>

<form>
 Name: <input>
 Password: <input type=password>
 <login-extras tabindex=-1></login-extras>
 <input type=submit value="login">
</form>

Actually, this doesn't skip the checkbox and help link.
Demo: http://jsfiddle.net/4y3xntx8/

Thanks for the example.

I *think* the general idea makes sense - changing the shadow root's tabindex should apply to whatever is in the component.

There is an analagous situation in aria. I'll have a look what they say, but I suspect their answer will be "build JS that manages this", which doesn't really help in this case…

(There is a problem with the example: the functionality inaccessible for keyboard. The normal interaction pattern would be to fill in the things you want, then hit enter to submit the form.)

Moved to https://github.com/w3c/webcomponents/issues/86