You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rewrite for 3.3.1 Error Identification understanding document (#1651)
* remove the misleading statement about screen reader users needing to
know that an error occurred before hitting one of the indicators/fields.
this implicitly suggests that the intent is for an error message/list to
be shown to (screen reader) users before the actual form, which is not
in fact the intention nor the requirement of this SC
* tweak the benefit for users with cognitive/language/learning
disabilities
* refocus on the benefit to ALL users, not just screen reader users
* ~add allowance for situations where an error indication is already
self-explanatory/obvious from context (e.g. a form where fields have
already explicitly been identified as mandatory/required - not necessary
for compliance to now ALSO explicitly say "as we already told you, this
field is mandatory")~ [potentially removed by mbgower suggestion]
Closes#977
---------
Co-authored-by: Alastair Campbell
Co-authored-by: Mike Gower
Co-authored-by: Wilco Fiers
Co-authored-by: Mike Gower
Currently, few technologies support this kind of programmatic information, but this
65
+
success criterion does not require, nor prevent it.p>
66
+
67
+
<p>It is perfectly acceptable to indicate the error in other ways such as through the use of an image,
68
+
color, or other visual indicator, in addition to the text description.p>
69
+
70
+
<divclass="note">
71
+
<p>This criterion does not mandate any particular way in which errors should be displayed. Depending
72
+
on the situation, it may be more suitable for all errors to be listed at the start or before a form.
73
+
In other cases, it may be more appropriate to show errors inline, with error messages next to the specific
74
+
fields that are in error. Errors could also be listed in an alert, or dialog. This criterion does not
75
+
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.
76
+
p>
77
+
div>
78
+
79
+
<p>See also <ahref="error-suggestion">3.3.3: Error Suggestiona>.p>
80
+
96
81
section>
97
82
<sectionid="benefits">
98
83
<h2>Benefits of Error Identificationh2>
99
-
100
-
84
+
101
85
<ul>
102
-
103
-
<li> Providing information about input errors in text allows users who are blind or colorblind
104
-
to perceive the fact that an error occurred.
86
+
<li>
87
+
Providing information about input errors in text allows users who are blind or color deficient (color blind) to perceive the fact that an error occurred.
105
88
li>
106
-
107
89
<li>
108
-
This Success Criterion may help people with cognitive, language, and learning disabilities
109
-
who have difficulty understanding the meaning represented by icons and other visual
110
-
cues.
111
-
112
-
90
+
This success criterion may help people with cognitive, language, and learning disabilities
91
+
who have difficulty understanding the specific reason why a form submission failed (in cases
92
+
where this is not already made obvious by the nature of the form).
113
93
li>
114
-
115
94
ul>
116
-
95
+
117
96
section>
118
-
97
+
119
98
<sectionid="examples">
120
99
<h2>Examples of Error Identificationh2>
121
-
100
+
122
101
<dl>
123
102
<dt>Identifying errors in a form submissiondt>
124
103
<dd>
@@ -127,11 +106,10 @@
Examples of Error Identification
127
106
phone number, seating preference and e-mail address. If any of the fields of the form
128
107
are either not completed or completed incorrectly, an alert is displayed notifying
129
108
the user which field or fields were missing or incorrect.p>
130
-
109
+
131
110
<divclass="note">
132
-
<p>This Success Criterion does not mean that color or text styles cannot be used to indicate
133
-
errors. It simply requires that errors also be identified using text. In this example,
134
-
two asterisks are used in addition to color.
111
+
<p>This success criterion does not mean that color or text styles cannot be used to indicate
112
+
errors. It simply requires that errors also be identified using text.
135
113
p>
136
114
div>
137
115
dd>
@@ -140,159 +118,66 @@
Examples of Error Identification
140
118
and providing a unique character to make it easy to search for the fields, the fields
141
119
are highlighted in yellow to make it easier to visually search for them as well.dd>
142
120
dl>
143
-
121
+
144
122
section>
145
-
123
+
146
124
<sectionid="resources">
147
125
<h2>Resources for Error Identificationh2>
148
-
149
-
150
-
126
+
151
127
section>
152
-
128
+
153
129
<sectionid="techniques">
154
130
<h2>Techniques for Error Identificationh2>
155
-
156
-
131
+
157
132
<sectionid="sufficient">
158
133
<h3>Sufficient Techniques for Error Identificationh3>
<li><ahref="../Techniques/general/G84" class="general">G84: Providing a text description when the user provides information that is not in the list of allowed valuesa>li>
159
+
<li><ahref="../Techniques/general/G85" class="general">Providing a text description when user input falls outside the required format or valuesa>li>
160
+
<li><ahref="../Techniques/client-side-script/SCR18" class="script">Providing client-side validation and alerta>li>
161
+
<li><ahref="../Techniques/client-side-script/SCR32" class="script">Providing client-side validation and adding error text via the DOMa>li>
0 commit comments