Understanding SC 3.3.2 Labels or Instructions
Success Criterion 3.3.2 Labels or Instructions (Level A): Labels or instructions are provided when content requires user input.
Labels or Instructions Transcript
Hello everyone. Today, we’re going to talk about labels and instructions. We will also discuss their importance, the benefits for various users, some examples, and how we can fix them.In order for users to enter data into form controls, it is necessary for those controls to have accompanying labels or instructions. These instructions include the expected data format or anything that is non-standard input. An example of the importance of labels and instructions can be seen in a signup form page, where each field is labeled with information such as “first name” and “last name.” In this case, the asterisk indicates that the field is required. It’s also important to note that labels and instructions are necessary for radio buttons and checkboxes as well. Additionally, when a group of radio buttons is related to a specific question or required input, a group-level label with a fieldset legend is a must.
But let’s try to understand who benefits from this. Well, this is important for several groups of users, including people with cognitive disabilities who require visible text labels and instructions in order to effectively fill out forms. Additionally, individuals with low vision who don’t use screen readers rely on visible labels. Even users without vision or any disabilities may still require instructions on the expected data format or any non-standard input data.
Now, let’s take a look at a good example that demonstrates effective labeling. A good example of effective labeling can be seen in an online insurance enrollment form, where all the fields are accompanied by visible labels such as “first name,” “middle name,” “email,” and so on. Also, required fields are denoted with an asterisk in the label. Another example is an e-commerce site with a product search result page that features checkboxes with the group-level label for each filter group, such as “brand” and “price.” This approach ensures that users can easily navigate and understand the available filtering options.
Here is an example of a labeling failure scenario: an online contact form requires users to enter their phone numbers in three separate fields—area code, exchange code, and number. Although the number field is marked with a label, each individual field is not labeled and is only denoted by a hyphen.
But how can these issues be resolved? Let’s take a look. One should use label tags to provide labels for all form controls. One should avoid using placeholders as a replacement for labels, as they disappear upon typing. One should use group-level labels for related groups of form controls and provide individual labels for each control. When asking for phone or credit card numbers, one should use “phone” or “credit card” as the group label and include a title attribute for each individual field.
In conclusion, labels or instructions ensure that web content is easily understandable by providing clear and concise language. By adhering to this guideline, web content can be made more accessible and inclusive for users, regardless of their cognitive abilities or language proficiency.
This is the end of the video. Thank you for joining. If you like the video, do like and subscribe.
The intention of this success criterion is to provide labels or instructions to form fields and controls which require user input. While the criterion asks for labels or instructions, it is important for the designers and content authors to decide which best suits the design and identify the form controls with their purpose.
Our best experience says, just like a medicine bottle that requires a label for its identification, every form field or control requires a visible and persistent label at all times. Secondly, the instructions can be context sensitive, can include specific data format like a character combination of a password field or date format for a date field. While giving instructions, content authors must ensure that information is not overwhelming and thus do not clutter the page or even the memory of the users.
Providing labels or instructions must not be confused with the following:
- Accessible names – They are not visible labels and they are dealt with separately in SC 4.1.2
- Descriptive labels – if the labels are not descriptive, they are dealt with in SC 2.4.6
Users who benefit
People who benefit out of clear, persistent, visible labels and/or instructions are:
I’d like to get some input please.
I’m designing a form that by default has
– a descriptive heading
– 3 input fields with hint text. Purpose of these input fields is the same
– aria labeling for fields
The number of fields can go up to 100. Every single input field would have the same label, labels were ommitted to avoid visual clutter.
I find the instructions confusing. It say that “Always provide visible labels to every form fields and controls”. Before that, in the description it suggests “content authors must ensure that information is not overwhelming and thus do not clutter the page or even the memory of the users”
I’d like to know in the instance described above do we need to add the same label for every input field?
Thanks very much in advance!
Every visible label and programmatic name must be unique to ensure that users can easily distinguish the purpose of each field. For example, using the same label name for first name and last name would create confusion for the user. It is important to follow SC 2.4.6 which requires descriptive labels.