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 ARIA19. Also see WAI-ARIA Technology Notes.
The purpose of this technique is to notify Assistive Technologies (AT) when an input error occurs. The aria-live attribute makes it possible for an AT (such as a screen reader) to be notified when error messages are injected into a Live Region container. The content within the aria-live region is automatically read by the AT, without the AT having to focus on the place where the text is displayed.
There are also a number of special case live region roles which can be used instead of applying live region properties directly.
The following example uses role=alert which is equivalent to using aria-live=assertive.
In the example there is an empty error message container element with aria-atomic=true and an aria-live property or alert role present in the DOM on page load. The error container must be present in the DOM on page load for the error message to be spoken by most screen readers. aria-atomic=true is necessary to make Voiceover on iOS read the error messages after more than one invalid submission.
jQuery is used to test if the inputs are empty on submit and inject error messages into the live region containers if so. Each time a new submit is attempted the previous error messages are removed from the container and new error messages injected.
<script src="http://code.jquery.com/jquery.js"></script>
<script>
$(document).ready(function(e) {
$('#signup').submit(function() {
$('#errors').html('');
if ($('#first').val() === '') {
$('#errors').append('<p>Please enter your first name.</p>');
}
if ($('#last').val() === '') {
$('#errors').append('<p>Please enter your last name.</p>');
}
if ($('#email').val() === '') {
$('#errors').append('<p>Please enter your email address.</p>');
}
return false;
});
});
</script>
<form name="signup" id="signup" method="post" action="">
<p id="errors" role="alert" aria-atomic="true"></p>
<p>
<label for="first">First Name (required)</label><br>
<input type="text" name="first" id="first">
</p>
<p>
<label for="last">Last Name (required)</label><br>
<input type="text" name="last" id="last">
</p>
<p>
<label for="email">Email (required)</label><br>
<input type="text" name="email" id="email">
</p>
<p>
<input type="submit" name="button" id="button" value="Submit">
</p>
</form>Working example: Using role=alert to identify errors.
Resources are for information purposes only, no endorsement implied.
(none currently listed)
Determine that an empty error container role=alert or aria-live=assertive attribute is present in the DOM at page load.
Trigger the error that causes the content in the live region to appear or update.
Determine that the error message was injected into the already present error container.
#1 and #3 are 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.