Re: Better focus support for Shadow DOM
Hi, Changes for Blink have landed and now you can play this by enabling "experimental web platform features" in chrome://flags. Now I am proposing this as a patch to shadow DOM, at https://github.com/w3c/webcomponents/blob/gh-pages/proposals/ShadowRoot-delegatesFocus-Proposal.md Feel free to comment here, or at github issue tracker. (The full version of the doc also moved to markdown format, at https://github.com/TakayoshiKochi/tabindex-focus-navigation-explainer/blob/master/TabindexFocusNavigationExplainer.md ) On Wed, Jun 3, 2015 at 4:47 PM, Takayoshi Kochi (河内 隆仁) wrote: > Hi, > > (cross-posting mostly the same content to blink-...@chromium.org, sorry > for duplication if you encounter this twice) > > With much feedback from many people, I've updated the design doc. > > https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing > Thanks all who have shared thoughts and experience with me. > > The biggest change is that "tabStop" property on Element moved to > ShadowRoot, as "delegatesFocus". > > After implementing the spec on Blink, I noticed that even tabStop property > is > on every Element, it has effect only on shadow hosts, which is very > confusing. > So delegatesFocus should make more clear sense on shadow hosts. > > With the new spec, delegatesFocus can be specified via ShadowRootInit > dictionary, > which is a parameter to createShadowRoot(). > > I'll start making changes in Blink immediately. > > For reference, I copied a snapshot of old doc (Mar. 19): > > https://docs.google.com/document/d/1wFXrPYmoqb8-b-rfZdmcVfZt09NaTFyOLvGztdlIPxE/edit# > > Any comment is welcome. > > On Thu, Jan 22, 2015 at 6:38 AM, Domenic Denicola wrote: > >> Thanks Takoyoshi! This new version looks great to me. It would allow >> people to create custom elements with the same focus capabilities as native >> elements, including both the simple cases (like ) and the more >> complicated ones with a shadow DOM (like ). Very >> exciting stuff! >> >> >> >> I hope others are as enthused as I am :) >> >> >> >> *From:* Takayoshi Kochi (河内 隆仁) [mailto:ko...@google.com] >> *Sent:* Wednesday, January 21, 2015 02:41 >> *To:* public-webapps >> *Subject:* Re: Better focus support for Shadow DOM >> >> >> >> Hi, >> >> >> >> After conversation with Domenic Denicola, I changed the title and the >> whole story of >> >> solving this issue, though the result is not quite different. Instead of >> adding "delegatesFocus" >> >> property, we added "isTabStop()" to expose "tab focusable flag" explained >> in HTML5 spec. >> >> >> >> >> https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing >> >> >> >> Any comments/suggestions welcome. >> >> >> >> On Wed, Jan 14, 2015 at 2:27 PM, Takayoshi Kochi (河内 隆仁) < >> ko...@google.com> wrote: >> >> Hi, >> >> >> >> For shadow DOMs which has multiple focusable fields under the host, >> >> the current behavior of tab navigation order gets somewhat weird >> >> when you want to specify tabindex explicitly. >> >> >> >> This is the doc to introduce a new attribute "delegatesFocus" to resolve >> the issue. >> >> >> https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing >> >> >> >> Any comments are welcome! >> >> -- >> >> Takayoshi Kochi >> >> >> >> >> >> -- >> >> Takayoshi Kochi >> > > > > -- > Takayoshi Kochi > -- Takayoshi Kochi
Re: Better focus support for Shadow DOM
Hi, (cross-posting mostly the same content to blink-...@chromium.org, sorry for duplication if you encounter this twice) With much feedback from many people, I've updated the design doc. https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing Thanks all who have shared thoughts and experience with me. The biggest change is that "tabStop" property on Element moved to ShadowRoot, as "delegatesFocus". After implementing the spec on Blink, I noticed that even tabStop property is on every Element, it has effect only on shadow hosts, which is very confusing. So delegatesFocus should make more clear sense on shadow hosts. With the new spec, delegatesFocus can be specified via ShadowRootInit dictionary, which is a parameter to createShadowRoot(). I'll start making changes in Blink immediately. For reference, I copied a snapshot of old doc (Mar. 19): https://docs.google.com/document/d/1wFXrPYmoqb8-b-rfZdmcVfZt09NaTFyOLvGztdlIPxE/edit# Any comment is welcome. On Thu, Jan 22, 2015 at 6:38 AM, Domenic Denicola wrote: > Thanks Takoyoshi! This new version looks great to me. It would allow > people to create custom elements with the same focus capabilities as native > elements, including both the simple cases (like ) and the more > complicated ones with a shadow DOM (like ). Very > exciting stuff! > > > > I hope others are as enthused as I am :) > > > > *From:* Takayoshi Kochi (河内 隆仁) [mailto:ko...@google.com] > *Sent:* Wednesday, January 21, 2015 02:41 > *To:* public-webapps > *Subject:* Re: Better focus support for Shadow DOM > > > > Hi, > > > > After conversation with Domenic Denicola, I changed the title and the > whole story of > > solving this issue, though the result is not quite different. Instead of > adding "delegatesFocus" > > property, we added "isTabStop()" to expose "tab focusable flag" explained > in HTML5 spec. > > > > > https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing > > > > Any comments/suggestions welcome. > > > > On Wed, Jan 14, 2015 at 2:27 PM, Takayoshi Kochi (河内 隆仁) > wrote: > > Hi, > > > > For shadow DOMs which has multiple focusable fields under the host, > > the current behavior of tab navigation order gets somewhat weird > > when you want to specify tabindex explicitly. > > > > This is the doc to introduce a new attribute "delegatesFocus" to resolve > the issue. > > > https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing > > > > Any comments are welcome! > > -- > > Takayoshi Kochi > > > > > > -- > > Takayoshi Kochi > -- Takayoshi Kochi
Re: Better focus support for Shadow DOM
Hi Chaals, Thanks for the comment. Honestly I'm not so familiar with ARIA/a11y requirements but the problem sounds to apply Shadow DOMs overall, not specific to the problem I'm trying to address here. Do you have any concrete cases that this (isTabStop feature et al.) can regress or degenerate (or improve?) any a11y? For issue 27965, I commented on it with an example. On Thu, Feb 19, 2015 at 7:45 PM, wrote: > Hi, > > I noted the bugs, this thread, and the document in the HTML accessibility > wiki where I am trying to collate stuff about focus navigation and similar > keyboard access issues (in what might yet be a vain attempt to really > improve the situation which is overall pretty dismal still): > https://www.w3.org/WAI/PF/HTML/wiki/Keyboard > > 19.02.2015, 04:56, "Takayoshi Kochi (河内 隆仁)" : > > [Shadow]: Shadow host with tabindex=-1, all descendent tree should be > ignored for tab navigation > https://www.w3.org/Bugs/Public/show_bug.cgi?id=27965 > > > > I am not sure if this really is a problem (which might just be my brain > going slowly). See my comment for more details, but it isn't clear to me > that this needs to be fixed. On further reflection, I wonder if the point > is where the author has explicitly marked tabindex="-1" - and how this > relates to comound ARIA controls... > > > cheers > > > Focus on shadow host should slide to its inner focusable node > https://www.w3.org/Bugs/Public/show_bug.cgi?id=28054 > > On Wed, Jan 14, 2015 at 2:27 PM, Takayoshi Kochi (河内 隆仁) > wrote: > > Hi, > > For shadow DOMs which has multiple focusable fields under the host, > the current behavior of tab navigation order gets somewhat weird > when you want to specify tabindex explicitly. > > This is the doc to introduce a new attribute "delegatesFocus" to resolve > the issue. > > https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing > > Any comments are welcome! > -- > Takayoshi Kochi > > > > > -- > Takayoshi Kochi > > > > -- > Charles McCathie Nevile - web standards - CTO Office, Yandex > cha...@yandex-team.ru - - - Find more at http://yandex.com > > -- Takayoshi Kochi
Re: Better focus support for Shadow DOM
Hi, I noted the bugs, this thread, and the document in the HTML accessibility wiki where I am trying to collate stuff about focus navigation and similar keyboard access issues (in what might yet be a vain attempt to really improve the situation which is overall pretty dismal still): https://www.w3.org/WAI/PF/HTML/wiki/Keyboard 19.02.2015, 04:56, "Takayoshi Kochi (河内 隆仁)" :[Shadow]: Shadow host with tabindex=-1, all descendent tree should be ignored for tab navigationhttps://www.w3.org/Bugs/Public/show_bug.cgi?id=27965 I am not sure if this really is a problem (which might just be my brain going slowly). See my comment for more details, but it isn't clear to me that this needs to be fixed. On further reflection, I wonder if the point is where the author has explicitly marked tabindex="-1" - and how this relates to comound ARIA controls... cheers Focus on shadow host should slide to its inner focusable nodehttps://www.w3.org/Bugs/Public/show_bug.cgi?id=28054On Wed, Jan 14, 2015 at 2:27 PM, Takayoshi Kochi (河内 隆仁)wrote:Hi, For shadow DOMs which has multiple focusable fields under the host,the current behavior of tab navigation order gets somewhat weirdwhen you want to specify tabindex explicitly. This is the doc to introduce a new attribute "delegatesFocus" to resolve the issue.https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing Any comments are welcome!-- Takayoshi Kochi -- Takayoshi Kochi --Charles McCathie Nevile - web standards - CTO Office, Yandexcha...@yandex-team.ru - - - Find more at http://yandex.com
Re: Better focus support for Shadow DOM
Hi, Thanks for the feedback from you all. During the discussion on the feedback, I've filed a couple of bugs. Any comments are welcome. [Shadow]: Shadow host with tabindex=-1, all descendent tree should be ignored for tab navigation https://www.w3.org/Bugs/Public/show_bug.cgi?id=27965 Focus on shadow host should slide to its inner focusable node https://www.w3.org/Bugs/Public/show_bug.cgi?id=28054 On Wed, Jan 14, 2015 at 2:27 PM, Takayoshi Kochi (河内 隆仁) wrote: > Hi, > > For shadow DOMs which has multiple focusable fields under the host, > the current behavior of tab navigation order gets somewhat weird > when you want to specify tabindex explicitly. > > This is the doc to introduce a new attribute "delegatesFocus" to resolve > the issue. > > https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing > > Any comments are welcome! > -- > Takayoshi Kochi > -- Takayoshi Kochi
RE: Better focus support for Shadow DOM
Thanks Takoyoshi! This new version looks great to me. It would allow people to create custom elements with the same focus capabilities as native elements, including both the simple cases (like ) and the more complicated ones with a shadow DOM (like ). Very exciting stuff! I hope others are as enthused as I am :) From: Takayoshi Kochi (河内 隆仁) [mailto:ko...@google.com] Sent: Wednesday, January 21, 2015 02:41 To: public-webapps Subject: Re: Better focus support for Shadow DOM Hi, After conversation with Domenic Denicola, I changed the title and the whole story of solving this issue, though the result is not quite different. Instead of adding "delegatesFocus" property, we added "isTabStop()" to expose "tab focusable flag" explained in HTML5 spec. https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing Any comments/suggestions welcome. On Wed, Jan 14, 2015 at 2:27 PM, Takayoshi Kochi (河内 隆仁) mailto:ko...@google.com>> wrote: Hi, For shadow DOMs which has multiple focusable fields under the host, the current behavior of tab navigation order gets somewhat weird when you want to specify tabindex explicitly. This is the doc to introduce a new attribute "delegatesFocus" to resolve the issue. https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing Any comments are welcome! -- Takayoshi Kochi -- Takayoshi Kochi
Re: Better focus support for Shadow DOM
Hi, After conversation with Domenic Denicola, I changed the title and the whole story of solving this issue, though the result is not quite different. Instead of adding "delegatesFocus" property, we added "isTabStop()" to expose "tab focusable flag" explained in HTML5 spec. https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing Any comments/suggestions welcome. On Wed, Jan 14, 2015 at 2:27 PM, Takayoshi Kochi (河内 隆仁) wrote: > Hi, > > For shadow DOMs which has multiple focusable fields under the host, > the current behavior of tab navigation order gets somewhat weird > when you want to specify tabindex explicitly. > > This is the doc to introduce a new attribute "delegatesFocus" to resolve > the issue. > > https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing > > Any comments are welcome! > -- > Takayoshi Kochi > -- Takayoshi Kochi
Re: Better focus support for Shadow DOM
Thanks for those who gave me the first round of comments on the document. I'm now rewriting many parts of the document for suggestions by Domenic, so it also applies to regular HTML elements behavior. During the rewrite, the document will be updated real time - which means the doc is inconsistent. Once it finishes, I'll post the updates. On Wed, Jan 14, 2015 at 2:27 PM, Takayoshi Kochi (河内 隆仁) wrote: > Hi, > > For shadow DOMs which has multiple focusable fields under the host, > the current behavior of tab navigation order gets somewhat weird > when you want to specify tabindex explicitly. > > This is the doc to introduce a new attribute "delegatesFocus" to resolve > the issue. > > https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing > > Any comments are welcome! > -- > Takayoshi Kochi > -- Takayoshi Kochi
Re: Better focus support for Shadow DOM
Hi Takayoshi, 14.01.2015, 13:04, "Takayoshi Kochi (河内 隆仁)" :I was not aware that positive tabindex value is being deprecated, but anyway it should make sensewhen tabindex=0 specified on the shadow host. And as it has not been completely deprecated,it should be okay to keep the document as is, but I will add some comments or pointer. Yep. It was more "for your information". For aria-activedescendant, I was not aware either, do you think it still make sense when thereal active descendant is in a shadow tree (i.e. the host and the active element live in different scope)?(added public-html-a11y to cc) Yes, because I think as far as possible it makes sense to align the models we use for managing focus in different places. (It may be that the right answer is to look at changing ARIA - but having two different models for fairly similar things seems like a bad idea to me). cheers On Wed, Jan 14, 2015 at 6:28 PM,wrote:Hi, please consider how thi relates to the management of "aria-active-descendant" and why we should not be working to bring the two of these in line. Note also that in HTML there is a proposal to deprecate (and hopefully one day abandon) tabindex with positive values, in favour of something less painful than forcing the user to press tab a zillion times as the way to get around an app. The HTML accessibility task force is currently looking at these issues for HTML, and it would be good to align the work. There is a question of where it makes more sense to have the conversation, but for the moment it is on public-html-a...@w3.org and on their wiki - listed as accesskey for increasingly irrelevant historical reasons http://www.w3.org/WAI/PF/HTML/wiki/51wishlist cheers Chaals 14.01.2015, 08:30, "Takayoshi Kochi (河内 隆仁)" :Hi, For shadow DOMs which has multiple focusable fields under the host,the current behavior of tab navigation order gets somewhat weirdwhen you want to specify tabindex explicitly. This is the doc to introduce a new attribute "delegatesFocus" to resolve the issue.https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing Any comments are welcome!-- Takayoshi Kochi --Charles McCathie Nevile - web standards - CTO Office, Yandexcha...@yandex-team.ru - - - Find more at http://yandex.com -- Takayoshi Kochi --Charles McCathie Nevile - web standards - CTO Office, Yandexcha...@yandex-team.ru - - - Find more at http://yandex.com
Re: Better focus support for Shadow DOM
Hi Chaals, Thanks for the pointers. I was not aware that positive tabindex value is being deprecated, but anyway it should make sense when tabindex=0 specified on the shadow host. And as it has not been completely deprecated, it should be okay to keep the document as is, but I will add some comments or pointer. For aria-activedescendant, I was not aware either, do you think it still make sense when the real active descendant is in a shadow tree (i.e. the host and the active element live in different scope)? (added public-html-a11y to cc) On Wed, Jan 14, 2015 at 6:28 PM, wrote: > Hi, > > please consider how thi relates to the management of > "aria-active-descendant" and why we should not be working to bring the two > of these in line. > > Note also that in HTML there is a proposal to deprecate (and hopefully one > day abandon) tabindex with positive values, in favour of something less > painful than forcing the user to press tab a zillion times as the way to > get around an app. The HTML accessibility task force is currently looking > at these issues for HTML, and it would be good to align the work. > > There is a question of where it makes more sense to have the conversation, > but for the moment it is on public-html-a...@w3.org and on their wiki - > listed as accesskey for increasingly irrelevant historical reasons > http://www.w3.org/WAI/PF/HTML/wiki/51wishlist > > cheers > > Chaals > > 14.01.2015, 08:30, "Takayoshi Kochi (河内 隆仁)" : > > Hi, > > For shadow DOMs which has multiple focusable fields under the host, > the current behavior of tab navigation order gets somewhat weird > when you want to specify tabindex explicitly. > > This is the doc to introduce a new attribute "delegatesFocus" to resolve > the issue. > > https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing > > Any comments are welcome! > -- > Takayoshi Kochi > > > > -- > Charles McCathie Nevile - web standards - CTO Office, Yandex > cha...@yandex-team.ru - - - Find more at http://yandex.com > > -- Takayoshi Kochi
Re: Better focus support for Shadow DOM
Hi, please consider how thi relates to the management of "aria-active-descendant" and why we should not be working to bring the two of these in line. Note also that in HTML there is a proposal to deprecate (and hopefully one day abandon) tabindex with positive values, in favour of something less painful than forcing the user to press tab a zillion times as the way to get around an app. The HTML accessibility task force is currently looking at these issues for HTML, and it would be good to align the work. There is a question of where it makes more sense to have the conversation, but for the moment it is on public-html-a...@w3.org and on their wiki - listed as accesskey for increasingly irrelevant historical reasons http://www.w3.org/WAI/PF/HTML/wiki/51wishlist cheers Chaals 14.01.2015, 08:30, "Takayoshi Kochi (河内 隆仁)" :Hi, For shadow DOMs which has multiple focusable fields under the host,the current behavior of tab navigation order gets somewhat weirdwhen you want to specify tabindex explicitly. This is the doc to introduce a new attribute "delegatesFocus" to resolve the issue.https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing Any comments are welcome!-- Takayoshi Kochi --Charles McCathie Nevile - web standards - CTO Office, Yandexcha...@yandex-team.ru - - - Find more at http://yandex.com