What is a modal
A modal is a large rectangular component that appears in the center of a user's screen, temporarily interrupting their workflow to prompt immediate action. Modals are triggered by user-initiated actions, such as requesting to delete content that can’t be restored or attempting to leave a page without saving. When a modal is presented, the background content is typically disabled to draw the user's focus to the modal’s content. The user is expected to complete the action requested within the modal or dismiss it.
Tip: A good way to determine whether to use the modal component is to ask yourself whether the action the user is about to take is reversible.
For example, in Figure 1, the user has attempted to close the document they are working on without saving their most recent changes. This would be considered a critical and irreversible error, resulting in frustration for the user. This modal, triggered by the user requesting to close the document, requests the user to perform an action to prevent the critical error.
When to use this Component
Use modals in user-initiated situations requiring immediate intervention or critical decisions, such as irreversible errors or important confirmations
When not to use this Component
Do not use modals for system-initiated content such as informational and warning messages, see Page Alerts instead
Do not use modals for decisions that will require additional information
Do not use modals during challenging, time-sensitive, or important workflows. Modals break the users' focus and can cause them to forget where they were
Best practices
Do
Fill 25% of the screen when viewing on desktop. This size should be increased on smaller viewports
Disable background content to draw the user's attention to the modal
Keep the content in modals concise, clear, and action-oriented so users can quickly understand the action they need to take
Set the keyboard focus to the modal when it appears, ensuring that keyboard or assistive technology users can easily interact with the modal's content. When the modal is closed, ensure that focus is returned to its original location from before the modal was activated
Don’t
Use modals excessively or unnecessarily, overuse will be disruptive to the user’s workflow
Trap users in a keyboard loop, ensure the modal is dismissible by both keyboard and mouse interactions
Nest modals so that the call to action triggers another modal window on top of the initial modal
Require users to scroll within the modal to view all text or content
Accessibility
2.1.1: Keyboard
WCAG criterion 2.1.1 states that all functionality of web content should be operable through a keyboard. This means that users must be able to interact with modals using the keyboard alone, with no mouse interaction necessary. Users should be able to successfully navigate through the modal using the key commands in Figure 2.
Key | Function |
|---|---|
Tab | Moves focus to the next focusable element inside the modal. If the focus is on the last focusable element, the focus is returned to the first focusable element. |
Shift + Tab moves | Moves focus to the previous focusable element inside the modal. If the focus is on the first focusable element, the focus moves to the last focusable element. |
Escape | Closes the modal |
Figure 2 - Keyboard commands for successful keyboard operation of a modal
G202: Ensuring keyboard control for all functionality
2.4.3: Focus order
To ensure web content is accessible to users of assistive technology, WCAG criterion 2.4.3 emphasizes the importance of a logical focus order similar to the flow a sighted user would follow. For modals, this means that once activated, the focus should be programmatically set to the modal so the user is aware of its presence and can interact with its content. Once the modal has been dismissed or the intended action has been completed, focus should return to its original location before the modal is activated.
SCR37: Creating custom dialogs in a device-independent way
4.1.2: Name, role, value
Using ARIA (Accessible Rich Internet Applications) names, roles, and values can help assistive technologies and their users identify UI components and their purpose, making them more understandable and usable. Using ARIA with modals will help convey the purpose of the dialogue, announce the content to screen reader users, prevent interactions with background content, and ensure the modal is treated as separate from background content.
Modal Dialog Example - Role, Property, State and Tabindex Attributes
Key component features
Telerik Blazor Dialogue Component - Overview
Header
The header of a modal should clearly and briefly explain the purpose or desired action that will be achieved through interacting with the modal.
Body
The body text in the modal should further inform users of the goal of the modal and provide any information or guidance needed to make a decision or complete an action. This text should be brief and no more than 1 to 2 sentences.
Call to action
The call to action, typically in the form of a button, prompts the user to perform the action the modal is requesting of them. The text on this button should be action-oriented and make it clear to the user what decision or action they are performing.
Dismiss modal
Modals should include a way for the user to close or dismiss the modal without performing the action being requested by them. This is typically done through a close or cancel button, or an icon such as an “X”.
Background disabled
When a modal is activated, background content is typically disabled to draw the user’s attention to the modal. A translucent overlay is often applied as well, further emphasizing the modal while reassuring the user they can return to their workflow afterward.
Examples
Pending: Will add examples of this component implemented in MAACE applications.
Resources
External resources
Modal and Nonmodal Dialogs: When (& When Not) to Use Them
Best Practice for Modal Window Design
Modal UX Design for SaaS in 2023 - Best Practices and Examples