HOME / ROLES / DEVELOPERS / STRUCTURE - DEVELOPERS /

Provide accessible labels and instructions

Forms allow users to enter data by typing or selecting from a set of options. When forms are not designed with accessibility in mind, people with disabilities are likely to have difficulty or even find it impossible to enter data without errors. So forms need to be designed so that the purpose of each control is clear.

  • Provide an accessible label for every control. Preferably, give each control a visible text label that explains its purpose. This is best done with an HTML label element that’s programmatically associated with the control.
    • For a text input field, its accessible label would be a short description of the data the field collects.
    • For a control that is a group of options, such as a drop-down menu or list of radio buttons or checkboxes, the group should have a label that describes the relationship of the options. Each label should have a short description that indicates the value associated with each option.
  • Make sure the label remains visible when the control has focus. Wherever possible, avoid relying on placeholder text to label an input field. There are several usability issues relating to placeholder text because it disappears when the user starts to type into the field. So it's much better to have an external label that remains visible at all times. If space is limited, such as when designing responsively for small screens, media queries could be used to change how label text is displayed.
  • Provide additional input instructions when they are needed. Some controls may collect data that has constraints (such as upper or lower limits) or restricted formats. Preferably, use controls that only allow selections within those constraints. If this is not possible, provide additional text that describes the constraints in plain language.
  • Provide additional information (metadata) to help people better understand and recognize the intention of input forms. People who have difficulty completing forms requesting personal data -- for example, those with cognitive or mobility impairments -- will benefit, because it will save time and eliminate typing or spelling errors. Most browsers today recognize well-labeled input fields corresponding to name and address. If the user allows the browser to autofill and store personal information in the settings, the browser will suggest values to complete the fields. This makes entering data faster and more accurate by eliminating typing errors.

Testing

For each form control:

  • If the control is a text input field, is there a visible text label that describes what should be entered into the field?
  • If the control is a group of selectable options, such as a dropdown menu or list of radio buttons or checkboxes, are both of these true?
    • There is a visible, meaningful label describing the collection of options.
    • Each option has a visible, meaningful label that conveys the value of the options.
  • If there is no visible label for a control, are both of these true?
    • There are sufficient visual clues to explain the function of the control.
    • There is label text that is programmatically associated with the control, and the label is read aloud by a screen reader when it encounters the control.
  • If users need additional information to interact with the control, is that information provided accessibly?
  • Has the autocomplete attribute been leveraged to allow additional information to be offered to users to assist them in understanding and recognizing the intention of input fields? 

Resources

See also: Forms

✎ Technique: Identify input purpose

Make it easier for people to complete input fields requesting personal information. People with mobility issues have difficulty entering data into the fields. People with cognitive disabilities may have difficulty remembering details. It may be hard for them to enter personal information due to memory loss, dyslexia, or other impairments.

Developers should use autocomplete on fields that collect personal data to explicitly identify the data type. Use the list of  Input Purposes for User Interface Components to select the correct value. Turn off autocomplete for sensitive information.

(Source: Knowbility article on input purpose)

Examples

 

✗ Bad example: the browser does not offer to complete the form

When mouse is used to select fields without autocomplete, the browser does not offer to complete the form.

Screen capture of an input form that is not auto filled

(Source: Knowbility article on input purpose)

✓ Good example: the browser offers to complete the form

Since the autocomplete attribute has been added on the fields, the browser offers to enter the data.

Screen capture of an input form that is auto filled

(Source: Knowbility article on input purpose)

 

See also: Provide accessible labels and instructions ✎, Cognitive, Keyboard ✎, Perceivable, Inputs, CSS, Forms

✎ Technique: Required fields

A clear indication that specific form fields are required can save users time and avoid potential errors relating to missing data when a form is submitted.

This indication should be visually distinct without relying on color, and it should also be programmatically available to screen-reader users.

Examples

✗ Bad example

In this example, the asterisk is placed next to the text input. It has no connection to the input, so it will not be read aloud when the input is focused, and the screen-reader user would have no idea that it was required. If it were read, it would be read as “asterisk,” even though it should be read as “required.” 


<label for="email">Your email</label>
<input type="text" id="email" /> <span>*</span>

✗ Bad example

In this example, the asterisk is inside the label, so it is announced. However, “asterisk” or “star” does not clearly convey that the field is required. 


<label for="email">Your email *</label>
<input type="text" id="email" />

✓ Good example

In this example, the aria-required attribute is placed on the form field itself, meaning that “required” will be read when the control has focus. In addition, the redundant “star” is hidden from screen readers by placing it inside a <span> with aria-hidden="true". Content in a DOM tree with an aria-hidden="true" attribute is ignored by screen readers. 


<label for="email">Your email <span aria-hidden="true">*</span></label>
<input type="text" id="email" aria-required="true" />

This information is now available to screen readers whenever the field is focused. For example, VoiceOver (macOS) will read, “Your email, required, edit text.”

See also: Provide name, role, and value information ✎, Avoid reliance on color ✎, Provide accessible labels and instructions ✎, Blind, Low vision, Color blind, Dyslexia, Screen reader, High contrast mode, Custom stylesheet, Perceivable, Understandable, Inputs, CSS, Forms, HTML

✎ Technique: Input labels

Descriptive labels help users understand the purpose of a form control. Labels should be associated with their controls so that when the input is focused, the label is announced by screen readers.

Examples

✓ An explicit label

The HTML label element can be used to provide a label or "accessible name" for an interactive form element. However, it does not work on its own: You have to code a relationship between the label and the input. An "explicit" label is achieved by using the for attribute to associate the label with the input's id, like so: 


<label for="firstname">Your first name</label>
<input id="firstname" type="text" />

Now, when the screen-reader user focuses the input, it will announce the label's text content, "your first name" (as well as information about the input’s type and state). Note that the value of the label’s for attribute must match the id of the form field that it refers to.

✓ An implicit label

Another option, which might better suit your style of markup, is to use "implicit" labeling. The same result is achieved without an explicit for relationship explicitly but instead by placing the form field inside its label element: 


<label>Your first name 
  <input id="firstname" type="text" />
</label>

Note that in both cases, clicking the label will result in the input element being focused, ready to receive input.

✗ Bad example

HTML5 provides the placeholder attribute for showing hints about what to enter into the field. In this case, a suitable placeholder might be "Example: John". It is not appropriate to use the placeholder as the input's sole label because:

  • It is not as robust or as well supported in screen readers
  • The placeholder disappears on focus, potentially confusing sighted keyboard users
  • The default display color of the placeholder text may have insufficient contrast against the form field’s background color. 

<!-- Don't do this without also giving the field a label: -->
<input id="firstname" type="text" placeholder="your first name" />
See also: Provide name, role, and value information ✎, Provide accessible labels and instructions ✎, Blind, Screen reader, Robust, Understandable, Inputs, Forms, HTML