I noticed that Léonie added the accessibility keywords, so I just wanted to clarify that this not an assistive technology issue, as ATs like screen readers don't have problems navigating into and out of shadow DOM components. 

This bug is about the fact that a general keyboard user cannot control complex shadow DOM components, including a number of the "native" implementations of HTML5 form controls. HTML should not force people to use a mouse or other pointer device, regardless if their reason is an accessibility need, personal preference, or general usability decision.

I think the issue is related to focus navigation.
http://w3c.github.io/webcomponents/spec/shadow/#focus-navigation

But I am afraid that I don't understand what the proposal is.

> I suggest that the specs provide a way for a web component to declare whether it has a focusable sub-DOM, which should be the default for <video> and <audio> sub-DOMs, and probably some input types like date and color.

I appreciate if you could you clarify this part.

(In reply to Hayato Ito from comment #2)
> I think the issue is related to focus navigation.
> http://w3c.github.io/webcomponents/spec/shadow/#focus-navigation
> 
> But I am afraid that I don't understand what the proposal is.
> 
> > I suggest that the specs provide a way for a web component to declare whether it has a focusable sub-DOM, which should be the default for <video> and <audio> sub-DOMs, and probably some input types like date and color.
> 
> I appreciate if you could you clarify this part.

In the following example, I would expect subsequent presses of the Tab key to move focus through #tabstop1, #tabstop2, #tabstop3, #tabstop4, and #tabstop5. into and out of the shadow DOM, because those controls are navigable and not otherwise controllable via the keyboard.

<button id="tabstop1">A button *before* the video element</button>
<video src="movie.m4v">
  <shadow-root id="video-shadow-root">
    <button id="tabstop2">Play/pause</button>
    <button id="tabstop3">Toggle captions</button>
    <button id="tabstop4">Mute</button>
  </shadow-root>
</video>
<button id="tabstop5">A button *after* the video element</button>


I would expect focus to only land on the <input type="text"> sub-DOM element, because the shadow DOM author already included the functionality for the increment/decrement buttons as keyboard event handlers on the UP and DOWN arrow keys. Giving those elements a tab stop would be redundant for keyboard users. 

It's possible this can be achieved using existing tabindex syntax to mark sub-DOM elements as focusable or non-focusable using an explicit tabindex of 0 or -1, or falling back to the elements "focusability" default. E.g. input fields are focusable, most everything else is not, unless overridden with tabindex="0"

<button id="tabstop1">A button *before* the input element</button>
<input type="number">
  <shadow-root id="video-shadow-root">
    <input type="text">
    <!-- b/c the functions of the next two elements are already handled by UP/DOWN arrow key events on the text input, these next two are focusable, so the shadow DOM only gets one tab stop (#tabstop2). (Could be specified using tabindex like so.) -->
    <button aria-label="increment" tabindex="-1">+</button>
    <button aria-label="decrement" tabindex="-1">-</button>
  </shadow-root>
</input>
<button id="tabstop3">A button *after* the input element</button>

The UA should determine how many tab stops a shadow DOM has, and change the Tab key behavior accordingly. During one of these shadow DOM focus change events, the document.activeElement should remain the same, but the shadow DOM activeElement should change. 

Tangent:

It's possible the Event object's relatedTarget property should be updated as well. If the current press of the Tab key does not change the main document.activeElement (b/c focus is moving to another sub-DOM element), should Event.target and Event.relatedTarget point to the same element? It seems to me that KeyboardEvent.relatedTarget should only point to an different element if focus will move there assuming the author does not call preventDefault().

For example, if focus is on #tabstop1, pressing the Tab key will trigger keyboard blur and focus events where Event.target and Event.relatedTarget both point to the video#target element. However, if focus is on #tabstop4, pressing the Tab key will trigger keyboard blur and focus events where Event.target is video#target, and Event.relatedTarget if button#tabstop5. 

<button id="tabstop1">A button *before* the video element</button>
<video src="movie.m4v" id="target">
  <shadow-root id="video-shadow-root">
    <button id="tabstop2">Play/pause</button>
    <button id="tabstop3">Toggle captions</button>
    <button id="tabstop4">Mute</button>
  </shadow-root>
</video>
<button id="tabstop5">A button *after* the video element</button>

(In reply to James Craig from comment #3)

> <button id="tabstop1">A button *before* the input element</button>
> <input type="number">
>   <shadow-root id="video-shadow-root">
>     <input type="text">
>     <!-- b/c the functions of the next two elements are already handled by
> UP/DOWN arrow key events on the text input, these next two are focusable, so
> the shadow DOM only gets one tab stop (#tabstop2). (Could be specified using
> tabindex like so.) -->
>     <button aria-label="increment" tabindex="-1">+</button>
>     <button aria-label="decrement" tabindex="-1">-</button>
>   </shadow-root>
> </input>
> <button id="tabstop3">A button *after* the input element</button>

I left off the referenced ID. 

  <input type="text">

Should be:

  <input type="text" id="tabstop2">

It seems to me that http://w3c.github.io/webcomponents/spec/shadow/#focus-navigation addresses this now. Can we close this bug?

The only lacking part I see now is that the spec does not address how a parent document can prevent the focusability of elements inside a shadow DOM. For example, shadow DOM implementations of <input type="date"> will likely include several focusable elements (a popup dialog with menus, buttons, etc), whether natively focusable or by adding tabindex="0". If an author explicitly disallows focusability on the element by one of these methods:

<input type="date" disabled>
<input type="date" tabindex="-1">

...then I believe the sub-level shadow DOM elements should inherit the non-focusability of the shadow host.

Needs to be copied across to Github and Shadow DOM

Moved, and then fixed… see https://github.com/w3c/webcomponents/issues/375