Ensuring that visible labels match their accessible names

Metadata

general

sufficient

When to Use

This Technique applies to all web technologies that include interactive controls (such as links or form inputs)

Description

The objective of this technique is to ensure that speech input users can operate web content reliably. The secondary objective is to prevent speech input users from accidentally activating controls.

When speech input users interact with a web page, they usually speak a command followed by the reference to some visible label (like the text in a button or a link, or the text labelling some input). For example, they may speak "click search" to activate a search button. The speech recognition software can then process the input, match the name of the label to the control, and carry out the command (here, activate the search button).

This Technique aims to ensure that this matching of speech input to controls will be successful. When speech recognition software processes speech input and looks for matches, it uses the so-called "accessible name" of controls, which is not necessarily identical to the visible label. For example, a button following a search input field may contain the text "go" but use an invisible aria-label attribute with the value "search". Since aria-label takes precedence over the text included in the button, the accessible name of this button will be "search", not "go". (Compare the Accessible Name and Description Computation algorithm). Another example is links that contain visually hidden text. A visible link may just read "home", the actual accessible name however may be "go to the home page" where CSS has been used to hide the portions around "home". This would create problems for speech input users when they say "click home" to activate the link, because 'home' cannot be easily matched to the accessible name of that control.

When authors make sure that the visible label of a control (the text in a link or button, the value set for an input type=submit, or the label programmatically associated to another type of input) corresponds to the accessible name of that control, speech input users can be confident that their input is correctly interpreted.

When authors want to add additional text provide more context to a link or other control to make it more descriptive for users of assistive technologies, they should add that text after the visible label so the accessible name starts with the visible label. In the case of the search button, the accessible name could be "search this site", in the case of the home link, the text could be "home - go to start page". In both cases, the hidden portion of the label may be supplied by different means, for example, as text accessibly hidden via CSS or by using the aria-label or the aria-labelledby attribute.

An unintended effect of using accessible names that are visually hidden is that speech users may accidentally activate controls when they happen to speak words that map to these hidden accessible names.

Examples

Example 1: Link text equals the accessible name

In this example, the link text provides the accessible name:

<p>Go to <a href="code-of-conduct.html">Code of conduct</a></p>

Example 2: Link text matches the beginning of the accessible name

Here, the link contains visible text and hidden link text. Both together make up the link's accessible name. The visible text comes first. The idea is to make the link more descriptive for users of assistive technologies.

<p>Go to <a href="code-of-conduct.html">Code of conduct <span class="accessibly-hidden"> of ACME Corporation</span></a><p>

Example 3: A visible label provides the accessible name for a checkbox

A checkbox is labelled by a programmatically linked and visible label element which thereby provides its accessible name:

<input type="checkbox" id="notification" name="notify" value="delays"> <label for="notification">Notify me of delays</label>

Example 4: The button text provides the accessible name

The visible text inside a button element makes up its accessible name:

<button>Send</button>

Example 5: The visible button text matches the beginning of the accessible name

The visible text inside a button element matches the beginning of accessible name, which also includes hidden text. The idea of the hidden text is to make the button more descriptive for users of assisitve technologies.

<button>Send <span class="accessibly-hidden"> Mail</span></button>

Example 6: The button text matches the first part of a concatenated accessible name

The accessible name of an "order" button is concatenated via aria-labelledby (first referencing the button itself, then the contents of a text field, then the label of that text field). The accessible name is "order 3 things". The idea is to provide more programmatic context of the order for users of assistive technologies. Speech input users can still activate the button by speaking the command "click order" because the button text comes first.

<p><label id="thinglabel" for="thingnum">Things</label>: <input id="thingnum" type="text" value="3" /></p>
<button id="compbtn" aria-labelledby="compbtn thingnum thinglabel">Order</button>

Working example

:

Tests

Procedure

For all controls with a visible label (e.g. link text, button text, programmatically linked label, value of input), check that

  1. The visible label matches the accessible name of the control
  2. The visible label matches the beginning of the accessible name of the control

Expected Results