[focusgroup]: should focusgroup require the use of a modifier key? or ??? for unexpected patterns

Back in August 2023, the ARIA WG discussed the focusgroup proposal. My apologies for taking so long to make this issue.

The following questions/concerns were raised:

Since focusgroup could apply to focusable content, including content that generally does not have wide expectations to be navigable via arrow keys (e.g., hyperlinks), what considerations can be/should be made to ensure that:

1. assistive technology will handle this correctly (e.g., JAWS/NVDA in their default 'automatic forms mode' have behaved oddly (at least last time tested) when navigating focusgroup elements that aren't expected to keep a user in forms mode
2. that sighted keybord users will be able to readily understand when website A has used focusgroup for their primary navigation, but website B uses traditional tab navigation.

While I know the example in this linked comment is not necessarily meant to demonstrate how someone should use focusgroup, it being a potential valid example demonstrates both a markup pattern that could result in the JAWS/NVDA in/out of forms mode behavior I mentioned, as well as significantly buck user expectations for how such standard content should be navigated.

Outside of having screen readers be able to support arrow key behavior on elements that have not ever had an expectation of default arrow key navigation, and how to visually communicate this to people in general... is overriding standard arrow key behavior actually a good idea outside of the patterns (which are largely not native to the web platform and require someone use ARIA to build them now) where arrow key navigation is expected?

Take arrow key navigation through an accordion for example. On its surface this seems like something people might immediately think to do - allow for arrow key navigation to jump between the triggering elements for each accordion panel. The issue with this though is that an accordion panel can contain lots of content - and may/may not contain other focusable elements for the user to navigate to.

In the scenario where an accordion does contain focusable element (such as hyperlinks), what then is the expectation for the next tab key press if the accordion triggers are all part of the focus group? Should tab key go to the next accordion trigger, since it would have been the next focusable element if not for the focusgroup behavior? Or, would tab focus move to the next focusable element AFTER all the accordion triggers that participate in the focusgroup?

Next, let's consider an accordion that doesn't have any focusable content within its panels. While this might seem like a non-issue for people using large viewport sizes, people who have to zoom in to read content (1.4.4 Text Resize or 1.4.10 Reflow WCAG SCs) or who may just generally be on smaller screens but require the use of keyboard to navigate their device (bluetooth keyboards for touch devices). Arrow keys should allow these users to scroll the viewport so they can read the content. But if arrow key navigation is overwritten to instead move focus between the accordion triggers, then you get something like this - https://codepen.io/scottohara/pen/abMaxNx - where at the simulated Reflow viewport size, parts of the content cant be scrolled into view because arrow keys jump between the accordion buttons.

Too many words scott, again, what do you want?

The idea that some of these concerns could be resolved if arrow keys alone were not used as the default way to navigate focusgroup content (edit for clarity: specifically content that does not have a history of using arrow keys for navigation). (browsers could potentially include a toggle to allow users to make their own choice about whether they wanted to navigate focusgroup content by [modifier key} + arrow keys, or arrow keys alone).

Going this route would open the potential for both currently expected keyboard navigation to coexist with the modified and improved (regardless of all the concerns mentioned, the ARIA wg does want this proposal to succeed and acknowledges the need for it) focusgroup navigation.

This wouldn't necessarily resolve the discoverability issue, but arguably if people are made aware of this new feature / even purposefully opt into it, then they can start to expect it. E.g., it would be less frustrating to come to a website navigation and find that tab key doesn't work, and have to determine that they need to switch keyboard navigation methods to get to the page they want to - than it would to come to a web page and check to see if (for example) ctrl + arrow key works, and if it does great, and if it doesn't, well they then know the tab key will work.

If this solution doesn't hold water for some reason, that's fine. But, we do need to have a longer think on how to resolve the concerns mention in my word mess, above. I have other (lesser, imo) ideas of what could be done... but I'll save those for another time.

Start by reading the focusgroup proposal and the linked comment in open-ui#537, then review the CodePen example to understand the scrolling and keyboard-navigation concerns. A completed outcome would be a resolved design or specification direction for modifier-key use, tab behavior, assistive-technology handling, and viewport scrolling.