FKA: No way to get focus from DOM to shadow DOM components (Was: HTML5 media controls not keyboard accessible)

• Component: Accessibility
• Status: RESOLVED FIXED

[James Craig]

FKA: Default HTML 5 Video controls are not keyboard accessible

[James Craig]

<rdar://problem/14220941>

[Eric Carlson]

https://chromiumcodereview.appspot.com/22791003/ is a proposed fix for this in Blink.

[James Craig]

Related to bug 31786, which is just about spacebar play/pause and is therefore more readily solvable than this one.

[James Craig]

*** Bug 31786 has been marked as a duplicate of this bug. ***

[James Craig]

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.

[James Craig]

*** Bug 125805 has been marked as a duplicate of this bug. ***

[James Craig]

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

[James Craig]

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.

[James Craig]

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.

[James Craig]

*** Bug 145971 has been marked as a duplicate of this bug. ***

[Ryosuke Niwa]

Created attachment 278229 [details]
Fixes the bug

[WebKit Commit Bot]

Comment on attachment 278229 [details]
Fixes the bug

Clearing flags on attachment: 278229

Committed r200520: <http://trac.webkit.org/changeset/200520>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[James Craig]

*** Bug 157736 has been marked as a duplicate of this bug. ***