Chrome 150 Ships focusgroup: Adrian Roselli's Tests Find Role Bugs

Chrome 150 shipped support for focusgroup, an attribute that maps six composite ARIA widgets to keyboard behavior with zero scripting — and Adrian Roselli's first-pass tests have already surfaced role-exposure behaviors that read like bugs.

The feature comes from Open-UI, where Google and Microsoft staff hold outsized representation, which explains why Chrome implemented it first. WHATWG HTML has nothing beyond a feature request (issue 11641). The Open-UI explainer is currently the only documentation, inside or outside any spec.

Roselli built script-free CodePen demos for listbox, menu, menubar, radiogroup, tablist, and toolbar, each linked to the ARIA spec rather than the APG and mapped to behaviors drawn from APG keyboard guidance. The only styles honor dark and light mode, make focus visible, and set text defaults. Nothing works. Labels are nonsense.

What do the tests expose?

In quick testing across all patterns, Roselli found:

• A button carrying focusgroup="none", plus its flanking buttons, still accept Tab focus — presenting as three focusable buttons where you might expect one excluded.
• An interactive child with focusgroup="none" keeps its element role instead of the required accessibility child role. That surprises you if you expected a disabled-state effect. It isn't one.
• role="presentation" and role="none" on a focusgroup node have no effect; the focusgroup role still lands in the accessibility tree and AAPIs. You cannot un-role a focusgroup to keep the interaction while dodging the role's other requirements.

Roselli also logged a default-behavior table: listbox and menu move on the block axis, menubar, tablist, and toolbar on the inline axis, radiogroup on both. Only toolbar gets no default accessibility child role.

He corrected one earlier claim after James Scholes pushed back on his reading of NVDA and JAWS virtual-cursor behavior.

Is the explainer itself clean?

No. Roselli is frustrated it leans on APG patterns as if they were the standard while pointing to MDN instead of the ARIA spec. The menu example originally used site navigation, an anti-pattern with years of evidence against it; on 14 July, Luke Warlow swapped it for a toolbar example (issue 1474, PR 1475). One explainer menu example also failed to strip roles from lists — issue 1476, filed 14 July, should address it.

A 6 July fork of his 2019 link-and-disclosure navigation prototype added focusgroup="menubar". Used alone, no roles change. Combined with role="menubar", child <li> elements lose their roles and buttons role-up to menuitems. Possibly a bug. Certainly a place where developers will confuse where ARIA roles belong.

His larger worry: developers will role-up standard HTML just to get free arrow-key interactions. He is also watching the CSS Working Group, unimpressed by its record on accessibility concerns, though relieved focusgroup landed in HTML territory rather than CSS.

Microsoft is already building on the momentum: the Edge team is drafting a focuslandmark explainer for declarative landmark focus navigation, discussed at Open-UI issue 1472, and has published its own undated focusgroup demos that predate Chrome's release. Roselli's demos need Chrome 150 today but stay useful as other browsers follow — and as accessibility practitioners document gaps before the spec ossifies code that can't be readily changed later.