#1152: Incubation: Scoped Focusgroup

Visit on Github

Opened Sep 18, 2025

Explainer

https://open-ui.org/components/scoped-focusgroup.explainer/

The explainer

Where and by whom is the work is being done?

  • GitHub repo: https://github.com/openui/open-ui
  • Primary contacts:
    • Jacques Newman (@janewman), Microsoft, Explainer author, Chromium Implementor
    • Chris Holt (@chrisdholt), Microsoft, Prior Explainer co-author
    • Leo Lee (@leolee), Microsoft, team lead
  • Organization/project driving the design: Microsoft
  • This work is being funded by: Microsoft
  • Incubation and standards groups that have discussed the design:
  • Standards group(s) that you expect to discuss and/or adopt this work when it's ready: WhatWG

Feedback so far

You should also know that...

An earlier version of this feature was proposed and resolved here: https://github.com/w3ctag/design-reviews/issues/732

<!-- Content below this is maintained by @w3c-tag-bot -->

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1152

Discussions

Log in to see TAG-private discussions.

Discussed Oct 13, 2025 (See Github)

Matthew: Think it needs a bit more work. Will have another look.

Comment by @janewman Oct 14, 2025 (See Github)

@matatk friendly ping as it's been a month since this was filed, but looks like this is getting attention, so thanks! Please let me know if you have any questions, if something isn't clear, etc. happy to fill in the gaps! Thanks again!

Discussed Oct 20, 2025 (See Github)

Matthew: This is really neat. Like so many things I've seen in previous career would be fixed with this. That was the general consensus in APA. We discussed yesterday and we have some questions. Or some things that could be mentioned, possibly as future work. I might put them in the thread. I will probably post directly. I plan to do that today.

Discussed Oct 27, 2025 (See Github)

Matthew asked for more info

Comment by @matatk Oct 29, 2025 (See Github)

Hi @janewman. Thanks for your review request, and sorry for my slow reply. We have discussed this in some TAG calls, and also in a couple of Accessible Platform Architectures WG calls. My comment here is aimed at gathering a bit of information before TAG can come to consensus. Also many thanks to @AutoSponge for contributing many of the below questions on your proposal.

First of all: this is neat! It's a clear pain point for devs and users, and your proposed solution looks great. The explainer is well written. There are some things that we'd like some clarification on, though...

  1. Orientation of certain types of construct, and aria-orientation don't seem to be mentioned - is orientation something the group considered?

  2. Is there a reason why tree and treegrid controls are not mentioned? (grid is mentioned as future work)

  3. Do you intend that the behavior tokens will always have the same names as their ARIA role counterparts?

  4. Do you foresee adding anything that is not currently covered by ARIA?

Again I really liked this proposal. I'm also pleased that applying behaviours via CSS is not in scope for this proposal, as I'm concerned about the possibility for author error to make huge changes to the way pages work, without it being obvious to the author.

Thanks for your time, and in advance for info you may have on the above.

Discussed Dec 8, 2025 (See Github)

Matthew: Will look at their latest comment.

Discussed Dec 15, 2025 (See Github)

Matthew: Another one where the proponents came back with new information. Did put my thoughts on a comment. Most of there update seems good, still thinking about no. 1 where orientation needs to be taken into consideration. Need more time to think about it. It was a detailed answer, rest seems reasonable. Need to decide whether no. 1 is also fine, or need to ask them another question. Will either get back to them about no. 1, or post a comment on the private brainstorming thread, saying "satisfied" before Thursday.

Discussed Jan 5, 2026 (See Github)

Matthew: We asked a load of questions. Got many answers. I wasn't entirely clear, so they answered a question other than what I asked, but their answer satisfies my real question anyway. Seems all good to me. I left a comment recently to explain where I think the confusion might have been, and to say it looks fine and say what I understand. They're thinking about it in some good ways in terms of not subtly changing how ARIA works and not being too dependent on it, but let developers do common-but-tricky things. Question that remained was about orientation, and they've clearly thought about it and specified it in a good way. Uses logical orientation (inline+block rather than left+right+up+down). Can constrain keyboard handling to work in a particular direction, and they have the right escape hatches.

Jeffrey: You'll post a comment to confirm your understanding, and if they confirm, close with satisfied?

[general agreement with Matthew's draft comment.]

Comment by @matatk Jan 5, 2026 (See Github)

Thanks for your clear and comprehensive reply, @janewman - this sounds good.

Just one point I'd like to clarify regarding question 1, about orientation. I think I wasn't clear in my question (sorry about that), and that you've answered "will focusgroup affect the exposed aria-orientation attribute value?" - but I was meaning to ask "will focusgroup be affected by the given aria-orientation attribute value?"

Your answer, plus your reminders of the relevant parts of the explainer, do answer my question though - by default, both axes of arrow keys will respond, and the author can limit that to the inline or block axis as desired. It also seems that the value of aria-orientation is not influential in any way (though the role of controls may be). If I'm understanding correctly, this does mean that there may be some cases where the author needs to specify both an aria-orientation value, and an optional inline or block constraint for the focusgroup, but that doesn't seem too onerous (and is consistent with the rest of how focusgroup works).

tl;dr: Again this all sounds reasonable. It will be great to see this feature come to the web!

Comment by @janewman Jan 5, 2026 (See Github)

That all lines up with my thinking, thanks for reviewing!

Discussed Jan 12, 2026 (See Github)

Matthew: Proposed by Open UI. We had some questions, they got back to me. We are in agreement. We didn’t discuss what to do with it, but I would suggest to close it as "satisfied."

Martin: What’s the implementation status?

Matthew: There isn’t an indication from the other two.

Martin: Whis is unfortunate, as it could be good.

Matthew: Should we reach out to Mozilla/WebKit?

Lola: Not really our business.

Matthew: Concern is, I can’t see anything in here that would be hard to implement.

Lola: Think we don’t have to have a resolution right now, we can go back to them and ask them regarding the implementation status in browsers, and let them come back to us.

Matthew: Could put a comment, had you have any concerns raised by implementers?

Lola: Or, if they know about implementation commitment.

Matthew: What we don’t have, but we could ask if things are hard to implement.

Christian: "The other two" was Gecko/WebKit?

Matthew: Confirmed.

(Group consensus: Not closing as satisfied yet.)

Comment by @matatk Jan 19, 2026 (See Github)

@janewman: We see that there isn't an official position from Gecko or WebKit. Are you aware of any implementation concerns that they may have, or of any forthcoming commitment to implement?

Comment by @janewman Jan 20, 2026 (See Github)

Mozilla has had some comments on the Draft HTML Spec I've authored, see: https://github.com/whatwg/html/pull/11723, but I'm still waiting to get feedback from Apple. Focusgroup has been discussed at length with people working on the other browser engines in several forums at this point, AriaWG, OpenUI, and WHATWG, and I've updated the explainer and chromium implementation to address any concerns brought up in those discussions.

I'm not aware of any commitments to implement.