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: ***@***.***>

[smhigley]

Adding a thought here responding to the closing proposal in the ARIA call to have something like a minimum role for this--

I don't think a minimum role would be good here, since I imagine most of the use cases for needing a default mapping would be when focusgroup is applied to things like buttons or links that already have a role that we don't want to override.

I wonder if it'd be possible to have a default attribute mapping, similar to how applying patterns works in IA2 or UIA (e.g. like putting SelectionPattern on top of a list or grid, without affecting the role). That's more of a squishy idea since:
A) we don't have an attribute that would cover this
B) we don't have an existing mapping in any API I know of that would make sense
C) I don't think screen readers are set up to pay attention to something like this for things like mode switching behavior

I do think all of those are actually problems with the original challenge, though, rather than with a default attribute approach specifically. If the purpose of focusgroup is to expose a set of controls, regardless of role/purpose, as an arrow-navigation region, then I think that means we need something entirely new in ARIA, browsers, mappings, and AT.

What do other folks think? Especially anyone who works on screen readers with interaction modes?

[spectranaut]

discussed at last week's meeting: https://www.w3.org/2024/11/07-aria-minutes#630b