by Glen Walker,
'Tis but thy name that is my enemy. Thou art thyself, though not a Montague. What’s Montague? It is nor hand, nor foot, Nor arm, nor face, nor any other part Belonging to a man. O, be some other name! What’s in a name? That which we call a rose By any other word would smell as sweet.
You might recognize those words. It's often paraphrased as "A rose by any other name would smell as sweet". The quote comes from Shakespeare's Romeo and Juliet, and in this particular verse, Juliet is speaking to Romeo and referring to the family feud between the Capulets (Juliet's family) and the Montagues (Romeo's family). She is explaining to Romeo her thoughts about the meaning of a name. What does it mean to be called a Capulet or a Montague? Or perhaps, modernly, what does it mean to be called a Jones or a Smith or a Williams? Regardless of your last name, you are who you are. If a rose bush were named by the famous children's author, Dr Seuss, it might be a "Zizzer-Zazzer-Zuzz" (which, of course, would be ridiculous because that's already the name of a mystical patch-work creature). The Zizzer-Zazzer-Zuzz bush would still smell beautiful even if it weren't called a rose bush.
Can we apply that same logic when naming objects on our webpage? Why does it matter if we call a button "Search" or "Find" or "Seek" or "Forage"? Or if you want to use the button for several actions, call it "Go". Type in your search term and "Go". Select your shopping cart and "Go". Type your email and "Go".
When designing and developing websites, leave Juliet's thoughts aside because an object by any other name might not be accessible.
For assistive technology, such as screen readers, magnifiers, speech recognition, braille devices, etc, the name of an object, or more specifically, the "accessible name" of an object, is extremely important.
What is an accessible name?
Officially, an accessible name is "the name of a user interface element…The value of the accessible name may be derived from a visible (e.g., the visible text on a button) or invisible (e.g., the text alternative that describes an icon) property of the user interface element." The complete rules for determining the accessible name can feel overwhelming at first, but in most cases the name is fairly easy to determine.
Who uses the accessible name?
You do, but you might not know it. If a website has a print button and the alternative text is 'print' or the tooltip is 'print', you are using the accessible name.
If you're a screen reader user, the accessible name becomes even more critical. Without it, the button just becomes "button" or "unlabeled 15 button". Do you dare select it? What's going to happen if you select "unlabeled 15 button"? You might try listening to the text that preceeds or follows the button to get a clue as to its context, but it might be surrounded by other unlabeled buttons. If you hear "print button", you know exactly what's going to happen when it's selected.
If you're a speech interface user, the accessible name allows you to address the button by name as if you're having a polite conversation with it. It's as if the button has a "Hello, my name is…" sticker on it.
You can say, "Click print button".
How is the accessible name generated?
Because the accessible name is so important for assistive technology, it's important for you to understand how the accessible name is generated.
In simple cases, the accessible name is what's displayed on the screen. A button displaying the text 'Print' has an accessible name of 'Print'.
Beyond that, the complexity starts building because there are many factors that contribute to the accessible name beyond the visible text, such as alt, title, aria-label, aria-labelledby, nested elements and their respective accessible names, etc. The role of an object also factors in.
The bulk of the work is described in step 2 of W3C's "4.3 Text Alternative Computation" which is essentially a large if/then/else statement with eight conditions.
A few notes about reading the W3C spec:
- Both the accessible name and the accessible description are described in the W3C spec because the process is the same, other than a minor difference in step 2B (aria-labelledby for names and aria-describedby for descriptions).
- In order for the spec to not continuously say "accessible name or accessible description" (since the process is describing both), it uses a common term, "text alternative". Don't confuse "text alternative" with the alt text attribute. They're different things.
- In 2.B, the bullets i, ii, iii apply to *both* the accessible name and accessible description, not just to the accessible description. They're indented under the second bullet (accessible description) so it appears they only apply to the accessible description.
Here's a simplified summary of step 2 (using the same letters, A-G, as the W3C spec). The first step that has a value is returned and then the process is over. This is a precedence list.
- If the element is hidden and not used in another element's
aria-labelledby, return a blank.
- Else, if the element has an
aria-labelledbyproperty, recurse over the IDs in the
aria-labelledbyproperty and concatenate and return the accessible name of all the elements in the
- Else, return the
- Else, return the
altattribute or associated
- Else, if the element is a widget whose value can be changed by the user (such as a text field, menu item, combobox, or range object [spin button, progress bar, slider]), and the element is embedded in the label of another widget, return the value of the widget
- Else, if the element's role allows the accessible name to come from the text value of the element (*) or if the element is the destination of an
aria-labelledby(from another element), recurse through any nested elements. Include list item indicators (bullet, number, letter) and CSS pseudo elements
- Else, return the text that's displayed (eg, "hello" for
<h3>hello</h3>or "there" for
- Else, return the
(*) Roles that allow the accessible name to come from the text value of the element are listed in https://www.w3.org/TR/wai-aria/roles#namefromcontent.
How does knowing how the accessible name is generated help me?
When designing and implementing objects on a website, the name of the object is surfaced to assistive technology. Knowing how that name is generated can help you define a name that is both succinct and clear.
Screen reader users often scan a page for the same reason a sighted user scans a page, to quickly get key information, but the scanning is done with their ears instead of their eyes. Just like a sighted user wants to pick out keywords on objects and ignore the "fluff", a screen reader user wants the key information quickly too. Because of this, it's important to put key information at the beginning of an accessible name.
Let's look at an example. If the time zone selector in Microsoft Windows were a webpage, it would use the
Figure 1 - Time Zone selector on Windows 7
Figure 2 - Time Zone selector on Windows 10
The accessible names of the items all start with "UTC" and the time zone offset. Sighted users can easily ignore the first "column" of information and just focus on the time zone names. That same ability should be surfaced to screen reader users. If you were listening for a certain time zone, such as "Mountain Time", you'd have to listen through the UTC offset before hearing the name of the time zone. Most people choose a time zone based on the time zone's name rather than its offset from Greenwich Mean Time, so putting the name first would help the screen reader user.
One way to fix it is to put the time zone name first in the
<option>Mountain Time (US & Canada) (UTC-07:00)</option>
<option>Central America (UTC-06:00)</option>
<option>Central Time (US & Canada) (UTC-07:00)</option>
But from a styling perspective, the UTC offsets don't line up nicely. Another way to fix it is to use an aria-label to specify the accessible name. As noted in "How is the accessible name generated?" section, step C computes the accessible name from the aria-label property.
<option> aria-label="Mountain Time">(UTC-07:00) Mountain Time (US & Canada)</option>
<option>aria-label="Central America">(UTC-06:00) Central America</option>
<option>aria-label="Central Time">(UTC-07:00) Central Time (US & Canada)</option>
Now the sighted user can still skip over the UTC info with their eyes and a screen reader user can hear the time zone name. Speech interface users can say, "Click Mountain Time".
One thing to keep in mind for speech interface users, make sure that any non-visual text that affects the accessible name matches the important words of the visible text. In the example above, "Mountain Time" is the accessible name and matches the important part of "(UTC-07:00) Mountain Time (US & Canada)".
If you had a print button with an image of a printer and the word "print", if you specify an accessible name of "send document to hardcopy device", then a speech interface user would not be able to say "Click Print". They would have to say "Click Send" or "Click Send Document" or "Click Hardcopy", or some other word that exists in the accessible name. If the accessible name comes from aria-label, then there's no visual clue as to what the accessible name is.
<button aria-label="send document to hardcopy device">
<img src="print.jpg" alt="">
Another item to keep in mind for speech interface users, again if the visible text doesn't match the accessible name, is that another object might get selected by accident. Consider this example of two links to a dog and cat picture.
<a aria-label="my dog likes to chase our cat">
<img src="spot.jpg" alt="">
<img src="mrwhiskers.jpg" alt="">
The link for the dog has the word "dog" in the accessible name (aria-label), but it also has the word "cat". The accessible name for the cat link is "mr whiskers". If a speech interface user sees the text "my cat" next to the cat picture and says "Click Cat", the dog link will be selected because the word "cat" is not in the accessible name of the cat link but it is in the accessible name of the dog link
What's in a name? A lot when it comes to the accessible name of an object. The generation of the accessible name is a well-documented process and once that process is understood, accessible names can be specified with the understanding of how it affects different types of users and assistive technology