Add section on native browser form validation to 3.3.1 understanding

understanding/20/error-identification.html

@@ -21,7 +21,7 @@ <h2>In brief</h2>
    <section id="intent">
       <h2>Intent of Error Identification</h2>
 
-      <p>The intent of this success criterion is to ensure that users are aware that an error
+      <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. 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.
@@ -51,8 +51,8 @@ <h2>Intent of Error Identification</h2>
       <div class="note">
          <p>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
+            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 <a href="error-suggestion">3.3.3 Error Suggestion</a>.
          </p>
       </div>
@@ -61,7 +61,7 @@ <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.
-         This type of programmatic information is not required for this success criterion, but may be covered
+         This type of programmatic information is not required for this Success Criterion, but may be covered
          by other criteria such as <a href="name-role-value">4.1.2 Name, Role, Value</a>.</p>
 
       <p>It is perfectly acceptable to indicate the error in other ways such as through the use of an image,
@@ -78,6 +78,26 @@ <h2>Intent of Error Identification</h2>
 
       <p>See also <a href="error-suggestion">3.3.3: Error Suggestion</a>.</p>
 
+      <h3>User agent native HTML form validation</h3>
+
+      <p>When using native HTML <a href="https://html.spec.whatwg.org/multipage/forms.html#client-side-form-validation">client-side form validation</a>,
+         user agents will automatically prevent the submission of incomplete or invalid forms, and display generic error messages to the user.
+         The user agent will generally set focus back to the first form field that is in error, and as a result scroll the page
+         so that the field in error and the generated error message will be visible in the viewport.</p> 
+      <p>In most common user agent and screen reader combinations, the screen reader will announce the error message
+         and the programmatic name of the focused field. 
+         While this meets the requirements of this Success Criterion, it should be noted that there are several disadvantages related to this approach:</p>
+      <ul>
+         <li>Depending on the user agent, the message may not be permanent, or fail to scroll with the page.</li>
+         <li>Depending on the user agent, even if a user has zoomed-in (magnified) the content, the error messages will not appear magnified,
+            as the text in the validation message will be displayed at the same size as the user agent interface; the message may be too small for users to read.</li>
+         <li>The default HTML validation error messages are generally quite generic, and they may not provide sufficiently helpful or specific suggestions to the user
+            that would conform to <a href="error-suggestion">3.3.3 Error Suggestion</a>.
+         </li>
+         <li>If several errors are present, only the first error message is exposed; once the user has provided an input that conforms to the type of field,
+            and resubmits the form, the next error (if present) will be exposed. This means that repeated resubmissions and corrections may be required.</li>
+      </ul>
+
    </section>
    <section id="benefits">
       <h2>Benefits of Error Identification</h2>
@@ -87,7 +107,7 @@ <h2>Benefits of Error Identification</h2>
             Providing information about input errors in text allows users who are blind, have low vision, or have color vision deficiency to perceive the fact that an error occurred.
          </li>
          <li>
-            This success criterion may help people with cognitive, language, and learning disabilities
+            This Success Criterion may help people with cognitive, language, and learning disabilities
             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>
@@ -108,7 +128,7 @@ <h2>Examples of Error Identification</h2>
                the user which field or fields were missing or incorrect.</p>
 
             <div class="note">
-               <p>This success criterion does not mean that color or text styles cannot be used to indicate
+               <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.
                </p>
             </div>