Select your language
Select other languages

Automatic translation

Loading translator…

Magoomake your components work correctlyBack to homepage

Modal

Displays a task or information over the page, requiring attention to focus entry, containment, and exit.

For working examples and design patterns for this component, see the references tab (opens the references on this page).

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 when a task or information needs to interrupt the flow. First consider whether that interruption is necessary.

What to draw

Show the opening control, the open dialog above the content, its title, actions, and a visible way to close or cancel.

How it behaves

On opening, keyboard navigation starts at an appropriate point inside the dialog and stays within it. On closing, it returns to the opening control or a logical point in the flow. Escape may close it when this does not cause unconfirmed data loss.

What to document in Figma

Annotate initial and returning focus, control order, and the name announced by screen readers. Record whether clicking outside closes the dialog and how data loss is prevented. Background content is unavailable while it is open.

How to review

Is the purpose of opening clear? Is cancellation easy? Do content and actions fit small and large screens? Record keyboard navigation and screen reader announcements as pending implementation checks.

Full guidance

Interaction Design

Questions to ask when designing interactive components of type Modal.

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"

  1. Before opening the component, can you tell which action will open the modal window?
  2. Does the name of the control that opens the modal make the action's purpose clear?
  3. Is the modal necessary to interrupt the person's flow?

Designing for mouse use (any pointing device)

  1. Is there visual feedback when activating the control that opens the modal?
  2. Does the modal appear above the main content and make clear that the rest of the page is unavailable?
  3. Is there a visible control to close or cancel the modal?

Designing for gesture use

  1. Do the opening control and internal controls have adequate touch areas?
  2. When the modal opens, does the main content avoid visually competing with the modal task?
  3. Can the modal be closed without relying on a difficult or hidden gesture?

Designing for keyboard use (any non-pointing device)

  1. When the modal opens, does focus move to a suitable point inside it?
  2. Does navigation with TAB remain inside the modal while it is open?
  3. Can the modal be closed with ESC, when doing so will not cause unconfirmed data loss?
  4. When the modal closes, does focus return to the component that opened it or a logical point in the flow?

Designing for screen reader use

  1. Is the modal announced as a dialog?
  2. Is the dialog's accessible name clearly announced?
  3. Is content outside the modal unavailable for navigation while the modal is open?
  4. Are the focus change and closing perceptible?

Interaction methods

Possible interaction methods for components of type Modal.

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

Mouse interaction (any pointing device)

  • Clicking the opening control displays the modal.
  • Clicking the close, cancel, or primary action button performs the corresponding action.
  • Clicking outside the modal should only close it when that is a safe, documented product decision.

Keyboard interaction (any non-pointing device)

  • ENTER or SPACE activates internal buttons.
  • TAB and SHIFT+TAB cycle through the modal's controls.
  • ESC closes the modal when applicable.

Keyboard (or gesture) interaction + screen reader

  • The dialog must have an accessible name.
  • Focus must move inside the modal when it opens.
  • The background should be inert or unavailable to assistive technologies.

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 modal

Keyboard navigation

  1. WHEN I activate the button that opens the modal
  2. I SEE the modal displayed above the main content
  3. THEN, when I use the Tab
  4. I SEE focus staying within the modal's controls
  5. THEN, when I close the modal
  6. I SEE focus return to a predictable point in the flow

Desktop screen reader

  1. When I use a screen reader on a computer (NVDA, JAWS, VoiceOver) and move focus to the component
    • I HEAR that the component is a dialog.
    • I HEAR the modal's accessible name.
    • I HEAR the modal's main content or instruction.
  2. THEN, when I activate or change the component
  3. I HEAR or perceive that its corresponding state, value, content, or action has been updated.

Mobile screen reader

  1. WHEN I use a screen reader on a phone (TalkBack, VoiceOver) and swipe to focus the component, the following happens:
    • I HEAR that the component is a dialog.
    • I HEAR the modal's accessible name.
    • I can navigate the modal's controls without accessing background content.
  2. THEN, when I double-tap or use the appropriate gesture to activate the component
  3. I HEAR or perceive that its corresponding state, value, content, or action has been updated.

Considerations

Considerations for components of type Modal.

  • Modals interrupt the flow and should only be used when interaction requires immediate focus.
  • Do not hide the close button when the person needs to be able to cancel the action.
  • Confirm before closing the modal if the person could lose entered data.

References

Additional references for components of type Modal.

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.

Design patterns

Design System

Original content by Marcelo Sales, initially used in the AccessBoost course (external link - opens in a new window). These interactions represent standard industry patterns, but may be customized in specific cases, provided there are sufficient instructions for people to understand the behavioral change.