FKA: Default HTML 5 Video controls are not keyboard accessible
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
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.
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.
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. ***