[a11y]:UI shell right panel interaction and presentation needs attention

[mbgower]

Package

@carbon/react

Browser

Chrome

Operating System

MacOS

Package version

https://react.carbondesignsystem.com/?path=/story/components-ui-shell--header-base-w-actions-and-switcher

React version

No response

Automated testing tool and ruleset

n/a

Assistive technology

No response

Description

This is a continuation of some of the issues and considerations found in UI Shell header and UI shell left panel, but IMO they are more pronounced and in need of a thorough design rethink for the right panel.

Here are the key points of discussion:

• documentation suggests that when discussing the right panel, what's really meant is the Switcher. If there is any behaviour independent of the switcher that needs to be captured and considered for the right panel, it would be good to delineate what that is
• the Switcher is arguably a non-persistent component. There is no scenario I am aware of where someone would want to leave it persistently on screen. I'd like to get agreement on that, or understand the 'persistent' use cases.
• although it is IMO intended to be non-persistent (and implemented that way for pointer users) it is implemented as somewhat persistent for keyboard users. There are several behaviours that vary but every one I have seen in Carbon consistently leaves the right panel open once opened by keyboard until such time as a user activates a control. It does not collapse on loss of focus. This is very different from pointer interaction, and results in a poor user experience which will become an explicit WCAG failure in 2.2. (There are potential ways to fail the behaviour now, but nothing so clear cut as will be the case.)

I advocate that the following should be the behaviour of the Switcher:

1. It closes automatically when the pointer or keyboard is located anywhere outside the switcher (for the pointer, this could be hover based or click based; both have their considerations. For keyboard, this means that when focus leaves the Switcher, it collapses (rarely happening now)
2. It can be closed by pressing Esc (often happening with current implementations)
3. When it is open, it can overlay other content, but that content should not be dimmed (more consistently happening for right than left panel)

---

Some of its current behaviour matches that of a disclosure pattern:

• It is activated by Enter and Space, not byDown arrow
• when it is activated, it just toggles the visibility of the child elements; it does not put focus into the first of the children
• all its actionable children are in the tab order

Some of its behaviour matches that of a menu:

• it collapses when Esc is pressed
• selecting any of its children collapses the panel

While I would personally prefer all vertical reveals to operate like menus (use arrow keys, put the first item in focus on expand) I am aware that this space is in transition, and I think that this hybrid behaviour is 'okay' as long as it is documented and implemented consistently

WCAG 2.1 Violation

No response

Reproduction/example

Just use carbondesignsystem.com

Steps to reproduce

1. Got to carbondesignsystem.com
2. select the switcher with the keyboard
3. navigate through it with Tab, including tabbing right out of it

Code of Conduct

• I agree to follow this project's Code of Conduct
• I checked the current issues for duplicate problems

[mbgower]

In addition to what's mentioned above, there is the consideration for the naming of the right panel. Since it takes a nav section, and there are other navigation roles on the Carbon page, it needs to have a name. I suggest "site" as the default.
Carbon could elect to synchronize the name of the switcher icon and the left panel navigation (call them both "site" or whatever), but I think "switch" or "switcher" is a good default name for the button while "site" is a decent generic name for this navigation panel.