Bug: Indicate when a tab is in a group via accessibility APIs
Status: NEW
Priority: --
Created: 2025-03-05 06:20:43+00:00
Resolved: 2025-03-05 06:20:43+00:00

STR (with a screen reader):

1. Open three tabs: example.com, google.com and mozilla.org.
2. Move Google into a tab group called test.
3. Focus the tab bar and press left arrow several times to get to the Example Domain tab.
4. Press right arrow thrice to move to the Mozilla tab.
    - Expected: There should be some indication that you are no longer in the test tab group.
    - Actual: There is no such indication. A screen reader user has no way of knowing that they have left the tab group.
5. Press left arrow to move to the Google tab.
    - Expected: There should be some indication that you have moved into the test tab group.
    - Actual: There is no such indication. A screen reader user has no way of knowing that they have entered a tab group when moving to the left (assuming LTR).

This makes tab groups somewhat tedious to use for a screen reader user. The only way to really be certain of which tabs are in a group is to collapse the group so that they are no longer reachable.

Unfortunately, this is a tricky problem to solve:

1. In theory, one possible fix would be to give the tab group role="group" and put the tabs inside it. That would cause NVDA to read the group when entering it from either direction and it would also automatically change the group position info (1 of 2, 2 of 2, etc.).
2. However, per the ARIA spec, role="group" isn't valid inside role="tablist" and the Firefox accessibility engine currently won't allow this.
3. Even if that were possible, it wouldn't work for VoiceOver. In fact, it would break VoiceOver navigation inside the group.
4. Another possibility is aria-level. That wouldn't report the name of the group when moving to the left, but it would at least report "level 2" when entering a group from either direction. The user would still have to move all the way to the first tab in the group to figure out what group it belongs to, but that's still better than what we have now.
5. Per the ARIA spec, aria-level isn't valid on tabs, though Firefox supports it anyway.
6. However, VoiceOver doesn't report that information.
7. We could include the name of the group in the accessibility description. I don't think VoiceOver reads that though.

Talking to Anna about this, I think the best we can do is fix this as best we can for NVDA (and probably Orca). There's nothing we can do for VoiceOver, but we still have to be careful not to break it.

1. Include the name of the group in the tab's accessibility description.
2. Put aria-level="1" on ungrouped tabs, aria-level="2" on grouped tabs.
3. Tab groups can be siblings with no ungrouped tabs between. The tab group toggles are buttons, not tabs. Unfortunately, that means that the accessibility engine's group position calculation will be wrong because it will count the tabs at level 2, ignoring the intervening button. For example, if you have 2 adjacent tab groups containing 2 tabs each, NVDA would report "1 of 4", "2 of 4", etc. instead of "1 of 2", "2 of 2". We can work around this by explicitly setting aria-posinset and aria-setsize on grouped tabs. However, we'll need to reset this on all tabs in a group whenever tabs are added, removed or reordered in the group.