See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how they relate to the normative WCAG 2.0 success criteria. The Applicability section explains the scope of the technique, and the presence of techniques for a specific technology does not imply that the technology can be used in all situations to create content that meets WCAG 2.0.
Technologies that support Accessible Rich Internet Applications (WAI-ARIA).
This technique relates to:
See User Agent Support Notes for ARIA18. Also see WAI-ARIA Technology Notes.
The purpose of this technique is to alert people that an input error has occured. Using role="alertdialog" creates a notification. This notification should be modal with the following characteristics:
aria-label or aria-labelledby attribute gives the alertdialog an accessible name.
aria-describedby provides a reference to the text of the alert.
The alertdialog contains at least one focusable control, and the focus should move to that control when the alertdialog opens.
The tab order is constrained within the alertdialog whilst it is open.
When the dialog is dismissed, the focus moves back to the position it had before the dialog opened, if possible.
Note that the alertdialog should not be present in a way that it will be accessed by AT until it is needed. One way to do this is not to include it in the static HTML and instead to insert it into the DOM via script when the error condition is triggered. The insertion would correspond to the following HTML sample.
This example shows how a notification using role="alertdialog" can be used to notify someone they have entered invalid information.
<div role="alertdialog" aria-labelledby="alertHeading" aria-describedby="alertText">
<h1 id="alertHeading">Error</h1>
<div id="alertText">Employee's Birth Date is after their hire date. Please verify the birth date and hire date.</div>
<button>Save and Continue</button>
<button>Return to page and correct error</button>
</div>Working example: Alert dialog.
Resources are for information purposes only, no endorsement implied.
(none currently listed)
Trigger the error that causes the alertdialog to appear.
Determine that the alertdialog contains at least one focusable control, and the focus moves to that control when the alertdialog opens.
Determine that the tab order is constrained within the alertdialog while it is open, and when the dialog is dismissed, the focus moves back to the position it had before the dialog opene, if possible.
Examine the element with role="alertdialog" applied.
Determine that either the aria-label or aria-labelledby attribute has been correctly used to give the alertdialog an accessible name.
Determine that the contents of the alertdialog identifies the input error.
Determine whether contents of the alertdialog suggests how to fix the error.
Checks 2, 3, 5 and 6 are true. For SC 3.3.3, Check 7 is also true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.