The Web Content Accessibility Guidelines (WCAG) 2.1 includes success criteria for accessible names, which can be simply defined as the “names of user interface elements.” Accessible names play an important role in helping people use the internet, but misunderstandings about their role can lead to significant accessibility issues.
That’s partly because developers may not use the same terminology as WCAG, particularly when discussing names and labels. In the guidelines, name refers to "text by which software can identify a component within Web content to the user." That’s functionally distinct from the label, which identifies the component to the user.
To put that another way: Names and labels serve a similar purpose, but functionally, they’re distinct. Assistive technologies need consistently accurate names in order to work properly, particularly when interactive components (such as buttons or linked images) are the only way to navigate a website.
In most circumstances, a user interactive control’s name and label can be identical, but when the name of a component doesn’t match its label, the user might encounter some frustrating experiences.
Non-accessible names can create major accessibility issues for some users.
To illustrate the importance of accessible names, let’s consider a basic example. You’re browsing an auto dealership’s website and you see a linked image; the image has the word “Buy Now,” and clicking the image takes you to another page where you can purchase a car.
If you’re not using assistive tech — and the image loads correctly — you’ll understand that clicking the image will allow you to navigate the site. However, if you’re using a screen reader or you can’t perceive the image, you’ll need to understand its purpose.
Here’s one way that a developer could demonstrate the function of the image link with the alt attribute:
<img srce=”arrow.jpg" alt=”Buy Cars">
The screen reader would read “Buy Cars,” which isn’t the same wording as “Buy Now.” If someone’s helping you use the website, they might tell you to click “Buy Now,” but you don’t perceive a link that matches those words — you’re not sure what to do.
This can be especially frustrating for people who navigate with voice control tools. Those users may be able to visually perceive a website, but their tools aren’t capable of describing interactive controls without consistent names and labels. A typical user would expect the words “Buy Now" to take them to the next page, but to actually navigate, they’ll need to keep guessing the component’s name until they come up with “Buy Cars.”
Likewise, voice control tools may be able to read the text on a form entry, but if the label doesn’t match the name, the user would have trouble figuring out how to complete the form. This <label> element could create problems for our user:
<label for="subscribe">Sign our petition</label>
The label “subscribe" isn’t identical to the text “sign our petition,” so the user might not understand the purpose of the form control.
Most users won’t go through the trouble of guessing the correct name for a component; they’ll move on to a different website. Our fictional auto dealership has lost a potential customer — and to avoid shutting out their audience, they’ll need to resolve the accessibility issue.
For most sites, creating accurate accessible names is a straightforward process.
While the concept of accessible names might seem intimidating at first, most sites can address this issue easily. The first step is to review the names of interactive components by using developer tools or viewing the code of the page. You can also use a screen reader or an accessibility evaluation tool.
After identifying component labels and names, make sure they’re consistent. User interface components can be named via HTML or ARIA, but in either case, developers should follow this simple rule: The component label should match the component name. This ensures conformance with WCAG 2.5.3, “Label in Name.”
Remember, the label is always perceivable by the user. Since the name allows the user to interact with the component, the user will expect to be able to use the label text for the interaction. Refer to the example above; if a button has a perceivable label that reads “buy now,” a person using speech recognition technology will assume that they can say “buy now" to navigate to the next page. If they can’t do that, it’s a problem.
Most sites can resolve accessible name issues by simply reviewing interactive components individually. However, this can be a significant project on larger websites. While we can’t address all of the factors that affect accessible names in this blog, here are a few other important considerations to keep in mind.
Don’t confuse the <label> element with WCAG’s definition of “label.”
Here’s where many developers get confused — most assistive tools give priority to the HTML element “label" when determining accessible names. However, a component can get its accessible name from other attribute values, so a site may correctly use accessible names for a control without using the <label> element.
An accessible name can be defined in different ways.
A component’s accessible name is usually defined by a <label> element, but it can also be defined by <title>, <alt> or various <aria> attributes. Different types of software may assign different priorities to these name contenders — if all of those contenders match, however, users will have a consistent experience regardless of how they’re browsing your site. For more information about accessible name hierarchies, refer to the World Wide Web Consortium’s Accessible Name and Description Computation 1.1 recommendation.
ARIA labels typically override other attributes that give elements accessible names.
Improper ARIA usage can cause significant accessibility issues. A developer may take the time to accurately name elements in HTML, but if the ARIA label is different (or present, but empty), visitors who use assistive tech may be unable to navigate the site.
ARIA can be extraordinarily helpful when used properly. However, HTML is often easier to implement correctly, particularly when developers don’t have much experience with ARIA. Correct implementation is extremely important, so when in doubt, stick with the HTML <label> element.
As with other accessibility concepts, developers should prioritize accessible names throughout development — instead of trying to fix problems after they’ve affected users. Always think about accessibility when developing interactive elements, and wherever possible, test your site to make sure it offers a perceivable, usable, navigable, and robust experience for every visitor.
