Examples
+ +The remainder of this document outlines scenarios where it is problematic to match the adjacent visible text label through native semantics, but it is still possible to match the accessible name to the label by applying ARIA roles and attributes. The examples are in accordance with the guidance in the 2.5.3 Understanding document.
+Note: These examples are drawn from the web and are not offered as examples of excellent design. They serve as examples of common implementations which pose challenges when trying to meet 2.5.3 as well as incorporate other considerations such as those for 1.3.1 Information and Relationships and 3.3.2 Labels or Instructions.
+ + +A single label for multiple controls: telephone number
+A series of inputs may only have a single group label between them. A common occurrence of this is a telephone entry that has multiple inputs.
+
+ "Work Phone:" is adjacent to the first of the three inputs, so for the purposes of 2.5.3 it should be considered the first input's label. However, "Work Phone" also describes the group of three inputs. Text in such a scenario is normally referred to as a "group label", but it is important to emphasize that group labels are not part of the accessible name using native HTML semantics. As well, according to the guidance on "Confining the label to adjacent text" in the 2.5.3 Understanding document, the "Work Phone" text should not be considered the label for the other inputs.
+Associating the label with the first input can be accomplished through aria-labelledby, which can reference the id of the element containing the string (in the following code example, a span nested inside a parent div).
The parent div can be used to nest the group of related inputs to meet 1.3.1 Information and Relationships, with the aria role of group assigned to the div and aria-labelledby providing the group label (by pointing to the same nested span).
To meet 3.3.2 ("Labels or instructions are provided when content requires user input."), each of the fields can be given a unique name through the use of the title attribute. Where an accessible name already exists (for the first input), the title value becomes part of the accessible description. In the absence of another candidate for accessible name, the title value is used in the calculation for the name (for the second and third inputs).
+<div role="group" aria-labelledby="groupLabel">
+ <span id="groupLabel">Work Phone:</span>
+ <input type="number" aria-labelledby="groupLabel" title="Area Code" min="3" max="3" />
+ <input type="number" title="Prefix" min="3" max="3" />
+ <input type="number" title="Line Number" min="4" max="4" />
+</div>
+
+
+ There are several advantages to constructing the inputs this way, some of which go beyond the requirements of 2.5.3 but are relevant when considering the most appropriate techniques: +
-
+
- Speech-input users who say "move to work phone" will be moved to the first of the three fields, which is where they would typically wish to begin. If they wish to reposition to the other inputs, it is simple for them to issue a "Press tab" command. +
- Sighted users who wish to have more context can use hover to reveal the
titlevalue as a tool tip. This can be beneficial for users with low vision or with some cognitive disabilities.
+ - Since the
titleattribute is used across all three inputs, the behaviour of the inputs is consistent for many users.
+ - The computation for accessible name and description ensures that the value of
titleis always available programmatically, either as the accessible name or description. Thus screen readers will always have access to this information.
+
There are a couple of disadvantages to this construction: +
-
+
- Screen reader users will hear "Work Phone:" announced twice – as the group name and as the label of the first field. (This is an unfortunate outcome of the new 2.5.3 requirement and will occur for at least one input in a set of inputs with a group label in all implementations.) +
- The keyboard user cannot see a label for the second and third inputs since most browsers do not provide a mechanism to display
titlevia keyboard. (Unless the telephone inputs are redesigned to provide persistently visible labels, this will remain a challenge.)
+
Radio buttons laid out in a matrix
+A more complex construction involves inputs that are laid out in a grid, with the row and column headings serving as the only possible "labels". This is a common construction in a survey.
+
+ When considering this complex component, it is important to remember that the purpose of 2.5.3 Label in Name is to enable speech input. For such users, the text at the start of each row ("The interaction with the sales staff", "Your experience at the the register", etc ) should be treated as the labels for the first radio buttons to meet 2.5.3. The column headers could also be assigned as names for the corresponding radio buttons in the first row, given their proximity.
+To meet 2.5.3, it is not necessary to assign every radio button the table header text as its accessible name. The text is not adjacent to most of them and may not offer a significant improvement in user experience for speech recognition users.
+For instance, in this example each row logically represents a radio button group – a user should only be able to give one rating to the interaction of the sales staff. As such, if the speech recognition user can navigate to the first choice in that group via the row header label, the user can use the keyboard API to easily navigate between the choices.
+From a strictly programmatic perspective, authors may be tempted to treat the column headers ("Very satisfied", "Somewhat satisfied", etc) as the labels for each of the radio buttons. This is consistent with how the simple radio button group was done. However, especially in a survey which contains a number of similar questions, the result does not necessarily improve the speech interaction since there may be dozens of "Very satisfied" radio buttons.
+Many authors will assign the table header values to each input. This is unlikely to improve the interaction for speech-input users, and it has ramifications for screen reader user experience. Giving the header values to each radio button may create a more reliable experience for some users. However, it should be noted that popular screen readers already extract the table's scope information to provide context to users, and wordy table headers will likely decrease the experience for users rather than enhance it.
+For instance, relying on only scope attributes of the table headers, some screen readers will announce each row header as a user traverses to new rows, but (depending on the screen reader's configuration) will not announce the row header while the user navigates between cells on the same row. This is an established and efficient means of navigating by screen reader since it gives good context with reduced verbosity.
+In contrast, concatenating the row and column headers for every cell into its accessible name will result in the screen reader user hearing that combination announced before the radio button's state for each radio button, for example "The interaction with the sales staff Neither satisfied nor dissatisfied, not checked". Depending on the label length, that may result in a less welcome interaction.
+Regardless of decisions on what to do for each radio button, aria-labelledby will typically be used to provide the accessible name (since scope attributes cannot).
+
To summarize, this matrix is a good example of the need to distinguish between a visible label, as discussed in 2.5.3, and notions of a programmatic label (and other programmatic relationships) covered in 1.3.1 Information and Relationships.
+
+ <table>
+
+ <caption>2. How satisfied or dissatisfied are you with each of the following?</caption>
+ <thead>
+ <tr>
+ <th scope="col" title="Feature"></th>
+ <th scope="col" id="VS">Very satisfied</th>
+ <th scope="col" id="SS">Somewhat satisfied</th>
+ <th scope="col" id="NSD">Neither satisfied nor dissatisfied</th>
+ <th scope="col" id="SD">Somewhat dissatisfied</th>
+ <th scope="col" id="VD">Very dissatisfied</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <th scope="row" id="interaction">The interaction with the sales staff</th>
+ <td><input type="radio" name="interaction" id="VS1" value="VS1" aria-labelledby="interaction VS"></td>
+ <td><input type="radio" name="interaction" id="SS1" value="SS1" title="Somewhat satisfied"></td>
+ <td><input type="radio" name="interaction" id="NSD1" value="NSD1" title="Neither satisfied nor dissatisfied"></td>
+ <td><input type="radio" name="interaction" id="SD1" value="SD1" title="Somewhat dissatisfied"></td>
+ <td><input type="radio" name="interaction" id="VD1" value="VD1" title="Very dissatisfied"></td>
+ </tr>
+...
+<tr>
+ <th scope="row" id="price">The price of the products</th>
+ <td><input type="radio" name="price" id="VS5" value="VS5" aria-labelledby="price"></td>
+ <td><input type="radio" name="price" id="SS5" value="SS5"></td>
+ <td><input type="radio" name="price" id="NSD5" value="NSD5"></td>
+ <td><input type="radio" name="price" id="SD5" value="SD5"></td>
+ <td><input type="radio" name="price" id="VD5" value="VD5"></td>
+ </tr>
+ <tr>
+ <th scope="row" id="sizes">The sizes available at the store</th>
+ <td><input type="radio" name="sizes" id="VS6" value="VS6" aria-labelledby="sizes"></td>
+ <td><input type="radio" name="sizes" id="SS6" value="SS6"></td>
+ <td><input type="radio" name="sizes" id="NSD6" value="NSD6"></td>
+ <td><input type="radio" name="sizes" id="SD6" value="SD6"></td>
+ <td><input type="radio" name="sizes" id="VD6" value="VD6"></td>
+ </tr>
+ </tr>
+</tbody>
+</table>
+
+
Inputs laid out in a matrix
+Other inputs besides radio buttons may be laid out in a matrix. In Figure 10, the cells in a grid are primarily text inputs, with column and row headers.
+
+ The same basic proximity guidance applies, as in the radio button matrix – since the first column text is adjacent to the second column input, it should be considered its visible label; the top row may also be considered to supply labels for the second row's cells. The correct names for the second column/row cells will be sufficient to allow a speech-input user to reposition to the first editable cell in each row of the matrix by voice command.
+As with the prior example, some authors may elect to use the column and row headers as the accessible names for all the cells. User testing will help determine the best implementation for the target audience. Here are some considerations for matrixes: +
-
+
- The table header text length. The short text strings in this example could provide context without adding too much verbosity (for screen reader users). Longer strings may be more intrusive. +
- The size of the matrix. Low-vision users who use magnification may have difficulty orienting themselves in large tables (since the text at the beginning of the row and/or column may be out of the viewport). Concatenated header text used as a
titlevalue viaaria-labelledbyfor each cell would provide context as a tool tip.
+ - The nature of the table and position of the inputs. Sometimes the text appearing in the first row or first column of the table is not intended as context for a particular input. The table may not have column or row headers; the value in the first cells may not be meaningful. +
- The value of information in neighbouring cells. If a cell is not neighboring a row or column header, then any text in adjacent cells is likely the text closest in proximity. However, whether text in adjacent cells could serve as a label for the cell is entirely dependent on context. Generally, the text content of cells not serving a header function should be disregarded as potential labels for neighbouring cells, particularly if the cell is itself a user input. +
Such considerations will help to determine if there is an appropriate label for any given actionable cell in a grid.
+