Intro to accessible names

This post marks the second installment of my five part series diving into more developer-focused WCAG success criteria and explaining them for my designer friends.

Background

What's in a(n accessible) name? - William Shakespeare

A name, often referred to as an accessible name, is a short description, typically one to three words, that is used to provide people who use assistive technology with the purpose of a UI element and differentiate it from others on the page. At the very least, all interactive UI elements to have an accessible name, though some non-interactive elements (like headers and tables) can also have them.

How accessible names are determined

I discussed this briefly in my Differentiating ARIA Properties post, but there are several different HTML elements and attributes that can make up an accessible name. Because developers can combine these elements/attributes in a number of various ways, web browsers use a complex algorithm for determining an element's accessible name.

Related WCAG success criteria

Providing accessible names is a critical task in order to ensure a web experience is accessible and that is reflected by how many success criteria reference names in their requirements:

• 1.1.1 Non-text content (Level A)
• 1.3.5 Identify input purpose (Level AA)
• 1.3.6 Identify purpose (Level AAA)
• 2.4.4 Link purpose (in context) (Level A)
• 2.4.6 Headings and labels (Level AA)
• 2.4.9 Link purpose (link only) (Level AAA)
• 2.5.3 Label in name (Level A)
• 3.2.4 Consistent identification (Level AA)
• 3.3.2 Labels or instructions (Level A)
• 4.1.2 Name, role, value (Level A)

Designing for accessible names

While the HTML elements and attributes are ultimately a developer's responsibility for writing and establishing an accessible name, here are some basic recommendations for designers to prevent errors from occurring with accessible names.

Recommendation #1: Use visible labels

First and foremost, you should be using visible text labels within your designs as it makes the interface easier to understand for all users. If your design does not have one, consider adjusting the design to include one. Additionally it simplifies developer maintenance, prevents bugs, and reduces language translation requirements.

Recommendation #2: Provide accessible names

We've all left something up to the developer's interpretation before and been unpleasantly surprised with the results, right? In the instance where you cannot use a visible label, you should provide the element's accessible name to your developers. Make sure you find a balance between conciseness and clarity, otherwise they won't be accessible.

Some recommendations for crafting these names include:

• Convey function/purpose
• Prioritize important words first - usually a verb
• Be concise - no more than three words
• Create unique names for elements with the same role, unless they are actually identical
• Start names with a capital letter - it helps some screen readers speak with appropriate inflection
• Do not end names with a period - they are not sentences
• Do not include a ARIA role name in the accessible name - this results in the screen reader announcing duplicative info

Recommendation #3: Test your solution once built

Some naming techniques may have inconsistent results across browsers, making it important for you to verify they work properly in each browser

1. Using a screen reader only, navigate to the first interactive UI component on the webpage
2. Confirm that the screen reader says the correct purpose of the UI component
3. Repeat for each interactive UI component
4. Once complete, repeat process on another browser