focusgroup Is Here. The Accessibility Questions Aren't Answered Yet.

Chrome 150 shipped focusgroup before any formal spec exists. That's not unusual in browser development — but for keyboard navigation and screen reader compatibility, the timing creates real risk.

One browser. No WHATWG spec. A handful of CodePen demos. That's the current state of focusgroup, a proposed HTML attribute that Chrome 150 has now shipped into the wild. Adrian Roselli's detailed testing of the feature (opens in new window) is the clearest early look we have at how this proposal behaves in practice — and what he found should prompt accessibility practitioners to pay close attention, because the window to influence this feature is open right now, and it won't stay open long.

What focusgroup Actually Does

The premise is straightforward. Today, building composite ARIA widgets — listboxes, menus, tablists, radiogroups, toolbars — requires custom JavaScript to manage keyboard navigation. Arrow keys, wrapping behavior, focus roving: developers write this by hand, and they frequently get it wrong. focusgroup proposes to bake that navigation logic into the browser itself, declaratively, via an HTML attribute.

The Open-UI explainer (opens in new window) is currently the only documentation that exists. Not a W3C spec. Not a WHATWG standard. An explainer. That's the authoritative reference practitioners are working from today.

Roselli's demos cover six composite ARIA widget types: listbox, menu, menubar, radiogroup, tablist, and toolbar. He built them without scripting — the point was to isolate what the browser does natively. The results are instructive, and some are troubling.

The Bugs That Matter for Keyboard and Screen Reader Users

Roselli flagged four observations from his testing that deserve direct attention from an accessibility standpoint.

First, focusgroup="none" — intended to exclude a specific child element from the focus group — doesn't behave as expected. The excluded element and its neighbors all accept Tab focus, presenting as the first three buttons in sequence accepting focus when only one should. That's a navigation model that will confuse keyboard users.

Second, when an element is removed from the focusgroup via focusgroup="none", it retains its ARIA role rather than being assigned the required accessibility child role for the widget. If a developer uses this to create something like a disabled-state workaround, the accessibility tree will misrepresent what the element is.

Third — and this one has architectural implications — applying role="presentation" or role="none" to a node that carries focusgroup has no effect. The focusgroup role still surfaces in the accessibility tree and through Assistive Technology APIs (AAPIs). That means developers cannot use focusgroup for its interaction benefits while stripping the semantic role they don't want. The interaction and the semantics are coupled. Roselli flags this as a potential bug. It's also a constraint that will generate real-world errors when developers misunderstand it.

Fourth, NVDA and JAWS users cannot navigate letter-by-letter within a button while in forms/application mode — a standard interaction that normally works fine. This is the kind of nuanced screen reader behavior that automated testing will never catch. As research on testing methodology consistently shows, automated tools detect at most 37% of accessibility failures against comprehensive manual audits. focusgroup bugs will fall squarely in the 63% that only human testing with assistive technology reveals.

Why Pre-Spec Shipping Creates Compliance Risk

focusgroup is shipping in Chrome before it enters any normative specification. Open-UI has outsized representation from Google and Microsoft, which explains the Chrome-first implementation — but it also means the feature's design is being shaped by a small set of organizational perspectives before the broader accessibility community has formally weighed in.

Once browsers implement behavior and developers build on it, the practical cost of changing that behavior rises dramatically. This is how inaccessible patterns get ossified. The Web Content Accessibility Guidelines (opens in new window) require that keyboard navigation be operable and that the accessibility tree accurately represent component semantics. If focusgroup ships with the bugs Roselli documented — particularly the role="presentation" issue and the forms-mode screen reader behavior — those bugs become the baseline that developers build against.

For organizations subject to Title II and Title III compliance obligations, this matters practically. When a government agency or covered entity deploys a widget built with focusgroup, the question isn't whether the developer used a new HTML attribute. The question is whether a keyboard-only user can operate it and whether a screen reader user receives accurate information. The law doesn't care that the underlying technology was pre-spec. The DOJ's web accessibility guidance (opens in new window) is clear that WCAG 2.1 Level AA is the operative standard, and WCAG Success Criterion 4.1.2 — Name, Role, Value — applies regardless of implementation mechanism.

The compliance framework challenges organizations already face are substantial. Adding a browser feature that introduces new semantic behaviors before those behaviors are validated against assistive technology compounds that complexity.

What the Behavior Table Reveals

Roselli's behavior table documents default direction (block vs. inline), wrapping behavior, and default accessible child roles across the six widget types. A few observations stand out:

• toolbar has no default accessible child role — "nope" is Roselli's entry. That's not a trivial gap for a widget that typically contains interactive controls.
• radiogroup navigates on both axes by default, which differs from the unidirectional defaults of other widgets. That's a meaningful behavioral distinction developers will need to understand explicitly.
• Wrapping behavior varies: listbox and toolbar don't wrap; the others do. This matches expected ARIA patterns, but only if developers understand the mapping.

The explainer is doing real work here that a spec would normally do. That's a fragile documentation model.

The APG Problem Roselli Raises

Roselli notes his frustration that the explainer leans on ARIA Authoring Practices Guide (APG) patterns as if they are the standard, while linking to MDN rather than the actual ARIA specification. This isn't a minor editorial complaint. The APG is guidance, not normative. When a browser feature's design documentation treats APG as authoritative, it risks encoding patterns that the accessibility community has debated or, in some cases, identified as anti-patterns.

His specific example — the explainer referencing menu for website navigation — is well-documented territory. Using ARIA menu and menuitem for site navigation creates screen reader announcements and keyboard expectations that don't match how navigation actually works on the web. If focusgroup ships with examples that reinforce this pattern, the feature will actively make it easier for developers to build inaccessible navigation.

The Action Window

Roselli's call to action is direct: test the feature now, document what's wrong, and report it before the spec or browser implementation hardens. The Great Lakes ADA Center (opens in new window) and other regional ADA centers have long emphasized that proactive participation in standards development is more effective than reactive remediation after standards are set.

For practitioners, the practical steps are specific:

• Test the demos in Chrome 150 with actual assistive technology — NVDA, JAWS, VoiceOver. Roselli has done initial passes; more coverage across AT combinations is needed.
• Document role exposure issues in the accessibility tree using browser accessibility inspectors (Chrome DevTools, Firefox Accessibility Inspector).
• File issues against the Open-UI focusgroup proposal (opens in new window) with specific, reproducible findings.
• Watch for the role="presentation" coupling issue — this will generate real-world WCAG 4.1.2 failures if it ships as-is.

The testing methodology gap here is real. As analysis of hybrid testing approaches shows, neither automated tools nor manual audits alone are sufficient for validating complex interaction patterns. focusgroup requires hands-on assistive technology testing across multiple combinations — exactly the kind of evaluation that's hardest to scale but most necessary for a feature that will affect keyboard navigation across the web.

focusgroup could meaningfully reduce the number of broken keyboard interactions on the web. The proposal addresses a real problem. But "could" is doing a lot of work in that sentence. What it actually does — for the keyboard users and screen reader users who depend on these widgets working correctly — depends on whether the accessibility community engages now, while the implementation is still plastic, rather than after it becomes the default.