Understanding SC 3.3.2 Labels or Instructions (Level A)

In Brief

Goal

Users know what information to enter.

What to do

Provide labels or instructions for inputs.

Why it's important

Everyone, especially those with cognitive disabilities, will know how to respond.

Intent

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.

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.

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.

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.

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.

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.

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.

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 1.3.1 Info and Relationships. 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).

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 4.1.2 Name, Role, Value. It is possible for controls and inputs to have an appropriate accessible name or description (e.g., using aria-label="...") 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.

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.

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 2.4.6 Headings and Labels.

Benefits

• 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.
• 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.
• Providing labels can help users identify the expected accessible name of a control, so that it may be accessed more efficiently by voice commands.

Examples

• 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.
• A single form field for entering a date has text instructions to indicate the correct format for the date.
• 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.
• 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.
• 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".
• 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.
• 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".
• 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.

Techniques

Each numbered item in this section represents a technique or combination of techniques that the Accessibility Guidelines Working Group deems sufficient for meeting this success criterion. A technique may go beyond the minimum requirement of the criterion. There may be other ways of meeting the criterion not covered by these techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.