Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Create aria25.html #4061

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Create aria25.html #4061

Changes from 3 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
b92dd0b
Create aria24.html
mbgower May 14, 2019
2b37937
rename file
mbgower Oct 29, 2024
4cfd921
Update techniques/aria/aria25.html
mbgower Oct 29, 2024
2ddbc7d
Update techniques/aria/aria25.html
mbgower Oct 29, 2024
755bbbe
Merge branch 'main' into tech-label-in-name-aria
mbgower Nov 1, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
193 changes: 193 additions & 0 deletions techniques/aria/aria25.html
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,193 @@
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>
<title>Using ARIA to match the accessible name to the visible label</title>
<link rel="stylesheet" type="text/css" href="../../css/editors.css">
</head>
<body>
<h1>Using ARIA to match the accessible name to the visible label</h1>
<section id="meta">
<h2>Metadata</h2>
<p id="id"></p>
<p id="technology"></p>
<p id="type"></p>
</section>
<section id="applicability">
<h2>When to Use</h2>
<p class="instructions">This technique applies to all web technologies that include interactive controls (such as links or form inputs).</p>
</section>
<section id="description">
<h2>Description</h2>
<p class="instructions">The objective of this technique is to ensure that speech input users can operate web content reliably while not adversely affecting other users of assistive technology.</p>
<p>When speech input users interact with a web page, they usually speak a command followed by the reference to some visible label (such as text beside an input field or inside a button or link). For example, they may say "click search" to activate a button labelled Search. When speech recognition software processes speech input and looks for matches, it uses the <a href="https://www.w3.org/TR/accname/"> accessible name</a> of controls. Where there is a mismatch between the text in the label and the text in the accessible name, it can cause issues for the user.</p>

<p>The simplest way to enable speech input users and meet 2.5.3 Label in Name is to ensure that the accessible name matches the visible text label. The accessible name should be assigned through native elements and semantics where possible. That helps ensure an exact match between the visible label and name. This is covered in the related technique <a href="https://www.w3.org/WAI/WCAG21/Techniques/general/G211">Matching the accessible name to visible label with native semantics</a>.</p>
<p>Where it is not possible to match the adjacent visible text label through native semantics, authors may use aria-label and aria-labelledby to match the string. Such situations are unusual and tend to occur when there is not a clear 1:1 relationship between user interface components and labels. Especially where users may perceive more inputs than labels, the use of ARIA can be beneficial to ensure the name matches the label.</p>
</section>
<section id="examples">
<h2>Examples</h2>

<p>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 <a href="https://www.w3.org/WAI/WCAG21/Understanding/label-in-name"> 2.5.3 Understanding document</a>.</p>
<p>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 <a href="https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html"> 1.3.1 Information and Relationships</a> and <a href="https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions">3.3.2 Labels or Instructions</a>.</p>


<section class="example">
<h3>A single label for multiple controls: telephone number</h3>
<p>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.</p>
<figure>
<img src="img/work-phone.png" alt="Work Phone:">
<figcaption>Three text input fields preceded by a single label "Work Phone:".</figcaption>
</figure>
<p>"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.</p>
<p>Associating the label with the first input can be accomplished through <code>aria-labelledby</code>, which can reference the <code>id</code> of the element containing the string (in the following code example, a <code>span</code> nested inside a parent <code>div</code>).</p>
<p>The parent <code>div</code> can be used to nest the group of related inputs to meet 1.3.1 Information and Relationships, with the aria role of <code>group</code> assigned to the <code>div</code> and <code>aria-labelledby</code> providing the group label (by pointing to the same nested <code>span</code>). </p>
<p>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 <code>title</code> attribute. Where an accessible name already exists (for the first input), the <code>title</code> value becomes part of the accessible <em>description</em>. In the absence of another candidate for accessible name, the <code>title</code> value is used in the calculation for the name (for the second and third inputs).</p>
<code>
&lt;div role="group" aria-labelledby="groupLabel"&gt;<br>
&lt;span id="groupLabel"&gt;Work Phone:&lt;/span&gt;<br>
&lt;input type="number" aria-labelledby="groupLabel" title="Area Code" min="3" max="3" /&gt;<br>
&lt;input type="number" title="Prefix" min="3" max="3" /&gt;<br>
&lt;input type="number" title="Line Number" min="4" max="4" /&gt;<br>
&lt;/div&gt;<br>

</code>
<p>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:
</p><ol>
<li>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.</li>
<li>Sighted users who wish to have more context can use hover to reveal the <code>title</code> value as a tool tip. This can be beneficial for users with low vision or with some cognitive disabilities.</li>
<li>Since the <code>title</code> attribute is used across all three inputs, the behaviour of the inputs is consistent for many users.</li>
<li>The computation for accessible name and description ensures that the value of <code>title</code> is always available programmatically, either as the accessible name or description. Thus screen readers will always have access to this information. </li>
</ol>
<p></p>
<p>There are a couple of disadvantages to this construction:
</p><ol>
<li>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.)</li>
<li>The keyboard user cannot see a label for the second and third inputs since most browsers do not provide a mechanism to display <code>title</code> via keyboard. (Unless the telephone inputs are redesigned to provide persistently visible labels, this will remain a challenge.)</li>
</ol>
<p></p>
</section>

<section class="example">
<h3>Radio buttons laid out in a matrix</h3>
<p>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.</p>
<figure>
<img src="img/matrix-buttons.png" alt="How satisfied or dissatisfied are you with each of the following? The interaction with sales staff, Your experience at the register, The organziation of the store, The products offered in the store, The price of the product, The sizes available">
<figcaption>Figure 9 6x6 matrix question covering satisfaction of a number of experiences in the rows, with ratings from Very Satisfied to Very dissatisfied in the columns.</figcaption>
</figure>

<p>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.</p>
<p>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.</p>
<p> 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.</p>
<p>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.</p>
<p>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 <em>may</em> 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.</p>
<p>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.</p>
<p>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.</p>
<p>Regardless of decisions on what to do for each radio button, <code>aria-labelledby</code> will typically be used to provide the accessible name (since <code>scope</code> attributes cannot).
</p><p>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 <code>label</code> (and other programmatic relationships) covered in 1.3.1 Information and Relationships.</p>

<p>
<code>
&lt;table&gt;<br>
&lt;caption&gt;2. How satisfied or dissatisfied are you with each of the following?&lt;/caption&gt;<br>
&lt;thead&gt;<br>
&lt;tr&gt;<br>
&lt;th scope="col" title="Feature"&gt;&lt;/th&gt;<br>
&lt;th scope="col" id="VS"&gt;Very satisfied&lt;/th&gt;<br>
&lt;th scope="col" id="SS"&gt;Somewhat satisfied&lt;/th&gt;<br>
&lt;th scope="col" id="NSD"&gt;Neither satisfied nor dissatisfied&lt;/th&gt;<br>
&lt;th scope="col" id="SD"&gt;Somewhat dissatisfied&lt;/th&gt;<br>
&lt;th scope="col" id="VD"&gt;Very dissatisfied&lt;/th&gt;<br>
&lt;/tr&gt;<br>
&lt;/thead&gt;<br>
&lt;tbody&gt;<br>
&lt;tr&gt;<br>
&lt;th scope="row" id="interaction"&gt;The interaction with the sales staff&lt;/th&gt;<br>
&lt;td&gt;&lt;input type="radio" name="interaction" id="VS1" value="VS1" aria-labelledby="interaction VS"&gt;&lt;/td&gt;<br>
&lt;td&gt;&lt;input type="radio" name="interaction" id="SS1" value="SS1" title="Somewhat satisfied"&gt;&lt;/td&gt;<br>
&lt;td&gt;&lt;input type="radio" name="interaction" id="NSD1" value="NSD1" title="Neither satisfied nor dissatisfied"&gt;&lt;/td&gt;<br>
&lt;td&gt;&lt;input type="radio" name="interaction" id="SD1" value="SD1" title="Somewhat dissatisfied"&gt;&lt;/td&gt;<br>
&lt;td&gt;&lt;input type="radio" name="interaction" id="VD1" value="VD1" title="Very dissatisfied"&gt;&lt;/td&gt;<br>
&lt;/tr&gt;<br>
...<br>
&lt;tr&gt;<br>
&lt;th scope="row" id="price"&gt;The price of the products&lt;/th&gt;<br>
&lt;td&gt;&lt;input type="radio" name="price" id="VS5" value="VS5" aria-labelledby="price"&gt;&lt;/td&gt;<br>
&lt;td&gt;&lt;input type="radio" name="price" id="SS5" value="SS5"&gt;&lt;/td&gt;<br>
&lt;td&gt;&lt;input type="radio" name="price" id="NSD5" value="NSD5"&gt;&lt;/td&gt;<br>
&lt;td&gt;&lt;input type="radio" name="price" id="SD5" value="SD5"&gt;&lt;/td&gt;<br>
&lt;td&gt;&lt;input type="radio" name="price" id="VD5" value="VD5"&gt;&lt;/td&gt;<br>
&lt;/tr&gt;<br>
&lt;tr&gt;<br>
&lt;th scope="row" id="sizes"&gt;The sizes available at the store&lt;/th&gt;<br>
&lt;td&gt;&lt;input type="radio" name="sizes" id="VS6" value="VS6" aria-labelledby="sizes"&gt;&lt;/td&gt;<br>
&lt;td&gt;&lt;input type="radio" name="sizes" id="SS6" value="SS6"&gt;&lt;/td&gt;<br>
&lt;td&gt;&lt;input type="radio" name="sizes" id="NSD6" value="NSD6"&gt;&lt;/td&gt;<br>
&lt;td&gt;&lt;input type="radio" name="sizes" id="SD6" value="SD6"&gt;&lt;/td&gt;<br>
&lt;td&gt;&lt;input type="radio" name="sizes" id="VD6" value="VD6"&gt;&lt;/td&gt;<br>
&lt;/tr&gt;<br>
&lt;/tr&gt;<br>
&lt;/tbody&gt;<br>
&lt;/table&gt;<br>

</code>
</p>
<p class="working-example"><a href="file:///C:/Users/IBM_ADMIN/Documents/GitHub/wcag/working-examples/label-in-name-general/example5.html" target="_blank">Working example of radio buttons in a matrix</a></p>
mbgower marked this conversation as resolved.
Show resolved Hide resolved
</section>
<section class="example">
<h3>Inputs laid out in a matrix</h3>
<p>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.</p>
<figure>
<img src="img/matrix-inputs.jpg" alt="Column headers: competency, cost, viability, desirability, alignment, total. Row headers: criteria rating, idea A, weighted rating">
<figcaption>Figure 10 Decision 7x10 matrix with row and column headers and text input cells</figcaption>
</figure>

<p>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.</p>
<p>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:
</p><ul>
<li><strong>The table header text length.</strong> 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. </li>
<li><strong>The size of the matrix.</strong> 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 <code>title</code> value via <code>aria-labelledby</code> for each cell would provide context as a tool tip.</li>
<li><strong>The nature of the table and position of the inputs.</strong> 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.</li>
<li><strong>The value of information in neighbouring cells.</strong> 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.</li>
</ul>
<p></p>
<p>Such considerations will help to determine if there is an appropriate label for any given actionable cell in a grid.</p>
</section>
</section>
<section id="tests">
<h2>Tests</h2>
<section class="test-procedure">
<h3>Procedure</h3>
<p></p><ol>
<li>Examine each control that has adjacent text which serves as its label</li>
<li>The entire string of text (disregarding letter case and punctuation) matches the accessible name for the control (according to the accessible name computation)</li>
</ol><p></p>
</section>
<section class="test-results">
<h3>Expected Results</h3>
<ul>
<li>#2 is true</li>
</ul>
</section>
</section>
<section id="related">
<h2>Related Techniques</h2>
<p class="instructions">Provide links to other techniques that users should consider. This section is optional.</p>
<ul>
<li><a href="http://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/H44"> H44: Using label elements to associate text labels with form controls</a></li>
<li><a href="http://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/H71"> H71: Providing a description for groups of form controls using fieldset and legend elements</a></li>
<li><a href="http://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/H85"> H85: Using OPTGROUP to group OPTION elements inside a SELECT</a></li>
<li><a href="http://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/ARIA17"> ARIA17: Using grouping roles to identify related form controls</a>
</li>
</ul>
</section>
<section id="resources">
<h2>Resources</h2>
<p class="instructions">Provide links to external resources that are relevant to users of the technique. This section is optional.</p>
<ul>
<li><a href="https://www.w3.org/TR/accname-aam-1.1/"> Accessible Name and Description Computation</a></li>
<li><a href="https://www.w3.org/TR/html-aam-1.0/#accessible-name-and-description-computation"> Accessible Name and Description Computation in HTML Accessibility API Mappings 1.0</a></li>
</ul>
</section>


</body></html>