Exploring WCAG 2.1 — 2.5.3 Label in Name

Our series of new WCAG 2.1 Success Criteria continues with the next success criterion within the new 2.5 Input Modalities guideline: 2.5.3 Label in Name.

Guideline 2.5 Input Modalities

Make it easier for users to operate functionality through various inputs beyond keyboard.

Success Criterion 2.5.3 Label in Name (Level A)

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

Note:
A best practice is to have the text of the label at the start of the name.

Terminology

To understand this success criterion we need to review the difference between a label and a name. 

Label

The label identifies the control to all users. It is generally visible text. Examples of labels are the label element on a form control or the text of a link. The label is often used as the name as shown in the example search field below.

HTML code for search field:

<label for="itemSearch">Search: </label>
<input type="text" id="itemSearch">

The label is, “Search.”

Name

The name is what assistive technology uses to identify the control to the user. This means it can be programmatically determined and why it is often referred to as the accessible name. The accessible name is not related to the name attribute on input elements. 

A control may have both an accessible name and a label. The name may be the same as the label as in the search field example above.  Or, the name may not be detectable on the page unless you are using an assistive technology. Examples include the alt-text and the aria-label, and aria-labelledby attributes. The image below of the red coffee mug has the alt text of, “red coffee mug with large black polka dots.” The alt text is the accessible name that screen readers will speak. 

Who Benefits?

People who use speech input benefit from this success criterion. A user must speak the accessible name of the component for the speech input software to know which one to activate. If the accessible name does not match or start with the visible name, a user does not know the correct name to speak.

A proper behavior benefits people who can see, especially when they also are screen reader users. A screen reader speaks the accessible name. It confuses users when the visible label is not the same as the name, and they do not hear what they see on the screen.

Example

The simple example below lists several kitchen products for sale. The button next to each product has the label, “Buy.” A speech input user would say “Buy,” but the speech software doesn’t know what item to add.  The underlying code has an aria-label (which is the accessible name) of “Buy <item name> for <amount>.” The speech software expects to hear that text, but the sighted speech input user cannot see that name. 

Kitchen Tools – Poor Example

Kitchen Tools – Better Example

To solve this issue, make the label and the accessible name the same. If that is not possible, have the visible label text at the beginning of the accessible name. 

In this example, the accessible name that a screen reader user hears is “Buy <item name> for <amount>.” The speech input user sees and speaks, “Buy <item name>,” and the software can activate the correct button.

Take Aways

Make labels visible, unique, and descriptive when possible. In this case, the label is the accessible name.  If you need more details in the accessible name, make it start with the same text as the visual label and make sure each label is unique.