[focusgroup] clarify and handle cases where scrollable regions have focusgroups (accessiblity)

[w3cbot]

This is a tracker issue. Only discuss things here if they are a11y group internal meta-discussions about the issue. Contribute to the actual discussion at the following link:

§ openui/open-ui#1008

[travisleithead]

Executive summary: there is a conflict for the default use of arrow keys when in the presence of a [proposed] focusgroup: to scroll a scrollable or to move focus to a focusable.

[AutoSponge]

I don't like the proposed behavior. I like Scott's approach of using a modifier key. But I feel like that's going to be hard to do since JavaScript will be controlling the roving tabindex behavior and the browser is handling scroll. The inverse could be possible and while it muddles and affordance, it's still holding that the default (scroll with arrows) works for most. The only situation I can predict where that could be problematic, is if the scrolling focusgroup is a radiogroup. In that case, the browser is controlling both behaviors and Scott's idea makes sense.

So, my counter proposal would be something like: when the browser controls both the focus group and scrollable, a modifier key will be used to scroll. When only scroll is controlled by the browser, authors SHOULD use roving tabindex pattern with a modifier key. When only focus group is controlled by the browser (not sure why but probably possible with scroll none and some fancy script), authors SHOULD facilitate scroll with a modifier key.