Modal dialogs

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.

Video description

On the page (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 divs.

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

One reason why so many dialogs used on the web cause problems is that many developers use ready-made widgets provided by their development environment or JavaScript libraries. These baked-in dialogs often do not carry a 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.

For some of the better known Javascript and CSS frameworks, plugins or widgets have been developed that help improve accessibility. Examples are ngA11y for Angular, the bootstrap-accessibility-plugin for Bootstrap, and a fully accessible modal for React.


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.

Video description

A low vision user working with Windows 10 magnifier at 700% magnification uses Twitter (, 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.

Video description

On the page 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 role="dialog" (or role="alertdialog") and 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 aria-label.
  • 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 body element).
  • 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 ESC key 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).

Resources for modal dialogs