Focusgroup Tests

Chrome 150 has landed support for focusgroup, a feature proposed by Open-UI and not yet in WHATWG HTML as anything more than a feature request. Open-UI has outsized representation from Google and Microsoft folks, so it’s no surprise Chrome would implement it first.

Open-UI has a handy focusgroup explainer, which is the only place (inside or outside of a spec) to understand how to use it and what it’s meant to do. Which means this is your best opportunity to play with it before it gets into a spec.

To hopefully make that easier, I’ve created a series of very basic demos using the properties outlined in the explainer.

Demos

The effort has started with the composite (excepting toolbar) ARIA widgets listbox, menu, menubar, radiogroup, tablist, and toolbar. I’ve linked to the ARIA spec instead of APG. These map to specific behaviors, based on APG’s keyboard guidance.

There is no scripting in any of these demos. The only styles are to honor dark / light mode, make focus styles more obvious, and add some text defaults. None of the controls do anything. The labels are nonsense. I left a set of boring default HTML buttons at the end of each demo as a comparison.

Observe how the axis of movement is based on the default widget visual display. For example, listbox wants up and down arrows because they are generally vertically stacked (block). My demo, however, makes no effort to set a layout. This is not a focusgroup bug, but if you use listbox for something like “pills,” which are generally horizontal (inline), then you would need to address that.

With all the available properties, there are more permutations than I have coded. I also haven’t done complex nor nested demos. I just don’t have the time. But you, dear reader, probably enjoy pointing out things I missed. Please do so. Make your own examples. Play around. Try your own use cases and expectations. Leave comments letting me know what I, or the proposal, got wrong.

If you work in digital accessibility, you have an opportunity to find gaps that others might miss (especially in how roles are exposed). Let’s get those documented before the spec or browsers ossify code that cannot be readily changed in the future. Let’s help ensure developers won’t create more inaccessible experiences simply by using this new property.

You’ll need Chrome 150 to test these today, but as more browsers add support these will still be useful.

listbox

View the listbox demo pen directly or open the listbox demo in debug mode.

See the Pen focusgroup="toolbar" by Adrian Roselli (@aardrian) on CodePen.

menu

View the menu demo pen directly or open the menu demo in debug mode.

See the Pen focusgroup="menu" by Adrian Roselli (@aardrian) on CodePen.

menubar

View the menubar demo pen directly or open the menubar demo in debug mode.

See the Pen focusgroup="menubar" by Adrian Roselli (@aardrian) on CodePen.

radiogroup

View the radiogroup demo pen directly or open the radiogroup demo in debug mode.

See the Pen focusgroup="radiogroup" by Adrian Roselli (@aardrian) on CodePen.

tablist

View the tablist demo pen directly or open the tablist demo in debug mode.

See the Pen focusgroup="tablist" by Adrian Roselli (@aardrian) on CodePen.

toolbar

View the toolbar demo pen directly or open the toolbar demo in debug mode.

See the Pen Untitled by Adrian Roselli (@aardrian) on CodePen.

Notes

In very quick tests, a few things jumped out at me:

• In the focusgroup="none" test across all patterns, I found the button with focusgroup="none" as well as those flanking it accepted focus from Tab↹. It presents as the first three buttons accepting focus (the second one has focusgroup="none"). I understand why, but that feels like a bug.
• The interactive child with focusgroup="none" (to remove it from the focusgroup) keeps its role from the element, instead of assigning it the required accessibility child role. That might feel like a bug if you expect focusgroup="none" to work like a weird disabled state (it’s not).
• Adding role="presentation" to a node with focusgroup has no effect. The role from the focusgroup is still exposed in the accessibility tree and AAPIs. This is also true for role="none" (none is a synonym for presentation). This means you cannot apply focusgroup and then un-role it to keep the interaction but avoid the other requirements of the role. This feels like a bug?
• James Scholes has corrected my misunderstanding. When using NVDA or JAWS, the virtual cursor will not let me go letter-by-letter within a button (handy for getting the spelling) unless I leave forms mode (by pressing Esc in JAWS, for example). This is different from how I can typically interact with buttons. That feels buggy but I am not a daily screen reader user.

A table tracking what property behaviors are exposed from my tests.

Opinions

I’m frustrated the explainer leans on APG patterns as if they are a, or the, standard while pointing only to MDN instead of the actual ARIA standard. I understand why, but you may know how I feel about APG.

I’m frustrated the menu example refers to web site navigation, when there is years-old evidence showing that as an anti-pattern. I’m working on a web site navigation post to address this.

I’m frustrated yet pleased navigation across a two-axis construct, such as an ARIA grid, is deferred. Though I understand that gets more complex.

While I’m thrilled this isn’t going into CSS, I’m worried that it isn’t completely off the table. I’ve so far been unimpressed with the CSS Working Group’s ability to address accessibility concerns.

I’m excited to see these ARIA concepts finally make it to HTML (if only as a proposal so far). This fits the original model of ARIA as a temporary, bridging technology until HTML caught up. Which hey, maybe that will start to happen.

While I like that using focusgroup brings ARIA roles for free (in the accessibility tree and exposed to AAPIs), I’m worried how readily developers will unintentionally role-up standard HTML just to get free arrow key interactions. One Open-UI explainer menu example fails to remove roles from lists, demonstrating how easy it is to forget unless your testing is robust.

In April, Steve Frenzel shared his own in My thoughts on the “focusgroup” attribute proposal for an older proposal.

Added to Link + Disclosure Nav

6 July 2026. Open-UI’s focusgroup Quickstart (incorrectly) uses the APG menu navigation pattern. In mid-2019 I responded to the APG pattern with a link & disclosure navigation prototype. Today I forked it (debug view) and added focusgroup="menubar", something I half expect authors to try.

See the Pen 2017 Link + Disclosure Nav with `focusgroup` by Adrian Roselli (@aardrian) on CodePen.

I got some interesting results:

Using only focusgroup="menubar":

No roles change.

Using focusgroup="menubar":

Child <li>s lose their role.

Using both:

Child <li>s lose their role.

<button>s in child <li>s role-up to become menuitems.

I don’t know if this is a bug, but it certainly feels like someplace a dev can get confused when determining where to apply ARIA roles for accessibility children of the navigation.

Update: 10 July 2026

The Microsoft Edge team is working on an explainer, Focus Landmark: declarative landmark focus navigation for web apps. It looks like it might using the momentum from focusgroup to pitch focuslandmark, possibly with similar ARIA-role-setting tokens. Discussion is already happening at Open-Ui issue #1472 [focuslandmark] No declarative way to move keyboard focus between major page regions. Sarah Higley linked to Carolyn MacLeod’s years-old Web We Want request.