Modal interrupts the user with a message or request for certain actions with a block of content on top of the main view.
Use modals when it is necessary to interrupt users with a message or request for certain actions. For example:
Use them sparingly as they are interruptive. For screen reader users, it is especially frustrating because they’ll lose their place in the application.
It’s easy to confuse alerts with modals. Modals interrupt users by blocking the current view while alerts coexist on the page and do not stop the user flow. Don’t use modals when alerts are more appropriate as modals are intrusive.
Modals contains three parts:
Modals retain focus, including keyboard focus, until a certain action has been taken. Provide a visible and focusable way to close the modal.
Here are two different approaches:
Modals with actions
When an action is required from users, force them to make a decision by clicking a button. Don’t include the “X” or allow the users to click outside the modal to dismiss it.
Modals without actions
For less critical content, meaning it won’t make much difference if users ignore the content, then you don’t need to include buttons. Users can simply click the “X” or click outside the modal to dismiss it. For example, a modal that displays additional information about a teacher to help students choose a class doesn’t need action buttons.
Modal with actions
Modal without actions
When the modal content exceeds the height of the viewport the scrollable area will automatically expand to include just enough space for scrolling, without scrolling the page below.
Modals with actions: Sticky buttons
The buttons must be accessible upfront so that users know that they are expected to take an action.
Modal without action: Scrolling page
Modal with actions (Mobile). This prototype failed to show the scroll bar due to technical limitation, but the actual build should have the scroll bar visible at all times for this modal.
Modal without actions (Mobile)
Launching a modal within a modal adds complexity and confusion for the users. Look for alternative solutions such as creating a separate page for the task.
Modals are not designed for displaying long content, especially when we want the users to actually read the content. Consider in-line expansion within the originating page or displaying the information on a separate page for a better user experience.
On narrow devices, there isn’t enough horizontal room for a scrolling area inside modal if the modal happens to exceed the viewport as well. This would become a usability issue.
See the buttons component for how to place the buttons. Avoid having more than two buttons in a modal to keep it simple for users.
The layout changes at the following breakpoints. In short, the modal has a more compact spacing, wider buttons, and smaller font size on narrow devices.
For native mobile apps, use the native modal. The guideline in this documentation is for responsive web mobile design.
Modal on desktop (Viewport >= 768px)
Modal on iPhone 5 (Viewport = 320dp)
Note: The touch target for “X” is smaller than the minimal size of 44px because there is additional touch area outside the modal to accommodate for that. This allows more room for heading.
Use the native modal for native mobile apps. The specs in this documentation is for responsive web mobile design.
See specs on Zeplin. For access, contact Linda (linda.tsai@pearson.com)
When the modal content exceeds the height of the viewport the scrollable area will automatically expand to include just enough space for scrolling, without scrolling the page below.
Modal with buttons
Modal without buttons (Desktop)
Modal without buttons (Mobile)
Button labels should be as concise as possible - one or two words. However, in the case where multiple buttons just can’t fit in one row on a narrow device, they will stack up by default.
Modal