| Table of Contents |
|---|
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 requesting to proceed with a workflow that requires additional information of confirmation. 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.
...
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, or confirm they wish to proceed without saving if this truly is what they meant to do.
...
When to use this component
Use modals in user-initiated situations requiring immediate intervention, critical decisions or simple data entry
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
Do not use modals for complex data entry. Only request the user to input one or two simple values such as memorable dates, names or contact information. Anything that would require the user to complete multiple fields, cross-reference another source, and/ or validate the data before it is accepted should be done on a page or broken up into multiple pages using a wizard
Best practices
Do
Fill 25% of the screen when viewing on desktop. When viewed in smaller viewports, modals should take up the full screen to ensure they are visible and readable
Disable and apply a translucent overlay to 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. |
Enter or Return | Selects buttons or links within 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 content 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. Text should be brief and no more than 1 to 2 sentences. If the user is required to enter simple memorable data such as a name or date, the appropriate fields should be included in the body.
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 ‘Confirm’, for consistency and clarity.
Dismiss modal
Modals should include a ways for the user to close or dismiss the modal without performing the action being requested by them. This is done in two ways, via a ‘Cancel’ button to the left of the call to action, and an icon such as an 'X' in the top right corner.
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
| Info |
|---|
Note: The following example is a visual illustration of how this component could be used in a MAACE application. Live examples of the Telerik UI component implemented in MAACE applications will be added when available. |
...
Responsive design
In order to be inclusive to all users, we need to consider how our applications behave on smaller viewports. (For more information on viewports, see The viewport is the window to your site – Digital.gov.) While designing and building using responsive design principles will allow you to create an optimized layout for users accessing your application on smaller viewports, this is not the only benefit. This will also ensure you are supporting users with low vision who need to enlarge text by using the browser’s zoom function.
As previously mentioned, it is recommended to use modal dialogs sparingly, as they can be difficult to use, especially on smaller devices. However, if a modal is needed, there are some techniques that can be used to improve the experience on smaller viewports:
Ensure that the content behind the modal is locked and cannot be accessed while the modal is on the screen
Ensure that the header and footer of the modal are fixed and only the content area scrolls, if necessary
Follow the recommendations listed in the Best Practices section
...
Resources
External resources
Modal and Nonmodal Dialogs: When (& When Not) to Use Them
...