Rewrite for 3.13.1 Error Identification understanding document

* 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/learinng 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")

understanding/20/error-identification.html

@@ -14,13 +14,14 @@ <h2>Intent of Error Identification</h2>
 
 
       <p>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.
+      </p>
+      <p>Per the definition in WCAG 2.0, an "input error" is information provided by the user
          that is not accepted. This includes: 
       </p>
 
@@ -72,14 +73,22 @@ <h2>Intent of Error Identification</h2>
          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.
-
       </p>
 
       <p>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.
+      </p>
+      <p>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. 
       </p>
 
       <p>See also 
@@ -94,16 +103,14 @@ <h2>Benefits of Error Identification</h2>
 
       <ul>
 
-         <li> Providing information about input errors in text allows users who are blind or colorblind
-            to perceive the fact that an error occurred.  
+         <li>Providing information about input errors in text allows all users to perceive the fact
+            that an error occurred.
          </li>
 
          <li>
             This Success Criterion may help people with cognitive, language, and learning disabilities
-            who have difficulty understanding the meaning represented by icons and other visual
-            cues. 
-
-
+            who have difficulty understanding the specific reason why a form submission failed (in cases
+            where this is not already made obvious by the nature of the form).
          </li>
 
       </ul>
@@ -137,8 +144,7 @@ <h2>Examples of Error Identification</h2>
             <div class="note">
 
                <p>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.
                </p>
 
             </div>