Copyright © 2014-2021 W3C ® ( MIT , ERCIM , Keio , Beihang ). W3C liability , trademark and document use rules apply.
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 .
This section describes the status of this document at the time of its publication. Other documents may supersede this document. 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/.
This document was published by the Accessible Rich Internet Applications Working Group as an Editor's Draft.
GitHub Issues are preferred for discussion of this specification.
Publication as an Editor's Draft does not imply endorsement by the W3C Membership.
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 1 August 2017 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 .
This document is governed by the 15 September 2020 W3C Process Document .
This section is non-normative.
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".
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 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.
RFC-2119
keywords
are
formatted
in
uppercase
and
contained
in
a
strong
element
with
class="rfc2119"
.
When
the
keywords
shown
above
are
used,
but
do
not
share
this
format,
they
do
not
convey
formal
information
in
the
RFC
2119
sense,
and
are
merely
explanatory,
i.e.,
informative.
As
much
as
possible,
such
usages
are
avoided
in
this
specification.
The indication whether a section is normative or non-normative (informative) applies to the entire section including sub-sections.
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.
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:
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
.
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 Accessible Name and Description Computation .
If
aria-describedby
is
present,
user
agents
MUST
compute
the
accessible
description
by
concatenating
the
text
alternatives
for
elements
referenced
by
an
aria-describedby
attribute
on
the
current
element.
The
text
alternatives
for
the
referenced
elements
are
computed
using
a
number
of
methods,
outlined
below
in
the
section
titled
Accessible
Name
and
Description
Computation
.
The accessible name and description computation is used to generate 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
'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.
current
node
.
result
to
X.
result
to
the
end
of
X.
result
to
X.
result
to
X
after
the
space.
result
to
X.
result
to
the
start
of
X.
result
to
X.
result
to
the
start
of
X,
and
add
a
space
after
the
copy.
The text alternative for a given element is computed as follows:
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
("").
current
node
:
current
node
is
hidden
and
is
not
directly
referenced
by
aria-labelledby
or
aria-describedby
,
nor
directly
referenced
by
a
native
host
language
text
alternative
element
(e.g.
label
in
HTML
)
or
attribute
,
return
the
empty
string.
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
.
current
node
has
an
aria-labelledby
attribute
that
contains
at
least
one
valid
IDREF,
and
the
current
node
is
not
already
part
of
an
aria-labelledby
traversal,
process
its
IDREFs
in
the
order
they
occur:
current
node
has
an
aria-describedby
attribute
that
contains
at
least
one
valid
IDREF,
and
the
current
node
is
not
already
part
of
an
aria-describedby
traversal,
process
its
IDREFs
in
the
order
they
occur:
accumulated
text
to
the
empty
string.
current
node
to
the
node
referenced
by
the
IDREF.
current
node
current
node
is
being
rendered
,
recursively
skip
to
step
2.
current
node
is
not
being
rendered
:
current
node
has
an
aria-label
attribute
whose
value,
when
trimmed
of
white
space,
is
not
the
empty
string,
return
the
value
of
aria-label
.
innerText
of
the
node.
result
to
result
,
with
a
space,
to
the
accumulated
text
.
accumulated
text
.
The
following
example
shows
the
meaning
of
the
clause
"…
and
the
current
node
is
not
already
part
of
an
aria-labelledby
traversal
…"
.
element1
's
accessible
name
is
"hello"
because
this
is
a
first
traversal
of
its
aria-labelledby
,
leading
to
element3
.
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
>
current
node
is
a
control
embedded
within
the
label
(e.g.
the
label
element
in
HTML
or
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:
aria-valuetext
property
is
present,
return
its
value,
aria-valuenow
property
is
present,
return
its
value,
Consider a check box label that contains a text input field: "Flash the screen [input] times". If the user has entered "5" for the embedded textbox , the complete label is "Flash the screen 5 times", e.g.:
<
div
role
=
"checkbox"
aria-checked
=
"false"
>
Flash
the
screen
<
span
role
=
"textbox"
aria-multiline
=
"false"
>
5
</
span
>
times
</
div
>
current
node
has
an
aria-label
attribute
whose
value
is
not
the
empty
string,
nor,
when
trimmed
of
white
space,
is
not
the
empty
string:
current
node
is
due
to
recursion
and
the
current
node
is
an
embedded
control
as
defined
in
step
2E,
ignore
aria-label
and
skip
to
rule
2E.
aria-label
.
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.
<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
>
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"
).
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.
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
:
accumulated
text
to
the
empty
string.
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.
:before
pseudo
elements,
User
agents
MUST
prepend
CSS
textual
content,
without
a
space,
to
the
textual
content
of
the
current
node
.
:after
pseudo
elements,
User
agents
MUST
append
CSS
textual
content,
without
a
space,
to
the
textual
content
of
the
current
node
.
current
node
:
current
node
to
the
child
node.
current
node
beginning
with
step
2.
Set
the
result
to
that
text
alternative.
result
to
the
accumulated
text
.
accumulated
text
.
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.
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.
current
node
is
a
Text
node
,
return
its
textual
contents.
current
node
is
a
descendant
of
an
element
whose
Accessible
Name
or
Accessible
Description
is
being
computed,
and
contains
descendants,
proceed
to
2F.i.
current
node
has
a
Tooltip
attribute
,
return
its
value.
Tooltip attributes are used only if nothing else, including subtree content, has provided results.
Append
the
result
of
each
step
above,
with
a
space,
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.
Information
concerning
name
and
description
accessibility
API
mappings,
including
relationships,
such
as
labelled-by/label-for
and
described-by/description-for,
is
documented
in
the
Core
Accessibility
API
Mappings
specification
[
CORE-AAM-1.2
].
See
the
mapping
table
entries
for
aria-label
,
aria-labelledby
,
and
aria-describedby
.
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 and currently under contract number HHSP23301500054C. 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.