Modal Dialog Example

Read This First

The code in this example is not intended for production environments. Before using it for any purpose, read this to understand why.

This is an illustrative example of one way of using ARIA that conforms with the ARIA specification.

There may be support gaps in some browser and assistive technology combinations, especially for mobile/touch devices. Testing code based on this example with assistive technologies is essential before considering use in production systems.
The ARIA and Assistive Technologies Project is developing measurements of assistive technology support for APG examples.
Robust accessibility can be further optimized by choosing implementation patterns that maximize use of semantic HTML and heeding the warning that No ARIA is better than Bad ARIA.

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

Accessibility Features

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.
Focus and accessible descriptions are set based on the content of each dialog.
1. 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.
2. 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.
3. 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.
4. 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

Key	Function
`Tab`	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

Role	Attribute	Element	Usage
`dialog`		`div`	Identifies the element that serves as the dialog container.
	`aria-labelledby=IDREF`	`div`	Gives the dialog an accessible name by referring to the element that provides the dialog title.
	`aria-describedby=IDREF`	`div`	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`

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.
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.
In legacy dialog implementations where aria-hidden is used to make content outside a dialog inert for assistive technology users, it is important that:
1. aria-hidden is set to true on each element containing a portion of the inert layer.
2. 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

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.