[a11y]: UI Shell header has implementation, documentation and prototyping issues to address or consider

[mbgower]

Package

@carbon/react

Browser

Chrome

Operating System

No response

Package version

n/a

React version

on storybook

Automated testing tool and ruleset

n/a

Assistive technology

Screen readers and keyboard, depending on which issue in this omnibus I'm talking about

Description

A review of the the UI Shell Header was carried out as part of an accessibility review. There are copies of the documentation's Usage and Style pages with comments from both Jess Lin and myself. As well, we reviewed the Global header pattern, the Figma guidance and the React storybook implementation.

This is an omnibus issue. The intention is Carbon will peel off individual considerations as new issues.

Key items to consider:

Usage document

• Carbon frequently calls things in the header "link" even when they are clearly something else -- a button, a menu, etc)
• the Live demo on the Usage page is keyboard inaccessible/inoperable
• The left/right/header split in the UI Shell seems somewhat artificial. Is the Right UI Shell really separate, or just a component that appears in the header, for instance. For example the "switcher" is listed as a header component, but it's functionality is talked about in the Right UI Shell
• "Sub-menu" is a very unforunate name for a component in the header. A better name and precise implementation information on it would help make implementations consistent. Elsewhere on the same Usage page, these are called "primary-menu".
• inconsistent use of terminology for buttons in the header. Called "header utilities", "platform utility icons" and "header icons" all just in the Usage document.

Here's a screen detail of the live demo, expanded. I'm concerned with naming of "link 4" and "Sub-link 1". Link 4 is likely not a link at all. It would be a Button menu or some kind of disclosure pattern. Clicking on it does not launch a new page (which is what links are supposed to do) but reveals a dropdown menu.
Calling this a "link" is the kind of 'message' that can cause a lot of confusion amongst Carbon teams. There may not be a perfect vocabulary solution, but this needs to be addressed.

Style document

• There is little to no guidance on the sub-menu button behaviour

Globalal header pattern

• a number of considerations to do with description and functionality, and a number of questions specific to breadcrumbs and 'sub-menu' conventions

Figma

• The Figma version, like Usage, mixes Links with dropdown/menus to ill effect (shown above). Clearly from a functional and visual perspective, something that opens and closes a menu is NOT a link. Note that ARIA Authoring Practices Guide has something similar they call a Disclosure Menu (also not a link) which opens and closes a menu but does not reposition to the first item. I don't like some of their guidance here, and there is discussion going on about it.

• Figma divides non "link" behaviours into "actions" and "menu". In the image above, it's unclear why they have an "x" on the action, since these are buttons and so don't have a 'close' function.
  On the second row, the Menu is (as noted in Usage/style) peculiar in that the menu button becomes the close button. It's not very elegant or consistent versus other menu buttons, and should probably be explored carefully. I suspect the 'close' function exists because these are sometimes implemented in a way where the side menus can be left open, but at that point, it's not really a menu anymore. It's a side panel, and it should really be called something othen than a menu. Also, I don't think the right nav should EVER be left open (since the targets are outside the product, it makes no sense). So I think the left vs right nav need to be treated differently

React storybook

• The title display on the actions is really nicely done in React. We should make sure it is better documented. Appears on focus, dismissible with Esc.
  https://react.carbondesignsystem.com/?path=/story/components-ui-shell--header-base-w-actions

I don't understand the Header Base w/ Action and Right Panel version pictured above.
It creates a grey 10 section that is tied with the Notifications button, but it does not integrate with interaction. For example, in the preceding image, the focus is on the search component, but the notification is still visually tied in with the panel. Maybe it's just intended to demonstrate what it would look like?

The Header Base w/ Navigation, shown above, is the first to show the Skip to Main function and operability of the 'sub menu'

Note that they have not implemented the menu properly. Focus should go to the first item on open, but the focus here is remaining on the button menu. Realize there is debate about whether this should be a menu, but want attention on it.

The Header Base w/ Navigation, Acitons and SideNave shown above, provides a navigable and operable (but not launchable) top and side nav.

I'm interested that they say "Category title" for what in other places was called "Sub-menu". This is a bit better description, since the title is not itself a node. However, I still think a better term can be created and used globally.

Note that there is interesting description on this page that might make for good text in any of the above documentation.

WCAG 2.1 Violation

No response

Reproduction/example

visit carbondesignsystem.com and review docs

Steps to reproduce

See documents

Code of Conduct

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

[mbgower]

Another thing to call out in a discussion of the UI Shell is: why is there no UI Shell footer? I've never seen a Carbon implementation without a footer. The topic should at least be mentioned in the Global header pattern topic -- but it is obviously not a header! :) I think it makes more sense to define a Carbon UI Shell Footer as part of a UI Shell topic, even if it is just a container.

[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.