[Feature Request]: Tabs focus states

[kingtraceyj]

Resources

Issue: carbon-design-system/carbon-website#3669
Syle PDF

Notes

from @mbgower

A more effective focus indicator for the synchronized tablist is to have the focus indicator going around the WHOLE tablist not just the single tab.

The primary benefit I see to this is that if I’m a sighted keyboard user, there is little to indicate that I’m in a component whose parts are navigated with arrows. If I’m familiar with the UI, I may go ‘oh, this is a tablist/menu/select that I may navigate with my arrow keys’. But in many cases, I won’t realize it until I press Tab again and jump right past the item I wanted to interact with. Most experienced keyboard users then grasp what happened and shift+tab back to the last item and then try arrow keys.

This is a particular challenge with tabs because they have such varied appearance on the web, and because they are often only visually tabs but operate in another manner.

However, I think any additional cues we can provide the user that this thing they are on uses different keys for operation, is useful. I’ve seen some implementations where a little cursor key icon appears in the margin, as one example of something added for this. What I’m suggesting is giving the cue right where the user is working.

The solution

Further exploration of focus states is needed from design but so is prioritization.

Beginning of explorations found in Figma

Examples

No response

Application/PAL

No response

Business priority

None

Available extra resources

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

Thank you for submitting a feature request. Your proposal is open and will soon be triaged by the Carbon team.

If your proposal is accepted and the Carbon team has bandwidth they will take on the issue, or else request you or other volunteers from the community to work on this issue.

[kingtraceyj]

manual vs automatic considerations:

It’s also important to remember that there are 2 forms of tabs: automatic and manual. In the automatic, the focus and selection are ALWAYS synchronized. But in manual, the selected item may not be the item with focus. I think you’ve seen examples of these in the ARIA examples, but it’s worth mentioning. I think if we have a way of distinguishing between these as part of that, it would also be a win. One of the ways of doing this is that for an automatic tab, there is NEVER any need to put the focus on the tab item, becuase it will always be the selected item. So you can mantain a focus indicator around the whole, and that’s it. With a manual tablist, the focus can go around both the whole AND the one with focus (which would start as the one that is selected, but could change). So that second focus can be a cue that it is actually a manual tab list.