wcag/understanding/20/labels-or-instructions.html at b4e874b8cf7393cb4a73069e3193d4765cce0640 · w3c/wcag · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
<!DOCTYPE html>
<html lang="en">
<head>
   <meta charset="UTF-8">
   <title>Understanding Labels or Instructions</title>
   <link rel="stylesheet" type="text/css" href="../../css/sources.css" class="remove">
</head>
<body>
   <h1>Understanding Labels or Instructions</h1>

   <section id="brief">
		<h2>In brief</h2>
		<dl>
         <dt>Goal</dt><dd>Users know what information to enter.</dd>
         <dt>What to do</dt><dd>Provide labels or instructions for inputs.</dd>
         <dt>Why it's important</dt><dd>Everyone, especially those with cognitive disabilities, will know how to respond.</dd>
      </dl>

   </section>

   <section id="intent">
      <h2>Intent of Labels or Instructions</h2>

      <p>The intent of this success criterion is to have content authors present instructions
         or labels to identify the purpose of fields and controls that expect user input, so that
         users will know what sort of values to enter, or adjust. Commonly, labels or instructions
         will be necessary to help users understand how to fill out the input fields of a form.
      </p>
      <p>
         Despite their moniker, form fields and controls are not limited to use within a form. They
         are often used in web pages to allow a user to create or manipulate content. Labels,
         instructions, or both will commonly be needed for these controls to help ensure users
         understand their purpose and the expected values they will need to enter or adjust to
         use the controls efficiently while mitigating errors.
      </p>
      <p>
         In the case of radio buttons, checkboxes, comboboxes, or similar controls that provide
         users with choices, each choice will need a label so that users know what they are actually
         selecting. In some cases, these labels may be enough to indicate the purpose of the parent
         control (such as a select-only combobox), or grouping of controls (like groupings of radios
         or checkboxes), and thus further visible labels may not be necessary. However, in cases
         where the labels for the choices would be ambiguous without an overarching label or instructions
         for a control or group of controls, then authors would need to provide one or both for users.
      </p>

      <p>
         Beyond identifying the purpose of a field or control, instructions or labels may specify the
         necessary format(s) for data entry, especially if they are out of the customary formats
         or if there are specific rules for correct input. Content authors may also choose to make such
         instructions available to users only when the individual control has focus, or they may provide a
         means to display or link to the instructions, especially for when they are long and verbose.
      </p>

      <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 harmful as too little. Rather, the goal is to
         ensure enough information is provided for the user to accomplish the task without undue confusion
         or navigation.
      </p>

      <p>When form fields or controls would necessitate labels, instructions or both, they will need to be
         persistently available to users. In many cases, the best way to do this is to make them visually
         persistent as part of the UI. However, there can be times where labels or instructions would be
         better suited to the interface if they were made available on demand or only as necessary. For instance,
         within the context of a toolbar, a select-only combobox's label may only be available on hover or focus
         of the control. Or, a form field with verbose instructions may provide those instructions by using a
         button to invoke them as necessary.
      </p>

      <p>Note that the majority of form control labels are text-based.
         Using images as labels meets the requirements of the criterion, but care should be taken to ensure that the
         images are widely understood by the intended target audience. Authors may consider providing additional hints,
         such as text-based tooltips or supplementary text, to support clarity when using image-based labels.</p>

      <p>This success criterion does not require that labels or instructions be correctly marked up,
         identified, or associated with their respective controls — that 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 — that aspect is
         covered separately by <a href="name-role-value">4.1.2 Name, Role, 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 Name, Role, Value, but to still fail this success criterion
         (if the labels or instructions ren't presented to all users, not just those using assistive technologies).
         Additionally, it can be possible to pass this success criterion by providing a visible label, but fail Success Criterion
         2.5.3 Label in Name, if the visible text label is not included in the accessible name of the control.
      </p>
      <p>This success criterion does not apply to links or other controls (such as an expand/collapse widget, or similar
         interactive components) that are not associated with data entry.
      </p>
      <p>While this success criterion requires that form fields and controls have labels or instructions, whether or
         not labels (if used) are accurate, sufficiently clear, or descriptive is covered separately by
         <a href="headings-and-labels">2.4.6 Headings and Labels</a>.
      </p>
      <p class="note">The use of "requires" in this criterion's normative wording does not mean that the criterion only applies
         to <em>required</em> form fields. It is used here as a synonym for "accepts", "expects", or "allows". The criterion
         applies to all form fields, whether they're required or optional.
      </p>

   </section>
   <section id="benefits">
      <h2>Benefits of Labels or Instructions</h2>


      <ul>

         <li>Providing 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 labels and instructions (including 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>

         <li>Providing labels can help users identify the expected accessible name of a control, so that it may be accessed
            more efficiently by voice commands.
         </li>

      </ul>

   </section>

   <section id="examples">
      <h2>Examples of Labels or Instructions</h2>

      <ul>

         <li>A form field which asks the user to enter the two character abbreviation for a US state
            has a link next to it which will open another window with an alphabetized list of state names
            and the correct abbreviation.
         </li>

         <li>A single form field for entering a date has text instructions to indicate the correct format
            for the date.
         </li>

        <li>On one website, a field with the text label of "username" is provided for someone to create a username to login to a website.
          On another website, there are strict rules about what characters can be used to create a username. On this website additional instructions
          would need to accompany the field to prevent users from encountering unnecessary errors.
        </li>

        <li>A website provides a global search field in the header of the site. Any term can be entered,
          so there are no instructions needed, but the field needs a cue to communicate its purpose. Commonly, such search
          field will be paired with a "loupe" or "magnify glass" search icon, serving as its visible label, if not also doubling
          as the visual identifier for the button that submits the search query.
        </li>

         <li>To enter their name, users are provided with two separate text fields. Rather than
            having a single label "Name" (which would appear to leave the second text field unlabelled),
            each field is given an explicit label — "Given Name" and "Family Name".
         </li>

         <li>
            A rich text editor presents two select-only comboboxes to allow a user to choose the font family and
            font size of the text they are editing. Each of the combobox options are accurately labeled. The
            comboboxes are given accessible names ("font family" and "font size", respectively).
            The context of being part of the rich text editor's toolbar, as well as the clear option labels
            allow a user to determine the purpose of the controls, without the need for persistently visible
            combobox labels.
         </li>

         <li>A U.S. phone number separates the area code, exchange, and number into three fields.
            Parentheses surround the area code field, and a dash separates the exchange and number
            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
            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>A website presents a form as a series of individual pages (a wizard) rather than on one large page.
          All pages in the wizard are introduced by a heading. A few pages contain only a single form field. For these pages
          the form field is not given its own distinct label, as the heading is enough to indicate the purpose and
          expected value the user is to enter.  E.g., a page with the heading of "Email address" is sufficient in indicating
          the purpose of the single form field present on the page.
        </li>

      </ul>

   </section>

   <section id="resources">
      <h2>Resources for Labels or Instructions</h2>


   </section>

   {% # Data for associated techniques is defined in understanding/understanding.11tydata.js %}
   {% include "understanding/techniques.html" %}
</body>
</html>