search

WebKit / standards-positions

WebKit's positions on emerging web specifications
https://webkit.org/standards-positions/
254 stars 23 forks source link

focusgroup attribute #171

Open lukewarlow opened 1 year ago

lukewarlow commented 1 year ago

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 commented 1 year ago

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

cookiecrook commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

cookiecrook commented 1 year ago

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 commented 1 year ago

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.