Toasts

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 for brief feedback that does not block the task. Consider another pattern for critical messages.

What to draw

Show the message and any available action or close control.

How it behaves

An informational message does not move keyboard focus. If an action exists, it needs to remain available for use.

What to document in Figma

Define duration, announcements, and access to actions. The message must not disappear before it can be perceived or used.

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

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 disappearing, is the message brief, clear, and sufficient?
Does the toast avoid containing essential information the person needs to consult later?
Is the message type understandable without relying solely on color?

Designing for mouse use (any pointing device)

When there is an action or close control, does it provide visual feedback?
Does the message avoid covering important controls for the current task?
Can you pause, close, or access the action while the toast is temporary?

Designing for gesture use

Do toast controls have adequate touch areas?
Is the display duration long enough to read?
Does the toast appear somewhere that avoids obstructing the virtual keyboard or important content?

Designing for keyboard use (any non-pointing device)

Do internal controls enter the focus order only when necessary?
Is focus kept from automatically moving to the toast unnecessarily?
Can you activate the action or close control by keyboard when present?

Designing for screen reader use

Is the message announced without excessively interrupting reading?
Are the action and close controls announced clearly?
Does temporary content allow the person to continue the main flow?

Interaction methods

Possible interaction methods for components of type Toasts.

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

Mouse interaction (any pointing device)

Informational toasts may appear without requiring interaction.
Clicking a toast action performs the related action.
Clicking close removes the message when applicable.

Keyboard interaction (any non-pointing device)

Focus should not be taken over by a purely informational toast.
If there is an action, it must be reachable by keyboard while the toast is available.
ENTER or SPACE activates internal buttons.

Keyboard (or gesture) interaction + screen reader

Status messages can use a polite live region.
For critical messages, assess whether a toast is the appropriate pattern.
The message should not disappear before it is perceived or its action is used.

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 toasts

Keyboard navigation

WHEN a toast appears after an action
I SEE the temporary message without losing current focus
THEN, when the toast has an action or close button and I use Tab
I SEE that I can reach and activate the control while it is available

Desktop screen reader

When I use a screen reader on a computer (NVDA, JAWS, VoiceOver) and navigate the component
- I HEAR the message when it represents a relevant update.
- I HEAR internal controls with clear names when present.
- I do not unnecessarily lose the main task's focus context.
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 the message when it represents a relevant update.
- I can reach the toast action when present.
- I do not unnecessarily lose the main task's context.
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 Toasts.

Do not use toasts for critical errors, destructive confirmations, or content requiring a mandatory decision.
Be careful with automatic dismissal timing.
Toast actions need to remain available long enough to use with keyboards and screen readers.

References

Additional references for components of type Toasts.

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.