Fixes to WCAG 2.1 Understanding 2.4.6 and 3.3.2

understanding/20/headings-and-labels.html

@@ -12,7 +12,6 @@ <h1>Understanding Headings and Labels</h1>
    <section id="intent">
       <h2>Intent of Headings and Labels</h2>
 
-
       <p>The intent of this Success Criterion is to help users understand what information
          is contained in Web pages and how that information is organized. When headings are
          clear and descriptive, users can find the information they seek more easily, and they
@@ -24,48 +23,49 @@ <h2>Intent of Headings and Labels</h2>
          may suffice if it provides an appropriate cue to finding and navigating content.
       </p>
 
-      <div class="note">
-
-         <p>This success criterion does not require headings or labels. This success criterion
-            requires that if headings or labels are provided, they be descriptive. Also note that,
-            if headings or labels are provided, they must meet 
-            <a href="info-and-relationships">1.3.1: Info and Relationships</a>.
-         </p>
-
-      </div>
-
+      <p>This Success Criterion does not require headings or labels. This Success Criterion
+         requires that if headings or labels are provided, they be descriptive. This Success Criterion also
+         does not require that content acting as a heading or label be correctly marked up or
+         identified - this aspect is covered separately by
+         <a href="info-and-relationships">1.3.1: Info and Relationships</a>. It is possible for content
+         to pass this Success Criterion (providing descriptive content that acts as headings or labels) while failing
+         Success Criterion 1.3.1 (if the headings or labels aren't correctly marked up/identified). Conversely,
+         it is also possible for content to pass Success Criterion 1.3.1 (with headings or labels correctly
+         marked up or identified), while failing this Success Criterion (if those headings or labels are not
+         sufficiently clear or descriptive).
+      </p>
+      <p>Further, in the case of labels, this Success Criterion does not take into consideration whether or not
+         alternative methods of providing an accessible name for form controls and inputs has been
+         used - this aspect is covered separately by <a href="name-role-value">4.1.2: Name, Role and Value</a>. It is possible
+         for controls and inputs to have an appropriate accessible name (e.g. using <code>aria-label="..."</code>)
+         and therefore pass Success Criterion 4.1.2, but to still fail this Success Criterion (if the label is not
+         sufficiently clear or descriptive).
+      </p>
+      <p>While this Success Criterion does not <em>require</em> the use of labels (only ensuring that if labels
+         are present, they must be sufficiently clear or descriptive), this aspect is covered separately by
+         <a href="labels-or-instructions">3.3.2: Labels or Instructions</a>.
+      </p>         
 
    </section>
    <section id="benefits">
       <h2>Benefits of Headings and Labels</h2>
 
-
       <ul>
 
          <li>Descriptive headings are especially helpful for users who have disabilities that make
             reading slow and for people with limited short-term memory. These people benefit when
             section titles make it possible to predict what each section contains.
          </li>
-
-         <li>People who have difficulty using their hands or who experience pain when doing so
-            will benefit from techniques that reduce the number of keystrokes required to reach
-            the content they need.
-         </li>
-
-         <li>
-
-            <p>This Success Criterion helps people who use screen readers by ensuring that labels
-               and headings are meaningful when read out of context, for example, in a Table of Contents,
-               or when jumping from heading to heading within a page.
-            </p>
-
-            <p>This Success Criterion may also help users with low vision who can see only a few
-               words at a time. 
-
-            </p>
-
-         </li>
-
+
+         <li>Form input controls with labels that clearly describe the content that is expected to be
+            entered helps users know how to successfully complete the form.</li>
+
+         <li>When headings and labels are also correctly marked up and identified in accordance with
+            <a href="info-and-relationships">1.3.1: Info and Relationships</a>, this Success Criterion
+            helps people who use screen readers by ensuring that labels and headings are meaningful when
+            read out of context, for example, in an automatically generated list of headings/table of contents,
+            or when jumping from heading to heading within a page.</li>
+
       </ul>
 
    </section>

understanding/20/labels-or-instructions.html

@@ -12,8 +12,7 @@ <h1>Understanding Labels or Instructions</h1>
    <section id="intent">
       <h2>Intent of Labels or Instructions</h2>
 
-
-      <p>The intent of this success criterion is to have content authors place instructions
+      <p>The intent of this Success Criterion is to have content authors present instructions
          or labels that identify the controls in a form so that users know what input data
          is expected. Instructions or labels may also specify data formats for fields especially
          if they are out of the customary formats or if there are specific rules for correct
@@ -24,47 +23,44 @@ <h2>Intent of Labels or Instructions</h2>
 
       <p>The intent of this Success Criterion is not to clutter the page with unnecessary information
          but to provide important cues and instructions that will benefit people with disabilities.
-         Too much information or instruction can be just as much of a hindrance as too little.
+         Too much information or instruction can be just as harmful as too little.
          The goal is to make certain that enough information is provided for the user to accomplish
          the task without undue confusion or navigation.
       </p>
-
-      <div class="note">
-
-         <p>When labels are provided for input objects, the input object's relationship to the
-            label (or to redundant text serving as the label) must be programmatically determinable
-            or available in text per 
-            <a href="info-and-relationships">1.3.1: Info and Relationships</a>.
-         </p>
 
-      </div>
-
-
+      <p>This Success Criterion does not require that labels or instructions be correctly marked up, 
+         identified, or associated with their respective controls - this aspect is covered separately by
+         <a href="info-and-relationships">1.3.1: Info and Relationships</a>. It is possible for content
+         to pass this Success Criterion (providing relevant labels and instructions) while failing
+         Success Criterion 1.3.1 (if the labels or instructions aren't correctly marked up, identified, or associated).
+      </p>
+      <p>Further, this Success Criterion does not take into consideration whether or not alternative methods of
+         providing an accessible name or description for form controls and inputs has been used - this aspect is
+         covered separately by <a href="name-role-value">4.1.2: Name, Role and Value</a>. It is possible
+         for controls and inputs to have an appropriate accessible name or description (e.g. using <code>aria-label="..."</code>)
+         and therefore pass Success Criterion 4.1.2, but to still fail this Success Criterion (if the labels or instructions
+         aren't presented to all users, not just those using assistive technologies).
+      </p>
+      <p>While this Success Criterion requires that controls and inputs have labels, whether or not
+         these labels are sufficiently clear or descriptive is covered separately by
+         <a href="labels-or-instructions">2.4.6: Headings and Labels</a>.
+      </p> 
+
    </section>
    <section id="benefits">
       <h2>Benefits of Labels or Instructions</h2>
 
 
       <ul>
 
-         <li>When label elements are associated with input elements the label is spoken by screen
-            readers when the field receives focus and users with impaired motor control are helped
-            by a larger clickable area for the control, since clicking on the label or the control
-            will activate the control.
-         </li>
-
-         <li>Field labels located in close proximity to the associated field assist users of screen
-            magnifiers because the field and label are more likely to visible within the magnified
-            area of the page.
+         <li>Providing clear and unambiguous labels and instructions (including examples of expected
+            data formats) helps all users - but particularly those with cognitive, language, and learning
+            disabilities - to enter information correctly.
          </li>
 
-         <li>Providing examples of expected data formats help users with cognitive, language and
-            learning disabilities to enter information correctly.
-         </li>
-
-         <li>Clearly identifying required fields prevents a keyboard only user from submitting
-            an incomplete form and having to navigate the redisplayed form to find the uncompleted
-            field and provide the missing information.
+         <li>Providing clear and unambiguous labels and instructions (including clear identification of required
+            fields) can prevent users from making incomplete or incorrect form submissions, which prevents
+            users from having to navigate once more through a page/form in order to fix submission errors.
          </li>
 
       </ul>
@@ -95,11 +91,16 @@ <h2>Examples of Labels or Instructions</h2>
             fields. While the punctuation provides visual clues to those familiar with the U.S.
             telephone number format, the punctuation is not sufficient to label the fields. The
             single "Phone number" label also cannot label all three fields. To address this, the
-            three fields are grouped in a fieldset with the legend "Phone number". Visual labels for the fields (beyond the punctuation) cannot be provided
+            three fields are grouped in a fieldset with the legend "Phone number". Visual labels for
+            the fields (beyond the punctuation) cannot be provided
             in the design, so invisible labels are provided with the "title" attribute to each
             of the three fields. The value of this attribute for the three fields are, respectively,
             "Area Code", "Exchange", and "Number". 
          </li>
+
+         <li>In a form which contains both required and optional fields, the required fields and/or the
+            optional fields are clearly labeled as such.
+         </li>
 
       </ul>