Modal Dialog Example
Following is an example implementation of the
design pattern for modal dialogs.
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.
- 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.
Add Delivery Addressdialog (id=dialog1):
- Initial focus is set on the first input, which is the first focusable element.
- The dialog does not need
aria-describedbysince there is no static text that describes it.
- When the dialog closes as a result of the
Cancelaction, the user's point of regard is maintained by returning focus to the
Add Delivery Addressbutton.
When the dialog closes as a result of the
Addaction and the
Address Addeddialog replaces the
Add Delivery Addressdialog, the
Add Delivery Addressdialog passes a reference to the
Add Delivery Addressbutton to the
Address Addeddialog so that it can maintain the user's point of regard when it closes.
Verification Resultdialog (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
divthat is referenced by
- When the dialog closes, to maintain the user's point of regard, focus returns to the
- The text of this dialog describes design considerations for initial focus and accessible descriptions in dialogs with large amounts of text.
Address Addeddialog (id=dialog3):
Initial focus is set on the
OKbutton, 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
- The element containing the dialog message is referenced by
aria-describedbyto 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 Addressbutton.
- Initial focus is set on the
End of the Road!dialog (id=dialog4):
- This dialog has only one focusable element, which receives focus when the dialog opens.
- Like dialog3,
aria-describedbyis used to facilitate message announcement for screen reader users.
- Like all other dialogs in this example except for the
Address Addedconfirmation dialog, when it closes, the user's point of regard is maintained by returning focus to the element that triggered display of the dialog.
|Shift + Tab||
|Escape||Closes the dialog.|
Role, Property, State, and Tabindex Attributes
||Identifies the element that serves as the dialog container.|
||Gives the dialog an accessible name by referring to the element that provides the dialog title.|
||Tells assistive technologies that the windows underneath the current dialog are not available for interaction (inert).|
aria-modalproperty was introduced in ARIA 1.1. As a new property, screen reader users may experience varying degrees of support for it.
aria-modalproperty to the
dialogelement replaces the technique of using
aria-hiddenon the background for informing assistive technologies that content outside a dialog is inert.
In legacy dialog implementations where
aria-hiddenis used to make content outside a dialog inert for assistive technology users, it is important that:
aria-hiddenis set to
trueon each element containing a portion of the inert layer.
- The dialog element is not a descendant of any element that has