Copyright © 2015-2019 W3C ® ( MIT , ERCIM , Keio , Beihang ). W3C liability , trademark and permissive document license rules apply.
HTML Accessibility API Mappings ( HTML -AAM) defines how user agents map HTML [ HTML ] elements and attributes to platform accessibility application programming interfaces ( APIs ) . It leverages and extends the Core Accessibility API Mappings 1.2 and the Accessible Name and Description Computation 1.1 for use with the HTML host language. Documenting these mappings promotes interoperable exposure of roles, states, properties, and events implemented by accessibility APIs and helps to ensure that this information appears in a manner consistent with author intent.
The HTML -AAM 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 is subject to change without notice.
This document was initially developed by and with the approval of the HTML Accessibility Taskforce , a joint task force of the Protocols and Formats Working Group and the HTML Working Group . Work continued with the successor groups Accessible Rich Internet Applications Working Group and the Web Applications Working Group . The document is now maintained solely by the Web Applications WG, formerly the Web Platform WG .
This document was published by the Web Applications Working Group as an Editor's Draft.
GitHub Issues are preferred for discussion of this specification. Alternatively, you can send comments to our mailing list. Please send them to public-webapps@w3.org ( archives ).
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 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 1 March 2019 W3C Process Document .
This section is non-normative.
This specification defines how HTML user agents respond to and expose role , state and property information provided for Web content. Unless indicated otherwise, an HTML element or attribute with default Accessible Rich Internet Applications (WAI-ARIA) 1.0 semantics must be exposed to the platform accessibility APIs according to the relevant WAI-ARIA mappings defined in the Core Accessibility API Mappings 1.2 ([ core-aam-1.2 ]) specification.
In some cases, often due to features of the HTML host language or the accessibility API in question, an element or attribute's mapping differs from the corresponding ARIA mappings specified in the [ core-aam-1.2 ]. Where an HTML element or attribute does not have any default WAI-ARIA semantics, the applicable mapping for each platform accessibility API is defined by this specification.
This document also adapts the Accessible Name and Description Computation 1.1 ([ accname-1.1 ]) for deriving the accessible names and accessible descriptions of [ HTML ] elements, and provides accessible implementation examples for specific HTML elements and features.
Users often access HTML content using assistive technologies that rely on platform accessibility API to obtain and interact with information from the page. This document is part of the following suite of accessibility API mapping specifications for content rendered by user agents:
Accessibility APIs covered by this document are:
If user agent developers need to expose information using other accessibility APIs , it is recommended that they work closely with the developer of the platform where the API runs, and assistive technology developers on that platform.
For more information regarding accessibility APIs , refer to section 1.1 Accessibility APIs of the Core Accessibility API Mappings 1.2 .
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.
The classification of a section as normative or non-normative applies to the entire section and all sub-sections of that section.
Normative sections provide requirements that authors, user agents, and assistive technologies MUST follow for an implementation to conform to this specification.
Non-normative 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.
There are currently no deprecated requirements.
While some terms are defined in place, the following definitions are used throughout this document.
Operating systems and other platforms provide a set of interfaces that expose information about objects and events to assistive technologies . Assistive technologies use these interfaces to get information about and interact with those widgets . Examples of accessibility APIs are Microsoft Active Accessibility [ MSAA ], Microsoft User Interface Automation [ UI-AUTOMATION ], MSAA with UIA Express [ UIA-EXPRESS ], the Mac OS X Accessibility Protocol [ AXAPI ], the Linux/Unix Accessibility Toolkit [ ATK ] and Assistive Technology Service Provider Interface [ AT-SPI ], and IAccessible2 [ IAccessible2 ].
An
accessible
object
in
the
accessibility
tree
and
its
descendants
in
that
tree.
It
does
not
include
objects
which
have
relationships
other
than
parent-child
in
that
tree.
For
example,
it
does
not
include
objects
linked
via
aria-flowto
unless
those
objects
are
also
descendants
in
the
accessibility
tree
.
Tree of accessible objects that represents the structure of the user interface ( UI ). Each node in the accessibility tree represents an element in the UI as exposed through the accessibility API ; for example, a push button, a check box, or container.
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.
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 API s or assistive technologies .
A node in the accessibility tree of a platform accessibility API . Accessible objects expose various states , properties , and events for use by assistive technologies . In the context of markup languages (e.g., HTML and SVG ) in general, and of WAI-ARIA in particular, markup elements and their attributes are represented as accessible objects.
The
action
taken
when
an
event
,
typically
initiated
by
users
through
an
input
device,
causes
an
element
to
fulfill
a
defined
role.
The
role
may
be
defined
for
that
element
by
the
host
language,
or
by
author-defined
variables,
or
both.
The
role
for
any
given
element
may
be
a
generic
action,
or
may
be
unique
to
that
element.
For
example,
the
activation
behavior
of
an
HTML
or
SVG
<a>
element
shall
be
to
cause
the
user
agent
to
traverse
the
link
specified
in
the
href
attribute,
with
the
further
optional
parameter
of
specifying
the
browsing
context
for
the
traversal
(such
as
the
current
window
or
tab,
a
named
window,
or
a
new
window);
the
activation
behavior
of
an
HTML
<input>
element
with
the
type
attribute
value
submit
shall
be
to
send
the
values
of
the
form
elements
to
an
author-defined
IRI
by
the
author-defined
HTTP
method.
Hardware and/or software that:
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:
In this specification, attribute is used as it is in markup languages. Attributes are structural features added to elements to provide information about the states and properties of the object represented by the element.
A set of instance objects that share similar characteristics.
A deprecated role , state , or property is one which has been outdated by newer constructs or changed circumstances, and which may be removed in future versions of the WAI-ARIA specification. User agents are encouraged to continue to support items identified as deprecated for backward compatibility. For more information, see Deprecated Requirements in the Conformance section.
Event from/to the host operating system via the accessibility API , notifying of a change of input focus.
In this specification, element is used as it is in markup languages. Elements are the structural elements in markup language that contains the data profile for objects .
A programmatic message used to communicate discrete changes in the state of an object to other objects in a computational system. User input to a web page is commonly mediated through abstract events that describe the interaction and can provide notice of changes to the state of a document object. In some programming languages, events are more commonly known as notifications.
Translated to platform-specific accessibility APIs as defined in the Core Accessibility API Mappings . [ CORE-AAM-1.1 ]
A document containing graphic representations with user-navigable parts. Charts, maps, diagrams, blueprints, and dashboards are examples of graphical documents. A graphical document is composed using any combination of symbols, images, text, and graphic primitives (shapes such as circles, points, lines, paths, rectangles, etc).
Indicates that the element is not visible, perceivable , or interactive to any user. An element is considered hidden if it or any one of its ancestor elements is not rendered or is explicitly hidden.
Content provided for information purposes and not required for conformance. Content required for conformance is referred to as normative .
Accessible to the user using a keyboard or assistive technologies that mimic keyboard input, such as a sip and puff tube. References in this document relate to WCAG 2.1 Guideline 2.1: Make all functionality available from a keyboard [ WCAG21 ].
A type of region on a page to which the user may want quick access. Content in such a region is different from that of other regions on the page and relevant to a specific user purpose, such as navigating, searching, perusing the primary content, etc.
Live regions are perceivable regions of a web page that are typically updated as a result of an external event when user focus may be elsewhere. These regions are not always updated as a result of a user interaction. This practice has become commonplace with the growing use of Ajax. Examples of live regions include a chat log, stock ticker, or a sport scoring section that updates periodically to reflect game statistics. Since these asynchronous areas are expected to update outside the user's area of focus, assistive technologies such as screen readers have either been unaware of their existence or unable to process them for the user. WAI-ARIA has provided a collection of properties that allow the author to identify these live regions and process them: aria-live, aria-relevant, aria-atomic, and aria-busy.
An
implementing
host
language's
primary
content
element,
such
as
the
body
element
in
HTML
.
Accessibility API state that is controlled by the user agent, such as focus and selection. These are contrasted with "unmanaged states" that are typically controlled by the author. Nevertheless, authors can override some managed states, such as aria-posinset and aria-setsize. Many managed states have corresponding CSS pseudo-classes, such as :focus, and pseudo-elements, such as ::selection, that are also updated by the user agent.
The Nemeth Braille Code for Mathematics is a braille code for encoding mathematical and scientific notation. See Nemeth Braille on Wikipedia .
Basic type of object in the DOM tree or accessibility tree . DOM nodes are further specified as Element or Text nodes , among other types. The nodes of an accessibility tree are accessible objects .
Required for conformance. By contrast, content identified as informative or "non-normative" is not required for conformance.
In the context of user interfaces, an item in the perceptual user experience, represented in markup languages by one or more elements , and rendered by user agents .
In the context of programming, the instantiation of one or more classes and interfaces which define the general characteristics of similar objects. An object in an accessibility API may represent one or more DOM objects. Accessibility APIs have defined interfaces that are distinct from DOM interfaces.A description of the characteristics of classes and how they relate to each other.
Usable by users in ways they can control. References in this document relate to WCAG 2.1 Principle 2: Content must be operable [ WCAG21 ]. See Keyboard Accessible .
An
'owned
element'
is
any
DOM
descendant
of
the
element
,
any
element
specified
as
a
child
via
aria-owns
,
or
any
DOM
descendant
of
the
owned
child.
An
'owning
element'
is
any
DOM
ancestor
of
the
element
,
or
any
element
with
an
aria-owns
attribute
which
references
the
ID
of
the
element.
Presentable to users in ways they can sense. References in this document relate to WCAG 2.1 Principle 1: Content must be perceivable [ WCAG21 ].
Attributes
that
are
essential
to
the
nature
of
a
given
object
,
or
that
represent
a
data
value
associated
with
the
object.
A
change
of
a
property
may
significantly
impact
the
meaning
or
presentation
of
an
object.
Certain
properties
(for
example,
aria-multiline
)
are
less
likely
to
change
than
states
,
but
note
that
the
frequency
of
change
difference
is
not
a
rule.
A
few
properties,
such
as
aria-activedescendant
,
aria-valuenow
,
and
aria-valuetext
are
expected
to
change
often.
See
clarification
of
states
versus
properties
.
A connection between two distinct things. Relationships may be of various types to indicate which object labels another, controls another, etc.
Main indicator of type. This semantic association allows tools to present and support interaction with the object in a manner that is consistent with user expectations about other objects of that type.
The
primary
element
containing
non-metadata
content.
In
many
languages,
this
is
the
document
element
but
in
HTML
,
it
is
the
<body>
.
The meaning of something as understood by a human, defined in a way that computers can process a representation of an object , such as elements and attributes , and reliably represent the object in a way that various humans will achieve a mutually consistent understanding of the object.
A state is a dynamic property expressing characteristics of an object that may change in response to user action or automated processes. States do not affect the essential nature of the object, but represent data associated with the object or user interaction possibilities. See clarification of states versus properties .
Any
document
created
from
a
<frame>
,
<iframe>
or
similar
mechanism.
A
sub-document
may
contain
a
document,
an
application
or
any
widget
such
as
a
calendar
pulled
in
from
another
server.
In
the
accessibility
tree
there
are
two
accessible
objects
for
this
situation—one
represents
the
<frame>
/
<iframe>
element
in
the
parent
document,
which
parents
a
single
accessible
object
child
representing
the
spawned
document
contents.
An
element
specified
in
a
WAI-ARIA
relation.
For
example,
in
<div
aria-controls=”elem1”>
,
where
“elem1”
is
the
ID
for
the
target
element.
A hierarchical definition of how the characteristics of various classes relate to each other, in which classes inherit the properties of superclasses in the hierarchy. A taxonomy can comprise part of the formal definition of an ontology .
Type of DOM node that represents the textual content of an attribute or an element . A Text node has no child nodes.
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.
Presentable to users in ways they can construct an appropriate meaning. References in this document relate to WCAG 2.1 Principle 3: Information and the operation of user interface must be understandable [ WCAG21 ].
Any software that retrieves, renders and facilitates end user interaction with Web content. This definition may differ from that used in other documents.
A reference to a target element in the same document that has a matching ID
Discrete user interface object with which the user can interact. Widgets range from simple objects that have one value or operation (e.g., check boxes and menu items), to complex objects that contain many managed sub-objects (e.g., trees and grids).
WAI-ARIA support was first introduced to HTML in [ HTML5 ].
Where an HTML element or attribute has default WAI-ARIA semantics, it MUST be exposed to the platform accessibility APIs in a way that conforms to General rules for exposing WAI-ARIA semantics in the Core Accessibility API Mappings 1.2 .
Where the host language is [ HTML ], user agents MUST conform to Conflicts between native markup semantics and WAI-ARIA in the Core Accessibility API Mappings 1.2 .
HTML may have features that are not supported by accessibility APIs at the time of publication. There is not a one to one relationship between all features and platform accessibility APIs . When HTML roles, states and properties do not directly map to an accessibility API , and there is a method in the API to expose a text string, user agents MUST expose the undefined role, states and properties via that method.
For HTML elements or attributes with default WAI-ARIA semantics, user agents MUST conform to Exposing attributes that do not directly map to accessibility API properties in the [ core-aam-1.2 ].
In MSAA , the value of an accessible object 's Role property is retrieved with the IAccessible::get_accRole method . This method returns a VARIANT that is limited to a finite number of integer role constants insufficient for describing the role of every HTML element, especially new elements introduced by HTML . To address this limitation, some user agents, e.g., Firefox and Chrome in cooperation with some screen readers, have elected to expose certain roles by returning a string value ( BSTR ) in that VARIANT in a way that is not described by the MSAA specification.
For
example,
Firefox
returns
the
element's
tag
name
as
a
BSTR
for
the
following:
abbr
,
address
,
aside
,
blockquote
,
canvas
,
caption
,
dd
,
div
,
figcaption
,
footer
,
form
,
h1
–
h6
,
header
,
iframe
,
input
type="file"
,
main
,
menu
,
nav
,
output
,
p
,
pre
,
q
,
section
,
time
.
Similarly,
Chrome
returns
the
element's
tag
name
for:
blockquote
,
div
,
dl
,
figcaption
,
form
,
h1
–
h6
,
menu
,
meter
,
p
,
pre
.
to do
Notes:
aria-roledescription
property
value
in
the
accessibility
tree
unless
the
element
has
an
explicit,
conforming
role
attribute
value.
label
element's
for
attribute,
or
a
descendant
of
a
label
element,
the
labelable
element's
UIA
LabeledBy
property
points
to
the
UIA
element
for
the
label
element.
Text
Control
Type
are
not
generally
represented
as
accessible
objects
in
the
accessibility
tree
,
but
are
just
part
of
the
Text
Control
Pattern
implemented
for
the
whole
HTML
document.
However,
if
they
have
any
aria-
attributes
or
an
explicit
tabindex
specified,
elements
mapped
to
the
Text
Control
Type
will
be
represented
as
accessible
objects
in
the
accessibility
tree
.
Notes:
The terms accessible name and accessible description are properties provided in all accessibility APIs . The name of the properties may differ across APIs but they serve the same function: as a container for a short (name) or longer (description) string of text.
The text alternative 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.
input
type="text"
,
input
type="password"
,
input
type="search"
,
input
type="tel"
,
input
type="url"
and
textarea
Element
input
type="text"
,
input
type="password"
,
input
type="search"
,
input
type="tel"
,
input
type="email"
,
input
type="url"
and
textarea
Element
Accessible
Name
Computation
aria-label
or
an
aria-labelledby
attribute
the
accessible
name
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
label
element(s)
accessible
name
(s)
-
if
more
than
one
label
is
associated;
concatenate
by
DOM
order,
delimited
by
spaces.
title
attribute.
placeholder
attribute.
input
type="text"
,
input
type="password"
,
input
type="search"
,
input
type="tel"
,
input
type="email"
,
input
type="url"
and
textarea
Element
Accessible
Description
Computation
aria-describedby
attribute
the
accessible
description
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
title
attribute
if
it
wasn't
used
as
the
accessible
name
.
input
type="image"
input
type="image"
Accessible
Name
Computation
aria-label
or
an
aria-labelledby
attribute
the
accessible
name
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
alt
attribute.
title
attribute.
input
type="image"
Accessible
Description
Computation
aria-describedby
attribute
the
accessible
description
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
title
attribute
if
it
wasn't
used
as
the
accessible
name
.
fieldset
and
legend
Elements
fieldset
Element
Accessible
Name
Computation
fieldset
element
has
an
aria-label
or
an
aria-labelledby
attribute
the
accessible
name
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
fieldset
element
has
a
child
that
is
a
legend
element,
then
use
the
subtree
of
the
first
such
element.
fieldset
element
has
a
title
attribute,
then
use
that
attribute.
fieldset
Element
Accessible
Description
Computation
fieldset
element
has
an
aria-describedby
attribute
the
accessible
description
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
title
attribute
if
it
wasn't
used
as
the
accessible
name
.
output
Element
output
Element
Accessible
Name
Computation
output
element
has
an
aria-label
or
an
aria-labelledby
attribute
the
accessible
name
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
output
element
subtree.
title
attribute.
output
Element
Accessible
Description
Computation
aria-describedby
.
title
attribute
if
it
wasn't
used
as
the
accessible
name
.
aria-label
or
an
aria-labelledby
attribute
the
accessible
name
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
label
element.
title
attribute.
aria-describedby
attribute
the
accessible
description
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
title
attribute
if
it
wasn't
used
as
the
accessible
name
.
summary
Element
summary
Element
Accessible
Name
Computation
summary
element,
which
is
a
direct
child
of
the
details
element,
has
an
aria-label
or
an
aria-labelledby
attribute
the
accessible
name
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
summary
element
subtree.
title
attribute.
summary
element
as
a
direct
child
of
the
details
element,
the
user
agent
should
provide
one
with
a
subtree
containing
a
localized
string
of
the
word
"details".
summary
element
as
a
direct
child
of
the
details
element,
but
none
of
the
above
yield
a
usable
text
string,
there
is
no
accessible
name
.
summary
Element
Accessible
Description
Computation
aria-describedby
attribute
the
accessible
description
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
summary
element
subtree
if
not
used
as
the
accessible
name
.
title
attribute
if
it
wasn't
used
as
the
accessible
name
.
figure
and
figcaption
Elements
figure
Element
Accessible
Name
Computation
figure
element
has
an
aria-label
or
an
aria-labelledby
attribute
the
accessible
name
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
figure
element
has
a
child
that
is
a
figcaption
element,
then
use
the
subtree
of
the
first
such
element.
figure
element
has
a
title
attribute,
then
use
that
attribute.
figure
Element
Accessible
Description
Computation
aria-describedby
attribute
the
accessible
description
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
title
attribute
if
it
wasn't
used
as
the
accessible
name
.
img
Element
img
Element
Accessible
Name
Computation
img
element
has
an
aria-label
or
an
aria-labelledby
attribute
the
accessible
name
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
alt
attribute.
title
attribute.
img
Element
Accessible
Description
Computation
aria-describedby
attribute
the
accessible
description
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
title
attribute
if
it
wasn't
used
as
the
accessible
name
.
table
Element
table
Element
Accessible
Name
Computation
aria-label
or
an
aria-labelledby
attribute
the
accessible
name
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
table
element
has
a
child
that
is
a
caption
element,
then
use
the
subtree
of
the
first
such
element.
table
element
has
a
title
attribute,
then
use
that
attribute.
table
Element
Accessible
Description
Computation
aria-describedby
attribute
the
accessible
description
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
table
element
has
a
child
that
is
a
caption
element
and
it
wasn't
used
as
the
accessible
name
,
then
use
the
subtree
of
the
first
such
element.
table
element
has
a
title
attribute
and
it
wasn't
used
as
the
accessible
name
,
then
use
that
attribute.
tr
,
td
,
th
Elements
Accessible
Name
Computation
aria-label
or
an
aria-labelledby
attribute
the
accessible
name
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
title
attribute.
tr
,
td
,
th
Elements
Accessible
Description
Computation
aria-describedby
attribute
the
accessible
description
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
title
attribute
if
it
wasn't
used
as
the
accessible
name
.
a
Element
a
Element
Accessible
Name
Computation
a
element
has
an
aria-label
or
an
aria-labelledby
attribute
the
accessible
name
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
a
element
subtree.
title
attribute.
a
Element
Accessible
Description
Computation
aria-describedby
attribute
the
accessible
description
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
title
attribute
if
it
wasn't
used
as
the
accessible
name
.
area
Element
area
Element
Accessible
Name
Computation
area
element
has
an
aria-label
or
an
aria-labelledby
attribute
the
accessible
name
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
area
element's
alt
attribute.
title
attribute.
area
Element
Accessible
Description
Computation
aria-describedby
attribute
the
accessible
description
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
title
attribute
if
it
wasn't
used
as
the
accessible
name
.
iframe
Element
iframe
Element
Accessible
Name
Computation
aria-label
or
an
aria-labelledby
attribute
the
accessible
name
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
title
attribute.
The
document
referenced
by
the
src
of
the
iframe
element
gets
its
name
from
that
document's
title
element,
like
any
other
document.
If
there
is
no
title
provided,
there
is
no
accessible
name.
iframe
Element
Accessible
Description
Computation
aria-describedby
attribute
the
accessible
description
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
title
attribute
if
it
wasn't
used
as
the
accessible
name
.
aria-label
or
an
aria-labelledby
attribute
the
accessible
name
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
title
attribute.
aria-describedby
attribute
the
accessible
description
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
title
attribute
if
it
wasn't
used
as
the
accessible
name
.
abbr
,
b
,
bdi
,
bdo
,
br
,
cite
,
code
,
dfn
,
em
,
i
,
kbd
,
mark
,
q
,
rp
,
rt
,
ruby
,
s
,
samp
,
small
,
strong
,
sub
and
sup
,
time
,
u
,
var
,
wbr
aria-label
or
an
aria-labelledby
attribute
the
accessible
name
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
title
attribute.
aria-describedby
attribute
the
accessible
description
is
to
be
calculated
using
the
algorithm
defined
in
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
.
title
attribute
if
it
wasn't
used
as
the
accessible
name
.
This section is non-normative.
summary
and
details
Elements
The
summary
element
should
be
focusable
by
default.
The
details
element
should
not
be
focusable
by
default.
Pressing
the
spacebar
or
enter
keys
when
the
summary
element
has
focus
will
show
the
details
element
content
if
the
content
was
hidden.
If
the
details
element
content
was
showing
and
the
summary
element
has
focus,
pressing
the
spacebar
or
enter
keys
will
hide
the
details
element
content.
The
summary
element
should
be
mapped
to
a
disclosure
triangle
role
in
accessibility
APIs
that
have
such
a
role.
For
example
the
Mac
accessibility
API
includes
the
AXDisclosureTriangle
role.
In
accessibility
APIs
that
do
not
have
such
a
fine
grained
role,
the
summary
element
should
be
mapped
to
a
button
role.
The
role
mapping
table
contains
recommended
mappings
for
the
summary
element
.
The
default
accessible
name
for
the
summary
element
is
the
text
content
of
the
summary
element.
When
the
details
element
content
is
hidden,
the
state
of
the
content
should
be
reflected
by
an
accessible
state
or
property.
Example
1:
In
the
Mac
accessibility
API
on
the
summary
element
(
AXDisclosureTriangle
),
set
AXExpanded
property
to
NO
.
When
the
details
element
content
is
shown,
on
the
summary
element
(
AXDisclosureTriangle
),
set
the
AXExpanded
property
to
YES
.
The
hidden
and
shown
states
of
the
details
element
content
is
reflected
by
the
absence
or
presence
of
the
open
attribute.
Example
2:
In
the
IA2
accessibility
API
on
the
summary
element
(
ROLE_SYSTEM_PUSHBUTTON
),
set
STATE_SYSTEM_COLLAPSED
.
When
the
details
element
content
is
shown,
on
the
summary
element
(
ROLE_SYSTEM_PUSHBUTTON
),
set
STATE_SYSTEM_EXPANDED
.
The
hidden
and
shown
states
of
the
details
element
content
is
reflected
by
the
absence
or
presence
of
the
open
attribute.
figure
and
figcaption
Elements
to do
high
,
low
,
max
,
min
,
and
meter
and
progress
's
value
attribute.
See
GitHub
pull
request
#244
.
mark
element's
UIA
LocalizedControlType
and
AX
AXRoleDescription
.
See
GitHub
issue
summary
and
details
elements.
See
GitHub
issue
#142
and
GitHub
issue
#147
.
sub
and
sup
.
See
GitHub
pull
request
#252
.
menu
to
match
HTML
Living
Standard
.
Remove
element
and
attribute
mappings
that
are
not
applicable
to
menu
and
menuitem
.
Update
mapping
of
menu
to
role="list"
.
See
GitHub
issue
#188
.
ins
and
del
elements.
See
GitHub
pull
request
#219
.
ins
and
del
elements.
See
GitHub
issue
#141
.
header
and
footer
when
not
scoped
to
the
body
.
See
GitHub
issue
#129
.
map
element.
Add
accessible
name
and
description
computation
for
area
.
See
GitHub
issue
#176
.
sub
and
sup
elements.
See
Pull
request
#177
.
sup
and
sub
elements.
See
GitHub
issue
#174
.
address
element.
See
GitHub
issue
#170
.
placeholder
attribute
to
accessible
name
computation
for
various
input
elements.
See
GitHub
issue
#167
.
rb
and
rtc
elements,
and
updated
AXAPI
mappings
for
the
rb
,
rt
and
ruby
elements.
See
GitHub
issue
#115
.
svg
element.
See
GitHub
issue
#43
.
del
and
ins
elements,
and
the
datetime
attribute.
header
and
footer
when
scoped
to
body
,
aside
,
and
output
.
See
GitHub
issue
#119
.
multiple
attribute
on
input
element.
See
GitHub
issue
#96
.
sub
and
sup
elements.
See
GitHub
issue
#121
.
body
element.
See
GitHub
issue
#117
.
meter
element.
See
GitHub
issue
#2
.
address
element.
See
GitHub
issue
#33
.
dt
element.
See
GitHub
issue
#78
.
mark
element.
input
element
with
the
type
attribute
in
the
Color
state.
See
GitHub
issue
#48
.
pre
,
q
,
and
ruby
elements,
and
the
multiple
attribute
for
the
input
element.
See
GitHub
issue
#94
.
readonly
attribute
to
use
aria-readonly="true"
WAI-ARIA
mappings.
See
GitHub
issue
#93
.
canvas
element
from
AXImage
to
AXGroup
.
dfn
element.
See
GitHub
issue
#6
.
meter
element.
See
GitHub
issue
#2
.
audio
and
video
elements.
See
GitHub
issue
#80
.
figure
element
mappings
to
reflect
the
WAI-ARIA
figure
role
mappings
.
form
element
based
on
presence
of
accessible
name
.
See
GitHub
issue
#106
.
img
element's
title
attribute
when
the
element's
alt
attribute
is
empty.
See
GitHub
issue
#99
.
aria-roledescription
unless
element
also
a
conforming
role
attribute
value.
See
GitHub
issue
#98
.
type
attribute
on
the
ol
element.
See
GitHub
issue
#91
.
title
attribute
on
abbr
element,
and
abbr
attribute
on
th
element.
See
GitHub
issue
#16
.
hidden
attribute.
See
GitHub
issue
#38
.
selected
attribute.
See
GitHub
issue
#92
.
time
element.
See
GitHub
issue
#88
.
lang
and
dir
attributes.
See
GitHub
issue
#19
.
colspan
and
rowspan
attributes.
See
GitHub
issue
#56
and
issue
#57
.
section
element.
See
GitHub
issue
#79
.
datalist
element
if
not
linked
with
input
element.
See
GitHub
issue
#26
.
list
attribute.
See
GitHub
issue
#21
.
footer
and
header
elements.
See
GitHub
issue
#59
.
input@type='date'
attribute.
See
GitHub
issue
#61
.
input@type='file'
element.
See
GitHub
issue
#62
.
summary
element.
See
GitHub
issue
#64
.
header
and
footer
elements
are
or
are
not
ARIA
landmarks.
See
GitHub
issue
#65
.
aria-multiselectable
mapping
for
datalist
to
reflect
listbox
selection
model.
See
GitHub
issue
#71
.
multiple
attribute
on
input
and
select
elements.
See
GitHub
issue
#72
.
checked
,
contenteditable
,
disabled
,
and
indeterminate
attributes.
placeholder
attribute
from
accessible
description
computation
for
various
input
elements.
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.