24106 2013-12-16 05:27:18 +0000 FKA: No defined way to get keyboard focus into and out of a shadow DOM component 2015-07-06 08:06:03 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED MOVED a11y, a11ytf P2 normal --- 23870 1 silviapfeiffer1 dglazkov dglazkov faulkner.steve hayato ian jcraig lwatson mike public-html-admin public-html-wg-issue-tracking public-webapps public-webapps-bugzilla oldest_to_newest 97637 0 silviapfeiffer1 2013-12-16 05:27:18 +0000 +++ 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. 97686 1 jcraig 2013-12-16 19:54:30 +0000 Please note the follow-up discussion and example in Bug #23870 97692 2 ian 2013-12-16 21:55:46 +0000 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. 97694 3 jcraig 2013-12-16 22:01:30 +0000 (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. 97696 4 jcraig 2013-12-16 22:04:08 +0000 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? 97718 5 ian 2013-12-16 23:24:43 +0000 Yeah, good question, tabindex="1" also -- does the bound element get focused and then after a tab, the inner elements? 97722 6 jcraig 2013-12-16 23:46:35 +0000 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. 97770 7 hayato 2013-12-18 08:41:51 +0000 (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 97786 8 ian 2013-12-18 18:18:31 +0000 So is there nothing to do here? 97797 9 hayato 2013-12-19 04:39:11 +0000 (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. 97933 10 ian 2014-01-02 20:42:14 +0000 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. 99515 11 jcraig 2014-01-31 00:39:58 +0000 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. 99525 12 hayato 2014-01-31 05:02:47 +0000 (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. 100043 13 ian 2014-02-07 18:20:40 +0000 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. 100057 14 jcraig 2014-02-07 20:48:25 +0000 (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. 100073 15 ian 2014-02-07 23:47:14 +0000 So... what edits should be done to HTML? I don't know what I can do to resolve this bug at this point. 100096 16 hayato 2014-02-10 04:35:06 +0000 I am okay to move this issue to Shadow DOM spec's issue for now. That sounds reasonable to me. 100250 17 jcraig 2014-02-11 07:23:08 +0000 (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. 121651 18 hayato 2015-07-06 08:06:03 +0000 Moved to https://github.com/w3c/webcomponents/issues/228