Accessible Name Understanding
Contents
SC
https://rawgit.com/w3c/wcag21/master/guidelines/index.html#accessible-name
Understanding Accessible Name
Intent
Some users rely on speech recognition to control the computer. Speech users can navigate webpages by speaking visible labels of menus, links and button labels that appear on a webpage. But mismatched labels can confuse speech input users when they say the visible label they see but it does not match the Accessible Name, which is what is enabled as a command.
Speech input programs also sometimes enable users to speak labels that aren't visible on the page. Speech users can accidentally say a word in a hidden label and be taken to that link without knowing what has happened. Hidden commands aren't usually problematic for other means of input. But if speech users pause before and after a group of words that makes up a command, the speech input engine returns the command, not the words. This is the way speech engines generally work and it generally works well. But if a webpage contains many hidden, extra commands, it becomes easy to unexpectedly click a hidden command. When this happens it can be difficult for users to tell what happened. They can unwittingly click a link, making the current page seemingly disappear. If the user manages to get back to that page sometimes text they've entered is gone. Delineating the visible label portion of the invisible label would give speech engines a way to address this issue.
Benefits
Speech input users will have fewer surprising changes of focus and will be able to easily activate controls on the page.
Examples
Example 1: Accessible matches Visible The visible and accessible name of a label match.
Example 2: Accessible starts with Visible The acessible label of the Buy Now button begins with the visible label.
Resources
Accessible Name and Description Computation - https://www.w3.org/TR/accname-aam-1.1/
Techniques
Sufficient
Technique: Ensure accessible name contains visible label
Ensure that visible labels, including hover labels of icons, match hidden labels.
Identify all controls on the page. Review underlying code and note the accessible names provided for the control. Ensure that the visible label and the accessible name contain the same text.
Note: a best practice is for the visible label to occupy the beginning of the invisible Accessible name.
ID [AND ID]* [using] ID
<button aria-label="Visible label text and additional invisible text">Visible label</button>
<button aria-labelledby="foo1">Visible label</button>
Advisory
Failures
Failure: Accessible name does not contain the visible label text
NOTE: this only applies when there is visible text on the screen
Example 1: <button aria-label="Additional invisible text">Visible label</button> <button aria-labelledby="foo3">Visible label</button>
Example 2: <button aria-label="Additional invisible text">Visible label</button> <button aria-labelledby="foo3">Visible label</button>
Example 3: <button aria-label="Additional invisible text">Visible label</button> <button aria-labelledby="foo3">Visible label</button>
Here are some real-life examples of what happens to users during failures: A speech input user says "submit" to click a button labeled "submit", but it does not respond. This is because the visible label is not contained in the Accessible Name, but the user cannot see the mismatch and so does not know why the button does not respond. After trying to click the button by saying the label several times, she falls back to having to say several commands to move the mouse and click the button instead. The next time she uses the site she remembers that the site doesn't work well with speech, but doesn't remember which button doesn't respond.
A speech input user says "Buy Now" to click a "Buy Now button", but it does not respond. This is because the the accessible name is "Buy this incredible thingamajig now" rather then containing the full continuous string of the name, for example, "Buy now - incredible thingamajig"
