[focusgroup] Should it support shadow trees?

[travisleithead]

Copied from MicrosoftEdge/MSEdgeExplainers#556

@benbeaudry filed originally on 2022-02-23

I'm implementing a prototype of this explainer in Chromium and I'm wondering whether we should allow elements in shadow trees to be part of a focusgroup or not. I couldn't find any mention in the explainer, but I don't see why we shouldn't also include elements hidden within a shadow tree.

WDYT? If you agree, it might be a good idea to mention it in the explainer.

@travisleithead replied

Good point. Insofar as a shadow dom is used to wrap the internals of a logical component, it might makes sense for the host element of that component to declare a focusgroup such that descendents of the focusgroup within the component can take advantage of it. Definitely needs to be described in the explainer/spec.

Perhaps we should piggyback on the existing delegatesFocus flag. If present, then the author of the Shadow Root intends for focus to transition to some sub-component. Therefore, if a focusgroup definition is placed on the host element, then the focusable children (inside the component) should attempt to "link-up" to a cross-shadow-root focusgroup definition in their ancestor "flat tree". Otherwise (the delegatesFocus flag is absent), only elements in that light tree (e.g., those exposed through slots) would be candidates. This may require some clever defintion of the work "children" (e.g., shadow-inclusive children?).

@benbeaudry replied

The "delegatesFocus" flag that already exist is definitely something we could leverage with the focusgroup attribute. However, after some digging, it seems like this flag is only used to redirect the focus event from the ShadowRoot to the first focusable element within the ShadowDOM when the ShadowRoot isn't focusable.

In our situation, the use case would be a bit different: the focus would move from an element outside of the ShadowDOM to an element inside of it on an arrow key press without trying to first go to the ShadowRoot. In my opinion, the delegatesFocus flag is a totally different feature and it doesn't make much sense to piggyback on it because of the different use cases.

I am by no means an expert on the delegatesFocus flag or on ShadowDOMs, so my opinion is to be taken with a grain of salt.

That being said, for the moment, I've decided to allow a focusgroup within a ShadowDOM to extend one that is declared outside of that ShadowDOM in the initial implementation of the focusgroup feature (in Chromium-based browsers). I'll keep monitoring this thread to bring the appropriate changes to the Chromium implementation if needed.

[css-meeting-bot]

The Open UI Community Group just discussed [focusgroup] Should it support shadow trees?.

The full IRC log of that discussion

<gregwhitworth> Topic: [focusgroup] Should it support shadow trees?
<gregwhitworth> github: https://github.com//issues/521
<gregwhitworth> q?
<bkardell_> Travis: some context: in the current proposal (benjamin is also helping with the proposal and is here), you take any element you want and put a focus group content attribute on it. That is a signal that its children can participate as focus group items
<bkardell_> Travis: there is this relationship between some parent element and children it affects
<bkardell_> Travis: we quickly ran into an interesting... concern
<bkardell_> Travis: when you introduce shadow dom into the equation (a separate document/strong boundary) things get interesting
<bkardell_> Travis: should the parent element that becomes a host would be automatically opted into participation or should it enforce that boudnary
<JonathanNeal> q?
<JonathanNeal> q+
<bkardell_> Travis: this isn't unique, there are a number of parallels here - we're interested in hearing your thoughts
<bkardell_> JonathanNeal: Are there any examples that I could see where someone was even writing the pseudocode that shows me what you're saying
<bkardell_> Travis: (mouthblogging)
<gregwhitworth> ack JonathanNeal
<masonf> q+
<gregwhitworth> ack masonf
<bkardell_> masonf: it's an interessting question. I think it really does come down to the use cases and I can imagine both
<bkardell_> masonf: it sounds to me like maybe there could be some optional flag on the shadow root creation itself
<bkardell_> q+
<gregwhitworth> ack bkardell_
<gregwhitworth> bkardell_: opt-in or out, what's the default?
<gregwhitworth> bkardell_: I'll say, don't because it's a boundary
<gregwhitworth> benjamin: yes, you're correct it's off by default
<bkardell_> bkardell_: sgtm
<bkardell_> Travis: super, it seems we have a good proposal for default and we need to think about the opt-in mechanism
<bkardell_> Travis: I am hearing that a unique attribute would be desirable instead of piggybakcing on something like delegates focus
<bkardell_> Travis: are you aware of other things that are doing kind of this that we could learn/borrow from?
<bkardell_> gregwhitworth: We're working on some aria reflection stuff and Igalia just landed some stuff to do some of that - but it's not everything, so it would probably be helpful to work together on that maybe
<gregwhitworth> dandclark: yes that's the proposal. I'm putting it in the minutes: https://leobalter.github.io/cross-root-aria-delegation/
<Travis> Proposed Resolution: focusgroups will not automaticlly bind between shadow dom boundaries (by default).
<gregwhitworth> q?
<dandclark> +1
<flackr> q+
<bkardell_> I already said sgtm, so +1
<gregwhitworth> ack flackr
<JonathanNeal> +1
<bkardell_> q+
<gregwhitworth> bkardell_: if I understand flackr correctly, if you don't have 2 modes you have to make it work by default
<gregwhitworth> bkardell_: there is no other way
<gregwhitworth> flackr: it's just not clear to me where you have scenarios where don't want to have the shadow DOM participate
<bkardell_> flackr: I am imagining if you had focusable elements in the shadow...
<bkardell_> flackr: why wouldn't you want to have them participate
<bkardell_> Travis: that use case would have to be handled, and it would be an opt in with the current
<gregwhitworth> bkardell_: I hear Travis said that that usecase would have be handled
<gregwhitworth> bkardell_: flackr said that he doens't think that that usecase is real
<gregwhitworth> bkardell_: there's disonnance with me because they're conflicting statements
<gregwhitworth> bkardell_: do you disagree?
<bkardell_> Travis: I understood flackr to be saying that the use case where the internals not particpating are not 'really useful', is that right?
<bkardell_> flackr: that's right
<dandclark> q+
<bkardell_> Travis: that would imply we'd have to change the default the other way round and change the resolution
<bkardell_> bkardell_: that's why I asked
<gregwhitworth> ack bkardell_
<gregwhitworth> ack dandclark
<bkardell_> gregwhitworth: I think I agree
<bkardell_> dandclark: it's interesting to think about because we have multiple levels of shadow dom too. If the author designing the component wants to do that, but if I am making a composite widget, the parent might not want to have focus sucked into it, but some component might
<bkardell_> dandclark: I am thinking about a calendar in a dialog, for example - i might not to have tabs move along the dates in the calendar because its inside of some other component where that would 'generally' make sense
<gregwhitworth> q?
<bkardell_> flackr: wouldn't the calendar case then want to declare a focusgroup?
<bkardell_> dandclark: maybe. the whole calendar might just be one thing in the tab order, and partipates itself, but it wants keys to operate dates
<bkardell_> gregwhitworth: this same thing could apply to things like fileexplorer
<bkardell_> Travis: I'm confused about which default this argues for or against
<gregwhitworth> q+
<scotto_> q+
<bkardell_> Travis: you can always create new groups inside the shadow dom
<masonf> q+
<bkardell_> dandclark: I'm trying to mentally piece together a good use case myself
<bkardell_> Travis: I'm super happy to take a proposal and collect and put it through the paces with some use cases and we can see
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack scotto_
<bkardell_> gregwhitworth: what I am hearing is like what rob said "it seems like there could be one meaningful default, let's see if that can work" but we might find that there is a need for something beyond that default
<flackr> +1
<bkardell_> scotto_: this seems like an issue that happens regardless of shadow dom really - we can have a popup that is participating in the focus group all of the sudden for example... it can get confusing
<gregwhitworth> ack masonf
<bkardell_> masonf: scotts point about top layer is interesting. You might also have a focusgroup name namespacing issue because the names are local
<bkardell_> gregwhitworth: is this where we go back full circle to something like 'focusgroup registries'
<bkardell_> Travis: I hope not
<bkardell_> gregwhitworth: it sounds like there is a general sentiment that there is a meaningful default and that maybe it is to let it through, but we're not sure and need to collect some cases and experience and come back to it

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[travisleithead]

Current plan:

• Mention in the explainer that, by default, a focusgroup will consider all nodes in shadow-including tree order, not just the element's descendants when looking for focusgroup candidates.
• Mention in the explainer that we may add an opt-out mechanism if only descendants should be considered for a compelling use case.

[css-meeting-bot]

The Open UI Community Group just discussed [focusgroup] Should it support shadow trees?, and agreed to the following:

• RESOLVED: focusgroup will consider focusable items inside shadow dom boundaries

The full IRC log of that discussion

<gregwhitworth> Travis: this is about whether focus groups should pick up elements in shadow DOM
<gregwhitworth> Travis: we resolved by default it should since that's what the tab key would do
<gregwhitworth> Travis: we could possibly allow blocking it?
<luke> q+
<masonf> q+
<gregwhitworth> Travis: until that comes up I think it's worth having that as the default
<gregwhitworth> ack luke
<gregwhitworth> luke: only thing to say to that is that focusgroup needs an opt-out for subtrees and right now it only takes immediate children and we're wanting to open it up to more trees
<gregwhitworth> ack masonf
<gregwhitworth> masonf: one more +1 to support shadow DOM and I wanted to say opting out of the sub-tree is confusing to me but that's a separate issue. If I hit the arrow key over the hole and then I tab it will take me to it?
<Travis> Proposed Resolution: focusgroup will consider focusable items inside shadow dom boundaries
<masonf> +1
<luke> +10
<philippgfeller> +1
<gregwhitworth> scotto_: not an objection but I'm curious what some people are thinking right now with some of these topics
<gregwhitworth> scotto_: I'm curious what people are trying to make
<gregwhitworth> scotto_: I'm maybe not thinking fourth dimensionally like doc brown would say
<gregwhitworth> scotto_: what are some of these usecases that these more complex usecases would come in to play?
<gregwhitworth> luke: for me, the shadow DOM has buttons in a toolbar and I want them to be a part of the focus group, I need them to be involved without javascript hacks
<gregwhitworth> luke: we should be able to do this with web components and it just work
<gregwhitworth> luke: in terms of immediate children vs not
<gregwhitworth> scotto_: yeah, having individual focusgroups being navigable by arrow key I have not had a user study where they're pleased with that result
<gregwhitworth> luke: the actual focusable item was inside of a container
<gregwhitworth> Travis: I looked at preview in the wicag guide would require some nesting
<gregwhitworth> scotto_: thanks
<Travis> RESOLVED: focusgroup will consider focusable items inside shadow dom boundaries
<gregwhitworth> Zakim, end meeting