HTML `focusgroup` attribute

[ramiy]

Description

This is an accessibility improvement for users that use keyboards to navigate websites..

Currently, developers can manage keyboard focus navigation among focusable elements (<a>, <button>, <summary>, <input>, <select>, <textarea> etc.) using "TAB" and "SHIFT+TAB" keys. To add navigation using "Arrow Keys" (left/right, up/down, home/end) for special groups of elements like Tabs, Accordions, Mega Menus, Carousels and others, we use JavaScript.

Developers have the ability to control keyboard navigation only with three global HTML attributes - tabindex, autofocus and inert. The focusgroup attribute is a complementary attribute that facilitates keyboard focus navigation using arrow keys (not tabs), among a set of focusable elements.

Specification

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

Open Issues

No response

Tests

No response

Current Implementations

• [ ] Blink
• [ ] Gecko
• [ ] WebKit

Standards Positions

https://chromestatus.com/feature/5637601087193088 https://github.com/mozilla/standards-positions/issues/631

Browser bug reports

https://bugs.chromium.org/p/chromium/issues/detail?id=1286127 https://bugs.webkit.org/show_bug.cgi?id=255482

Developer discussions

No response

Polls & Surveys

No response

Existing Usage

No response

Workarounds

Currently we use custom JS for arrow keys navigation.

Accessibility Impact

This feature has a huge potential to improve web accessibility by providing a built-in browser support for arrow-keys navigation among groups of focusable elements.

Privacy Impact

No response

Other

No response

[lukewarlow]

https://github.com/WebKit/standards-positions/issues/171 WebKit standards position request

[lukewarlow]

Focus group still needs design and spec work before it's ready to ship. And as much as I think it's a great idea I don't think it'll be ready in time for interop 2024.

[nt1m]

An OpenUI explainer does not meet the criteria for a spec, it needs work to be in a WHATWG living standard.

[scottaohara]

Agreed with the above. Focus group still has many open questions (many of which I have yet to file from discussion with the aria working group). This is not ready

[foolip]

From State of HTML preliminary results, the focusgroup attribute was among the features that respondents expressed the most interest for. Note that this wasn't freeform, it's based on the features the survey asked about experience and sentiment for.

[LeaVerou]

From State of HTML preliminary results, the focusgroup attribute was among the features that respondents expressed the most interest for. Note that this wasn't freeform, it's based on the features the survey asked about experience and sentiment for.

To provide more details, out of the features we asked about that corresponded to an Interop proposal, it came second in terms of interest:

In terms of freeform questions, focus management came up frequently as an a11y pain point:

…and a11y in general was the 3rd biggest interactivity pain point:

[jgraham]

Thank you for proposing HTML focusgroup attribute for inclusion in Interop 2024.

We wanted to let you know that this proposal was not selected to be part of Interop this year.

As of the deadline, the specifications for HTML focusgroup attribute were not yet complete enough to allow interoperable implementations. To make progress on this area in the future, it will first be necessary to ensure that the feature has a clear specification in a standards track document.

For an overview of our process, see proposal selection. Thank you again for contributing to Interop 2024!

Posted on behalf of the Interop team.