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.
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.
Add Delivery Address
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
The first paragraph is also contained inside the element that provides the dialog description, i.e., the element that is referenced by
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.
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.
End of the Road!
You activated a fake link or button that goes nowhere! The link or button is present for demonstration purposes only.
- 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.
- Applying the
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
- CSS: dialog.css