Alerts

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 communicate important information and guide the next decision.

What to draw

Show a clear message, actions, and a close control when present.

How it behaves

Reading the message requires no interaction. Only internal controls need to be reached by keyboard.

What to document in Figma

Define urgency and how new messages are announced. Field-related errors need to accompany those fields.

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

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 or reading the screen, can you perceive an important message?
Is the alert type understandable without relying only on color or an icon?
Does the text clearly state what happened and what the person can do?

Designing for mouse use (any pointing device)

Do links or buttons inside the alert provide visual feedback on hover?
Does the alert avoid covering essential content unnecessarily?
Do dismissible alerts have a visible close control?

Designing for gesture use

Do controls inside the alert have comfortable touch areas?
Does the message remain visible long enough to read?
When the alert can be closed, does tapping outside avoid unexpected closing?

Designing for keyboard use (any non-pointing device)

Do interactive components inside the alert enter the natural focus order?
Is visible focus preserved on alert links or buttons?
When closing an alert by keyboard, does focus move to a predictable point?

Designing for screen reader use

Are critical alerts announced appropriately?
Do informational alerts avoid unnecessarily interrupting reading?
Do links, buttons, and error messages inside the alert have clear names?

Interaction methods

Possible interaction methods for components of type Alerts.

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

Mouse interaction (any pointing device)

Reading the alert requires no interaction.
Clicking internal links or buttons performs the related action.
Clicking the close control removes or hides the alert when applicable.

Keyboard interaction (any non-pointing device)

TAB should reach only interactive controls inside the alert.
ENTER activates internal links and buttons.
Purely informational alerts should not receive focus just to be read.

Keyboard (or gesture) interaction + screen reader

Important dynamic messages may use role="alert".
Less urgent status messages may use role="status".
Form errors should be associated with their respective fields when applicable.

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 alerts

Keyboard navigation

WHEN an alert appears on the screen
I SEE the message and its type visually indicated
THEN, when I use Tab
I SEE focus only on interactive controls inside the alert, if present
THEN, when I activate an alert control
I SEE the corresponding action performed

Desktop screen reader

When I use a screen reader on a computer (NVDA, JAWS, VoiceOver) and navigate the component
- I HEAR the alert message when it is critical or dynamic.
- I HEAR internal links and buttons with clear names.
- I HEAR the relationship between error and field when the alert relates to validation.
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 alert message when it is critical or dynamic.
- I can navigate internal controls when present.
- I HEAR the relationship between error and field when the alert relates to validation.
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 Alerts.

Do not use alerts for decorative messages; reserve them for information relevant to the flow.
Avoid alerts that disappear too quickly or without the person's control.
Do not rely solely on color to communicate success, errors, warnings, or information.

References

Additional references for components of type Alerts.

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.