Accessible Name and Description Computation 1.2

Abstract

This document describes how user agents determine the names and descriptions of accessible objects from web content languages. This information is in turn exposed through accessibility APIs so that assistive technologies can identify these objects and present their names or descriptions to users. Documenting the algorithm through which names and descriptions are to be determined promotes interoperable exposure of these properties among different accessibility APIs and helps to ensure that this information appears in a manner consistent with author intent.

The accessible name and description computation specification defines support that applies across multiple content technologies. This includes accessible name and description provided by general-purpose WAI-ARIA [WAI-ARIA] roles, states, and properties as well as features specific to individual content languages.

This document updates and will eventually supersede the accessible name and description guidance in the Accessible Name and Description Computation 1.1 [ACCNAME-1.1] W3C Recommendation. It is part of the WAI-ARIA suite described in the WAI-ARIA Overview.

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

Publication as an Editor's Draft does not imply endorsement by W3C and its Members.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

The starting point of the name and description computation is a DOM element. The output is a flat, unstructured string that can be as simple as a single word, or a string of space-separated tokens. Examples include Save and Reload from disk.

An important factor is the element's role, that determines which content contributes to the name string. Roles have a nameFrom RDF property, with three possible values:

author: name is generated from values provided by the author in explicit markup features such as the aria-label and aria-labelledby attribute, or a host language labeling mechanism, such as the alt or title attribute in HTML, or the desc element in SVG.
contents: name is generated from the Text nodes associated with the element. Although this may be allowed in addition to "author" in some roles, "content" is used only if higher priority "author" features are not provided. Priority is defined by the text equivalent computation algorithm.
prohibited: the element has no name. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.

The Accessible Rich Internet Applications (WAI-ARIA) 1.2 [WAI-ARIA] specification provides lists of roles that support name from author, roles that support name from content and roles that cannot be named.

User agents MUST compute an accessible name using the rules outlined below in the section titled Text Equivalent Computation.

The following table provides the order of precedence for markup that can be applied to compute an accessible description. User agents MUST use the first applicable entry from the table where the listed conditions are met, as described in the last column. The user agent MUST NOT use any markup other that the first relevant markup found, even if that markup results in an empty description:

Precedence	Attribute	Applicable conditions	How used to compute description
1	`aria-describedby` attribute	Use on any element	Name computation on all nodes referenced by aria-describedby on the element, concatenated, and separated by a space character
2	`aria-description` attribute	Use on any element	As a flat string
3	host language features which participate in the description calculation	Unique host language features MAY participate in the description computation for an element, only if they were not already used for the accessible name of the applicable element. See HTML AAM: Accessible Description Computation for the HTML elements which meet this condition.	Either a text equivalent computation of the host language element, or the string value of the host language attribute.
4	host language tooltip attribute or equivalent feature (e.g., HTML `title` attribute)	Any element Only use if not already used for the accessible name of this node	As a flat string

The text equivalent computation is used by both the accessible name and accessible description. There are different rules provided for several different types of elements, nodes, and combinations of markup. Text alternatives are built up, when appropriate, from all the relevant content contained within an element. This is accomplished via steps 2B and 2F, which are recursive, using the full set of rules to retrieve text from its own children or nodes it references.

The purpose of the computation is to create a perceivable label or description for alternative presentations, in the form of a flat string of space separated textual tokens.

Root node

The DOM node or element for which the text alternative is sought.

Current node

The DOM node currently traversed to compute the root node's text equivalent. Initially, the current node is the root node, but at later stages is either some descendant of the root node, or another referenced node.

Rendered child nodes

The nodes that are rendered as child nodes of a given node when taking shadow roots and slots into consideration.

Flat string

A string of characters where all carriage returns, newlines, tabs, and form-feeds are replaced with a single space, and multiple spaces are reduced to a single space. The string contains only character data; it does not contain any markup.

Total accumulated text

The text equivalent computed up to, but not including the current node.

Accumulated text

Text accumulated at a step or sequence of steps described below. It is temporary storage for those steps.

Result

The text equivalent computed at one of the steps described below.

Append the result, without a space, to X

If X is empty, copy the result to X.
If X is non-empty, copy the result to the end of X.

Append the result, with a space, to X

If X is empty, copy the result to X.
If X is non-empty, add a space to the end of X and then copy the result to X after the space.

Prepend result, without a space, to X

If X is empty, copy the result to X.
If X is non-empty, copy the result to the start of X.

Prepend the result, with a space, to X

If X is empty, copy the result to X.
If X is non-empty, copy the result to the start of X, and add a space after the copy.

The text alternative for a given element is computed as follows:

Initialization: Set the root node to the given element, the current node to the root node, and the total accumulated text to the empty string (""). If the root node's role prohibits naming, return the empty string ("").
Computation: Compute the text alternative for the current node:
1. Hidden Not Referenced: If the current node is hidden and is:
  1. Not part of an aria-labelledby or aria-describedby traversal, where the node directly referenced by that relation was hidden.
  2. Nor part of a native host language text alternative element (e.g. label in HTML) or attribute traversal, where the root of that traversal was hidden.
  Return the empty string.
  Note
  It's important to clarify the broad definition of hidden for the purposes of accessible name calculation:
  1. Nodes with CSS properties display:none, visibility:hidden, visibility:collapse or content-visibility:hidden: They are considered hidden, as they match the guidelines "not perceivable" and "explicitly hidden".
  2. Nodes with CSS properties opacity:0 or filter:opacity(0%), or similar SVG mechanisms: They are not considered hidden. Text hidden with these methods can still be selected or copied, and user agents still expose it in their accessibility trees.
  3. Nodes with the aria-hidden="true" property: it is considered hidden, matching the "explicitly hidden" guideline.
  4. Nodes hidden off screen or behind another object: they are not considered hidden. They are exposed in the accessibility tree and they can even name on-screen objects.
  Note
  
  By default, assistive technologies do not relay hidden information, but an author can explicitly override that and include hidden text as part of the accessible name or accessible description by using aria-labelledby or aria-describedby.
  Example 1
  
  The following examples show the meaning of the clause "Not part of an aria-labelledby or aria-describedby traversal, where the node directy referenced by that relation was hidden.".
  
  First, element1's accessible name is "hello" because, although element3 is hidden, it is part of an aria-labelledby traversal started in element2, which is hidden too.
  Example
```
<element1 id="el1" role="button" aria-labelledby="el2" />
  <element2 id="el2" class="hidden">
    <element3 id="el3" class="hidden">hello</element3>
  </element2>
```
  Example 2
  
  Conversely, element1 has no accessible name if element3 is hidden and it is part of an aria-labelledby traversal started in element2, but element2 is not hidden.
```
<element1 id="el1" role="button" aria-labelledby="el2" />
<element2 id="el2">
  <element3 id="el3" class="hidden">hello</element3>
</element2>
```
2. LabelledBy: Otherwise, if the current node has an aria-labelledby attribute that contains at least one valid IDREF, and the current node is not already part of an ongoing aria-labelledby or aria-describedby traversal, process its IDREFs in the order they occur:
  1. Set the accumulated text to the empty string.
  2. For each IDREF:
    1. Set the current node to the node referenced by the IDREF.
    2. LabelledBy Recursion: Compute the text alternative of the current node beginning with the overall Computation step. Set the result to that text alternative.
    3. Append a space character and the result to the accumulated text.
  3. Return the accumulated text if it is not the empty string ("").
  The result of LabelledBy Recursion in combination with Hidden Not Referenced means that user agents MUST include all nodes in the subtree as part of the accessible name or accessible description, when the node referenced by aria-labelledby or aria-describedby is hidden.
  Example 3
  
  The following example shows the meaning of the clause "… and the current node is not already part of an aria-labelledby traversal …" .
  1. element1's accessible name is "hello" because this is a first traversal of its aria-labelledby, leading to element3.
  2. element2 has no accessible name. The computation involves a first traversal of its aria-labelledby leading to element1, but element1's aria-labelledby is not subsequently followed.
```
<element1 id="el1" aria-labelledby="el3" />
<element2 id="el2" aria-labelledby="el1" />
<element3 id="el3"> hello </element3>
```
3. Embedded Control: Otherwise, if the current node is a control embedded within the label (e.g. any element directly referenced by aria-labelledby) for another widget, where the user can adjust the embedded control's value, then return the embedded control as part of the text alternative in the following manner:
  1. Textbox: If the embedded control has role textbox, return its value.
  2. Combobox/Listbox: If the embedded control has role combobox or listbox, return the text alternative of the chosen option.
  3. Range: If the embedded control has role range (e.g., a spinbutton or slider):
    1. If the aria-valuetext property is present, return its value,
    2. Otherwise, if the aria-valuenow property is present, return its value,
    3. Otherwise, use the value as specified by a host language attribute.
  Example 4
  
  Consider a check box label that contains a text input field: "Flash the screen [input] times". If the input field has the value "5", the complete label is "Flash the screen 5 times", e.g.:
```
<label for="flash">
  <input type="checkbox" id="flash">
  Flash the screen <span tabindex="0" role="textbox" aria-label="number of times" contenteditable>5</span> times.
</label>
```
4. AriaLabel: Otherwise, if the current node has an aria-label attribute whose value is not undefined, not the empty string, nor, when trimmed of whitespace, is not the empty string:
  1. If traversal of the current node is due to recursion and the current node is an embedded control, ignore aria-label and skip to rule Embedded Control.
  2. Otherwise, return the value of aria-label.
  Example 5
  
  The following example shows the interaction of aria-labelledby and aria-label when a node has an aria-labelledby that refers to itself. The <span role="button"> elements have the accessible names "Delete Documentation.pdf" and "Delete HolidayLetter.pdf", respectively.
  Example
```
<h1>Files</h1>
<ul>
  <li>
    <a id="file_row1" href="./files/Documentation.pdf">Documentation.pdf</a>
    <span role="button" tabindex="0" id="del_row1" aria-label="Delete" aria-labelledby="del_row1 file_row1"></span>
  </li>
  <li>
    <a id="file_row2" href="./files/HolidayLetter.pdf">HolidayLetter.pdf</a>
    <span role="button" tabindex="0" id="del_row2" aria-label="Delete" aria-labelledby="del_row2 file_row2"></span>
  </li>
</ul>
```
5. Host Language Label: Otherwise, if the current node's native markup provides an attribute (e.g. alt) or element (e.g. HTML label or SVG title) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language, unless the element is marked as presentational (role="presentation" or role="none").
  Note
  See HTML-AAM, SVG-AAM, or other host language documentation for more information on markup that defines a text alternative.
  
  Note
  
  For example, in HTML, the img element's alt attribute defines a text alternative string, and the label element provides text for the referenced form element. In SVG2, the desc and title elements provide a description of their parent element.
6. Name From Content: Otherwise, if the current node's role allows name from content, or if the current node is referenced by aria-labelledby, aria-describedby, or is a native host language text alternative element (e.g. label in HTML), or is a descendant of a native host language text alternative element:
  1. Name From Content Reset: Set the accumulated text to the empty string.
  2. Name From Generated Content: Check for CSS generated textual content associated with the current node and include it in the accumulated text. The CSS ::before and ::after pseudo elements [CSS2] can provide textual content for elements that have a content model.
    1. For ::before pseudo elements, User agents MUST prepend CSS textual content, without a space, to the textual content of the current node.
    2. For ::after pseudo elements, User agents MUST append CSS textual content, without a space, to the textual content of the current node.
  3. Determine Child Nodes: Determine the rendered child nodes of the current node:
    1. If the current node has an attached shadow root, set the rendered child nodes to be the child nodes of the shadow root.
    2. Otherwise, if the current node is a slot with assigned nodes, set the rendered child nodes to be the assigned nodes of the current node.
    3. Otherwise, set the rendered child nodes to be the child nodes of the current node.
  4. Name From Each Child: For each rendered child node of the current node:
    1. Set the current node to the rendered child node.
    2. Compute the text alternative of the current node beginning with the overall Computation step. Set the result to that text alternative.
    3. Append the result to the accumulated text.
  5. Return the accumulated text if it is not the empty string ("").
  Important: Each node in the subtree is consulted only once. If text has been collected from a descendant, but is referenced by another IDREF in some descendant node, then that second, or subsequent, reference is not followed. This is done to avoid infinite loops.
  
  Note
  
  This step can apply to the child nodes themselves, which means the computation is recursive and results in text collected from all the elements in the current node's subtree, no matter how deep it is. However, any given descendant node's text alternative can result from higher precedent markup described in steps B through D above, where "Namefrom: author" attributes provide the text alternative for the entire subtree.
  
  Note
  
  18 January 2024: The ARIA Working Group is considering the feasibility of joining text strings with and without spaces, depending on the CSS display value of the current node, and its adjacent nodes and pseudo-elements. The ongoing discussion is in AccName #225.
7. Text Node: Otherwise, if the current node is a Text Node, return its textual contents.
8. Recursive Name From Content: Otherwise, if the current node is a descendant of an element whose Accessible Name or Accessible Description is being computed, and contains descendants, proceed to Name From Content Reset.
9. Tooltip: Otherwise, if the current node has a Tooltip attribute, return its value.
  Note
  
  Tooltip attributes are used only if nothing else, including subtree content, has provided results.
10. Append a space character and the result of each step above to the total accumulated text.
After all steps are completed, the total accumulated text is used as the accessible name or accessible description of the element that initiated the computation.

Accessible Name and Description Computation 1.2

Abstract

Status of This Document

1. Introduction

2. Important Terms

3. Conformance

3.1 RFC-2119 Keywords

3.2 Normative and Informative Sections

4. Name and Description

4.1 Name Computation

4.2 Description Computation

4.3 Text Equivalent Computation

4.3.1 Terminology

4.3.2 Computation steps

5. Accessible Name and Description Mapping

6. Appendices

6.1 Change Log

6.1.1 Substantive changes since the last public working draft

6.1.2 Substantive changes since the Accessible Name and Description Computation 1.1 Recommendation

6.2 Acknowledgments

6.2.1 Participants active in the ARIA WG at the time of publication

6.2.2 Enabling funders

A. References

A.1 Normative references

A.2 Informative references