My thoughts on the "focusgroup" attribute proposal - Steve Frenzel

Table of contents

What it’s supposed to do

Things I like

Things I’m not sure about

Conclusion

What it’s supposed to do

You can read the proposal here: Request for developer feedback: focusgroup. Here is the summary of what the focusgroup attribute is meant to do:

The focusgroup HTML attribute is a proposed declarative way to add keyboard arrow-key navigation to composite widgets such as toolbars, tablists, menus, listboxes, etc. without writing any roving-tabindex JavaScript. One attribute replaces hundreds of lines of boilerplate. […]

That sounds very promising, since these patterns are very popular but, unfortunately, also significantly more complex. A native solution that eliminates dependencies and handles the heavy lifting when it comes to keyboard usage? Sounds like the best of both worlds!

When you when to implement a toolbar pattern, you’ll not only have to take care of name, role, value of all involved elements, but also keyboard functionality. It could look something like this in HTML:

div role="toolbar" aria-label="Text formatting" id="toolbar"><br>button type="button" tabindex="0">Boldbutton><br>button type="button" tabindex="-1">Italicbutton><br>button type="button" tabindex="-1">Underlinebutton><br>button type="button" tabindex="-1">Strikethroughbutton><br>div><br>Here, you’ll have to consider the following things:

Writing mode and RTL: Adjust arrow key directions based on content direction.

Last-focused memory: Restore focus to the previously active item when a user Tabs back in.

Disabled and hidden items: Skip over them during navigation.

Dynamic items: Update the roving index when items are added or removed.

With the focusgroup attribute, it would be done this way in HTML:

div focusgroup="toolbar" aria-label="Text formatting"><br>button type="button">Boldbutton><br>button type="button">Italicbutton><br>button type="button">Underlinebutton><br>button type="button">Strikethroughbutton><br>div><br>Which is supposed to offer the following features out of the box:

Arrow key navigation: Navigate between items, while respecting writing mode and directionality.

A single Tab stop: The browser collapses participating items into one Tab stop automatically. Developers don’t need to set tabindex="-1" on non-active items.

Last-focused memory: When a user leaves the focusgroup and returns, focus is restored to the item they left.

ARIA semantics: The browser supplies appropriate roles (like role="toolbar") based on the behavior chosen when generic elements are used.

Things I like

In general, I’m super stoked about this proposal! In this section, I’ll point out specific things that made me go “it’s really smart they thought about this!”.

The focusgroupstart attribute helps you to define which element should be focused first.

focusgroup="toolbar block" let’s you traverse this pattern only vertically using the arrow keys, but not horizontally.

Horizontal tablist with wrapping: Allows you to loop through with the arrow keys, but you can break out any time using the TAB key.

Clear distinction between keyboard navigation and the managing of selection state. The first is handled by focusgroup, the latter must be done via JavaScript.

Independent nested scopes: “When a focusgroup is nested inside another, they are completely independent. Each has its own navigation axis, wrapping behavior, memory, and entry point. Arrow keys only affect the focusgroup that currently has focus within it.” Nice!

Things I’m not sure about

Menu and menubar: It would be great if they would clarify the difference between a menu and a navigation here. These are often confused or not distinguished at all.

Radiogroup: I don’t understand the purpose of the radiogroup pattern, since there’s already the element? Also, tabindex is added in this example, and isn’t this one of the things they wanted to avoid?

Chatbot pattern: When using JAWS and NVDA in Google Chrome and Microsoft Edge, there’s no feedback or indication regarding the generated messages, their content, or that they can be found above the input field. This is something that should be considered, as this might confuse screen reader users and could make them think nothing happened.

Conclusion

I’m sure it’s not easy to bring together so many similar yet distinct and complex patterns using a single attribute. I’m already very excited about what’s being proposed here and have high hopes for it! This could resolve a major bottleneck in development, since these patterns are used very frequently.

Above all, I hope there will be a simple, easy-to-understand explanation of the individual patterns, so that users don’t end up bearing the consequences because it wasn’t clear to developers when to use which one.

My thoughts on the "focusgroup" attribute proposal<br>Steve Frenzel<br>Using only HTML to create complex patterns like menus and tabs.<br>April 20, 2026<br>Table of contents

What it’s supposed to do

Things I like

Things I’m not...