[Focusgroup] Navigation in screen readers on touch devices?

[Malvoz]

Can we expect focusgroups to be navigable by screen reader users on touch devices? With a somewhat limited set of basic/simple user gestures, is it possible that focusgroups may perhaps not improve the situation for these users in particular?

[Malvoz]

/cc @travisleithead

[chrisdholt]

Can we expect focusgroups to be navigable by screen reader users on touch devices? With a somewhat limited set of basic/simple user gestures, is it possible that focusgroups may perhaps not improve the situation for these users in particular?

I think that AT would necessitate specifically implementing the correct role, any corresponding ARIA, and any prescriptive DOM - I don't think focusgroup changes that situation and I'm not sure I'd expect it to. Certainly @travisleithead would be the best to confirm or elaborate here :).

[smhigley]

As far as I understand it, focusgroup behavior would have no impact on touch screen readers, as @chrisdholt implied :). This would not be different from how things work today -- a grid or tree's keyboard interaction patterns do not impact the touch experience.

[scottaohara]

Initially, I had the same thought as both @chrisdholt and @smhigley in that I wouldn't have even expected focusgroup to be a consideration on touch with a screen reader active (I honestly am not sure how much focusgroup will benefit people using screen readers on desktop devices either, since screen readers already provide quick navigation to elements already). But, maybe that's not actually the right assumption? Maybe this could be the impetus to potentially introduce further UX options for these users?

For instance, using iOS + VO on a web page where there is a group (or groups) of radio buttons – if I'm jumping through form control elements using up/down swipe, I will reach such a grouping of radio buttons. However, if this group does does not represent the radios I want to interact with, up/down swipe doesn't move me to the next non-radio button form control. Instead it moves me to the next radio button in the group that i wanted to bypass. If i want to quickly get out of this, I have to change my quick nav element type, or just continue to swipe through the radio buttons in the group.

Maybe there's something to think about here. Even per my above example, trying to switch to navigate by 'containers' doesn't allow me to navigate to different radio groups. Even if nothing is done to change the behavior of navigating to individual elements within a focusgroup, maybe exposing them in a manner that would allow the quick navigation to different focus groups is something that could be considered/exposed?

[Malvoz]

Linking https://github.com/w3c/aria/issues/1947.

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[travisleithead]

Regarding https://github.com/openui/open-ui/issues/573#issuecomment-1278898701, it seems odd to me that VO would automatically switch from a pseudo-Tab based control navigation to an pseudo-Arrow key navigation for radio buttons, but alas, this must be what their users want or expect. Perhaps the guiding principle is that the swipe gesture can be used to get to all the possible activatable/invokable things on the page, and as radio control elements are separate elements, they get navigated as such (despite being only one Tab-stop for Tab navigation).

In any case, the way focusgroup is specified, it doesn't strictly enforce a "single-tab stop" semantic--the number of Tab stops > 1 will be up to the developer to indicate with the tabindex attribute, so having an AT like VO move from one activatable/invokable candidate in a focusgroup to the next seems like good default behavior for them.

If the ATs chose to add a new document-wide navigation-by-focusgroup key, that would be pretty cool too.

[travisleithead]

Current plan:

• Consider closing, unless new information surfaces?