3.3.1 Error Identification (A)

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 in WCAG 2.0, an "input error" is information provided by the user that is not accepted. This includes:

• Information that is required by the web page but omitted by the user, or
• Information that is provided by the user but that falls outside the required data format or allowed values.

For example:

• The user fails to enter the proper abbreviation in to state, province, region, etc. field;
• The user enters a state abbreviation that is not a valid state;
• The user enters a non-existent zip or postal code;
• The user enters a birth date 2 years in the future;
• The user enters alphabetic characters or parentheses into their phone number field that only accepts numbers;
• The user enters a bid that is below the previous bid or the minimum bid increment.

Note: 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 3.3.1 Error Identification and 3.3.3 Error suggestions (level AA).

Note: this criterion is only concerned with errors being identified using text, where "text" includes things such as images with appropriate alternative text as per 1.1.1 Non-text Content (level A). If an image (or other non-text element) is used to identify errors, and this does not pass 1.1.1 Non-text Content, then that is a fail for both this success criterion and 1.1.1 Non-text Content.

Note: beyond text, there are programmatic ways in which errors can be identified and described. User agents in general, and assistive technologies in particular, can use these programmatic ways to provide error information to the user. One example would be the use of aria-invalid="true" on an erroneous/invalid form field. However, this success criterion is not concerned with the presence or absence of these - any issues relating to programmatic identification or errors fall under success criterion 4.1.2 Name, role, value (level A). Further, if a page relies purely on programmatic ways to identify errors, without providing any visible text (or image with appropriate alternative), this criterion is marked as fail.

Note: if the page does not contain any components that require specific user input (and therefore cannot have any input errors), this criterion is marked as not applicable.