Purpose of this article
The wording of the intent for Success Criteria 3.3.1 leads many to believe that the SC requires error messages to be marked up in a manner that makes users aware of their presence when rendered on the screen. Actually a reading of the normative language of WCAG 2.0 does not support this view; there are other Success criteria that require that. Here is the text of SC 3.3.1:
SC 3.3.1 Error Identification:
If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. (Level A)
It may be noted that:
- SC 3.3.1 belongs to the "Understanding Principle"
- Success Criteria requiring content to be perceivable / programmatically determinable are covered under the first principle: Perceivable
- Success Criteria requiring proper role, state etc. for user interface components including components generated by scripts are covered under principle on robustness
- Finally, the phrase "described to the user" (or "provided to the user" in SC 3.3.3) is not defined in WCAG 2.0. So one cannot interpret this phrase to encompass the concept of "perceivable" which appears to be the assumpption underlying the statement, "The intent of this Success Criterion is to ensure that users are aware that an error has occurred " in the Understanding SC 3.3.1 in WCAG 2.0 as it stands now.
As an example, consider, SC 3.3.2 which reads,
"Labels or instructions are provided when content requires user input. (Level A)".
This is interpreted to mean that a form control only requires a label (or in its absence, an instruction) to identify its purpose. And it is SC 4.1.2 / SC 1.3.1 respectively (and not SC 3.3.2) that mandate that the form control needs an accessible name or a programmatically determinable label. That's why SC 3.3.1 cannot be burdened with accessibility mandates of SC 1.3.1 or SC 4.1.2. So here is a draft of the SC's Intent which I believe is more in line with the normative requirements of WCAG 2.0.
Intent of SC 3.3.1 – Error Identification -Re-written
The intent of this Success Criterion is to ensure that input errors detected are explicitly identified in text. Error messages expressed in text convey which specific form control failed validation and help users understand why a particular input item failed validation. The messages may be displayed as a group , or, separately close to the corresponding form control.
This SC only requires that the item in error is identified and the reason is described in text. Other SCs under Perceivable Principle and / or Robust principle require the text message when presented is perceivable by users in the expected order.
The error message may directly include the name of the form control that failed validation or it may be marked up in a manner that the control's label plus the error message together identify the failed control.
Merely providing a visual cue that identifies the failed field is not sufficient. An error icon, or a border around the failed field for instance, may be used for visual reinforcement but are not required by the SC.
Rules for correct input are not required to be presented before the form is submitted. Yet, doing so may minimize input errors if users are better informed before form submission but that is a matter of UI design and overall usability.
The term "input error" is defined in WCAG 2.0. It covers input validation errors that prevent successful submission of a form. These include:
- Failure to provide input data or to indicate a selection
- input data that does not match expected data values or data ranges or data format
- 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.
Input error messages in text may be presented in different ways. For instance:
- Instantly as the user’s focus moves away from a control that has failed validation
- On the same page without refreshing the entire page
- By re-displaying the form with error messages
If the manner of presenting the error message in text conveys that it is related to a particular form control, this relationship too may need to be programmatically determinable as per SC 1.3.1.
If the manner of presenting the error message in text appears like a form of visual alert, it may be necessary to ensure that message is assigned a suitable semantic role so that assistive technology users too can perceive it as an alert in order that the message meets SC 1.3.1.
Significance of this change:
- Failing to associate a visible text message describing an input error with the corresponding form control is often flagged as a violation of SC 3.3.1. It is really a violation of SC 1.3.1 when the message appears to be related to the form control by the manner of its presentation and not SC 3.3.1.
- Failing to alert screen reader users that an error message has been presented in text is also flagged as a violation of SC 3.3.1. This view needs to be reviewed in the light of the aforesaid. Setting keyboard focus on the error message as soon as it is rendered is appropriate in some situations and this is one method of promoting user awareness. Or, the error message needs to be assigned a suitable role to indicate that a notification has been visually added to the viewport.
WCAG 2.0 adequately addresses content changes in the form of error messages including global error messages placed above a form, like, "Please correct the errors and resubmit the form". One only has to invoke the support of the appropriate success criterion while flagging an accessibility violation.