From 1d8a008d472522cdbfeafa75adc0dfff1cd3fcac Mon Sep 17 00:00:00 2001
From: "Patrick H. Lauke" 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
+ 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. It also won't be sufficient to merely indicate that fields are in error, but not providing
+ users with sufficient information about the specific nature of the error. The error messages should
+ be as specific as possible. And, to ensure that the information is available to all users (whether
+ they are using assistive technologies or not), the error messages must be provided as visible text.
+ Per the definition in WCAG 2.0, an "input error" is information provided by the user
that is not accepted. This includes:
Intent of Error Identification
Intent of Error Identification
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.
- Currently, few technologies support this kind of programmatic information, but the
+ 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 image, color - etc, in addition to the text description. - + etc, in addition to the text description. +
+There may also be situations in which it is clear from the context what the specific error + is - for instance, in a simple login form with a username and password field, if a user + leaves one of the fields completely blank, simply indicating that the empty field is in + error using an image or icon (with appropriate alternative text) would be sufficient. + However, if the user did enter data in both of those fields, and login was unsuccessful, further + information and an actual specific error message will be required (e.g. "no account found with this + username", or "the username or password are incorrect"). Likewise, in a form that explicitly indicates + that all fields are mandatory/required, it will be sufficient to indicate empty fields as being in error, + without the need to reiterate that the user must fill in the field.
See also @@ -94,16 +103,14 @@
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. + errors. It simply requires that errors also be identified using text.
Per the definition in WCAG 2.0, an "input error" is information provided by the user - that is not accepted. This includes: +
An "input error" is information provided by the user that is not accepted. This includes:
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 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 (which are not already + clear from the specific nature/context of the input fields) to be presented to users in text. +
+See also
3.3.1: Error Suggestion.
From 82dd96bcf797e04e85e7e8be2f5cc3d0c524fb84 Mon Sep 17 00:00:00 2001
From: "Patrick H. Lauke" Intent of Error Identification
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.
It is perfectly acceptable to indicate the error in other ways such as image, color @@ -99,11 +100,6 @@
See also - 3.3.1: Error Suggestion. -
- -An "input error" is information provided by the user that is not accepted. This includes:
From 8af0fce3c4f88e18fe99161958de95c3a0928511 Mon Sep 17 00:00:00 2001 From: "Patrick H. Lauke"It is perfectly acceptable to indicate the error in other ways such as image, color
From 85bf19a90002d26f349fd18897558143cda4d310 Mon Sep 17 00:00:00 2001
From: "Patrick H. Lauke" Intent of Error Identification
it is not sufficient to only re-display the form without providing any hint that the submission
failed. It also won't be sufficient to merely indicate that fields are in error, but not providing
users with sufficient information about the specific nature of the error. The error messages should
- be descriptive, helping users understand what the problem was. And, to ensure that the information
- is available to all users (whether they are using assistive technologies or not), the error messages
- must be provided as visible text.
+ be as descriptive and specific as possible, helping users understand what the problem was.
+ And, to ensure that the information is available to all users (whether they are using assistive
+ technologies or not), the error messages must be provided as visible text.
An "input error" is information provided by the user that is not accepted. This includes:
From 6880cf0e4ac2de4a5d92621236410d16b659c1e4 Mon Sep 17 00:00:00 2001 From: "Patrick H. Lauke"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. It also won't be sufficient to merely indicate that fields are in error, but not providing + failed. It also won't be sufficient to merely indicate that fields are in error without providing users with sufficient information about the specific nature of the error. The error messages should be as descriptive and specific as possible, helping users understand what the problem was. And, to ensure that the information is available to all users (whether they are using assistive @@ -95,8 +95,8 @@
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 the specific
+ 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 (which are not already
clear from the specific nature/context of the input fields) to be presented to users in text.
From 5920a572d90b6db0e53a08428f0276d85fb9686f Mon Sep 17 00:00:00 2001
From: Alastair Campbell Intent of Error Identification
it is not sufficient to only re-display the form without providing any hint that the submission
failed. It also won't be sufficient to merely indicate that fields are in error, but not providing
users with sufficient information about the specific nature of the error. The error messages should
- be descriptive, helping users understand what the problem was. And, to ensure that the information
- is available to all users (whether they are using assistive technologies or not), the error messages
- must be provided as visible text.
+ be descriptive, helping users understand what the problem was.
An "input error" is information provided by the user that is not accepted. This includes:
@@ -99,7 +97,7 @@An "input error" is information provided by the user that is not accepted. This includes:
From 24e544bc8c1eb737511e8d726b075e9c07430941 Mon Sep 17 00:00:00 2001 From: Alastair CampbellA
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. + is described to the user in text.
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. It also won't be sufficient to merely indicate that fields are in error without providing - users with sufficient information about the specific nature of the error. The error messages must be sufficiently descriptive to help users understand what the problem is. + failed. It also won't be sufficient to merely indicate that fields are in error without providing users with sufficient information about the specific nature of the error. The error messages must be descriptive to help users understand what the problem is. The error can be indicated in text, which does allow for visually apparent images or icons with suitable alternative text. 3.3.3 Error Suggestion covers what the error messages should contain in certain circumstances
An "input error" is information provided by the user that is not accepted. This includes:
@@ -70,11 +69,7 @@It is perfectly acceptable to indicate the error in other ways such as image, color @@ -96,8 +91,7 @@
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. It also won't be sufficient to merely indicate that fields are in error without providing users with sufficient information about the specific nature of the error. The error messages must be descriptive to help users understand what the problem is. The error can be indicated in text, which does allow for visually apparent images or icons with suitable alternative text. 3.3.3 Error Suggestion covers what the error messages should contain in certain circumstances + failed. It also won't be sufficient to merely indicate that fields are in error without providing users with sufficient information about the specific nature of the error. The error messages must be descriptive to help users understand what the problem is. The error can be indicated in text, which does allow for visually apparent images or icons with suitable alternative text. 3.3.3 Error Suggestion covers what the error messages should contain in certain circumstances.
An "input error" is information provided by the user that is not accepted. This includes:
@@ -75,23 +75,12 @@It is perfectly acceptable to indicate the error in other ways such as image, color etc, in addition to the text description.
-There may also be situations in which it is clear from the context what the specific error - is - for instance, in a simple login form with a username and password field, if a user - leaves one of the fields completely blank, simply indicating that the empty field is in - error using an image or icon (with appropriate alternative text) would be sufficient. - However, if the user did enter data in both of those fields, and login was unsuccessful, further - information and an actual specific error message will be required (e.g. "no account found with this - username", or "the username or password are incorrect"). Likewise, in a form that explicitly indicates - that all fields are mandatory/required, it will be sufficient to indicate empty fields as being in error, - without the need to reiterate that the user must fill in the field. -
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 (which are not already - clear from the specific nature/context of the input fields) to be presented to users in text or a text alternative. + 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.
A
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. + is described to the user in text.
\ No newline at end of file From 7bebe1b4e223728ce5629493e13f3022e363ed89 Mon Sep 17 00:00:00 2001 From: Mike GowerAn "input error" is information provided by the user that is not accepted. This includes: +
An "input error" occurs when information provided by the user that is not accepted. This includes:
It is perfectly acceptable to indicate the error in other ways such as image, color
From 2caac67d044b608885e63ffd74a150905bdeaf83 Mon Sep 17 00:00:00 2001
From: "Patrick H. Lauke" 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. It also won't be sufficient to merely indicate that fields are in error without providing
- users with sufficient information about the specific nature of the error.
- The error messages must be descriptive to help users understand what the problem is.
+ failed.
The error can be indicated in text, which does allow for visually apparent images or
- icons with suitable alternative text. 3.3.3 Error Suggestion
- covers what the error messages should contain in certain circumstances.
+ icons with suitable alternative 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 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.
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
@@ -95,35 +76,29 @@ See also
- 3.3.3: Error Suggestion.
- 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.
@@ -144,159 +119,66 @@ Understanding Error Identification
-
+
In brief
@@ -17,77 +17,58 @@
In brief
Intent of Error Identification
-
-
+
-
-
+
-
-
-
+
Intent of Error Identification
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.
Benefits of Error Identification
-
-
+
-
-
+
Examples of Error Identification
-
+
Examples of Error Identification
phone number, seating preference and e-mail address. If any of the fields of the form
are either not completed or completed incorrectly, an alert is displayed notifying
the user which field or fields were missing or incorrect.
-
+
Examples of Error Identification
and providing a unique character to make it easy to search for the fields, the fields
are highlighted in yellow to make it easier to visually search for them as well.
-
+
-
+
Resources for Error Identification
-
-
-
+
Techniques for Error Identification
-
-
+
Sufficient Techniques for Error Identification
-
-
+
Situation A: If a form contains fields for which information from the user is mandatory.
-
+
-
-
-
Situation B: If information provided by the user is required to be in a specific data
format or of certain values.
-
+
-
-
-
Additional Techniques (Advisory) for Error Identification
-
-
+
-
Failures for Error Identification
-
-
+