[Bug 23870] FKA: No defined way to get keyboard focus into and out of a shadow DOM component

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23870

--- Comment #3 from James Craig <jcraig@apple.com> ---
(In reply to Hayato Ito from comment #2)
> I think the issue is related to focus navigation.
> http://w3c.github.io/webcomponents/spec/shadow/#focus-navigation
> 
> But I am afraid that I don't understand what the proposal is.
> 
> > 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.
> 
> I appreciate if you could you clarify this part.

In the following example, I would expect subsequent presses of the Tab key to
move focus through #tabstop1, #tabstop2, #tabstop3, #tabstop4, and #tabstop5.
into and out of the shadow DOM, because those controls are navigable and not
otherwise controllable via the keyboard.

<button id="tabstop1">A button *before* the video element</button>
<video src="movie.m4v">
  <shadow-root id="video-shadow-root">
    <button id="tabstop2">Play/pause</button>
    <button id="tabstop3">Toggle captions</button>
    <button id="tabstop4">Mute</button>
  </shadow-root>
</video>
<button id="tabstop5">A button *after* the video element</button>


I would expect focus to only land on the <input type="text"> sub-DOM element,
because the shadow DOM author already included the functionality for the
increment/decrement buttons as keyboard event handlers on the UP and DOWN arrow
keys. Giving those elements a tab stop would be redundant for keyboard users. 

It's possible this can be achieved using existing tabindex syntax to mark
sub-DOM elements as focusable or non-focusable using an explicit tabindex of 0
or -1, or falling back to the elements "focusability" default. E.g. input
fields are focusable, most everything else is not, unless overridden with
tabindex="0"

<button id="tabstop1">A button *before* the input element</button>
<input type="number">
  <shadow-root id="video-shadow-root">
    <input type="text">
    <!-- b/c the functions of the next two elements are already handled by
UP/DOWN arrow key events on the text input, these next two are focusable, so
the shadow DOM only gets one tab stop (#tabstop2). (Could be specified using
tabindex like so.) -->
    <button aria-label="increment" tabindex="-1">+</button>
    <button aria-label="decrement" tabindex="-1">-</button>
  </shadow-root>
</input>
<button id="tabstop3">A button *after* the input element</button>

The UA should determine how many tab stops a shadow DOM has, and change the Tab
key behavior accordingly. During one of these shadow DOM focus change events,
the document.activeElement should remain the same, but the shadow DOM
activeElement should change. 

Tangent:

It's possible the Event object's relatedTarget property should be updated as
well. If the current press of the Tab key does not change the main
document.activeElement (b/c focus is moving to another sub-DOM element), should
Event.target and Event.relatedTarget point to the same element? It seems to me
that KeyboardEvent.relatedTarget should only point to an different element if
focus will move there assuming the author does not call preventDefault().

For example, if focus is on #tabstop1, pressing the Tab key will trigger
keyboard blur and focus events where Event.target and Event.relatedTarget both
point to the video#target element. However, if focus is on #tabstop4, pressing
the Tab key will trigger keyboard blur and focus events where Event.target is
video#target, and Event.relatedTarget if button#tabstop5. 

<button id="tabstop1">A button *before* the video element</button>
<video src="movie.m4v" id="target">
  <shadow-root id="video-shadow-root">
    <button id="tabstop2">Play/pause</button>
    <button id="tabstop3">Toggle captions</button>
    <button id="tabstop4">Mute</button>
  </shadow-root>
</video>
<button id="tabstop5">A button *after* the video element</button>

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 2 December 2013 19:01:04 UTC