HelpMenu

A prebuilt menu as entrypoint for app specific help links and actions.

OverviewPropertiesAccessibility

New

Note

See Accessibility in Design Foundations for explanations of key concepts and best practices.

Keyboard accessibility and focus

HelpMenu handles focus management out of the box. When the menu opens, focus moves to the first menu item; when it closes, focus returns to the trigger.

• Do ensure that the trigger has a meaningful accessible name: "Help", for example. This allows screen readers to announce its purpose when it receives focus.
• Don't override the component's built-in focus handling. Focus must land on the first menu item when the menu opens and return to the trigger on close, so screen readers can announce the state change correctly.

Accessible names and roles

The proper approach depends on whether the trigger uses an icon only or a combination of icon and text.

Icon only

• Do provide an aria-label that describes the trigger's intent.
• Do set the SVG's role to img and hide it from assistive technology with aria-hidden="true".
• Do use a Tooltip to say what the trigger is for. Ensure that the tooltip text exactly matches the aria-label.

Icon and text

• Do verify that the trigger's accessible name matches its visible text.
• Do set the SVG's role to img and hide it from assistive technology with aria-hidden="true".
• Don't add alt text to the icon. It would be announced separately, creating redundant announcements.

State announcements

HelpMenu handles state announcements out of the box: aria-expanded="true" when open; aria-expanded="false" when closed.

• Do ensure that the expanded menu content follows in a logical tab order so users can navigate into it after the state is announced.