A modal dialog pops up on top of a page after some user action. It waits for user input. The page content below is now inactive. Often, it is darkened.
The modal dialog can have different purposes: It may ask users to select one of several options, to confirm an action before it happens, to change some settings or other data, or to write a comment or message.
A modal dialog in action
The following video shows a typical modal dialog in action.
On the page twitter.com (after login), the "Tweet" button opens up a modal dialog for typing in messages.
- The user tabs to the 'Tweet' button in the top right corner and activates it with ENTER.
- The modal dialog opens, the focus set to the text field.
- The user types "Hallo!" into the text field.
- The tabs through several controls to the 'Tweet' button
- He activates the 'Tweet' button with ENTER.
- The tweet "Hallo!" is sent and the modal dialog closes.
Different types of modal dialogs
A modal dialog is a common element in general software. In web content, it first appeared as the small grey system-type messages generated by the browser that authors could display when using a Javasript alert or confirm.
These messages were impossible to style and were severly limited in terms of content, which is why authors began creating custom modal dialogs using
The increased importance of web content on mobile devices has led to a decline of modal dialogs - at least if a dialog is understood to be a pseudo window on top of an inactive page background. On sites optimised for the moble screen, the modal dialog is usually just another full-screen intermediate view.
Finally, there is a native dialog in HTML5 which should make live easier for authors and users. Unfortunately, browser support for the native dialog is still too poor for using it confidently on the web (compare The current state of modal dialog accessibility). Microsoft's Internet Explorer and Edge as well as Apple's Safari Browser do not support it, and Firefox so far only supports it when it is manually enabled (something most users would not know about). However, there is a dialog polyfill that will generate fallback custom dialogs in browsers that do not support native dialogs. (Note: We have not tested how well this works).
Typical usability problems with modal dialogs
Problems for keyboard users - no way to access the dialog
The most serious usability problem caused by modal dialogs is that they are often inaccessible to keyboard users, and especially screen reader users. When a dialog pops up, it is often inserted at the end or start of the page's source code. This means that the dialog is far removed form the control that made it pop up. When a user clicks on a button and that opens a dialog, the focus is very often not set to the dialog. Keyboard users find it impossible to interact with the dialog content – or they can only reach it after tabbing through the entire page.
Problems for screen reader users - not even noticing the dialog
While sighted keyboard users at least see that a dialog has appeared and awaits some interaction, blind users often do not even notice that a dialog has appeared. The focus wanders through the page background while the program logic is stuck - it waits for input to the dialog.
Problems for screen reader users - badly labelled or not keyboard accessible dialog controls
Other frequent problems are that important elements like the close button are not keyboard-accessible, not labeled at all, or labelled in the wrong language.
Problems with widgets from development environments
role=dialog so they won't be announced as dialog to screen reader users. Only some some set the focus to the dialog, nearly all fail to set it back to the trigger - users will then find that their focus is at the start of the page.
The following examples show typical usability problems when interacting with modal dialogs.
1 Low vision use: Finding the modal dialog
Using strong magnification means that dialogs often open fully or partly outside the currently visible section of the screen.
A low vision user working with Windows 10 magnifier at 700% magnification uses Twitter (twitter.com, after login) and wants to post a tweet.
- First, he closes a notification section that asks him to verify his e-mail address.
- He searches along the top of the page towards the right, finds the 'Twittern' button, and klicks on it.
- On a darkened background, a modal dialog opens for writing the tweet, outside the currently visible section.
- The user moves the mouse cursor, and the visible section follows.
- The user discovers the modal dialog with the text input field for the tweet.
2 Keyboard use, non-visual use: bad focus visibility, bad focus management, unlabelled controls
The following video shows a keyboard user trying to interact with a dialog. The screen reader has been turned on to indicate where the focus is - for sighted keyboard users, it is not visible at all.
On the page simplesite.com which is a tool box for visually building simple websites, a keyboard user interacts with a modal dialog for selecting elements of web content.
- A keyboard user focuses the button "ADD CONTENT" which shows no visible focus, and activates it (see note)
- The dialog opens
- Tabbing on, no focus is visible on the close button (x)
- Tabbing on, there is also no visible focus on any of the elements
- Tabbing on, the focus runs past the content of the dialog to the browser chrome (address bar)
- The focus then runs through the entire page content behind the dialog
Note: To make it easier to follow what happens, we have turned on the screen reader. A sighted keyboard user would not know where the focus is, and would therefore be unable to open the dialog — unless he/she uses a helper bookmarklet like Force Focus that forces an indication of the focus position.
Accessibility tips for modal dialogs
- Make the dialog noticeable. The modal dialog shows some content that was initially not on the page. For screen reader users, it is important that they notice it when a modal dialog opens. If it is not marked up correctly, they may not perceive the dialog. Use
aria-modal="true"on the dialog (but compare note on aria-modal).
- Move keyboard focus to the dialog, and back to the trigger. For keyboard users (and that includes blind users), it is important that the focus is moved to the dialog when it opens so that they can interact with its contents. When the dialog closes, the focus should return to the element that triggered the dialog.
- Keep the focus in the dialog. The keyboard focus should stay in the dialog while open. It should circulate through the dialog's interactive elements.
- Give a meaningful name to the modal dialog. Refer to their visible heading via
aria-labelledby, or providing an invisible name via
- Label all dialog controls, including the close button. Each dialog should have a clearly labelled control for closing it. Icon-based buttons for closing [x] must have an accessible name that is read out to screen reader users.
- Hide content below the dialog. Set
aria-hidden="true"on the page content in the background while the dialog is open. A good structure for achieving this is implementing the dialog as a sibling of the main content (i.e., like
main, it is a direct child of the
- Manage pointer input outside the dialog. Either ignore clicks or taps outside the modal dialog, or make them close the modal dialog.
- Make sure the Escape key closes the dialog. It is common practice and expected by many users that hitting the
ESCkey closes the dialog. Do not rely on
ESC, but include a visible close button as well: There are devices that do not have keyboards.
Note on aria-modal: Using
aria-modal="true" currently makes static content in dialogs (if there is any) inaccessible in macOS and iOS (compare The current state of modal dialog accessibility).
COMPARE cases with accessibility ratings
Resources for modal dialogs
- The current state of modal dialog accessibility (Scott o'Hara, Paciello Group, June 2018) - read the comments, too.
- Dialog (modal) (WAI-ARIA Authoring Practices 1.1. W3C Working Group Note, July 2018)
- How To Make Modal Windows Better For Everyone (Scott o'Hara, Smashing Magazine, August 2014)
- Accessible modal window (GitHub, Scott O'Hara)
- Creating An Accessible Modal Dialog (bitsofcode, August 2016)
- Accessible Modal Dialogs - A11ycasts #19 (YouTube video, Rob Dodson, Google, June 2017)
- The Incredible Accessible Modal Window, Version 4 (Greg Kraus, no date)
- How to Build WAI-ARIA Modal Alert Dialogs: A11y Support Series (Paul Adam, Deque Blog, August 2016) - discusses deviations from the pattern proposed in WAI-ARIA Authoring Practices 1.1