This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
+++ This bug was initially created as a clone of Bug #23870 +++ FKA (full keyboard access): There is currently no defined way to get keyboard focus into and out of a shadow DOM component. Some components (like the native "number" input type) don't need this, but others (like native video controls) need multiple tab stops inside the shadow DOM component. For example: <input type="number"> Although there are multiple focusable elements inside (textfield, increment button, and decrement button), all features can be controlled with standard keyboard behavior. Focus stops on the input, and the increment/decrement buttons are activate with up/down arrows. <video controls> There are multiple controls in the shadow DOM component, including volume/mute buttons/sliders, a playback position slider, a cc toggle button and subtitle picker menu, etc. There is currently no consistent way to control HTML 5 media elements without using a mouse. 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.
Please note the follow-up discussion and example in Bug #23870
Why doesn't this just work if the shadow DOM has focusable controls? I don't understand what change to the HTML spec would address this.
(In reply to Ian 'Hixie' Hickson from comment #2) > Why doesn't this just work if the shadow DOM has focusable controls? I don't > understand what change to the HTML spec would address this. If that is the expected behavior, it may be enough, but the HTML/DomComponents specs don't say one way or the other, and implementations are currently different.
It should also specify what happens when an author specifies tabindex="-1" on an element that has focusable controls. Does this prevent the focusable descendants from being focused in the shadow DOM tree as well?
Yeah, good question, tabindex="1" also -- does the bound element get focused and then after a tab, the inner elements?
That's not (In reply to Ian 'Hixie' Hickson from comment #5) > Yeah, good question, tabindex="1" also -- does the bound element get focused > and then after a tab, the inner elements? That's the behavior I'd expect after tabindex="0", but not necessarily after tabindex="1"; but it's certainly something to think about in the context of bug 23960.
(In reply to James Craig from comment #4) > It should also specify what happens when an author specifies tabindex="-1" > on an element that has focusable controls. Does this prevent the focusable > descendants from being focused in the shadow DOM tree as well? Regarding with Web Components, even when the shadow host has 'tabindex=-1', focusable elements in its shadow tree can be focusable and can be traversed by 'tab' key. '8.2 Focus Navigation' in Shadow DOM spec defines sequential focus navigation order: > http://w3c.github.io/webcomponents/spec/shadow/#focus-navigation
So is there nothing to do here?
(In reply to Ian 'Hixie' Hickson from comment #8) > So is there nothing to do here? I think so. However I guess there is a *gap* between native elements and user-made Web components. Some native elements might use a shadow tree in its implementation, such as <video> element or <input> elements in Chrome. But we can't assume that these elements are implemented by Shadow DOM. If these elements have 'tabindex=-1', I think there is no spec which defines the behavior of focusable elements inside of native elements. We can't apply the Shadow DOM spec into these native elements unless we can assume that these are implemented in Shadow DOM.
The issue of defining how default bindings work is a separate bug. (Feel free to file that bug, though it can't really get resolved until Web Components are firmly established; it's on my radar in any case). Separate from that, though, I don't understand what needs to be done to resolve 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.
(In reply to James Craig from comment #11) > 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. That makes sense. I thought it should be addressed several times when I've updated the relevant spec. However, I haven't done yet because I've not heard strong requirements for that. In my opinion, we should have a power to *skip* entire sub-trees.
This is an issue for the shadow DOM spec, no? I mean, presumably the shadow DOM spec needs controls to handle focus on its bound element, since I see several options: - the bound element having focus really means some element in the shadow tree has focus (e.g. <input>) - the bound element having focus is separate from any subcomponent having focus (e.g. <video tabindex=1>) - the bound element can never have focus (e.g. <col>) - the bound element should be able to prevent subparts from having focus (e.g. <input tabindex=-1>) All of these need to be handled by the shadow tree, they're not something HTML can define as far as I can tell.
(In reply to Ian 'Hixie' Hickson from comment #13) > This is an issue for the shadow DOM spec, no? > ... > All of these need to be handled by the shadow tree, they're not something > HTML can define as far as I can tell. @tabindex is specific to HTML, whereas Shadow DOM is more general, so there are probably still edits for both specs.
So... what edits should be done to HTML? I don't know what I can do to resolve this bug at this point.
I am okay to move this issue to Shadow DOM spec's issue for now. That sounds reasonable to me.
(In reply to Ian 'Hixie' Hickson from comment #15) > So... what edits should be done to HTML? > > I don't know what I can do to resolve this bug at this point. There are some sketched ideas here regarding tabindex scoping (proposed @tabwrap, @tabtarget, @tabwrapper) that could be applied generally and as default values to existing cases like shadow DOM components and frames. https://github.com/bmeck/fm.js/wiki My point about doing this in HTML is that the shadow DOM spec could generally state that focus could move into focusable controls contained in the shadow DOM of a 'focusable shadow root' but HTML is the spec to define what constitutes the focusable shadow root, no? This is spread out over several other bugs now (bug 23475, bug 23871, more) that it's getting hard to track them all together. It's possible those other bugs will sufficiently cover the edits that need to be made.
Moved to https://github.com/w3c/webcomponents/issues/228