Technique: Providing error messages on small screens

From Mobile Accessibility Task Force

Mobile Technique - Providing error messages on a small screens

References

Previous version as of DATE

Proposed Mobile Technique - Providing error messages on a small screens

From Alastair Garrison 2016-01-04

Important Information about Techniques

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.

Applicability

Script used with HTML or XHTML.

This technique relates to:

Success Criterion 3.3.1 (Error Identification) How to Meet 3.3.1 (Error Identification) Understanding Success Criterion 3.3.1 (Error Identification) Success Criterion 3.3.3 (Error Suggestion) How to Meet 3.3.3 (Error Suggestion) Understanding Success Criterion 3.3.3 (Error Suggestion)

Description

The objective of this technique is to demonstrate how to provide error messages on a small screen when they have submitted form data that contains an error. The intension is to avoid excessive scrolling through the placement of large error sections ahead of the form.

In essence, once client-side data validation detects one or more errors in the submitted data the <label…> elements associated with each form field found to contain an error are altered to include the text "Error: " (as per W3C Tutorial http://www.w3.org/WAI/tutorials/forms/notifications/). In addition, a sentence is placed at the beginning of the form summarising the situation e.g. "the following registration form contains 3 errors". As the third and final step in the process the user's focus is set to this sentence.

This technique allows screen-reader users navigating in and out of focus to find the form fields with errors.

In a deployed application, if Javascript is turned off, client side validation will not occur. Therefore, this technique would only be sufficient in situations where scripting is relied upon for conformance or when server side validation techniques are also used to catch any errors and return the page with information about the fields with errors.

Examples

Example 1

This example validates required fields as well as fields where a specific format is required. If an error is detected it alters the associated <label…> element of the form field containing an error, creates a summary sentence before the form and changes focus to this sentence.

Example to come…

Related Techniques

SCR32: Providing client-side validation and adding error text via the DOM G83: Providing text descriptions to identify required fields that were not completed G85: Providing a text description when user input falls outside the required format or values SCR18: Providing client-side validation and alert

Tests

Procedure

Create error messages using anchor tags and appropriate scripting via the technique above.

1) Load the page. 2) Enter an invalid value in the field(s) associated with an error message and submit the form. 3) Verify that the <label…> element contents for each of the fields containing invalid values changes to include the text "Error: ", placed at the beginning of the label; that a sentence summarising the situation is created before the form; and that the sentence summarising the situation is now focused. 4) Enter valid data in the field(s) associated with an error message and submit the form. 5) Verify that no error messages are shown.

Expected Results

Checks #3 and #5 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.