add mapping for html focusgroup attribute

[cyns]

It's still early, but let's start thinking about this
The focusgroup attribute changes keyboard behavior. How should it map to AAPIs?

https://open-ui.org/components/focusgroup.explainer/
https://chromestatus.com/feature/5637601087193088
https://bugs.chromium.org/p/chromium/issues/detail?id=1286127

[scottaohara]

related openui/open-ui#990

i've been thinking about this for some time and have brought it up to the group before. glad to have a more official conversation here though.

[aleventhal]

Does it even need a special mapping? It affects keyboard navigation, therefore focus events, and the internal items will be exposed as focusable.

…

On Thu, Sep 26, 2024, 4:06 PM scottaohara ***@***.***> wrote: related openui/open-ui#990 <openui/open-ui#990> i've been thinking about this for some time and have brought it up to the group before. glad to have a more official conversation here though. — Reply to this email directly, view it on GitHub <#565 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKQAZVQFKQFYIR5D5ORFX3ZYSHNXAVCNFSM6AAAAABO55AYQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZYGA4TKMZXGM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[scottaohara]

it may need something... without doing anything screen readers with auto forms mode can get really squirrely since a focusgroup could consist of elements that are already expected to receive focus/stay in forms mode and elements that are supposed to pop a screen reader out of forms mode.

some sort of signal to help them accommodate / prevent that behavior would be good.

i still generally think - from many user studies i've seen now where people get tripped up by having to use arrow keys where they would have expected tab key - that this feature shouldn't necessarily be global. not at least without doing a better job to inform all users that behavior is not what they might expect (e.g., for a navigation full of regular links that someone decided just needed to be in a focusgroup)

but again, absolutely excited for this feature for the places where we need it - grids, toolbars, menu/menubars... the places where people expect a focusgroup to happen :)

[aleventhal]

Thanks for explaining. That makes sense to me. I think links would indeed be an issue if they were the focus items. However, it's the same problem that one would have if they used aria-activedescendant to point to links, or the roving tabindex method. So in a way this problem already exists, but we're making it easier to make a mistake. Is it worth considering having focusgroup be ignored when the focusitem elements don't match an expected pattern? We could put an error on the console in that case.

…

On Fri, Sep 27, 2024 at 4:09 PM scottaohara ***@***.***> wrote: it may need something... without doing anything screen readers with auto forms mode can get really squirrely since this could consist of elements that are already expected to receive focus/stay in forms mode and elements that are supposed to pop a screen reader out of forms mode. some sort of signal to help them accommodate / prevent that behavior would be good. i still generally think - from many user studies i've seen now where people get tripped up by having to use arrow keys where they would have expected tab key - that this feature shouldn't necessarily be global. not at least without doing a better job to inform *all users* that behavior is not what they might expect (e.g., for a navigation full of regular links that someone decided just needed to be in a focusgroup) — Reply to this email directly, view it on GitHub <#565 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKQAZSNYPYUYMZO5IDAMZ3ZYW3OPAVCNFSM6AAAAABO55AYQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZZHE3TONZTGY> . You are receiving this because you commented.Message ID: ***@***.***>