[focusgroup] Clarify tab behavior when focusgroup is bisected by an opted-out item

[janewman]

Problem

The current explainer didn't have much to say about how opted out items impact sequential focus navigation, this update remedies that by describing the behavior. When focus is on an opted-out element in the middle of a focusgroup, it isn't clear to a user if hitting tab or shift-tab will bring focus back within the focusgroup, and the result can even change based on the memory element.

Solution

This change introduces the concept of a focusgroup segment. When an opted out element that is focusable sits in the middle of a focusgroup, it will split the group into two segments, each having its own tab stop and memory. This ensures that a user navigating with tab won't skip content, and that focusgroup entry and exiting will remain symmetrical.

as always, I'm flexible on the approach, but want to make sure there is a good default behavior.

[gfellerph]

@janewman you showed an example at some point that has a search box in the middle of a toolbar. If that example also had a focusgroup none after the searchbox, segmenting the group. If a user enters a search term, focus might jump to a results list beyond the focusgroup. When the user then shift-tabs back to the toolbar, the memory element or guaranteed tab stop of the second segment will be focused and not the search bar in the first segment. To me, this seems to break with the premise of memory that should allow users to jump back in where they left off. Should memory not apply to the entire focusgroup, thus not respecting segmentation?

I guess this will rarely be an issue though since when tabbing through the page, at least one element of the last segment would receive focus and become the memory element and therefore it also makes sense to re-enter there when shift-tabbing back. It would only be noticeable if focus leaves the focusgroup through some other means than keyboard navigation.

[janewman]

My thinking is that if the author went out of their way to make an item to both not participate in the focusgroup and wanted it to appear in tab order, we should respect their decision and never "jump" past it.

In this example, let's assume that the pressed save and then focus was moved to somewhere below the toolbar, leaving the save button as the last focused item.

<div focusgroup="toolbar inline wrap" aria-label="Text formatting">
  <button type="button">Bold</button>
  <button type="button">Save</button>
  <button type="button">Italic</button>
  <span focusgroup="none">
    <button type="button">Super Important</button>
  </span>
  <button type="button">Underline</button>
  <button type="button">Strikethrough</button>
  <button type="button">link</button>
</div>

I see a few different ways this situation can be handled:

1. memory item is one-per-focusgroup, memory takes precedence over opted out element in taborder precedence.

Here, shift tabbing would restore focus immediately to the Save button, skipping over the "Super Important" button. Tabbing again moves focus to the Super Important button. Tabbing again moves focus to:
a. The content after the toolbar, as we are "after" the focusgroup. This preserves the single tabstop concept.
b. "Underline" which now replaces the "Save" button as the last focused item. This introduces a new rule about what items in the focusgroup are allowed to be considered when entering from an opted-out element.
c. The "Save" button, as we want to restore memory (this creates a loop and is clearly not an option in my opinion)

2. memory item is one-per-focusgroup, memory does not take precedence over opted out items in taborder precedence.

Here, shift tabbing would move focus to the "Super Important" button. Shift tabbing again moves focus to the "Save" button. Tabbing from here moves focus back to the "Super Important" button, and tabbing again moves focus to:
a. The content after the toolbar, as we are "after" the focusgroup. This preserves the single tabstop concept.
b. "Underline" which now replaces the "Save" button box as the last focused item. This introduces a new rule about what items in the focusgroup are allowed to be considered when entering from an opted-out element.
c. The "Save" button, as we want to restore memory. (this creates a loop and is clearly not an option in my opinion)

3. memory item is one-per-focusgroup segement, memory does not take precedence over opted out element in taborder precedence.

Here, shift tabbing would move focus to the "link" button (assuming there is no memory item). Shift tabbing again moves focus to the "Super Important" button. Shift tabbing again moves focus back to the "Save" button, Tabbing again moves focus to the "link" button. But then what happens to memory if the opt-out is dynamically removed and the two segments are joined?
a. Memory is cleared.
b. Both are kept until focus re-enters the group, prioritizing the closest to the element focus is moving from.

---

I never like the feeling of "skipping" content that 1-a and 2-a brings, that is my main motivation for #3
Let me know if you have strong feelings towards one of these or have an idea that wasn't mentioned.

Edit: updated example to use a "Save" button to avoid having to also mention the key-conflict behavior here and overcomplicating things.

[janewman]

I spent some time thinking about this one, and I am coming back around to a single memory item per focusgroup, not per segment. I want to retain the idea of a focusgroup segment to facilitate the entry algorithm. This means that if the memory element is not is the segment being navigated to, memory won't end up being used.
See this same example, assume that the user pressed save and then focus was moved to somewhere below the toolbar, leaving the save button as the last focused item.

<div focusgroup="toolbar inline wrap" aria-label="Text formatting">
  <button type="button">Bold</button>
  <button type="button">Save</button>
  <button type="button">Italic</button>
  <span focusgroup="none">
    <button type="button">Super Important</button>
  </span>
  <button type="button">Underline</button>
  <button type="button">Strikethrough</button>
  <button type="button">Link</button>
</div>

1. Shift+Tab from after the toolbar would move focus to the "link" button. "Link" is now the memory item.
2. Shift+Tab again moves focus to the "Super Important" button.
3. Shift+Tab again moves focus to the "Italic" button, as memory was set to "link" in the first step. "Italic" is now the memory item.

If an author wanted to make Save be the element that a user would jump to when shift-tabbing from after the toolbar, they have a few options:

• Reconsider making "Super Important" an opted-out item.
• Reconsider making "Super Important" In the middle of the focusgroup, either put it outside or on at one of the ends.
• Rather than having a focusable opt-out element splitting the focusgroup, consider making two focusgroups, each with their own memory. This would have the downside of not being able to arrow between these groups.

As always, let me know your thoughts here; more than happy to pivot if there is another approach that makes more sense.