Lists

COMPONENT GUIDE

Explore behaviors before defining the interface.

Quick guide for designers

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 related items; use a numbered sequence when order matters.

What to draw

Show grouping, order, and any links or buttons with clear purposes.

How it behaves

A static list requires no action. Only its links and buttons participate in keyboard navigation.

What to document in Figma

Record whether order is meaningful and keep reading and navigation order consistent with the items.

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

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 reading the content, can you visually tell that the items belong to a set?
Does list order matter, or is it just visual grouping?
Does each item have a clear relationship with the group?

Designing for mouse use (any pointing device)

Do links or buttons inside items provide visual feedback on hover?
Do clickable items clearly indicate which part is actionable?
Does interaction preserve the visual relationship between item and content?

Designing for gesture use

Do items with actions have comfortable touch areas?
Is the visual order of items maintained on small screens?
Does the list remain understandable when it wraps over multiple lines?

Designing for keyboard use (any non-pointing device)

Does focus order follow the list's visual and semantic order?
Do interactive components inside items have visible focus?
Are static items kept out of the focus order unless needed?

Designing for screen reader use

Does the screen reader announce that this is a list?
Is the number of items perceptible when supported?
Are the order and hierarchy of nested lists understandable?

Interaction methods

Possible interaction methods for components of type Lists.

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

Mouse interaction (any pointing device)

Static lists require no interaction.
Links and buttons inside the list should follow their own patterns.
Clickable areas should have a clear purpose.

Keyboard interaction (any non-pointing device)

Keyboard navigation should reach only interactive components.
Focus order should follow item order.
Lists used for navigation should preserve list and link semantics.

Keyboard (or gesture) interaction + screen reader

Use ul when order does not change the meaning.
Use ol when sequence matters.
Avoid simulating lists with only line breaks or generic elements.

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 lists

Keyboard navigation

WHEN I use the keyboard to navigate a list with actionable items
I SEE focus following the expected item order
THEN, when I activate a link or button within the list
I SEE the corresponding action take place

Desktop screen reader

When I use a screen reader on a computer (NVDA, JAWS, VoiceOver) and navigate the component
- I HEAR that the content is a list when the semantics are appropriate.
- I HEAR the number of items when supported.
- I HEAR each item in the correct order.
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 content is a list when the semantics are appropriate.
- I HEAR each item in the correct order.
- I can understand nested lists when present.
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 Lists.

Do not remove list semantics just to make visual layout easier.
Avoid very long lists without grouping, search, or supporting navigation when needed.
Nested lists need a clear hierarchy.

References

Additional references for components of type Lists.

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.