{"id":308,"date":"2018-12-10T16:04:35","date_gmt":"2018-12-10T16:04:35","guid":{"rendered":"https:\/\/pressbooks.library.ryerson.ca\/wafd\/?post_type=chapter&p=308"},"modified":"2022-12-16T18:29:59","modified_gmt":"2022-12-16T18:29:59","slug":"wai-aria-alert-and-message-dialogs","status":"publish","type":"chapter","link":"https:\/\/pressbooks.library.torontomu.ca\/wafd\/chapter\/wai-aria-alert-and-message-dialogs\/","title":{"raw":"WAI-ARIA Alert and Message Dialogs","rendered":"WAI-ARIA Alert and Message Dialogs"},"content":{"raw":"Providing feedback after a user completes an action is a critical accessibility feature. Feedback can be an error message when something has gone wrong. Additionally, it can\u00a0 be a confirmation or warning, after which a user has to make a decision before proceeding. Or, it could be completion feedback that is presented after a particular action has occurred to indicate it was successful.\r\n\r\nThe latter is often overlooked by developers. However, for people using a screen reader, notification that an action was successful can be as important as providing error messages. When completion feedback is provided, screen reader users do not need to search through the content of the screen to be sure the action they just completed was successful \u2014 the process\u00a0 can be quite time-consuming.\r\n\r\nIn each type of feedback, it is critical that messages be easy to access. The best strategy for making feedback accessible is to use the WAI-ARIA alert or alert-dialog roles. These are both types of live regions. When the content of the container element with role=\"alert\"<\/code> changes, the content that appears is automatically read aloud by screen readers. A WAI-ARIA alert has an implicit aria-live=\"assertive\"<\/code> and aria-atomic=\"true\"<\/code> (to be covered in more detail in the section on live regions). This means that, when the message appears, it will interrupt whatever the screen reader is in the middle of reading, and the entire content of the element will be read, as opposed to just the new content added (i.e., aria-atomic=\"false\"<\/code>).\r\n
Try This:<\/strong> In the following example of a WAI-ARIA alert, start ChromeVox, then press the \u201cSay Something\u201d button to hear how ChromeVox handles the message that appears. Examine the script and HTML below to see how it was done.<\/div>\r\n
[h5p id=\"11\"]<\/div>\r\n


<\/p>\r\n\r\n

alert vs. alertdialog<\/h2>\r\nError, warning, and completion feedback will typically be created with role=\"alert\"<\/code>, while confirmation feedback will often use role=\"alertdialog\"<\/code>. Use role=\"alert\"<\/code> \u00a0when no user input is needed. Use role=\"alertdialog\"<\/code> when user input is expected, with focus sent to the dialog. At least one element in the dialog must be focusable when using role=\"alertdialog\"<\/code>.\r\n\r\nWatch and listen to the following video to understand how ChromeVox handles WAI-ARIA alerts.\r\n\r\nVideo: WAI-ARIA Alerts<\/a>\u00a0<\/strong>(1:09)\r\n\r\n[embed]https:\/\/www.youtube.com\/embed\/JYcWYAe9dJM[\/embed]\r\n
Suggested Reading:<\/strong> Using ARIA role=\"alert\" or Live Regions to Identify Errors<\/a><\/div>\r\n

Modal Dialogs<\/h2>\r\nModal dialogs interrupt users and require an action. They are appropriate when users' attention needs to be directed toward important information.\r\n\r\nModal dialogs are defined using role=\"alertdialog\"<\/code> and aria-modal=\"true\"<\/code>. Be aware what WAI-ARIA is used for modals, and be aware that when a modal dialog is displayed, focus must be sent to the dialog, and it must remain in the dialog until whatever interaction is complete (e.g., clicking the confirmation button) and the dialog closes. When the dialog closes, focus must be returned to the location from where the dialog was opened.\r\n

Dialogs<\/h2>\r\nDialogs are used like modal dialogs are, except it is still possible to interact with the other content of the page. These are defined using role=\"dialog\"<\/code>.\r\n
\r\n\r\nSuggested Reading:<\/strong>\r\n