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

[travisleithead]

Mentioned first in issue #990.

In some cases, a focusgroup's capability of scrolling the document to the next focusable item in a focusgroup can be in conflict with a user's need to use the arrow keys to manually scroll a scrollable container in order to read all content.

See demo by @scottaohara: https://codepen.io/scottohara/pen/abMaxNx

In such situations, focusgroup needs to give priority to scrollable-area scrolling.

One proposed solution is to automatically disable focusgroup arrow-key navigation to the next focusable item when that next focusable item is not "in view". In which case, once arrow-key scrolling has moved the item into view, then the focusgroup arrow-key navigation will move the focus to that item.

• Pros: resolves the issue, can be automatic.
• Cons: makes focusgroup arrow key navigation a bit less predictable if the arrow key will "magically" switch between content scrolling and focusgroup navigation. (May need to experiment with this in the case of a listbox-scenario to see how unexpected it is...)

[travisleithead]

The wrap capability may also be impacted by this...

From @gfellerph

In Scotts example was a small scroll area filled with long content accordion items. The titles are focusgroup candidates and while the first title is focused, the content is so long, that the second title is out of view. The issue describes that the focus should not jump to the second title when the arrow down key is pressed, but should rather scroll the container until the second title is in view and then focus it. The first title is now out of view. If wrapping behavior is applied to the focusgroup, an arrow down keypress should jump back to the first title, but it's out of view so the focusgroup does not capture the event and the page/container scrolls further down (or does nothing if the end of the page is reached).

This could just be handled with an exception to that rule, but I don't really know what's expected from a user perspective vs. what's defined in markup.

[travisleithead]

Thinking about @scottaohara's idea of a modifier key, and if we can't make a default solution "just work" (I'm not saying we can't, but just generating some other possibilities...) I wonder if Shift+Arrow keys could be a built-in fallback to enable the UA to scroll the scrollable area when focus is on a focusgroup element inside of a scrollable container. "Shift" + arrow keys is typically reserved for patterns in which selection should be extended, so maybe not a good idea if it gets in the way of some actual JS selection logic... Another approach is a built-in on/off toggle mechanism. A bad example: the never-used ScrollLock key on some physical keyboards that could be used to toggle between arrow key navigation and arrow key scrolling behavior...?

[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.