You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current Shadow DOM spec, basically focusable nodes in a shadow tree are inserted after their shadow host in the tab navigation order.
This means that when shadow host has "tabindex=-1", the host itself is skipped in the order, but right after the host the descendant nodes in its shadow tree will be visited.
This is probably not the behavior that a component author or user would expect.
I'm not immediately clear why this would be unexpected...
A couple of scenarios:
A date picker should have a tabindex at its root, so this doesn't arise.
A sound mixer may well begin with a bunch of non-interactive material, and be the main component on a page. So it seem logical that it doesn't have a tabindex at the root (although it might well be a landmark, in screen reader navigation terms).
Am I missing something obvious? (That seems quite possible)
I think the general idea makes sense - changing the shadow root's tabindex should apply to whatever is in the component.
There is an analagous situation in aria. I'll have a look what they say, but I suspect their answer will be "build JS that manages this", which doesn't really help in this case…
(There is a problem with the example: the functionality inaccessible for keyboard. The normal interaction pattern would be to fill in the things you want, then hit enter to submit the form.)
The text was updated successfully, but these errors were encountered:
This means that when shadow host has "tabindex=-1", the host itself is skipped in the order, but right after the host the descendant nodes in its shadow tree will be visited.
This is probably not the behavior that a component author or user would expect.
We've got reports from component users in Chrome's Web UI that they depend on and expect the old semantics, see #774.
Title: [Shadow]: Shadow host with tabindex=-1, all descendent tree should be ignored for tab navigation (bugzilla: 27965)
Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27965
comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27965#c0
Takayoshi Kochi wrote on 2015-02-05 07:51:29 +0000.
In the current Shadow DOM spec, basically focusable nodes in a shadow tree are inserted after their shadow host in the tab navigation order.
This means that when shadow host has "tabindex=-1", the host itself is skipped in the order, but right after the host the descendant nodes in its shadow tree will be visited.
This is probably not the behavior that a component author or user would expect.
comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27965#c1
Charles McCathieNevile wrote on 2015-02-19 06:00:33 +0000.
I'm not immediately clear why this would be unexpected...
A couple of scenarios:
Am I missing something obvious? (That seems quite possible)
comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27965#c2
Takayoshi Kochi wrote on 2015-02-26 06:10:12 +0000.
Let me explain an example.
Suppose I have an component (which is out of control of mine)
|#shadow-root | save cookie | Help2 focusables contained in a shadow.
I put it in some form:
Name: Password:And want to skip for typical cases, only require
Name: Password:name and password then user can hit login button.
So I put tabindex=-1 in
Actually, this doesn't skip the checkbox and help link.
Demo: http://jsfiddle.net/4y3xntx8/
comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27965#c3
Charles McCathieNevile wrote on 2015-02-26 10:43:04 +0000.
Thanks for the example.
I think the general idea makes sense - changing the shadow root's tabindex should apply to whatever is in the component.
There is an analagous situation in aria. I'll have a look what they say, but I suspect their answer will be "build JS that manages this", which doesn't really help in this case…
(There is a problem with the example: the functionality inaccessible for keyboard. The normal interaction pattern would be to fill in the things you want, then hit enter to submit the form.)
The text was updated successfully, but these errors were encountered: