Labeling Controls

Provide labels to identify all form controls, including text fields, checkboxes, radio buttons, and drop-down menus. In most cases this is done by using the <label> element.

Labels need to describe the purpose of the form control. This section of the tutorial describes how to provide labels that are properly associated with form controls. Later sections explain how to provide instructions, validate user input, and provide feedback to help users complete your form.

A label and a form control need to be associated with each other either implicitly or explicitly. Web browsers provide the label as a larger clickable area, for example, to select or activate the control. It also ensures that assistive technology is able to refer to the correct label when presenting a form control.

Associating labels explicitly

Whenever possible, use the label element to explicitly associate text with form elements. The for attribute of the label must exactly match the id of the form control.


Code snippet: HTML
<label for="firstname">First name:</label>
<input type="text" name="firstname" id="firstname"><br>

<input type="checkbox" name="subscribe" id="subscribe">
<label for="subscribe">Subscribe to newsletter</label>

Hiding label text

A label for a form control helps everyone better understand its purpose. In some cases the purpose may be clear enough from the context when the content is rendered visually. In such cases a label can be hidden visually, though it still needs to be provided within the code to support other forms of presentation and interaction, such as for screen reader and speech input users. The method used in this tutorial to hide an element visually but make it available for assistive technologies is explained in Note on hiding element.

In the example below, the search field is positioned directly beside the search button. The purpose of the text input field is evident from the context in most situations.


Hiding the label element

In this approach, the <label> element is provided to identify a form control within the code, but it is visually hidden to avoid redundancy for users who can derive the purpose from the visual cues.

Code snippet:
<label for="search" class="visuallyhidden">Search: </label>
<input type="text" name="search" id="search">
<button type="submit">Search</button>

Using aria-label

The aria-label attribute can also be used to identify form controls. This approach is generally well supported by screen readers and other assistive technology, but, unlike the title attribute (see next section), the information is not conveyed to visual users.

Code snippet:
<input type="text" name="search" aria-label="Search">
<button type="submit">Search</button>

Using the title attribute

The title attribute can also be used to identify form controls. This approach is generally less reliable and not recommended because some screen readers and assistive technologies do not interpret the title attribute as a replacement for the label element, possibly because the title attribute is often used to provide non-essential information. The information of the title attribute is shown to visual users as a tool tip when hovering over the form field with the mouse.

Code snippet:
<input title="Search" type="text" name="search">
<button type="submit">Search</button>

Note on hiding elements

Screen readers and other assistive technology, just as web browsers, hide elements from their users when they are styled using display: none; and visibility: hidden;.

The common approach used to hide information visually but keep them available to screen reader and other assistive technology users, is to use CSS that will keep the information technically visible but practically hidden. For example, presenting the label in a 1-by-1 pixel area with a 1-pixel margin, as demonstrated with the CSS class visuallyhidden (do not confuse with CSS visibility: hidden) below:

Code snippet:
.visuallyhidden {
  border: 0;
  clip: rect(0 0 0 0);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;

Associating labels implicitly

In some situations, form controls cannot be labelled explicitly. For example, a content author might not know the id of a form field generated by a script, or that script might not add an id at all. In this case the label element is used as a container for both the form control and the label text, so that the two are associated implicitly.

Code snippet: HTML
  First name:
  <input type="text" name="firstname">
  <input type="checkbox" name="subscribe">
  Subscribe to newsletter

Labelling buttons

The label of a <button> element is set inside the element and can include markup. This allows more advanced accessibility hints to be included, like marking up language change. When using the <input> element to create buttons, the label is set in the value attribute of the element.

Code snippet: HTML
<button type="submit">Submit</button>
<button type="button">Cancel</button>

<input type="submit" value="Submit">
<input type="button" value="Cancel">

Note: If the image button (<input type="image">) is used, the label is set in the alt attribute, for example: <input type="image" src="searchbutton.png" alt="Search">. See Functional Images for more information on how to describe images in buttons.

Visual position of label text

In left-to-right languages it is customary to visually position labels to the right of radio buttons and checkboxes, and to the left or directly above other form fields. Maintaining this practice increases predictability and understandability of your form for all users.

In general, placing labels above the form fields helps reduce horizontal scrolling for people with low vision and for mobile device users. However, the usefulness of this approach depends on other design aspects, such as the proximity of other nearby form fields and content, and needs to be assessed individually. The aim should be to maintain a close and distinct visual relationship between the label and the form control.

The following WCAG 2.0 resources are directly related to this page. Relationship to WCAG 2.0 provides more background information.

Success Criteria:

  • 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)

  • 2.4.6 Headings and Labels: Headings and labels describe topic or purpose. (Level AA)

  • 3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A)

  • 4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)