Modal Dialog Example

About This Example

Following is an example implementation of the Dialog (Modal) Pattern. The below Add Delivery Address button opens a modal dialog that contains two buttons that open other dialogs. The accessibility features section explains the rationale for initial focus placement and use of aria-describedby in each dialog.

Similar examples include:

• Alert Dialog Example: A confirmation prompt that demonstrates an alert dialog.
• Date Picker Dialog example: Demonstrates a dialog containing a calendar grid for choosing a date.

Example

Add Delivery Address

Add Delivery Address

Street:

City:

State:

Zip:

Special instructions: For example, gate code or other information to help the driver find you

Verify AddressAddCancel

Verification Result

This is just a demonstration. If it were a real application, it would provide a message telling whether the entered address is valid.

For demonstration purposes, this dialog has a lot of text. It demonstrates a scenario where:

• The first interactive element, the help link, is at the bottom of the dialog.
• If focus is placed on the first interactive element when the dialog opens, the validation message may not be visible.
• If the validation message is visible and the focus is on the help link, then the focus may not be visible.
• When the dialog opens, it is important that both:
  • The beginning of the text is visible so users do not have to scroll back to start reading.
  • The keyboard focus always remains visible.

There are several ways to resolve this issue:

• Place an interactive element at the top of the dialog, e.g., a button or link.
• Make a static element focusable, e.g., the dialog title or the first block of text.

Please DO NOT make the element with role dialog focusable!

• The larger a focusable element is, the more difficult it is to visually identify the location of focus, especially for users with a narrow field of view.
• The dialog has a visual border, so creating a clear visual indicator of focus when the entire dialog has focus is not very feasible.
• Screen readers read the label and content of focusable elements. The dialog contains its label and a lot of content! If a dialog like this one has focus, the actual focus is difficult to comprehend.

In this dialog, the first paragraph has tabindex=-1. The first paragraph is also contained inside the element that provides the dialog description, i.e., the element that is referenced by aria-describedby. With some screen readers, this may have one negative but relatively insignificant side effect when the dialog opens -- the first paragraph may be announced twice. Nonetheless, making the first paragraph focusable and setting the initial focus on it is the most broadly accessible option.

link to helpaccepting an alternative formClose

Address Added

The address you provided has been added to your list of delivery addresses. It is ready for immediate use. If you wish to remove it, you can do so from your profile.

OK

End of the Road!

You activated a fake link or button that goes nowhere! The link or button is present for demonstration purposes only.

Close

Accessibility Features

1. To make the content easier to read when displayed on small screens, the dialog fills 100% of the screen. Completely covering the background window also hides background movement that occurs on some mobile devices when scrolling content inside the dialog.

2. Focus and accessible descriptions are set based on the content of each dialog.

3. Add Delivery Address dialog (id=dialog1): - Initial focus is set on the first input, which is the first focusable element. - The dialog does not need aria-describedby since there is no static text that describes it. - When the dialog closes as a result of the Cancel action, the user's point of regard is maintained by returning focus to the Add Delivery Address button. - When the dialog closes as a result of the Add action and the Address Added dialog replaces the Add Delivery Address dialog, the Add Delivery Address dialog passes a reference to the Add Delivery Address button to the Address Added dialog so that it can maintain the user's point of regard when it closes.

4. Verification Result dialog (id=dialog2): - Initial focus is set on the first paragraph because the first interactive element is at the bottom, which is out of view due to the length of the text. - To support screen reader user awareness of the dialog text, the dialog text is wrapped in a div that is referenced by aria-describedby. - When the dialog closes, to maintain the user's point of regard, focus returns to the Verify Address button. - The text of this dialog describes design considerations for initial focus and accessible descriptions in dialogs with large amounts of text.

5. Address Added dialog (id=dialog3): - Initial focus is set on the OK button, which is the last focusable element. This is for efficiency since most users will simply dismiss the dialog as soon as they have read the message. Users can press Tab to focus on the My Profile link. - The element containing the dialog message is referenced by aria-describedby to hint to screen readers that it should be announced when the dialog opens. - When the dialog closes, the user's point of regard is maintained by setting focus on the Add Delivery Address button.

6. End of the Road! dialog (id=dialog4): - This dialog has only one focusable element, which receives focus when the dialog opens. - Like dialog3, aria-describedby is used to facilitate message announcement for screen reader users. - Like all other dialogs in this example except for the Address Added confirmation dialog, when it closes, the user's point of regard is maintained by returning focus to the element that triggered display of the dialog.

Keyboard Support

• Moves focus to next focusable element inside the dialog.
• When focus is on the last focusable element in the dialog, moves focus to the first focusable element in the dialog.

| | Shift + Tab |

• Moves focus to previous focusable element inside the dialog.
• When focus is on the first focusable element in the dialog, moves focus to the last focusable element in the dialog.

| | Escape | Closes the dialog. |

Role, Property, State, and Tabindex Attributes

• Gives the dialog an accessible description by referring to the dialog content that describes the primary message or purpose of the dialog.
• Used in three of the four dialogs included in the example. See the above accessibility features section for an explanation.

| | | aria-modal=true | div | Tells assistive technologies that the windows underneath the current dialog are not available for interaction (inert). |

Notes on aria-modal and aria-hidden

1. The aria-modal property was introduced in ARIA 1.1. As a new property, screen reader users may experience varying degrees of support for it.
2. Applying the aria-modal property to the dialog element replaces the technique of using aria-hidden on the background for informing assistive technologies that content outside a dialog is inert.
3. In legacy dialog implementations where aria-hidden is used to make content outside a dialog inert for assistive technology users, it is important that:
4. aria-hidden is set to true on each element containing a portion of the inert layer.
5. The dialog element is not a descendant of any element that has aria-hidden set to true.

Assistive Technology Support

Learn how to interpret and use assistive technology support data

Embedded content

JavaScript and CSS Source Code

• CSS: dialog.css
• JavaScript: dialog.js, utils.js

HTML Source Code

To copy the following HTML code, please open it in CodePen.