Dialogs

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 present a message or decision in a dialog; define whether it interrupts the flow.

What to draw

Show the title, message, actions, and a way to cancel or close.

How it behaves

Buttons perform their actions. Escape or an outside click closes only when safe; a modal dialog prevents background interaction.

What to document in Figma

Document whether it is modal, keyboard focus destinations, and data loss risk. Alert dialogs may require a response.

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

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 opening the dialog, can you tell which action will open the window?
Is the dialog necessary to confirm, collect, or communicate something within the flow?
Does the dialog title clearly describe its purpose?

Designing for mouse use (any pointing device)

Is there visual feedback when activating the control that opens the dialog?
Does the dialog make the available controls clear, such as confirm, cancel, or close?
Are the primary and cancel actions visually distinguishable?

Designing for gesture use

Do internal controls have comfortable touch areas?
Can you close or cancel the dialog without relying on a hidden gesture?
Can the dialog be read visually without competition from the background?

Designing for keyboard use (any non-pointing device)

On opening, does focus move to an appropriate point inside the dialog?
TAB and SHIFT+TAB follow a predictable order?
ESC close the dialog when permitted?
On closing, does focus return to the trigger or a logical point in the flow?

Designing for screen reader use

Is the dialog announced with an accessible name?
Is the description or main message announced when needed?
Does the modal or nonmodal state match the interface's actual behavior?

Interaction methods

Possible interaction methods for components of type Dialogs.

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

Mouse interaction (any pointing device)

Clicking the trigger opens the dialog.
Clicking internal controls performs their corresponding actions.
Closing by clicking outside should only be available when there is no risk of data loss.

Keyboard interaction (any non-pointing device)

ENTER or SPACE activates buttons.
TAB navigates available controls.
ESC closes the dialog when doing so is safe.

Keyboard (or gesture) interaction + screen reader

The dialog must have an accessible name through a visible title or appropriate attribute.
Modal dialogs must prevent interaction with background content.
Alert dialogs should communicate a message and require a response when interrupting the flow.

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 dialogs

Keyboard navigation

WHEN I activate the control that opens the dialog
I SEE the dialog displayed
THEN, when I use Tab
I SEE focus navigating the dialog's controls
THEN, when I activate confirm, cancel, or close
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 component is a dialog when it opens.
- I HEAR its title or accessible name.
- I HEAR the main message when it is essential to deciding the action.
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 component is a dialog when it opens.
- I HEAR its title or accessible name.
- I can navigate the dialog's internal controls.
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 Dialogs.

Dialog and Modal may overlap conceptually; this page treats dialogs as a message or decision pattern within the flow.
Use alertdialog only when the message requires immediate attention and the person's response.
Do not mark a dialog as modal if background content can still be used.

References

Additional references for components of type Dialogs.

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.