FKA: Default HTML 5 Video controls are not keyboard accessible
<rdar://problem/14220941>
https://chromiumcodereview.appspot.com/22791003/ is a proposed fix for this in Blink.
Related to bug 31786, which is just about spacebar play/pause and is therefore more readily solvable than this one.
*** Bug 31786 has been marked as a duplicate of this bug. ***
Making these keyboard accessible now (part of bug 123749) but there is still no way to get keyboard access from the parent DOM to the shadow DOM.
*** Bug 125805 has been marked as a duplicate of this bug. ***
W3C HTML: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23870 WHATWG: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24106
This chunk was just added to the WebComponents spec: > 7.2 Focus Navigation > > If a node doesn’t participate in the composed tree, the node must be skipped from the navigation order [CSS3UI] sequence. > > The navigation order within a shadow tree must be computed as a list of focusable elements in tree order, and is called shadow tree navigation order. > > For sequential focus navigation, the shadow tree navigation order sequence for a given shadow tree A must be inserted into other navigation order as follow: > > 1. If the root node of A is the youngest shadow root: > 1.1. Let B be the parent tree of A > 1.2. Let HOST be the shadow host which hosts A > 1.3. The shadow tree navigation order for A must be inserted into the navigation order for B: > 1.3.1. immediately after HOST, if HOST is focusable; or > 1.3.2. in place of the HOST as if HOST were assigned the value of auto for determining its position. > 2. Otherwise: > 2.1. Let B be the younger shadow root relative to A > 2.2. Let SHADOW be the shadow insertion point in B > 2.3. If SHADOW exists, the shadow tree navigation order for A must be inserted into the navigation order for B immediately after SHADOW as if SHADOW were assigned the value of auto for determining its position. > > For directional focus navigation, it is up to the user agent to integrate the shadow tree navigation orders into the document navigation order. Cite: http://w3c.github.io/webcomponents/spec/shadow/#focus-navigation The only bit that is still missing is: > 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. Cite: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23870#c6 But I think that—with the one caveat—we can probably consider this bug unblocked now.
FWIW, tabindex works to some degree. If you include a tabindex and navigate with VoiceOver, focus is pulled along to the element with tabindex, and the focus ring shows up. It may just be that the tab *key* doesn't work when traversing into the sub-DOM. WebKit has a similar issues with getting the tab key to traverse into SVG content. See related bug 130212.
*** Bug 145971 has been marked as a duplicate of this bug. ***
Created attachment 278229 [details] Fixes the bug
Comment on attachment 278229 [details] Fixes the bug Clearing flags on attachment: 278229 Committed r200520: <http://trac.webkit.org/changeset/200520>
All reviewed patches have been landed. Closing bug.
*** Bug 157736 has been marked as a duplicate of this bug. ***