The intent of this Success Criterion is to ensure that users are aware that an error - has occurred and can determine what is wrong. The error message should be as specific - as possible. - In the case of an unsuccessful form submission, re-displaying the form and indicating - the fields in error is insufficient for some users to perceive that an error has occurred. - Screen reader users, for example, will not know there was an error until they encounter - one of the indicators. They may abandon the form altogether before encountering the - error indicator, thinking that the page simply is not functional. Per the definition, - an "input error" is information provided by the user that is not accepted. This includes: + +
The intent of this success criterion is to ensure that users are aware that an error + has occurred and can determine what is wrong. In the case of an unsuccessful form submission, + it is not sufficient to only re-display the form without providing any hint that the submission + failed. + The error must be indicated in text. + Whether or not an error message provides users with sufficient information about the nature of + the error, and what they should do to correct it, is covered more specifically by + 3.3.3 Error Suggestion.
- +An "input error" is information provided by the user that is not accepted. This includes:
+For example:
- +If a user enters a value that is too high or too low, and the coding on the page automatically changes that value to fall within the allowed range, the user's error would still need to be described to them as required by the success criterion. Such an error description telling the person of the changed value would meet both this success criterion (Error - Identification) and - Success Criterion 3.3.3 (Error Suggestion). + Identification) and 3.3.3 Error Suggestion.
-The identification and description of an error can be combined with programmatic information that user agents or assistive technologies can use to identify an error and provide error information to the user. For example, certain technologies can specify that the user's input must not fall outside a specific range, or that a form field is required. - This type of programmatic information is not required for this success criterion, but may be covered - by other criteria such as 4.1.2 Name, Role, Value. -
- -It is perfectly acceptable to indicate the error in other ways such as image, color - etc, in addition to the text description. -
- -See also - 3.3.3: Error Suggestion. -
- + Currently, few technologies support this kind of programmatic information, but this + success criterion does not require, nor prevent it. + +It is perfectly acceptable to indicate the error in other ways such as through the use of an image, + color, or other visual indicator, in addition to the text description.
+ +This criterion does not mandate any particular way in which errors should be displayed. Depending + on the situation, it may be more suitable for all errors to be listed at the start or before a form. + In other cases, it may be more appropriate to show errors inline, with error messages next to the specific + fields that are in error. Errors could also be listed in an alert, or dialog. This criterion does not + cover which of these methods should be used - the only requirement is for errors to be presented to users in text or a text alternative. +
+See also 3.3.3: Error Suggestion.
+This Success Criterion does not mean that color or text styles cannot be used to indicate - errors. It simply requires that errors also be identified using text. In this example, - two asterisks are used in addition to color. +
This success criterion does not mean that color or text styles cannot be used to indicate + errors. It simply requires that errors also be identified using text.