You are here: Home » Uncategorized, Web/Media/App Access » Decoding label and name for accessibility

Decoding label and name for accessibility

Handouts

Presented at 2:15pm in Governors Square 14 on Wednesday, November 17, 2021.

#34529

Speaker(s)

  • Jonathan Whiting, Director of Training, WebAIM

Session Details

  • Length of Session: 2-hr
  • Format: Lab
  • Expertise Level: Beginner
  • Type of session: General Conference

Summary

WCAG requires that interactive elements have a “label” and “name” (often called “accessible name”), but the way these terms are used in WCAG does not always match how they are used by Web Developers. This hands-on lab will learn how WCAG defines label and name, and practice how to identify the WCAG label and name in common components like images, links, buttons, and form fields. We will also discuss the new WCAG 2.1 requirement for “Label in Name” and the danger of using ARIA labels.

Abstract

The Web Content Accessibility Guidelines (WCAG) 2.0 require that interactive elements have a "label" and "name" (often called "accessible name"), but the way these terms are used in WCAG does not always match how they are used by Web Developers. WCAG defines an element’s label as: "text or other component with a text alternative that is presented to a user to identify a component within Web content." It defines name as: "text or other component with a text alternative that is presented to a user to identify a component within Web content". These definitions are almost identical, but there Is one important difference: "label" is presented to the user and "name" is presented to software or assistive technology, typically screen readers.

For most elements, the WCAG name and label should be the same. This includes the text in a link or button and the visible

During this lab, we will look at 3 common scenarios where identifying the accessible name is not always straightforward.

1. For images, you must check the alternative text to discover the accessible name. 2. If an element has multiple bits of information competing for the accessible name, you must determine what rises to the top. This is especially common for form controls. 3. If an element uses ARIA labels (aria-label or aria-labelledby), this will override any other contender for accessible name, sometimes with disastrous results.

WCAG 2.1 builds on these requirements for an accessible name and label with Success Criterion 2.5.3 - Label in Name. Label in Name requires that the accessible name for an interactive element contain the text label. For example, an image with visible text of "Next" and alternative text of "Continue" would fail this requirement. However an image with alternative text of "Next Page" would meet this requirement because the visible text "label" is contained within the accessible name. During this lab, we will review how this requirement benefits many users.

Keypoints

  1. For images, you must check the alternative text to discover the accessible name.
  2. If an element has multiple bits of information competing for the accessible name, you must determine what r
  3. If an element uses ARIA labels (aria-label or aria-labelledby), this will override any other contender for

Disability Areas

Mobility, Vision

Topic Areas

Uncategorized, Web/Media/App Access

Speaker Bio(s)

Jonathan Whiting

Jonathan is the director of training at WebAIM. His main passion is helping others learn to make the web more accessible to people with disabilities. With a master's degree in Instructional Technology and 20 years of experience in the field of web accessibility, Jonathan has published dozens of articles, tutorials, and other instructional resources. He has traveled extensively to train thousands of web developers and other professionals who develop or maintain web content.

Handout(s)