focusgroup attribute

[lukewarlow]

WebKittens

No response

Title of the spec

focusgroup attribute

URL to the spec

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

URL to the spec's repository

https://github.com/openui/open-ui/blob/main/site/src/pages/components/focusgroup.explainer.mdx

Issue Tracker URL

No response

Explainer URL

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

TAG Design Review URL

https://github.com/w3ctag/design-reviews/issues/732

Mozilla standards-positions issue URL

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

WebKit Bugzilla URL

https://bugs.webkit.org/show_bug.cgi?id=255482

Radar URL

rdar://108403002

Description

A new HTML attribute that allows for creating focusgroups that are navigable using arrow keys without needing to use JavaScript. (See explainer for a far better explanation)

[hober]

Added concerns: venue because this should be discussed in the HTML Workstream at WHATWG.

[cookiecrook]

Overall I think the focusgroup proposal is a good idea, will be useful to authors, and will be more accessible to users. I'd like to see an example of this non-goal issue.

Stated under "Non-Goals" heading:

For this proposed standard, we decouple selection from focus and only focus (cough) on the focus aspect: moving focus using the keyboard among eligible focus targets. Adding selection state, e.g., tracking the currently selected option in a list, will be a separate feature. To handle selection-based scenarios, we defer to the CSS proposal Toggles which can work nicely with focusgroups.

This intended decoupling of focus and selection may require AT changes (e.g. VoiceOver) in addition to User Agent (WebKit) additions. As such, I think we would need to see an example of the Toggles+FocusGroup combo example that is alluded to here. Especially for an interactive ARIA grid, with multiple selection and multi-directional focus via focus-group-direction: horizontal; perhaps including the wrap options.

[cookiecrook]

Another item I think is missing from the proposal is that an extension interface or assistive technology (e.g. VoiceOver or another) should be able to drive this "roaming/roving tabindex" selection if needed. For example, by calling UA focus() on one of the tabindex="-1" elements, in the same way that a mouse user could click to set focus directly, even if it's not Tab-focusable.

[lukewarlow]

For any concerns or additions, I recommend filing issues in the open-ui GitHub.

[cookiecrook]

Assuming there's a missing question mark after the word additions above. In any case, I'm having trouble parsing... Also that the venue concern appears acknowledged but then dismissed in the same sentence.

[lukewarlow]

I'm just a web developer, not someone working on this proposal.

I merely meant any feedback you have would be welcomed in the open UI repo so they can integrate that feedback into the API design.

I've raised an issue to query moving the spec to a WHATWG/html PR but I suspect this would require multi browser interest to champion and land this API.

Apologies the previous comment didn't make much sense after rereading it. I have corrected it to make more sense.

[janewman]

Hi folks, the focusgroup explainer has evolved since this was last visited, and I recently created a new, "Scoped" version of that explainer that takes all of these advancements and then scopes the behavior in a few different ways:

• Moves 2D grid navigation to a future consideration.
• Moves CSS support to a future consideration.
• Requires a new "behavior" attribute that will be used to compute a minimum aria role, ensuring that focusgroups are accessible-by-default.

I would love to get feedback on the approach; I intended for this to resolve the biggest remaining points of contention. https://open-ui.org/components/scoped-focusgroup.explainer/