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 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 standards and drafts index.
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 a 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 that the individual believes contains
Essential Claim(s)
must disclose the information in accordance with
section 6 of the W3C Patent Policy.
User agents acquire information from the DOM
[DOM] and create a parallel structure called the
accessibility tree, made up of accessible objects. An accessible object provides information about its role,
states, and properties. An example is an accessible object whose role is menuitem, is currently in an enabled state, with a
haspopup property, indicating that it leads to a sub-menu.
The two properties of accessible objects described in this document are its accessible name and accessible description. The name is a short label
that provides information about the purpose of the object. An example of an accessible name for a menu item is New, signifying that the menu item provides for the creation of new
documents, windows, and so on.
The description is a short explanation that further clarifies the nature of the accessible object. It is not always necessary to provide a description if the name is sufficient, but it can
help a user better understand the use of the object.
Accessibility APIs currently support flat, unstructured strings for accessible names and descriptions. The result
of the name/description computation is thus a flat string.
The terms "accessible name" and "accessible description" are used to emphasize that they are properties of accessible objects as exposed by
Accessibility APIs. However, they are frequently referred to hereafter as simply "name" and "description".
2. Important Terms
This section is non-normative.
While some terms are defined in place, the following definitions are used throughout this document.
Assistive Technologies
Hardware and/or software that:
relies on services provided by a user agent to retrieve and render Web content
works with a user agent or web content itself through the use of APIs, and
provides services beyond those offered by the user agent to facilitate user interaction with web content by people with disabilities
This definition may differ from that used in other documents.
Examples of assistive technologies that are important in the context of this document include the following:
screen magnifiers, which are used to enlarge and improve the visual readability of rendered text and images;
screen readers, which are most-often used to convey information through synthesized speech or a refreshable Braille display;
text-to-speech software, which is used to convert text into synthetic speech;
speech recognition software, which is used to allow spoken control and dictation;
alternate input technologies (including head pointers, on-screen keyboards, single switches, and sip/puff devices), which are used to simulate the keyboard;
alternate pointing devices, which are used to simulate mouse pointing and clicking.
Accessible Description
An accessible description provides additional information, related to an interface element, that complements the accessible name. The accessible description might or might not be
visually perceivable.
Accessible Name
The accessible name is the name of a user interface element. Each platform accessibility API provides the accessible name
property. The value of the accessible name may be derived from a visible (e.g., the visible text on a button) or invisible (e.g., the text alternative that describes an icon) property of
the user interface element. See related accessible description.
A simple use for the accessible name property may be illustrated by an "OK" button. The text "OK" is the accessible name. When the button receives focus, assistive
technologies may concatenate the platform's role description with the accessible name. For example, a screen reader may speak "push-button OK" or "OK button". The
order of concatenation and specifics of the role description (e.g., "button", "push-button", "clickable button") are determined by platform
accessibility APIs or assistive technologies.
Tooltip attribute
Any host language attribute that would result in a user agent generating a tooltip such as in response to a mouse hover in desktop user agents.
3. Conformance
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, and MUST NOT in this document
are to be interpreted as described in
BCP 14
[RFC2119] [RFC8174]
when, and only when, they appear in all
capitals, as shown here.
Normative sections provide requirements that authors, user agents and assistive technologies MUST follow for an implementation to conform to this specification.
Non-normative (informative) sections provide information useful to understanding the specification. Such sections may contain examples of recommended practice, but it is not required to follow
such recommendations in order to conform to this specification.
4. Name and Description
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'srole, 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-labelledbyattribute, or a host language labeling mechanism, such as the alt or titleattribute in
HTML, or the descelement 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 following table provides the order of precedence for markup that can be applied to compute an accessible description. User agentsMUST 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:
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
4.3 Text Equivalent Computation
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 2.2 and 2.6, 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.
4.3.1 Terminology
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.
4.3.2 Computation steps
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:
Hidden Not Referenced: If the current node is
hiddenand is:
Not part of an aria-labelledby or aria-describedby traversal, where the node directly referenced by that relation was hidden.
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:
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".
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.
Nodes with the aria-hidden="true" property: it is considered hidden, matching the "explicitly hidden" guideline.
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.
LabelledBy: Otherwise, if the current node has an
aria-labelledbyattribute 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:
Set the accumulated text to the empty string.
For each IDREF:
Set the current node to the node referenced by the IDREF.
LabelledBy Traversal: Compute the text alternative of the
current node beginning with the overall Computation step. Set the result to that text alternative.
Append a space character and the result to the accumulated text.
Return the accumulated text if it is not the empty string ("").
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:
Textbox: If the embedded control has role textbox, return its value.
Combobox/Listbox: If the embedded control has role combobox or listbox,
return the text alternative of the chosen option.
If the aria-valuetext property is present, return its value,
Otherwise, if the aria-valuenow property is present, return its value,
Otherwise, use the value as specified by a host language attribute.
AriaLabel: Otherwise, if the current node is not a slot element and has an
aria-labelattribute whose value is not undefined, not the empty string, nor, when trimmed of whitespace, is not the empty string:
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 (e.g., HTML-AAM), unless the
current node is exposed as presentational (role="presentation" or role="none", alt="").
Note
Important! The accessible name for native HTML elements may be calculated differently depending on host language. Make sure to review
HTML-AAM for more information.
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.
Name From Content: Otherwise, if the current node'srole 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:
Name From Content Reset: Set the accumulated text to the empty string.
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, in addition to the
::marker pseudo element.
For ::marker pseudo elements, User agentsMUST prepend CSS textual content, without a space,
to the textual content of the current node if the current node supports ::marker.
For ::before pseudo elements, User agentsMUST prepend CSS textual content, without a space,
to the textual content of the current node.
For ::after pseudo elements, User agentsMUST append CSS textual content, without a space, to
the textual content of the current node.
Determine Child Nodes: Determine the rendered child nodes of the current node:
If the current node has an attached shadow root, set the rendered child nodes to be the child nodes of the shadow root.
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.
Otherwise, set the rendered child nodes to be the child nodes of the current node.
Name From Each Child: For each rendered child node of the
current node:
Set the current node to the rendered child node.
Compute the text alternative of the current node beginning with the overall
Computation step. Set the result to that text alternative.
Append the result to the accumulated text.
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.
Text Node: Otherwise, if the current node is a text node, return
its textual contents.
27-June-2019: Add statement allowing for the possibility of naming being prohibited on the root node. Note: This change in and of itself has no implementation impact, but it allows other
specifications to optionally prohibit naming for a top-level element. Furthermore, even if this prohibition is made within a specification, that prohibition will not have any impact on
calculating name from contents.
6.2 Acknowledgments
This section is non-normative.
The following people contributed to the development of this document.
This publication has been funded in part with U.S. Federal funds from the Department of Education, National Institute on Disability, Independent Living, and Rehabilitation Research (NIDILRR), initially under contract number ED-OSE-10-C-0067, then under contract number HHSP23301500054C, and now under HHS75P00120P00168. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.
You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.