ErrorNotificationUsingAlertRoleOrAriaLive action=edit
Applicability
This technique applies to HTML with WAI-ARIA.
- SC 3.3.1 Level A): Error Identification
- SC 3.3.3 (Level AA): Error Suggestion
Description
The objective of this technique is to alert the user for input validation errors or a failed form submission. An error message placed within an element that is marked up with WAI-ARIA role=”alert” or aria-live=”assertive” is exposed to assistive technology and automatically announced by most screen reading software without the AT having to explicitly focus on the error message displayed on the page. With respect to functionality and user agent behavior, using role="alert" is equivalent to using aria-live="assertive".
When the alert text is worded in a manner that includes suggestion for fixing the error, this method will satisfy SC 3.3.3 too.
Notes:
- Role=”alert” may be set on elements like P, DIV, SPAN. Placing it directly on elements like H<n> or UL / OL tag will result in a validation error.
- Aria-live=”assertive” may be set directly on elements like H<n> or UL / Li besides other elements like P, DIV or SPAN.
- The placement of error messages depends on the overall design of the form, its length, content and context of use. When error messages are placed adjacent to relevant fields, this method may simply be employed to convey a failed form submission and not field-specific message(s).
- Although the text marked up with role=”alert” or aria-live=”assertive” is announced without explicit focus management, authors may still need to do so to ensure a user can navigate meaningfully (SC 2.4.3) to correct input errors or review especially lenthy alert messages. Explicitly setting focus on the alert text (by using tabindex=”-1” or on the first field that has failed validation are possible approaches.
- When focus is not set explicitly,set aria-atomic=”true” on the element with role=”alert” or aria-live=”assertive”.
User Agent Notes:
- To make it work with most screen readers, the element with role=”alert” or aria-live=”assertive” should be present on page load, i.e. when the form is first displayed.
- When using role="alert", set tabindex="-1" and focus explicitly on the element containing the error message(s). This will ensure it works with Internet Explorer.
Examples
Example 1:
A DIV with role=alert is present above the form on page load. This contains a UL tag into which a list item is injected using jQuery for each input error detected.
<a href="http://mars.dequecloud.com/demo/Form-alertWithJQ.htm" target="_new">Example with role="alert"</a>
The Code Block
<script>
$(document).ready(function(e) {
$('#signup').submit(function() {
$('#errors').html();
if ($('#first').val() === ) {
$('#errors').append('
Please enter your first name. ');
}
if ($('#last').val() === ) {
$('#errors').append('
Please enter your last name. ');
}
if ($('#email').val() === ) {
$('#errors').append('
Please enter your email address. ');
}
$('#errors').focus();
return false;
});
});
</script>
<form name="signup" id="signup" method="post" action="#">
<label for="first">First Name (required)</label>
<input type="text" name="first" id="first">
<label for="last">Last Name (required)</label>
<input type="text" name="last" id="last">
<label for="email">Email (required)</label>
<input type="text" name="email" id="email">
<input type="submit" name="button" id="button" value="Submit">
</form>
Example 2:
An H2 tag with aria-live=assertive is present above the form on page load. The error message is injected using jQuery when input errors are detected. Field-specific errors are not necessary in this example; instead every failed field is marked up with aria-invalid=true.
<a href="http://mars.dequecloud.com/demo/Form-AriaLiveWithJQ.htm" target="_new">Example with aria-live="assertive"</a>
The Code Block
<script src="http://code.jquery.com/jquery-1.10.2.js"></script>
<script>
$(document).ready(function(e) {
$('#signup').submit(function() {
$('#errText').html();
$('input').removeAttr("aria-invalid");
$('label').removeAttr("class");
var eFlag = 0;
if ($('#first').val() === ) {
$('#first').attr("aria-invalid", "true");
$("label[for='first']").addClass('failed');
eFlag++;
}
if ($('#last').val() === ) {
$('#last').attr("aria-invalid", "true");
$("label[for='last']").addClass('failed');
eFlag++;
}
if ($('#email').val() === ) {
$('#email').attr("aria-invalid", "true");
$("label[for='email']").addClass('failed');
eFlag++;
}
if (eFlag > 0) {
$('#errText').html("Please complete all required fields (" + eFlag + ") and retry").focus();
}
return false;
});
});
</script>
<style type="text/css">
label.failed {
border: red thin solid;
}
</style>
<body>
<form name="signup" id="signup" method="post" action="#">
<label for="first">First Name (required)</label>
<input type="text" name="first" id="first">
<label for="last">Last Name (required)</label>
<input type="text" name="last" id="last">
<label for="email">Email (required)</label>
<input type="text" name="email" id="email">
<input type="submit" name="button" id="button" value="Submit">
</form>
Example 3
<a href="http://mars.dequecloud.com/demo/form-alert2.htm">This example</a> that uses aria-live includes other accessibility features that enhance usability especially in certain contexts.
- Aria-describedby to associate the error text with specific field
- An error icon next to every field that has failed validation
- Setting focus on the error message(s) placed before the form.
Test Procedure:
- Either role="alert" or aria-live="assertive" is present on the element on page load
- Suitable error text is dynamically injected into the element when error(s) are triggered. (When using role="alert", the error message may be placed in the immediate child element too).
- The error message placed within the element with role=”alert” or aria-live=”assertive”:
- clearly states the validation error
- identifies the failed field when this is not done in any other accessible manner
- The error messages are instantly exposed to and rendered by user agent – assistive technologies.
- The alert text suggests corrective action for fixing the error
For SC 3.3.1, items 1 to 4 are true; for SC 3.3.3, items 1 to 5 are true
Rationale for technique re-write
- There are nuances in the usage of role=alert and aria-live=assertive, which is not conveyed by the technique in its present form
- The example#1 places all error messages in a P tag … this fails SC 1.3.1 as the content represents a list semantically.
- There is no example for aria-live.
- The focus of the test procedure is on the mechanics of coding … not on how the SC is satisfied
- Reference to other special aria-live roles like status etc. in the current description is not relevant while discussing role=alert / aria-live=assertive as they are not meant for error notification
- The technique fails to say that this can satisfy SC 3.3.3 too.
I agree the re-write above is long … it can be split into two techniques with little effort if all agree. Admittedly, there may be some text duplication. I had included some of the above points in my survey comments for Dec 10 and 17