Menu

COMPONENT GUIDE

Explore behaviors before defining the interface.

Always consider the context of the application, even when the guidance follows a standard pattern. Interaction design documents intent. Behavior must be verified in the implementation.

When to use

Use to group navigation destinations or actions predictably.

What to draw

Show items, submenus when present, expanded or collapsed states, and visible focus.

How it behaves

Links navigate and buttons open submenus. Do not rely on hovering alone; Escape closes temporary submenus where applicable.

What to document in Figma

Distinguish links from buttons and record navigation order. Ordinary site navigation should not be treated as an application menu.

How to review

Check whether the purpose and states are clear on small and large screens and with zoom. Verify documented behavior in the implementation, including keyboard and screen reader use where applicable.

Full guidance

Interaction Design

Questions to ask when designing components of type Menu.

Important:
Depending on the context in which you build your components, there may be further questions, and some listed here may not be necessary. Assess each case individually.

Designing for "no interaction"

Before interacting, can you tell that the menu contains navigation options?
Is the current item or active section visually identifiable?
Do items with submenus make clear that they open more options?

Designing for mouse use (any pointing device)

Is there visual feedback when hovering over actionable items?
Does clicking a link load the corresponding page or section?
Does clicking a submenu trigger predictably open or close the submenu?

Designing for gesture use

Does the menu open and close comfortably on small screens?
Do items and triggers have sufficient touch areas?
Does the mobile menu's visual order follow the navigation order?

Designing for keyboard use (any non-pointing device)

Do menu links and buttons have visible focus?
TAB move through items in the expected order?
ESC close submenus or temporary menus when applicable?
Does focus return to the trigger when a temporary menu is closed?

Designing for screen reader use

Does the navigation region have an accessible name when needed?
Do links have clear, unique names within the context?
Do submenus expose their open or closed state when applicable?

Interaction methods

Possible interaction methods for components of type Menu.

Important:
Only the main methods are listed here. Custom components require further study.

Mouse interaction (any pointing device)

Clicking links navigates to the corresponding destination.
Clicking submenu buttons toggles their display.
Hover can reveal visual cues but should not be the only way to open.

Keyboard interaction (any non-pointing device)

TAB navigates menu links and buttons.
ENTER activates links and buttons.
SPACE activates opening buttons when present.
ESC closes temporary menus or submenus when applicable.

Keyboard (or gesture) interaction + screen reader

Use nav for navigation menus.
Use lists when grouping links.
Use aria-expanded on submenu triggers.
Avoid applying role="menu" to ordinary website navigation.

Gherkin

BDD (Behavior-Driven Development) methodology focusing on three pillars: User Stories, Acceptance Criteria, and Gherkin Syntax (Given, When, Then).

Scenario: Given that I am on a page containing a navigation menu

Keyboard navigation

WHEN I use the Tab key to move focus to the menu
I SEE visible focus on menu links and buttons
THEN, when I activate a link with Enter
I SEE the corresponding destination loaded
THEN, when I activate a submenu button
I SEE the submenu open or close

Desktop screen reader

When I use a screen reader on a computer (NVDA, JAWS, VoiceOver) and navigate the component
- I HEAR that the menu belongs to a navigation region when applicable.
- I HEAR clear names for links and buttons.
- I HEAR the open or closed state on submenu triggers.
THEN, when I interact with the component, when applicable
I HEAR or perceive that the corresponding information, state, content, or action is available.

Mobile screen reader

WHEN I use a screen reader on a phone (TalkBack, VoiceOver) and swipe to navigate the component, the following happens:
- I HEAR that the menu belongs to a navigation region when applicable.
- I HEAR clear names for links and buttons.
- I can open, navigate, and close the menu without improperly accessing hidden content.
THEN, when I interact with the component, when applicable
I HEAR or perceive that the corresponding information, state, content, or action is available.

Considerations

Considerations for components of type Menu.

Website navigation menus should not automatically be treated as role="menu"; that pattern is better suited to application menus.
Submenus opened only on hover exclude keyboard and touch users.
Mobile menus should keep visual order and focus order consistent.

References

Additional references for components of type Menu.

Important:
Most references are on the course platform alongside the lessons cited in this material.

Disclaimer:
The links listed here are a curated collection of references where you can find implemented components, rather than recommendations. There is no unified implementation format and no guarantee that these links follow every design pattern. Direct questions to the teams responsible for the linked materials. Before copying a model, remember that all materials are constantly updated and that patterns, particularly proprietary ones, may change.

Quick guide for designers