This
document
describes
how
user
agents
should
expose
semantics
of
web
content
languages
to
accessibility
APIs
.
This
helps
users
with
disabilities
to
obtain
and
interact
with
information
using
assistive
technologies
.
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.
This
Core
Accessibility
API
Mappings
specification
defines
support
that
applies
across
multiple
content
technologies,
including
general
keyboard
navigation
support
and
mapping
of
general-purpose
roles
,
states,
and
properties
provided
in
Web
content
via
WAI-ARIA
[
WAI-ARIA-1.2
].
Other
Accessibility
API
Mappings
specifications
depend
on
and
extend
this
Core
specification
for
specific
technologies,
including
native
technology
features
and
WAI-ARIA
extensions.
This
document
updates
and
will
eventually
supersede
the
guidance
in
the
Core
Accessibility
API
Mappings
1.1
[
CORE-AAM-1.1
]
W3C
Recommendation.
It
is
part
of
the
WAI-ARIA
suite
described
in
the
WAI-ARIA
Overview
.
Status
of
This
Document
This
is
a
preview
Do
not
attempt
to
implement
this
version
of
the
specification.
Do
not
reference
this
version
as
authoritative
in
any
way.
Instead,
see
https://w3c.github.io/core-aam/
for
the
Editor's
draft.
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
a
Candidate
Recommendation
does
not
imply
endorsement
by
W3C
and
its
Members.
A
Candidate
Recommendation
Draft
integrates
changes
from
the
previous
Candidate
Recommendation
that
the
Working
Group
intends
to
include
in
a
subsequent
Candidate
Recommendation
Snapshot.
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.
The
Core
Accessibility
API
Mappings
specifies
how
WAI-ARIA
roles
,
states
,
and
properties
are
expected
to
be
exposed
by
user
agents
via
platform
accessibility
APIs
.
It
is
part
of
a
set
of
resources
that
define
and
support
the
WAI-ARIA
specification
which
includes
the
following
documents:
WAI-ARIA
Authoring
Practices
Guide
[
WAI-ARIA-PRACTICES-1.2
],
a
planned
W3C
Working
Group
Note,
describes
how
web
content
developers
can
develop
accessible
rich
internet
applications
using
WAI-ARIA
.
It
provides
detailed
advice
and
examples
directed
primarily
to
web
application
developers,
yet
also
useful
to
user
agent
and
developers
of
assistive
technologies.
Accessibility
APIs
make
it
possible
to
communicate
accessibility
information
about
user
interfaces
to
assistive
technologies.
This
information
includes:
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.
1.2
Comparing
Accessibility
APIs
For
various
technological
and
historical
reasons,
accessibility
APIs
do
not
all
work
in
the
same
way.
In
many
cases,
there
is
no
simple
one-to-one
relationship
between
how
each
of
them
names
or
exposes
roles,
states,
and
properties
to
assistive
technologies.
The
following
subsections
describe
a
few
of
the
distinguishing
characteristics
of
some
of
the
APIs
.
1.2.1
ATK
/
AT
-SPI
MSAA
,
IAccessible2,
UIA
,
and
AX
API
each
define
an
API
that
is
shared
by
both
the
software
application
exposing
information
about
its
content
and
interactive
components,
and
the
assistive
technology
consuming
that
information.
Conversely,
Linux/GNOME
separates
that
shared
interface
into
its
two
aspects,
each
represented
by
a
different
accessibility
API
:
ATK
or
AT
-SPI.
ATK
defines
an
interface
that
is
implemented
by
software
in
order
to
expose
accessibility
information,
whereas
AT
-SPI
is
a
desktop
service
that
gathers
accessibility
information
from
active
applications
and
relays
it
to
other
interested
applications,
usually
assistive
technologies.
For
example,
the
GNOME
GUI
toolkit
[GTK],
implements
the
relevant
aspects
of
ATK
for
each
widget
(menu,
combobox,
checkbox,
etc.)
in
order
that
GTK
widgets
expose
accessibility
information
about
themselves.
AT
-SPI
then
acquires
the
information
from
applications
built
with
GTK
and
makes
it
available
to
interested
parties.
ATK
is
most
relevant
to
implementors,
whereas
AT
-SPI
is
relevant
to
consumers.
In
the
context
of
mapping
WAI-ARIA
roles,
states
and
properties,
user
agents
are
implementors
and
use
ATK
.
Assistive
Technologies
are
consumers,
and
use
AT
-SPI.
1.2.2
UIA
(UI
Automation)
UI
Automation
expresses
every
element
of
the
application
user
interface
as
an
automation
element.
Automation
elements
form
the
nodes
of
the
application
accessibility
tree,
that
can
be
queried,
traversed
and
interacted
with
by
automation
clients.
There
are
several
concepts
central
to
UI
Automation:
Automation
element
-
controls
and
some
application
content
are
presented
as
automation
elements.
Element
properties
-
Automation
elements
have
several
common
properties
describing
native
framework
element
characteristics
in
an
agnostic
way
that
all
automation
clients
can
understand.
There
are
several
ways
to
access
element
property
values,
described
below.
Control
Patterns
-
Some
common
interactivity
in
different
frameworks
is
expressed
as
control
patterns
in
UIA
,
allowing
different
automation
clients
to
interact
with
controls
using
common
programmatic
interfaces.
Events
-
Similar
to
other
accessibility
APIs
,
automation
elements
support
various
events
that
allow
automation
providers
to
notify
clients
on
important
state
changes.
All
automation
elements
inherit
from
the
IUIAutomationElement
interface
and
all
properties
that
are
not
specific
to
a
particular
control
pattern
can
be
queried
through
that
interface.
There
are
several
ways
to
access
UI
Automation
element
properties:
Direct
property
accessors
to
the
current
values
-
Current{PropertyName}
,
e.g.
IUIAutomationElement::CurrentName
for
the
Name
property
Cached
property
accessors
-
Cached{PropertyName}
,
e.g.
IUIAutomationElement::CachedName
for
the
Name
property.
Using
cached
values
is
preferred
when
providers
and
clients
are
used
in
remote
environments.
GetCurrentPropertyValue
and
passing
the
UIA
Property
ID
enumeration
value
corresponding
to
that
property
to
get
the
current
value,
e.g.
IUIAutomationElement::GetCurrentPropertyValue(UIA_NamePropertyId)
for
the
Name
property.
GetCachedPropertyValue
and
passing
the
UIA
Property
ID
enumeration
value
corresponding
to
that
property
to
get
the
cached
value,
e.g.
IUIAutomationElement::GetCachedPropertyValue(UIA_NamePropertyId)
for
the
Name
property.
Properties
for
specific
UIA
control
patterns
are
queried
the
same
way
using
relevant
control
pattern
interfaces.
Taking
Toggle
Pattern
as
an
example,
to
query
the
ToggleState
property
clients
can
use
IUIAutomationTogglePattern::CurrentToggleState
or
IUIAutomationTogglePattern::GetCurrentPropertyValue(UIA_ToggleToggleStatePropertyId)
to
get
the
current
value.
The
property
mappings
in
this
specification
provide
the
{PropertyName}
and
do
not
specify
all
specific
ways
to
access
the
property
value.
Automation
clients
can
access
current
or
cached
values
using
conventions
described
above,
depending
on
specific
needs
and
coding
style
conventions.
For
instance,
in
MSAA
,
all
accessible
objects
support
the
accName
property,
which
stores
the
object's
accessible
name
.
Where
the
object
also
supports
having
an
accessible
description
,
MSAA
stores
this
property
in
the
object's
accDescription
property.
Software
using
ATK
can
read
and
write
to
an
object's
accessible-name
and
accessible-description
properties.
In
turn,
AT
-SPI
can
query
the
values
of
those
properties
through
its
atspi_accessible_get_name
and
atspi_accessible_get_description
functions.
Automation
elements
in
the
UIA
accessibility
tree
have
a
Name
property.
Where
the
object
also
supports
having
an
accessible
description
,
UIA
stores
this
property
in
the
object's
FullDescription
property.
The
approach
to
accessible
names
and
accessible
descriptions
in
AX
API
is
somewhat
different
to
the
other
platform
APIs
.
Accessible
names
are
exposed
using
the
AXTitle
property
when
the
name
is
visually
rendered,
while
the
AXDescription
property
is
used
when
the
object's
name
is
not
rendered
visually.
An
object's
accessible
description
,
where
provided
by
aria-description
or
aria-describedby
,
should
be
exposed
in
the
accessibilityCustomContent
API
.
Otherwise,
it
should
be
exposed
as
AXHelp
.
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
,
MUST
NOT
,
SHOULD
,
and
SHOULD
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.
2.1
RFC-2119
Keywords
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.
2.2
Normative
and
Informative
Sections
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.
2.3
Features
Deprecated
in
WAI-ARIA
The
WAI-ARIA
specification
lists
some
features
as
deprecated
.
Although
this
means
authors
are
encouraged
not
to
use
such
features,
it
is
expected
that
the
features
could
still
be
used
in
legacy
content.
Therefore,
it
is
important
that
user
agents
continue
to
map
these
features
to
accessibility
APIs
,
and
doing
so
is
part
of
conformance
to
this
specification.
When
future
versions
of
the
WAI-ARIA
specification
change
such
features
from
deprecated
to
removed,
they
will
be
removed
from
the
mappings
as
well
and
user
agents
will
no
longer
be
asked
to
continue
support
for
those
features.
3.
Important
Terms
This
section
is
non-normative.
While
some
terms
are
defined
in
place,
the
following
definitions
are
used
throughout
this
document.
Accessibility
Subtree
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
.
Activation
behavior
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.
4.
Mapping
WAI-ARIA
to
Accessibility
APIs
4.1
General
rules
for
exposing
WAI-ARIA
semantics
Where
supported
by
the
platform
Accessibility
API
,
user
agents
expose
WAI-ARIA
semantics
through
the
standard
mechanisms
of
the
desktop
accessibility
API
.
For
example,
for
WAI-ARIA
widgets
,
compare
how
the
widget
is
exposed
in
a
similar
desktop
widget.
In
general
most
WAI-ARIA
widget
capabilities
are
exposed
through
the
role
,
value,
Boolean
states
,
and
relations
of
the
accessibility
API
.
With
respect
to
WAI-ARIA
1.0
and
1.1,
accessibility
APIs
operate
in
one
direction
only.
User
agents
publish
WAI-ARIA
information
(roles,
states,
and
properties)
via
an
accessibility
API
,
and
an
AT
can
acquire
that
information
using
the
same
API
.
However,
the
other
direction
is
not
supported.
WAI-ARIA
1.0
and
1.1
do
not
define
mechanisms
for
assistive
technologies
to
directly
modify
WAI-ARIA
information.
4.2
Conflicts
between
native
markup
semantics
and
WAI-ARIA
WAI-ARIA
roles,
states,
and
properties
are
intended
to
add
semantic
information
when
native
host
language
elements
with
these
semantics
are
not
available,
and
are
generally
used
on
elements
that
have
no
native
semantics
of
their
own.
They
can
also
be
used
on
elements
that
have
similar
but
not
identical
semantics
to
the
intended
object
(for
instance,
a
nested
list
could
be
used
to
represent
a
tree
structure).
This
method
can
be
part
of
a
fallback
strategy
for
older
browsers
that
have
no
WAI-ARIA
implementation,
or
because
native
presentation
of
the
repurposed
element
reduces
the
amount
of
style
and/or
script
needed.
Except
for
the
cases
outlined
below,
user
agents
MUST
always
use
the
WAI-ARIA
semantics
to
define
how
it
exposes
the
element
to
accessibility
APIs
,
rather
than
using
the
host
language
semantics.
Host
languages
can
have
features
that
have
implicit
WAI-ARIA
semantics
corresponding
to
roles
.
When
a
WAI-ARIA
role
is
provided
that
has
a
corresponding
role
in
the
accessibility
API
,
user
agents
MUST
use
the
semantic
of
the
WAI-ARIA
role
for
processing,
not
the
native
semantic,
unless
the
role
requires
WAI-ARIA
states
and
properties
whose
attributes
are
explicitly
forbidden
on
the
native
element
by
the
host
language.
Values
for
roles
do
not
conflict
in
the
same
way
as
values
for
states
and
properties,
and
because
authors
are
expected
to
have
a
valid
reason
to
provide
a
WAI-ARIA
role
even
on
elements
that
would
not
normally
be
repurposed.
For
example,
spin
buttons
are
typically
constructed
from
text
fields
(
<input
type="text">
)
in
order
to
get
most
of
the
default
keyboard
support.
But,
the
native
role,
"text
field",
is
not
correct
because
it
does
not
properly
communicate
the
additional
features
of
a
spin
button.
The
author
adds
the
WAI-ARIA
role
of
spinbutton
(
<input
type="text"
role="spinbutton"
...>
)
so
that
the
control
is
properly
mapped
in
the
accessibility
API
.
When
a
WAI-ARIA
role
is
provided
that
does
not
have
a
corresponding
role
in
the
accessibility
API
,
user
agents
MAY
expose
the
native
semantic
in
addition
to
the
WAI-ARIA
role.
If
the
host
language
element
is
overridden
by
a
WAI-ARIA
role
whose
semantics
or
structure
is
not
equivalent
to
the
native
host
language
semantics
or
to
a
subclass
of
those
semantics,
then
treat
any
child
elements
having
roles
specified
as
Allowed
Accessibility
Child
Roles
as
having
presentation
or
none
.
Note
The
above
text
differs
slightly
from
the
WAI-ARIA
specification.
The
requirement
for
user
agents
to
expose
the
WAI-ARIA
role
instead
of
the
native
role
was
intended
to
only
apply
in
cases
where
there
is
a
direct
mapping
from
the
WAI-ARIA
role
to
a
corresponding
role
in
the
accessibility
API
.
The
wording
of
the
requirement
is
not
clear
in
the
WAI-ARIA
specification,
however,
and
has
been
interpreted
differently
by
implementers.
The
requirement
has
been
clarified
here
and
an
additional
statement
added
to
indicate
that
user
agents
may
expose
native
semantics
if
there
is
not
a
direct
mapping
to
a
role
in
the
accessibility
API
.
Because
there
are
differing
implementations,
authors
will
be
advised
against
adding
such
WAI-ARIA
roles
to
native
elements
that
have
their
own
semantics
in
the
WAI-ARIA
Authoring
Practices
Guide.
When
WAI-ARIA
states
and
properties
correspond
to
host
language
features
that
have
the
same
implicit
WAI-ARIA
semantic,
it
can
be
problematic
if
the
values
become
out
of
sync.
For
example,
the
HTML
checked
attribute
and
the
aria-checked
attribute
could
have
conflicting
values.
Therefore
to
prevent
providing
conflicting
states
and
properties
to
assistive
technologies,
host
languages
will
explicitly
declare
where
the
use
of
WAI-ARIA
attributes
on
a
host
language
element
conflict
with
native
attributes
for
that
element.
When
a
host
language
declares
a
WAI-ARIA
attribute
to
be
in
direct
semantic
conflict
with
a
native
attribute
for
a
given
element,
user
agents
MUST
ignore
the
WAI-ARIA
attribute
and
instead
use
the
host
language
attribute
with
the
same
implicit
semantic.
Host
languages
might
also
document
features
that
cannot
be
overridden
with
WAI-ARIA
(these
are
called
"strong
native
semantics").
These
can
be
features
that
have
implicit
WAI-ARIA
semantics
as
well
as
features
where
the
processing
would
be
uncertain
if
the
semantics
were
changed
with
WAI-ARIA
.
While
conformance
checkers
might
signal
an
error
or
warning
when
a
WAI-ARIA
role
is
used
on
elements
with
strong
native
semantics,
user
agents
MUST
still
use
the
value
of
the
semantic
of
the
WAI-ARIA
role
when
exposing
the
element
to
accessibility
APIs
.
4.3
Exposing
attributes
that
do
not
directly
map
to
accessibility
API
properties
Platform
accessibility
APIs
might
have
features
that
are
not
in
WAI-ARIA
.
Likewise,
WAI-ARIA
exposes
capabilities
that
are
not
supported
by
accessibility
APIs
at
the
time
of
publication.
There
typically
is
not
a
one
to
one
relationship
between
all
WAI-ARIA
attributes
and
platform
accessibility
APIs
.
When
WAI-ARIA
roles
,
states
and
properties
do
not
directly
map
to
an
accessibility
API
,
and
there
is
a
mechanism
in
the
API
to
expose
the
WAI-ARIA
role,
states,
and
properties
and
their
values,
user
agents
MUST
expose
the
WAI-ARIA
data
using
that
mechanism
as
follows:
In
IAccessible2
and
ATK
/
AT-SPI
,
use
object
attributes
to
expose
semantics
that
are
not
directly
supported
in
the
APIs
.
Object
attributes
are
name-value
pairs
that
are
loosely
specified,
and
very
flexible
for
exposing
things
where
there
is
no
specific
interface
in
an
accessibility
API
.
For
example,
at
this
time,
the
aria-live
attribute
can
be
exposed
via
an
object
attribute
because
accessibility
APIs
have
no
such
property
available.
Specific
rules
for
exposing
object
attribute
name-value
pairs
are
described
throughout
this
document,
and
rules
for
the
general
cases
are
in
State
and
Property
Mapping
.
In
Microsoft
UIA
,
use
the
AriaRole
and
AriaProperties
properties
to
expose
semantics
that
are
not
directly
supported
in
the
control
type.
Note
MSAA
does
not
provide
a
mechanism
for
exposing
attributes
that
do
not
map
directly
to
the
API
and
among
implementers,
there
is
no
agreement
on
how
to
do
it.
User
agents
MUST
also
expose
the
entire
role
string
through
this
mechanism
and
MAY
also
expose
WAI-ARIA
attributes
and
values
through
this
mechanism
even
when
there
is
a
direct
mapping
to
an
accessibility
API
.
Browser
implementers
are
advised
to
publicly
document
their
API
methods
for
exposing
any
relevant
information,
so
that
assistive
technology
developers
can
use
the
API
to
support
user
features.
4.4
Role
mapping
Platform
accessibility
APIs
traditionally
have
had
a
finite
set
of
predefined
roles
that
are
expected
by
assistive
technologies
on
that
platform
and
only
one
or
two
roles
may
be
exposed.
In
contrast,
WAI-ARIA
allows
multiple
roles
to
be
specified
as
an
ordered
set
of
space-separated
valid
role
tokens.
The
additional
roles
are
fallback
roles
similar
to
the
concept
of
specifying
multiple
fonts
in
case
the
first
choice
font
type
is
not
supported.
4.4.1
General
rules
User
agents
MUST
expose
the
WAI-ARIA
role
string
if
the
API
supports
a
mechanism
to
do
so.
This
allows
assistive
technologies
to
do
their
own
additional
processing
of
roles.
MSAA
:
not
supported
.
User
agents
SHOULD
NOT
expose
a
custom
role
in
MSAA
's
accRole
property.
IAccessible2:
expose
as
an
object
attribute
pair
(
xml-roles:"string"
)
UIA
:
expose
as
AriaRole
property.
The
AriaRole
property
can
also
support
secondary
roles
using
a
space
as
a
separator.
ATK
/
AT-SPI
:
expose
as
an
object
attribute
pair
(
xml-roles:"string"
)
4.4.2
Computed
Role
The
computedrole
of
an
element
is
a
string
that
represents
the
role
of
the
element
as
computed
by
the
browser
engine.
The
computedrole
is
used
primarily
for
the
purposes
of
developer
tools
and
specification
comformance
and
interoperability
testing.
When
an
element
has
a
role
but
is
not
contained
in
the
required
context
(for
example,
an
orphaned
listitem
without
the
required
accessible
parent
of
role
list
),
User
Agents
MUST
ignore
the
role
token,
and
return
the
computedrole
as
if
the
ignored
role
token
had
not
been
included.
When
host
language
elements
do
not
have
an
exact
or
equivalent
mapping
to
a
valid,
non-abstract
role,
the
related
Accessibilty
API
Mapping
extension
specification
MAY
specify
a
unique
computedrole
string
as
the
return
value
for
interoperability
testing
purposes,
such
as
<video>
->
"html-video"
in
[
HTML-AAM
].
However,
authors
MUST
NOT
use
any
host-language-prefixed
computedrole
string
in
the
role
attribute
(such
as
html-video
),
unless
the
token
also
matches
valid,
defined
role
(such
as
dpub-chapter
).
User
Agents
MUST
ignore
any
abstract
or
invalid
role
token.
Role:
ROLE_SYSTEM_ALERT
Event:
The
user
agent
SHOULD
fire
EVENT_SYSTEM_ALERT
.
[
Note
2
]
UIA
Control
Type:
Group
Localized
Control
Type:
alert
LiveSetting:
Assertive
(2)
Event:
The
user
agent
SHOULD
fire
a
system
alert
LiveRegionChanged
event
.
[
Note
2
]
ATK
/
AT-SPI
Role:
ROLE_NOTIFICATION
Event:
The
user
agent
SHOULD
fire
a
system
alert
event
.
[
Note
2
]
AXRole:
AXGroup
AXSubrole:
AXDeleteStyleGroup
AXAttributedStringForTextMarkerRange:
contains
AXIsSuggestedDeletion
=
1;
for
all
text
contained
in
a
deletion
Because
WAI-ARIA
does
not
support
modifying
the
selection
via
the
accessibility
API
,
user
agents
MUST
return
false
for
all
Selection
methods
that
provide
a
means
to
modify
the
selection.
AXRole:
AXTable
AXSubrole:
<nil>
AXColumnHeaderUIElements:
a
list
of
pointers
to
the
columnheader
elements
AXHeader:
a
pointer
to
the
row
or
group
containing
those
columnheader
elements
AXRowHeaderUIElements:
a
list
of
pointers
to
the
rowheader
elements
Control
Type:
DataItem
Localized
Control
Type:
item
Control
Pattern:
SelectionItem
Control
Pattern:
GridItem
Control
Pattern:
TableItem
SelectionItem.SelectionContainer:
the
containing
grid
AXRole:
AXGroup
AXSubrole:
AXInsertStyleGroup
AXAttributedStringForTextMarkerRange:
contains
AXIsSuggestedInsertion
=
1;
for
all
text
contained
in
a
insertion
Because
WAI-ARIA
does
not
support
modifying
the
selection
via
the
accessibility
API
,
user
agents
MUST
return
false
for
all
Selection
methods
that
provide
a
means
to
modify
the
selection.
Because
WAI-ARIA
does
not
support
modifying
the
selection
via
the
accessibility
API
,
user
agents
MUST
return
false
for
all
Selection
methods
that
provide
a
means
to
modify
the
selection.
Because
WAI-ARIA
does
not
support
modifying
the
selection
via
the
accessibility
API
,
user
agents
MUST
return
false
for
all
Selection
methods
that
provide
a
means
to
modify
the
selection.
Because
WAI-ARIA
does
not
support
modifying
the
selection
via
the
accessibility
API
,
user
agents
MUST
return
false
for
all
Selection
methods
that
provide
a
means
to
modify
the
selection.
For
objects
that
have
specified
allowed
accessibility
children
(e.g.,
a
grid
with
gridcell
children,
a
list
with
listitem
children),
and
the
descendant
is
in
the
accessibility
tree
,
expose
it
as
IA2_ROLE_TEXT_FRAME
.
user
agents
SHOULD
prune
empty
descendants
from
the
accessibility
tree
.
UIA
For
objects
that
have
specified
allowed
accessibility
children
(e.g.,
a
grid
with
gridcell
children,
a
list
with
listitem
children),
and
the
descendant
is
in
the
accessibility
tree
,
expose
it
using
the
text
pattern.
user
agents
SHOULD
prune
empty
descendants
from
the
accessibility
tree
.
ATK
/
AT-SPI
For
objects
that
have
specified
allowed
accessibility
children
(e.g.,
a
grid
with
gridcell
children,
a
list
with
listitem
children),
and
the
descendant
is
in
the
accessibility
tree
,
expose
it
as
ROLE_SECTION
.
user
agents
SHOULD
prune
empty
descendants
from
the
accessibility
tree
.
For
objects
that
have
specified
allowed
accessibility
children
(e.g.,
a
grid
with
gridcell
children,
a
list
with
listitem
children),
and
the
descendant
is
in
the
accessibility
tree
,
expose
it
as
AXGroup
.
user
agents
SHOULD
prune
empty
descendants
from
the
accessibility
tree
.
For
objects
that
have
specified
allowed
accessibility
children
(e.g.,
a
grid
with
gridcell
children,
a
list
with
listitem
children),
and
the
descendant
is
in
the
accessibility
tree
,
expose
it
as
IA2_ROLE_TEXT_FRAME
.
user
agents
SHOULD
prune
empty
descendants
from
the
accessibility
tree
.
UIA
For
objects
that
have
specified
allowed
accessibility
children
(e.g.,
a
grid
with
gridcell
children,
a
list
with
listitem
children),
and
the
descendant
is
in
the
accessibility
tree
,
expose
it
using
the
text
pattern.
user
agents
SHOULD
prune
empty
descendants
from
the
accessibility
tree
.
ATK
/
AT-SPI
For
objects
that
have
specified
allowed
accessibility
children
(e.g.,
a
grid
with
gridcell
children,
a
list
with
listitem
children),
and
the
descendant
is
in
the
accessibility
tree
,
expose
it
as
ROLE_SECTION
.
user
agents
SHOULD
prune
empty
descendants
from
the
accessibility
tree
.
For
objects
that
have
specified
allowed
accessibility
children
(e.g.,
a
grid
with
gridcell
children,
a
list
with
listitem
children),
and
the
descendant
is
in
the
accessibility
tree
,
expose
it
as
AXGroup
.
user
agents
SHOULD
prune
empty
descendants
from
the
accessibility
tree
.
Control
Type:
ProgressBar
Control
Pattern:
RangeValue
if
aria-valuenow
,
aria-valuemax
,
or
aria-valuemin
is
present
ATK
/
AT-SPI
Role:
ROLE_PROGRESS_BAR
Interface:
Value
Because
WAI-ARIA
does
not
support
modifying
the
value
via
the
accessibility
API
,
user
agents
MUST
return
false
for
all
Value
methods
that
provide
a
means
to
modify
the
value.
Control
Type:
ScrollBar
Control
Pattern:
RangeValue
ATK
/
AT-SPI
Role:
ROLE_SCROLL_BAR
Interface:
Value
Because
WAI-ARIA
does
not
support
modifying
the
value
via
the
accessibility
API
,
user
agents
MUST
return
false
for
all
Value
methods
that
provide
a
means
to
modify
the
value.
Because
WAI-ARIA
does
not
support
modifying
the
value
via
the
accessibility
API
,
user
agents
MUST
return
false
for
all
Value
methods
that
provide
a
means
to
modify
the
value.
Because
WAI-ARIA
does
not
support
modifying
the
value
via
the
accessibility
API
,
user
agents
MUST
return
false
for
all
Value
methods
that
provide
a
means
to
modify
the
value.
Because
WAI-ARIA
does
not
support
modifying
the
value
via
the
accessibility
API
,
user
agents
MUST
return
false
for
all
Value
methods
that
provide
a
means
to
modify
the
value.
Role:
ROLE_SYSTEM_CHECKBUTTON
Role:
IA2_ROLE_TOGGLE_BUTTON
Object
Attribute:
xml-roles:switch
See
also:
aria-checked
in
the
State
and
Property
Mapping
Tables
UIA
Control
Type:
Button
Localized
Control
Type:
toggleswitch
Control
Pattern:
Toggle
See
also:
aria-checked
in
the
State
and
Property
Mapping
Tables
AXRole:
AXTable
AXSubrole:
<nil>
AXColumnHeaderUIElements:
a
list
of
pointers
to
the
columnheader
elements
AXHeader:
a
pointer
to
the
row
or
group
containing
those
columnheader
elements
AXRowHeaderUIElements:
a
list
of
pointers
to
the
rowheader
elements
Because
WAI-ARIA
does
not
support
modifying
the
selection
via
the
accessibility
API
,
user
agents
MUST
return
false
for
all
Selection
methods
that
provide
a
means
to
modify
the
selection.
Control
Type:
Text
Localized
Control
Type:
time
Note:
create
a
separate
UIA
Control
of
type
Text.
This
is
different
from
most
UIA
text
mappings,
which
only
create
ranges
in
the
page
text
pattern.
Because
WAI-ARIA
does
not
support
modifying
the
selection
via
the
accessibility
API
,
user
agents
MUST
return
false
for
all
Selection
methods
that
provide
a
means
to
modify
the
selection.
Because
WAI-ARIA
does
not
support
modifying
the
selection
via
the
accessibility
API
,
user
agents
MUST
return
false
for
all
Selection
methods
that
provide
a
means
to
modify
the
selection.
[Note
1]
User
agent
should
return
a
user-presentable,
localized
string
value
for
the
AXRoleDescription.
Note
[Note
2]
This
specification
does
not
currently
contain
guidance
for
when
user
agents
should
fire
system
alert
events.
Some
guidance
may
be
added
to
the
specification
at
a
later
date
but
it
will
be
a
recommendation
(
SHOULD
),
not
a
requirement
(
MUST
).
User
agents
MUST
compute
managed
states
VISIBLE
/
INVISIBLE
,
SHOWING
/
OFFSCREEN
,
etc.
This
typically
is
done
in
the
same
way
as
for
ordinary
elements
that
do
not
have
WAI-ARIA
attributes
present.
The
FOCUSABLE
/
FOCUSED
states
may
be
affected
by
aria-activedescendant
.
User
agents
MUST
continue
to
expose
native
semantics
in
addition
to
WAI-ARIA
state
and
property
semantics
except
where
an
explicit
WAI-ARIA
override
is
allowed
by
the
host
language.
For
example,
an
HTML
checkbox
may
have
an
aria-labelledby
attribute
but
the
native
HTML
semantics
must
still
be
exposed.
Some
WAI-ARIA
properties
are
not
global,
and
are
only
supported
on
certain
roles.
If
a
non-global
WAI-ARIA
state
or
property
is
used
where
it
is
not
supported,
user
agents
SHOULD
NOT
map
the
given
WAI-ARIA
property
to
the
platform
accessibility
API
.
For
example,
if
aria-checked="true"
is
specified
on
<div
role="grid">
,
it
should
not
be
exposed
in
MSAA
implementations
as
STATE_SYSTEM_CHECKED
.
There
are
a
number
of
occurrences
in
the
table
where
a
given
state
or
property
is
declared
"Not
mapped".
In
some
cases,
this
occurs
for
the
default
value
of
the
state/property,
and
is
equivalent
to
its
absence.
User
agents
might
find
it
quicker
to
map
the
value
than
check
to
see
if
it
is
the
default.
For
computational
efficiency,
user
agents
MAY
expose
the
state
or
property
value
if
doing
so
is
equivalent
to
not
mapping
it.
These
cases
are
marked
with
an
asterisk.
In
other
cases,
it
is
mandatory
that
the
state/property
not
be
mapped,
since
exposing
it
implies
a
related
affordance.
An
example
is
aria-grabbed
.
Its
absence
not
only
indicates
that
the
accessible
object
is
not
grabbed,
but
further
defines
it
as
not
grab-able.
These
cases
are
marked
as
"Not
mapped"
without
an
asterisk.
Object
Attribute:
atomic:true
Object
Attribute:
container-atomic:true
Object
Attribute:
container-atomic:true
on
all
descendants
Relation:
IA2_RELATION_MEMBER_OF
pointing
to
this
element
(the
atomic
root)
See
also:
Changes
to
document
content
or
node
visibility
Object
Attribute:
atomic:true
Object
Attribute:
container-atomic:true
Object
Attribute:
container-atomic:true
on
all
descendants
Relation:
RELATION_MEMBER_OF
pointing
to
this
element
(the
atomic
root)
See
also:
Changes
to
document
content
or
node
visibility
Not
mapped*
,
but
if
mapped:
Object
Attribute:
atomic:false
Object
Attribute:
container-atomic:false
Object
Attribute:
container-atomic:false
on
all
descendants
Relation:
IA2_RELATION_MEMBER_OF
pointing
to
this
element
(the
atomic
root)
See
also:
Changes
to
document
content
or
node
visibility
Not
mapped*
,
but
if
mapped:
Object
Attribute:
atomic:false
Object
Attribute:
container-atomic:false
Object
Attribute:
container-atomic:false
on
all
descendants
Relation:
RELATION_MEMBER_OF
pointing
to
this
element
(the
atomic
root)
See
also:
Changes
to
document
content
or
node
visibility
Object
Attribute:
colindex:<value>
Method:
IAccessible2::groupPosition()
:
positionInGroup=<value>
on
cells
and
headers
UIA
Property:
GridItem.Column
:
<value>
(zero-based)
ATK
/
AT-SPI
Object
Attribute:
colindex
should
contain
the
author-provided
value.
Method:
atk_table_cell_get_position()
should
return
the
actual
(zero-based)
column
index.
Relation:
IA2_RELATION_CONTROLLER_FOR
points
to
accessible
nodes
matching
IDREFs
Reverse
Relation:
IA2_RELATION_CONTROLLED_BY
points
to
element
See
also:
Mapping
Additional
Relations
UIA
Property:
ControllerFor
:
pointers
to
accessible
nodes
matching
IDREFs
ATK
/
AT-SPI
Relation:
RELATION_CONTROLLER_FOR
points
to
accessible
nodes
matching
IDREFs
Reverse
Relation:
RELATION_CONTROLLED_BY
points
to
element
See
also:
Mapping
Additional
Relations
AX
API
Property:
AXLinkedUIElements
:
pointers
to
accessible
nodes
matching
IDREFs
4.5.2.21
aria-current
with
non-
false
allowed
value
Property:
accDescription
:
<value>
Relation:
IA2_RELATION_DESCRIBED_BY
points
to
accessible
nodes
matching
IDREFs,
if
the
referenced
objects
are
in
the
accessibility
tree
Reverse
Relation:
IA2_RELATION_DESCRIPTION_FOR
points
to
element
See
also:
Name
Computation
and
Mapping
Additional
Relations
Property:
Description
:
<value>
Relation:
RELATION_DESCRIBED_BY
points
to
accessible
nodes
matching
IDREFs,
if
the
referenced
objects
are
in
the
accessibility
tree
Reverse
Relation:
RELATION_DESCRIPTION_FOR
points
to
element
See
also:
Name
Computation
and
Mapping
Additional
Relations
AX
API
In
the
accessibilityCustomContent
API
,
expose
as
an
AXCustomContent
object
with
{
label:
"description"
}
and
`
value
`
set
to
the
description
string.
-
See
also:
Name
Computation
In
the
accessibilityCustomContent
API
,
expose
as
an
AXCustomContent
object
with
{
label:
"description"
}
and
`
value
`
set
to
the
description
string.
See
also:
Name
Computation
Relation:
IA2_RELATION_DETAILS
points
to
accessible
nodes
matching
IDREFs,
if
the
referenced
objects
are
in
the
accessibility
tree
Reverse
Relation:
IA2_RELATION_DETAILS_FOR
points
to
element
See
also:
Mapping
Additional
Relations
UIA
Property:
DescribedBy
:
points
to
accessible
nodes
matching
IDREFs,
if
the
referenced
objects
are
in
the
accessibility
tree
ATK
/
AT-SPI
Relation:
RELATION_DETAILS
points
to
accessible
nodes
matching
IDREFs,
if
the
referenced
objects
are
in
the
accessibility
tree
Reverse
Relation:
RELATION_DETAILS_FOR
points
to
element
See
also:
Mapping
Additional
Relations
Relation:
IA2_RELATION_ERROR
points
to
accessible
nodes
matching
IDREFs,
if
the
referenced
objects
are
in
the
accessibility
tree
Reverse
Relation:
IA2_RELATION_ERROR_FOR
points
to
element
See
also:
Mapping
Additional
Relations
UIA
Property:
ControllerFor
:
pointer
to
the
target
accessible
object
ATK
/
AT-SPI
Relation:
RELATION_ERROR_MESSAGE
points
to
accessible
nodes
matching
IDREFs,
if
the
referenced
objects
are
in
the
accessibility
tree
Reverse
Relation:
RELATION_ERROR_FOR
points
to
element
See
also:
Mapping
Additional
Relations
AX
API
Property:
AXErrorMessageElements
:
pointers
to
accessible
nodes
matching
IDREFs
Relation:
IA2_RELATION_FLOW_TO
points
to
accessible
nodes
matching
IDREFs
Reverse
Relation:
IA2_RELATION_FLOW_FROM
points
to
element
See
also:
Mapping
Additional
Relations
UIA
Property:
FlowsTo
:
pointers
to
accessible
nodes
matching
IDREFs
ATK
/
AT-SPI
Relation:
RELATION_FLOWS_TO
points
to
accessible
nodes
matching
IDREFs
Reverse
Relation:
RELATION_FLOWS_FROM
points
to
element
See
also:
Mapping
Additional
Relations
AX
API
Property:
AXLinkedUIElements
:
pointers
to
accessible
nodes
matching
IDREFs
Property:
accName
:
<value>
Relation:
IA2_RELATION_LABELLED_BY
points
to
accessible
nodes
matching
IDREFs,
if
the
referenced
objects
are
in
the
accessibility
tree
Reverse
Relation:
IA2_RELATION_LABEL_FOR
points
to
element
See
also:
Name
Computation
and
Mapping
Additional
Relations
UIA
Property:
Name
:
<value>
Property:
LabeledBy
:
points
to
accessible
nodes
matching
IDREFs,
if
the
referenced
objects
are
in
the
accessibility
tree
See
also:
Name
Computation
ATK
/
AT-SPI
Property:
Name
:
<value>
Relation:
RELATION_LABELLED_BY
points
to
accessible
nodes
matching
IDREFs,
if
the
referenced
objects
are
in
the
accessibility
tree
Reverse
Relation:
RELATION_LABEL_FOR
points
to
element
See
also:
Name
Computation
and
Mapping
Additional
Relations
AX
API
Property:
AXDescription
:
<value>
if
the
value
is
not
exposed
visually
Property:
AXTitle
:
<value>
if
the
value
is
exposed
visually
Property:
AXTitleUIElement
points
to
accessible
node
matching
IDREF,
if
there
is
a
single
referenced
element
that
is
in
the
accessibility
tree
See
also:
Name
Computation
Object
Attribute:
level:<value>
Method:
IAccessible2::groupPosition()
:
groupLevel=<value>
on
roles
that
support
aria-posinset
and
aria-setsize
See
also:
groupPosition()
UIA
Property:
AriaProperties.level
:
<value>
ATK
/
AT-SPI
Object
Attribute:
level:<value>
AX
API
Property:
AXDisclosureLevel
:
<value>
(zero-based),
when
used
on
an
outline
row
(like
a
treeitem
or
group
)
Object
Attribute:
live:assertive
Object
Attribute:
container-live:assertive
Object
Attribute:
container-live:assertive
on
all
descendants
See
also:
Changes
to
document
content
or
node
visibility
Object
Attribute:
live:assertive
Object
Attribute:
container-live:assertive
Object
Attribute:
container-live:assertive
on
all
descendants
See
also:
Changes
to
document
content
or
node
visibility
Prune
the
accessibility
tree
such
that
the
background
content
is
no
longer
exposed.
No
specific
property
is
set
on
the
accessible
object
that
corresponds
to
the
element
with
aria-modal="true"
.
Only
the
tree
whose
root
is
that
modal
accessible
object
is
exposed.
Grow
the
accessibility
tree
such
that
the
background
content
is
exposed.
No
specific
property
is
set
on
the
accessible
object
that
corresponds
to
the
element
with
aria-modal="false"
.
User
agents
MAY
expose
the
elements
that
are
referenced
by
this
property
as
children
of
the
current
element.
In
which
case,
if
multiple
aria-owns
relationships
are
found,
use
only
the
first
one.
If
the
accessibility
tree
is
not
modified,
expose
as:
Relation:
IA2_RELATION_NODE_PARENT_OF
points
to
accessible
nodes
matching
IDREFs,
if
the
referenced
objects
are
in
the
accessibility
tree
Reverse
Relation:
IA2_RELATION_NODE_CHILD_OF
points
to
element
See
also:
Mapping
Additional
Relations
UIA
Expose
the
elements
that
are
referenced
by
this
property
as
children
of
the
current
element.
If
multiple
aria-owns
relationships
are
found,
use
only
the
first
one.
ATK
/
AT-SPI
User
agents
MAY
expose
the
elements
that
are
referenced
by
this
property
as
children
of
the
current
element.
In
which
case,
if
multiple
aria-owns
relationships
are
found,
use
only
the
first
one.
If
the
accessibility
tree
is
not
modified,
expose
as:
Relation:
RELATION_NODE_PARENT_OF
points
to
accessible
nodes
matching
IDREFs,
if
the
referenced
objects
are
in
the
accessibility
tree
Reverse
Relation:
RELATION_NODE_CHILD_OF
points
to
element
See
also:
Mapping
Additional
Relations
AX
API
Property:
AXOwns
:
pointers
to
accessible
nodes
matching
IDREFs
Property:
Value.IsReadOnly
:
true
,
if
the
element
implements
IValueProvider
.
Property:
RangeValue.IsReadOnly
:
true
,
if
the
element
implements
IRangeValueProvider
.
Property:
AriaProperties.readonly
:
true
ATK
/
AT-SPI
State:
STATE_READ_ONLY
State:
STATE_EDITABLE
not
exposed
on
text
input
roles
State:
STATE_CHECKABLE
not
exposed
on
roles
supporting
aria-checked
State:
STATE_CHECKABLE
not
exposed
on
radio
descendants
when
used
on
a
radiogroup
AX
API
Method:
AXUIElementIsAttributeSettable(AXValue)
:
NO
State:
STATE_SYSTEM_READONLY
not
exposed
State:
IA2_STATE_EDITABLE
UIA
Property:
Value.IsReadOnly
:
false
,
if
the
element
implements
IValueProvider
.
Property:
RangeValue.IsReadOnly
:
false
,
if
the
element
implements
IRangeValueProvider
.
Property:
AriaProperties.readonly
:
false
The
gridcell
MUST
inherit
any
author-provided
value
for
aria-readonly
from
the
containing
grid
or
treegrid
.
Expose
the
inherited
value
on
the
gridcell
as
described
for
aria-readonly="true"
and
aria-readonly="false"
.
UIA
The
gridcell
MUST
inherit
any
author-provided
value
for
aria-readonly
from
the
containing
grid
or
treegrid
.
Expose
the
inherited
value
on
the
gridcell
as
described
for
aria-readonly="true"
and
aria-readonly="false"
.
ATK
/
AT-SPI
The
gridcell
MUST
inherit
any
author-provided
value
for
aria-readonly
from
the
containing
grid
or
treegrid
.
Expose
the
inherited
value
on
the
gridcell
as
described
for
aria-readonly="true"
and
aria-readonly="false"
.
AX
API
The
gridcell
MUST
inherit
any
author-provided
value
for
aria-readonly
from
the
containing
grid
or
treegrid
.
Expose
the
inherited
value
on
the
gridcell
as
described
for
aria-readonly="true"
and
aria-readonly="false"
.
Object
Attribute:
relevant:<value>
Object
Attribute:
container-relevant:<value>
Object
Attribute:
container-relevant:<value>
on
all
descendants
See
also:
Changes
to
document
content
or
node
visibility
Object
Attribute:
relevant:<value>
Object
Attribute:
container-relevant:<value>
Object
Attribute:
container-relevant:<value>
on
all
descendants
See
also:
Changes
to
document
content
or
node
visibility
Localized
Control
Type
is
defined
as
that
specified
for
the
role
of
the
element:
based
on
the
explicit
role
if
the
role
attribute
is
provided;
otherwise,
based
on
the
implicit
role
for
the
host
language.
AXRoleDescription
is
defined
as
that
specified
for
the
role
of
the
element:
based
on
the
explicit
role
if
the
role
attribute
is
provided;
otherwise,
based
on
the
implicit
role
for
the
host
language.
Object
Attribute:
rowindex:<value>
Method:
IAccessible2::groupPosition()
:
positionInGroup=<value>
on
rows
UIA
Property:
GridItem.Row
:
<value>
(zero-based)
ATK
/
AT-SPI
Object
Attribute:
rowindex
should
contain
the
author-provided
value.
Method:
atk_table_cell_get_position()
should
return
the
actual
(zero-based)
row
index.
A
reverse
relation
exists
when
an
element's
ID
is
referenced
by
a
property
in
another
element
.
For
APIs
that
support
reverse
relations,
user
agents
MUST
use
the
mapping
defined
in
the
State
and
Property
Mapping
Tables
when
an
element's
ID
is
referenced
by
a
relation
property
of
another
element
and
the
referenced
element
is
in
the
accessibility
tree.
All
WAI-ARIA
references
must
point
to
an
element
that
is
exposed
as
an
accessible
object
in
the
accessibility
tree.
When
the
referenced
object
is
not
exposed
in
the
accessibility
tree
(e.g.
because
it
is
hidden
),
the
reference
is
null.
aria-labelledby
and
aria-describedby
have
an
additional
feature,
which
allows
them
to
pull
a
flattened
string
from
the
referenced
element
to
populate
the
name
or
description
fields
of
the
accessibility
API
.
This
feature
is
described
in
the
Name
and
Description
section.
Special
case:
If
both
aria-labelledby
and
HTML
<label
for=
…
>
are
used,
the
user
agent
MUST
use
the
WAI-ARIA
relation
and
MUST
ignore
the
HTML
label
relation.
Note
that
aria-describedby
may
reference
structured
or
interactive
information
where
users
would
want
to
be
able
to
navigate
to
different
sections
of
content.
User
agents
MAY
provide
a
way
for
the
user
to
navigate
to
structured
information
referenced
by
aria-describedby
and
assistive
technology
SHOULD
provide
such
a
method.
4.6.2.2
Implied
reverse
relations
In
addition
to
the
explicit
relations
defined
by
WAI-ARIA
properties
,
reverse
relations
are
implied
in
two
other
situations:
elements
with
role="treeitem"
where
the
ancestor
does
not
have
an
aria-owns
property
and
descendants
of
elements
with
aria-atomic
property.
In
the
case
of
role="
treeitem
"
,
when
aria-owns
is
not
used,
user
agents
SHOULD
do
the
following
where
reverse
relations
are
supported
by
the
API
:
If
the
current
treeitem
uses
aria-level
,
then
walk
backwards
in
the
tree
until
a
treeitem
is
found
with
a
lower
aria-level
,
then
set
RELATION_NODE_CHILD_OF
to
that
element.
If
the
top
of
the
tree
is
reached,
then
set
RELATION_NODE_CHILD_OF
to
the
tree
element
itself.
If
the
parent
of
the
treeitem
has
a
role
of
group
,
then
walk
backwards
from
the
group
until
an
element
with
a
role
of
treeitem
is
found,
then
set
RELATION_NODE_CHILD_OF
to
that
element.
In
the
case
of
aria-atomic
,
where
reverse
relations
are
supported
by
the
API
:
User
agents
SHOULD
check
the
chain
of
ancestor
elements
for
aria-atomic
="true"
.
If
found,
user
agents
SHOULD
set
the
RELATION_MEMBER_OF
relation
to
point
to
the
ancestor
that
sets
aria-atomic
="true"
.
4.6.3
Group
Position
aria-level
,
aria-posinset
,
and
aria-setsize
are
all
1-based.
When
the
property
is
not
present
or
is
"0",
it
indicates
the
property
is
not
computed
or
not
supported.
If
any
of
these
properties
are
specified
by
the
author
as
either
"0"
or
a
negative
number,
user
agents
SHOULD
use
"1"
instead.
If
aria-level
is
not
provided
or
inherited
for
an
element
of
role
treeitem
or
comment
,
user
agents
implementing
IAccessible2
or
ATK
/
AT-SPI
MUST
compute
it
by
following
the
explicit
or
computed
RELATION_NODE_CHILD_OF
relations.
for
role="
treeitem
"
and
role="
comment
"
,
walk
the
tree
backward
and
forward
until
the
explicit
or
computed
level
becomes
less
than
the
current
item's
level.
Count
items
only
if
they
are
at
the
same
level
as
the
current
item.
Otherwise,
if
the
role
supports
aria-posinset
and
aria-setsize
,
process
the
parent
(
DOM
parent
or
parent
defined
by
aria-owns
),
counting
items
that
have
the
same
role.
Because
these
value
are
1-based,
include
the
current
item
in
the
computation.
For
aria-posinset
,
include
the
current
item
and
other
group
items
if
they
are
before
the
current
item
in
the
DOM
.
For
aria-setsize
,
add
to
that
the
number
of
items
in
the
same
group
after
the
current
item
in
the
DOM
.
If
the
author
provides
one
or
more
of
aria-setsize
and
aria-posinset
,
it
is
the
author's
responsibility
to
supply
them
for
all
elements
in
the
set.
User
agent
correction
of
missing
values
in
this
case
is
not
defined.
MSAA
/IAccessible2
API
mappings
involve
an
additional
function,
groupPosition()
[
IAccessible2
],
when
aria-level
,
aria-posinset
,
and/or
aria-setsize
are
present
on
an
element,
or
are
computed
by
the
user
agent.
When
this
occurs:
aria-level
is
exposed
in
the
groupLevel
parameter
of
groupPosition()
,
aria-setsize
is
exposed
in
the
similarItemsInGroup
parameter,
and
As
part
of
mapping
roles
to
accessible
objects
as
defined
in
Role
Mapping
,
users
agents
expose
a
default
action
on
the
object.
MSAA
:
If
an
AT
calls
DoDefaultAction
on
an
accessible
object,
the
user
agent
SHOULD
simulate
a
click
on
the
DOM
element
which
is
mapped
to
that
accessible
object.
IAccessible2:
If
an
AT
calls
the
IAccessibleAction
on
an
accessible
object,
the
user
agent
SHOULD
simulate
a
click
on
the
DOM
element
which
is
mapped
to
that
accessible
object.
UIA
Automation:
If
an
AT
calls
any
UIA
pattern
method
on
an
accessible
object,
the
user
agent
SHOULD
simulate
a
click
on
the
DOM
element
which
is
mapped
to
that
accessible
object.
ATK
/
AT-SPI
:
If
an
AT
calls
an
action
on
an
accessible
object,
the
user
agent
SHOULD
simulate
a
click
on
the
DOM
element
which
is
mapped
to
that
accessible
object.
AX
API
:
If
an
AT
triggers
an
AXPress
action
on
an
accessible
object,
the
user
agent
SHOULD
simulate
a
click
on
the
DOM
element
which
is
mapped
to
that
accessible
object.
Note
Authors
will
need
to
create
handlers
for
those
click
events
that
update
WAI-ARIA
states
and
properties
in
the
DOM
accordingly,
so
that
those
updated
states
can
be
populated
by
the
user
agent
in
the
Accessibility
API
.
4.8
Events
User
agents
fire
events
for
user
actions,
WAI-ARIA
state
changes,
changes
to
document
content
or
node
visibility,
changes
in
selection
and
operation
of
menus
as
defined
in
the
following
sections.
In
some
APIs
,
AT
will
only
be
notified
of
events
to
which
it
has
subscribed.
For
simplicity
and
performance
the
user
agent
MAY
trim
out
change
events
for
state
or
property
changes
that
assistive
technologies
typically
ignore,
such
as
events
that
are
happening
in
a
window
that
does
not
currently
have
focus.
Note
Translators:
For
label
text
associated
with
the
following
table
and
its
toggle
buttons,
see
the
mappingTableLabels
object
in
the
<head>
section
of
this
document.
4.8.2
Changes
to
document
content
or
node
visibility
Processing
document
changes
is
important
regardless
of
WAI-ARIA
.
The
events
described
in
the
table
below
are
used
by
user
agents
to
inform
AT
of
changes
to
the
DOM
via
the
accessibility
tree.
For
the
purposes
of
conformance
with
this
standard,
user
agents
MUST
implement
the
behavior
described
in
this
section
whenever
WAI-ARIA
attributes
are
applied
to
dynamic
content
on
a
Web
page.
Table
of
document
change
scenarios
and
events
to
be
fired
in
each
API
Scenario
MSAA
+
IAccessible2
event
UIA
event
ATK
/
AT-SPI
event
AX
API
Notification
When
text
is
removed
IA2_EVENT_TEXT_REMOVED
EVENT_OBJECT_LIVEREGIONCHANGED
text_changed::delete
If
in
a
live
region
,
AXLiveRegionChanged
.
If
in
aria-errormessage
,
AXValidationErrorChanged
.
When
text
is
inserted
IA2_EVENT_TEXT_INSERTED
EVENT_OBJECT_LIVEREGIONCHANGED
text_changed::insert
If
in
a
live
region
,
AXLiveRegionChanged
.
If
in
aria-errormessage
,
AXValidationErrorChanged
.
When
text
is
changed
IA2_EVENT_TEXT_REMOVE
and
IA2_EVENT_TEXT_INSERTED
EVENT_OBJECT_LIVEREGIONCHANGED
text_changed::delete
and
text_changed::insert
If
in
a
live
region
,
AXLiveRegionChanged
.
If
in
aria-errormessage
,
AXValidationErrorChanged
.
Fire
these
events
for
node
changes
where
the
node
in
question
is
an
element
and
has
an
accessible
object
:
Table
of
document
change
scenarios
and
events
to
be
fired
in
each
API
EVENT_OBJECT_HIDE
The
MSAA
event
called
EVENT_OBJECT_DESTROY
is
not
used
because
this
has
a
history
of
stability
issues
and
assistive
technology
avoids
it.
In
any
case,
from
the
user's
point
of
view,
there
is
no
difference
between
something
that
is
hidden
or
destroyed.
AutomationElement..::.StructureChangedEvent
children_changed::remove
AXUIElementDestroyed
If
in
a
live
region,
AXLiveRegionChanged
When
an
accessibility
subtree
is
removed
EVENT_OBJECT_REORDER
The
MSAA
event
called
EVENT_OBJECT_DESTROY
is
not
used
because
this
has
a
history
of
stability
issues
and
assistive
technology
avoids
it.
In
any
case,
from
the
user's
point
of
view,
there
is
no
difference
between
something
that
is
hidden
or
destroyed.
AutomationElement..::.StructureChangedEvent
children_changed::remove
AXUIElementDestroyed
If
in
a
live
region,
AXLiveRegionChanged
When
an
accessibility
subtree
is
shown
EVENT_OBJECT_SHOW
children_changed::add
AXUIElementCreated
If
in
a
live
region,
AXLiveRegionChanged
When
an
accessibility
subtree
is
inserted
EVENT_OBJECT_REORDER
children_changed::add
AXUIElementCreated
If
in
a
live
region,
AXLiveRegionChanged
When
an
accessibility
subtree
is
moved
Treat
it
as
a
removal
from
one
place
and
insertion
in
another
Treat
it
as
a
removal
from
one
place
and
insertion
in
another
Treat
it
as
a
removal
from
one
place
and
insertion
in
another
AXUIElementDestroyed
/
AXUIElementCreated
If
in
a
live
region,
AXLiveRegionChanged
When
an
accessibility
subtree
is
changed
(e.g.
replaceNode)
Treat
it
as
a
removal
and
insertion
Treat
it
as
a
removal
and
insertion
Treat
it
as
a
removal
and
insertion
AXUIElementDestroyed
/
AXUIElementCreated
If
in
a
live
region,
AXLiveRegionChanged
In
some
cases,
node
changes
may
occur
where
the
node
is
not
an
element
or
has
no
accessible
object.
For
example,
a
numbered
list
bullet
("12.")
may
have
a
node
in
the
accessibility
tree
but
not
in
the
DOM
tree.
For
text
within
a
paragraph
marked
in
HTML
as
<strong>
,
the
<strong>
element
has
a
node
in
the
DOM
tree
but
may
not
have
one
in
the
accessibility
tree.
The
text
itself
will
of
course
be
in
the
accessibility
tree
along
with
the
identification
of
the
range
of
text
that
is
formatted
as
strong.
If
any
of
the
changes
described
in
the
table
above
occur
on
such
a
node,
user
agents
SHOULD
compute
and
fire
relevant
text
change
events
as
described
above.
User
agents
SHOULD
ensure
that
an
assistive
technology,
running
in
process
can
receive
notification
of
a
node
being
removed
prior
to
removal.
This
allows
an
assistive
technology,
such
as
a
screen
reader,
to
refer
back
to
the
corresponding
DOM
node
being
deleted.
This
is
important
for
live
regions
where
removals
are
important.
For
example,
a
screen
reader
would
want
to
notify
a
user
that
another
user
has
left
a
chat
room.
The
event
in
MSAA
would
be
EVENT_OBJECT_HIDE
.
For
ATK
/
AT-SPI
this
would
be
children_changed::remove
.
And
in
macOS,
the
event
is
AXLiveRegionChanged
.
This
also
requires
the
user
agent
to
provide
a
unique
ID
in
the
accessibility
API
notification
identifying
the
unique
node
being
removed.
When
firing
any
of
the
above-mentioned
change
events,
it
is
very
useful
to
provide
information
about
whether
the
change
was
caused
by
user
input
(as
opposed
to
a
timeout
initiated
from
the
page
load,
etc.).
This
allows
the
assistive
technology
to
have
different
rules
for
presenting
changes
from
the
real
world
as
opposed
to
from
user
action.
Mouse
hovers
are
not
considered
explicit
user
input
because
they
can
occur
from
accidental
bumps
of
the
mouse.
To
expose
whether
a
change
occurred
from
user
input:
In
ATK
/
AT-SPI
this
can
be
provided
by
appending
the
string
":system"
to
the
event
name
when
the
user
did
not
cause
the
change.
In
IAccessible2,
which
screen
readers
typically
access
in
process
on
the
same
thread,
the
best
practice
is
to
expose
the
object
attribute
event-from-user-input:true
on
the
accessible
object
for
the
event,
if
the
user
caused
the
change.
Exposing
additional
useful
information
about
the
context
of
the
change:
In
ATK
/
AT-SPI
and
IAccessible2,
the
RELATION_MEMBER_OF
relation
on
the
accessible
event's
target
accessible
object
SHOULD
point
to
any
ancestor
with
aria-atomic
="true"
(if
any).
In
ATK
/
AT-SPI
and
IAccessible2,
the
container-live
,
container-relevant
,
container-busy
,
container-atomic
object
attributes
SHOULD
be
exposed
on
the
accessible
event
object,
providing
the
computed
value
for
the
related
WAI-ARIA
properties.
The
computed
value
is
the
value
of
the
closest
ancestor.
It
is
recommended
to
not
expose
the
object
attribute
if
the
default
value
is
used.
Additional
MSAA
events
may
be
necessary:
If
something
changes
in
an
ancestor
with
a
mapped
MSAA
role
of
ROLE_SYSTEM_ALERT
,
then
an
EVENT_SYSTEM_ALERT
event
SHOULD
be
fired
for
the
alert.
The
alert
role
has
an
implied
value
of
"assertive"
for
the
aria-live
property.
Current
state
reflected
in
IUIAutomationElement::CurrentIsKeyboardFocusable
,
can
be
retrieved
with
IUIAutomationElement::GetCurrentPropertyValue
method
using
UIA_IsKeyboardFocusablePropertyId
property
identifier.
STATE_FOCUSABLE
boolean
AXFocused
:
the
AXUIElementIsAttributeSettable
method
returns
YES
.
Focused
state
STATE_SYSTEM_FOCUSED
Current
state
reflected
in
IUIAutomationElement::CurrentHasKeyboardFocus
,
can
be
retrieved
with
IUIAutomationElement::GetCurrentPropertyValue
method
using
UIA_HasKeyboardFocusPropertyId
property
identifier.
STATE_FOCUSED
boolean
AXFocused
Focus
event
EVENT_OBJECT_FOCUS
Clients
can
subscribe
with
IUIAutomation::AddFocusChangedEventHandler
using
callback
interface
is
IUIAutomationFocusChangedEventHandler
In
the
single
selection
case,
selection
follows
focus
(see
the
section
"
Focus
States
and
Events
Table
"
for
information
about
focus
events).
User
agents
MUST
fire
the
following
events
when
aria-selected
changes:
Single
selection
events
Scenario
MSAA
Microsoft
UIA
ATK
/
AT-SPI
AX
API
Focus
change
EVENT_OBJECT_SELECTION
and
EVENT_OBJECT_STATECHANGE
on
newly
focused
item.
UIA_SelectionItem_ElementSelectedEventId
on
the
newly
focused
element.
If
on
a
gridcell
,
row
,
option
,
or
tab
,
fire
UIA_SelectionItem_ElementSelectedEventId
.
object:selection-changed
on
the
current
container,
object:state-changed:selected
on
the
descendant
accessible
object
whose
selection
has
changed:
detail1
=
1
for
the
descendant
which
just
became
selected.
detail1
=
0
for
the
descendant
which
just
became
unselected.
User
agent
MAY
fire
an
EVENT_OBJECT_SELECTIONWITHIN
.
If
this
event
is
fired
the
other
events
noted
above
MAY
be
trimmed
out
for
performance.
For
each
element
selected
or
deselected,
fire
SelectionItem
Control
Pattern:
UIA_SelectionItem_ElementAddedToSelectionEventId
or
UIA_SelectionItem_ElementRemovedFromSelectionEventId
on
the
current
container.
User
agents
MAY
choose
to
fire
the
Selection
Control
Pattern
Invalidated
event,
which
indicates
that
the
selection
in
a
container
has
changed
significantly
and
requires
sending
more
addition
and
removal
events
than
the
InvalidateLimit
constant
permits.
the
user
agent
MAY
fire
a
single
object:selection-changed
event
on
the
container,
vs.
multiple
events,
for
performance,
object:state-changed:selected
on
any
descendant
accessible
object
whose
selection
has
changed:
Some
APIs
,
provide
special
events
whenever
a
menu
is
opened
or
closed.
User
agents
SHOULD
provide
the
events
as
described
in
the
table
below.
If
provided,
because
menus
can
be
made
visible
or
hidden
using
a
variety
of
techniques,
a
user
agent
MUST
ensure
that
the
events
are
nested
and
symmetrical.
Frequently,
a
menubar
is
used
to
organize
a
hierarchy
of
menus.
In
those
cases,
the
menubar
MUST
be
a
DOM
parent
of
the
associated
menuitem
s,
or
one
defined
by
aria-owns
.
In
other
cases,
no
menubar
is
involved;
for
example,
when
the
menu
is
associated
with
a
toolbar
button,
or
is
a
context
menu.
Nonetheless
the
relevant
menu
events
are
provided
as
described
in
the
following
table.
Menu
events
Scenario
MSAA
Microsoft
UIA
AX
API
Menubar
is
currently
not
active,
and
user
moves
focus
to
the
menubar
from
elsewhere
thereby
activating
it.
As
a
result,
a
menuitem
in
the
menubar
is
focused.
Activate
the
menubar
and
fire
EVENT_SYSTEM_MENUSTART
on
the
accessible
object
for
the
menubar.
MenuModeStartEvent
on
the
accessible
object
for
the
menu.
AXMenuOpenedNotification
Focus
a
menuitem
while
menubar
is
activated,
or
focus
a
menuitem
in
a
menu.
EVENT_OBJECT_FOCUS
AutomationFocusChangedEvent
AXMenuItemSelectedNotification
Menu
popup
made
visible
(menu
is
opened).
Should
only
be
fired
once
until
the
menu
is
closed
and
opened
again.
EVENT_SYSTEM_MENUPOPUPSTART
MenuOpenedEvent
,
then
a
focus
event
on
a
menuitem.
AXMenuOpenedNotification
Menu
popup
hidden
(menu
is
closed).
EVENT_SYSTEM_MENUPOPUPEND
once
only
for
accessible
menu
object
and
only
if
EVENT_SYSTEM_MENUPOPUPSTART
was
fired
for
it.
MenuClosedEvent
AXMenuClosedNotification
Any
open
menus
are
closed
including
sub-menus,
and
user
moves
focus
away
from
the
menubar;
menubar
is
deactivated.
EVENT_SYSTEM_MENUEND
on
the
menubar
and
deactivate
the
menubar.
MenuClosedEvent
,
then
MenuModeEndEvent
AXMenuClosedNotification
5.
Privacy
considerations
In
accordance
with
Web
Platform
Design
Principles
,
this
specification
provides
no
programmatic
interface
to
determine
if
information
is
being
used
by
Assistive
Technologies.
However,
this
specification
does
allow
an
author
to
present
different
information
to
users
of
Assistive
Technologies
from
the
information
available
to
users
who
do
not
use
Assistive
Technologies.
This
is
possible
using
many
features
of
the
ARIA
and
CORE-AAM
specifications,
just
as
this
is
possible
using
many
other
parts
of
the
web
technology
stack.
This
content
disparity
could
be
abused
to
perform
active
fingerprinting
of
users
of
Assistive
Technologies.
6.
Security
considerations
This
specification
introduces
no
new
security
considerations.
A.
Change
Log
A.1
Substantive
changes
since
the
last
public
working
draft
12-Oct-2022:
Remove
mappings
for
label
and
legend
.
05-Apr-2021:
Update
ATK
mappings
for
aria-colindex
,
aria-colspan
,
aria-colcount
,
aria-rowindex
,
aria-rowspan
,
and
aria-rowcount
.
06-Apr-2020:
Update
ATK
mappings
for
alert
and
alertdialog
.
25-Feb-2020:
Add
mappings
for
comment
,
mark
,
and
suggestion
roles.
Include
comment
in
calculation
for
aria-label
and
group
position.
25-Feb-2020:
Add
mappings
for
aria-description
.
03-Nov-2019:
Remove
explicit
AXRoleDescription
values
for
AX
API
.
User
agents
should
follow
the
guidance
described
in
the
note.
22-Oct-2019:
Add
mappings
for
strong
and
emphasis
roles
for
AX
API
.
22-Oct-2019:
Add
mappings
for
code
role
for
AX
API
.
21-Oct-2019:
Add
mappings
for
aria-colindextext
and
aria-rowindextext
roles
for
ATK
,
IA2,
and
UIA
.
21-Oct-2019:
Add
mappings
for
strong
and
emphasis
roles
for
ATK
,
IA2,
and
UIA
.
21-Oct-2019:
Add
mappings
for
code
role
for
ATK
,
IA2,
and
UIA
.
18-Sep-2019:
Update
MSAA
mappings
for
subscript
and
superscript
10-Sep-2019:
Add
mappings
for
generic
role.
09-Jul-2019:
Add
mappings
for
insertion
and
deletion
roles.
14-May-2019:
Add
mappings
for
legend
role.
14-May-2019:
Add
mappings
for
label
role.
14-May-2019:
Add
mappings
for
time
role.
25-Apr-2019:
Add
mappings
for
subscript
and
superscript
roles.
25-Feb-2019:
Add
mappings
for
meter
role.
05-Feb-2019:
Update
UIA
state
and
property
change
events.
06-Jun-2018:
Update
UIA
mappings
for
aria-placeholder
.
04-Jun-2018:
Add
mappings
for
blockquote
,
caption
,
and
paragraph
roles.
05-Mar-2018:
Add
mention
of
AXTitle
for
exposing
rendered
labels
for
AXAPI.
05-Mar-2018:
Add
events
for
aria-label
,
aria-labelledby
,
and
aria-describedby
.