[ contents ]
Copyright © 2012 W3C ® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark and document use rules apply.
This document describes how user agents should support keyboard navigation and respond to roles , states, and properties provided in Web content via WAI-ARIA [ ARIA ]. These features are used by authors creating accessible rich internet applications. Users often access the content using assistive technologies that rely on platform accessibility APIs to obtain and interact with information from the page. The WAI-ARIA User Agent Implementation Guide defines how implementations should expose content to accessibility APIs , helping to ensure that this information appears in a manner consistent with author intent. This document 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 http://www.w3.org/TR/.
This
is
a
Last
Call
Working
Draft
by
the
Protocols
&
Formats
Working
Group
of
the
Web
Accessibility
Initiative
.
It
supports
the
Accessible
Rich
Internet
Applications
(WAI-ARIA)
[
ARIA
]
Candidate
Recommendation,
providing
information
about
how
user
agents
should
expose
ARIA
features
to
platform
accessibility
APIs
.
The
accessibility
API
relationships
defined
here
are
important
to
WAI-ARIA,
and
this
document
is
expected
to
will
be
tested
as
part
of
the
testing
effort
for
WAI-ARIA.
This
version
reflects
continued
analysis
WAI-ARIA
User
Agent
Implementation
Guide
was
previously
published
as
a
Last
Call
Working
Draft
on
10
January
2012
.
During
testing
and
engineering
review
of
expected
WAI-ARIA
1.0,
the
group
found
ambiguities
in
user
agent
implementation
expectations.
This
resulted
in
a
careful
review
of
this
User
Agent
Implementation
Guide
to
expand
and
accessibility
API
behavior.
It
clarify
requirements.
This
version
also
incorporates
changes
made
in
response
to
public
comments
received
on
the
previous
version.
Therefore,
it
is
being
returned
to
ordinary
Working
Draft
status
in
order
to
collect
public
feedback
on
these
changes.
A
history
of
changes
to
WAI-ARIA
1.0
User
Agent
Implementation
Guide
is
available.
Refer
to
the
summary
of
actions
made
in
response
to
comments
on
the
previous
draft
and
the
issue
disposition
report
for
the
previous
draft
.
This
document
includes
general
information
for
user
agents
In
order
to
handle
keep
WAI-ARIA
roles,
states,
and
properties.
It
also
includes
host-language
specific
requirements
where
necessary
to
complete
the
accessibility
model.
In
1.0
on
a
planned
timeline,
the
future,
Working
Group
hopes
to
collect
feedback
on
the
PFWG
may
split
out
technology-specific
versions
of
this
guide,
moving
some
requirements
out
but
retaining
changes
in
this
document
and
publish
a
second
Last
Call
Working
Draft
as
soon
as
possible.
Therefore,
it
is
important
to
receive
major
comments
on
the
general
ARIA
implementation
guide.
Feedback
WAI-ARIA
User
Agent
Implementation
Guide
on
this
version.
Processing
all
changes
possible
before
the
information
provided
here
second
Last
Call
Working
Draft
is
essential
to
the
ultimate
success
of
Rich
Internet
Applications
that
afford
full
access
published
will
support
a
smooth
transition
to
their
information
and
operations.
Candidate
Recommendation.
The
PFWG
asks
in
particular:
Start
with
the
instructions
for
commenting
page
to
submit
comments
(preferred),
or
send
email
to
public-pfwg-comments@w3.org
(
comment
archive
).
Comments
should
be
made
by
17
February
21
September
2012
.
In-progress
updates
to
the
document
may
be
viewed
in
the
publicly
visible
editors'
draft
.
Publication as a Working 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 5 February 2004 W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
The disclosure obligations of the Participants of this group are described in the charter .
This section is informative .
In traditional desktop graphical user interface (GUI) applications, components of the user interface (UI) are displayed when needed and hidden when not needed based on user interactions. Accessibility application programming interfaces (APIs) are used to communicate semantic information about the user interface to assistive technology software used by people with disabilities. These APIs constitute a contract between applications and assistive technologies, such as screen readers, magnifiers, alternate input devices, and speech command and control, to enable them to access the appropriate semantics needed to produce a usable alternative to interactive applications. For example, screen reading software for blind users can determine whether a particular UI component is a menu, button, text field, list box, etc.
In traditional static Web pages, the HTML elements provided the necessary semantic information. The user agent provides keyboard navigation but only to the HTML elements that are known to be interactive, specifically links and form elements. Assistive technologies obtain the semantic information from the Document Object Model ( DOM ) or, in the case of links and form elements, through the Accessibility API . In both cases, the assistive technology expects that nothing changes until a new page is loaded based on a user action.
Yet
technologies
such
as
JavaScript,
Ajax,
and
CSS
have
enabled
Web
pages
to
look
and
behave
more
like
interactive
desktop
GUI
applications,
without
the
need
to
reload
the
page
with
each
user
interaction.
Developers
can
now
re-purpose
HTML
elements
into
UI
components
not
previously
defined
in
HTML
.
For
example,
Javascript
can
be
used
with
CSS
to
modify
a
<div>
element
based
on
user
interactions
to
make
it
look
and
behave
like
a
popup
menu.
Unfortunately,
the
<div>
element
does
not
provide
the
author
with
a
vehicle
to
add
semantic
metadata
that
can
be
exposed
through
the
DOM
and
mapped
to
Accessibility
APIs
.
These
accessibility
deficiencies
in
traditional
markup
render
rich
Internet
applications
unusable
by
people
who
use
assistive
technologies
or
who
rely
on
keyboard
navigation.
The W3C Web Accessibility Initiative's (WAI) Protocols and Formats working group (PFWG) has addressed these deficiencies through several W3C standards efforts, with a focus on the Accessible Rich Internet Applications [ WAI-ARIA ] specification.
WAI-ARIA enables rich Internet applications to have the same accessibility features as desktop GUI applications by adding metadata to markup technologies such as (X)HTML . Authors include WAI-ARIA in their markup and user agents translate the WAI-ARIA markup to the platform accessibility APIs .
For an introduction to WAI-ARIA , see the WAI-ARIA Overview . The User Agent Implementation Guide describes how WAI-ARIA roles , states , and properties should be supported in user agents using platform accessibility APIs . It is part of a set of resources that define and support the WAI-ARIA specification which includes the following documents:
The WAI-ARIA User Agent Implementation Guide begins by providing a general overview of accessibility APIs and the accessible object hierarchy known as the accessibility tree . The following sections give guidance on supporting keyboard navigation and mapping WAI-ARIA roles, states, and properties to accessibility APIs . Other sections give guidance on calculating text alternatives, mapping actions to events , event processing, special document handling procedures, and error handling.
This guide assumes that a user agent already exposes static content to assistive technology via the accessibility API on a given platform. Most of the additional work to enable WAI-ARIA can be divided into three parts:
In general, WAI-ARIA attributes should only affect how content is mapped to platform accessibility APIs . They should not affect the visual rendering of content or the behavior of mainstream desktop browsers, except when style sheets are deliberately keyed off of WAI-ARIA attributes as recommended in the specification. This allows one of the primary principles of WAI-ARIA to be upheld—that content still renders and behaves the same for the majority of users in legacy browsers which do not support WAI-ARIA .
This document includes general information for user agents to handle WAI-ARIA roles, states, and properties. It also includes host-language specific requirements where necessary to complete the accessibility model, in particular for HTML 4. In the future, the PFWG may split out technology-specific versions of this guide, moving some requirements out but retaining this document as the general ARIA implementation guide.
To provide access to desktop GUI applications, assistive technologies originally used heuristic techniques to determine the meaning of the user interface and build an alternative off-screen model. For example, a row of labels displayed horizontally near the top of an application window might be a menu. Labels with a border drawn around them might be buttons. Heuristic techniques are not always accurate, however, and require assistive technologies to be updated whenever the software application is updated.
A much better technique is for the software application to provide the necessary information for interoperability with assistive technology. To meet this need, platform owners have developed specialized interfaces, called accessibility APIs , which can be used to communicate accessibility information about user interfaces to assistive technologies.
In the case of static Web pages, the Document Object Model (DOM) is used to represent the structure and state of the elements in the document being rendered by a user agent . The elements of the document are organized into a hierarchy of nodes known as the DOM tree. For traditional static Web pages, assistive technologies, such as screen readers, interact with user agents using the DOM . For UI elements that are known to be interactive, such as HTML form elements and desktop applications, assistive technologies may use platform accessibility APIs .
In the case of rich Internet applications, developers use DOM APIs to manipulate objects in the DOM tree to make them behave like interactive desktop GUI applications. In order to make a Web application understandable to assistive technologies, the user agent needs to map accessibility information from the elements in the DOM tree to the Accessibility APIs of the underlying operating system or software platform throughout the lifecycle of the application. The information needed is provided when developers use WAI-ARIA to supply semantic role , state, and property information for elements. The screen reader or other assistive technology uses the semantic information exposed via the accessibility API to provide an alternative rendering of an application that is meaningful to a user.
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.
The
accessibility
tree
and
the
DOM
tree
are
parallel
structures.
Roughly
speaking
the
accessibility
tree
is
a
subset
of
the
DOM
tree.
It
includes
the
user
interface
objects
of
the
user
agent
and
the
objects
of
the
document.
Accessible
objects
are
created
in
the
accessibility
tree
for
every
DOM
element
that
should
be
exposed
to
an
assistive
technology
,
either
because
it
may
fire
an
accessibility
event
or
because
it
has
a
property
,
relationship
or
feature
which
needs
to
be
exposed.
Generally
if
something
can
be
trimmed
out
it
will
be,
for
reasons
of
performance
and
simplicity.
For
example,
a
<span>
with
just
a
style
change
and
no
semantics
may
not
get
its
own
accessible
object,
but
the
style
change
will
be
exposed
by
other
means.
This section is normative .
This specification indicates whether a section is normative or informative and the classification applies to the entire section. A statement "This section is normative" or "This section is informative" applies to all sub-sections of that section.
Normative
sections
provide
requirements
that
user
agents
must
follow
for
an
implementation
to
conform
to
this
specification.
The
keywords
MUST
,
MUST
NOT
,
REQUIRED
,
SHALL
,
SHALL
NOT
,
SHOULD
,
RECOMMENDED
,
MAY
,
and
OPTIONAL
in
this
document
are
to
be
interpreted
as
described
in
Keywords
for
use
in
RFCs
to
indicate
requirement
levels
[
RFC2119
].
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.
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.
This section is informative .
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 the Microsoft Active Accessibility [ MSAA ], the Microsoft User Interface Automation [ UIA-ARIA ], the Mac OS X Accessibility Protocol [ AXAPI ], the Linux/Unix Accessibility Toolkit [ ATK ] and Assistive Technology Service Provider Interface [ AT-SPI ], and IAccessible2 [ IA2 ].
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.
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.
A simple use for the accessible name property may be illustrated by an "OK" button. The text "OK" is the accessible name. When the button receives focus, assistive technologies may concatenate the platform's role description with the accessible name. For example, a screen reader may speak "push-button OK" or "OK button". The order of concatenation and specifics of the role description (e.g. "button", "push-button", "clickable button") are determined by platform accessibility APIs or assistive technologies.
A user interface object whose basic accessibility is exposed to assistive technology via a platform accessibility API . Accessible objects are included in the accessibility tree . MS UIA represents accessible objects as automation elements.
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
acts
as
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.
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.
Indicates
that
the
element
is
not
visible
or
perceivable
to
any
user.
An
element
is
only
considered
hidden
in
the
DOM
if
it
or
one
of
its
ancestor
elements
has
the
aria-hidden
(state)
attribute
set
to
true
.
Note:
Authors
are
reminded
that
visibility:hidden
and
display:none
apply
to
all
CSS
media
types
;
therefore,
use
of
either
will
hide
the
content
from
assistive
technologies
that
access
the
DOM
through
a
rendering
engine.
However,
in
order
to
support
assistive
technologies
that
access
the
DOM
directly,
or
other
authoring
techniques
to
visibly
hide
content
(for
example,
opacity
or
off-screen
positioning
),
authors
need
to
ensure
the
aria-hidden
attribute
is
always
updated
accordingly
when
an
element
is
shown
or
hidden.
hidden,
unless
the
intent
of
using
off-screen
positioning
is
to
make
the
content
visible
only
to
screen
reader
users
and
not
others.
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 Guideline 2.1; "Make all functionality available from a keyboard" [ WCAG20 ].
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 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 how to process them: aria-live, aria-relevant, aria-atomic, and aria-busy. Pre-defined live region roles are listed in the Choosing Between Special Case Live Regions ([ ARIA-PRACTICES ], Section 5.3).
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.
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.
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.
Presentable to users in ways they can sense. References in this document relate to WCAG 2 Principle 1; content must be perceivable [ WCAG20 ].
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 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 .
Presentable to users in ways they can construct an appropriate meaning. References in this document relate to WCAG 2 Principle 3; Information and the operation of user interface must be understandable [ WCAG20 ].
Any
software
that
retrieves
and
retrieves,
renders
web
content
for
users,
such
as
web
browsers,
media
players,
plug-ins,
and
facilitates
end
user
interaction
with
Web
content.
This
definition
may
differ
from
that
used
in
other
programs
including
assistive
technologies
.
documents.
A reference to a target element in the same document that has a matching ID
A literal that solidifies the information expressed by a state , property , role , or text content.
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).
This section is normative .
Enabling
keyboard
navigation
in
web
applications
is
a
necessary
step
toward
making
accessible
web
applications
possible.
User
agents
MUST
provide
a
mechanism
for
authors
to
specify
that
any
renderable
element
may
be
focusable
without
placing
the
element
in
a
pre-defined
tabbing
order.
In
HTML
for
example,
tabindex
is
used
to
provide
this
function.
User agents MUST also provide programmatic access to all focusable elements. This allows for device-independent access, is needed to conform to the User Agent Accessibility Guidelines [ UAAG ], and is vital for a successful implementation of WAI-ARIA .
Usable
keyboard
navigation
in
a
rich
Internet
application
is
different
from
the
tabbing
paradigm
among
interactive
elements
such
as
links
and
form
controls
in
a
static
document.
In
rich
internet
applications,
the
user
tabs
to
significant
complex
widgets
and
uses
the
arrow
keys
to
navigate
within
a
complex
widget,
such
as
a
menu
or
spreadsheet.
The
changes
that
WAI-ARIA
introduces
in
keyboard
navigation
make
this
enhanced
accessibility
possible.
In
WAI-ARIA
,
any
element
can
be
keyboard
focusable.
In
addition
to
host
language
mechanisms
such
as
tabindex
in
HTML
,
aria-activedescendant
provides
another
mechanism
for
keyboard
operation.
Most
other
aspects
of
WAI-ARIA
widget
development
depend
on
keyboard
navigation
functioning
properly.
Assistive technologies often need to set the focus. For example, voice input software, onscreen keyboards and screen readers supply their own structured navigation modes, providing additional commands for moving to elements in a page. User agents need to allow assistive technologies to set the focus. See the section titled " Handling focus changes from the Assistive Technology " for details.
The following table defines the accessibility API keyboard focus states and events used in later sections of the document.
MSAA | Microsoft UIA | ATK / AT-SPI | Mac OS X Accessibility | |
---|---|---|---|---|
Focusable state |
STATE_SYSTEM_FOCUSABLE
|
UIA_IsKeyboardFocusablePropertyId
|
ATK_STATE_FOCUSABLE
|
boolean
AXFocused
(writable)
|
Focused state |
STATE_SYSTEM_FOCUSED
|
UIA_HasKeyboardFocusPropertyId
|
ATK_STATE_FOCUSED
|
boolean
AXFocused
|
Focus event |
EVENT_OBJECT_FOCUS
|
UIA_AutomationFocusChangedEventId
|
or
object:focus
|
AXFocusedUIElementChanged
|
tabindex
Editorial Note: this section is specific to HTML only and may be moved to the HTML Implementation Guide.
User
agents
that
support
WAI-ARIA
for
HTML
expand
the
usage
of
tabindex
,
focus
,
and
blur
to
allow
them
on
all
HTML
elements
.
Authors
may
add
any
element
such
as
a
div
,
span
or
img
to
the
default
tab
order
by
setting
tabindex="0"
.
In
addition,
any
item
with
tabindex
equal
to
a
negative
integer
is
focusable
via
script
or
a
mouse
click,
but
is
not
part
of
the
default
tab
order.
This
is
not
supported
in
the
HTML
4
specification
but
is
expected
to
be
in
compliance
with
HTML
5.
The
tabindex
system
provides
one
way
to
develop
custom
widgets
which
are
keyboard
accessible
,
from
simple
widgets
like
a
slider
to
container
widgets
like
a
menubar
,
treeview
or
grid
.
Note: refer to the Table of accessibility APIs for focus states and events for the rules in this section.
The
user
agent
MUST
do
the
following
to
enable
accessible
tabindex
usage
on
all
elements:
tabindex
equals
a
negative
integer,
set
the
focusable
state,
but
do
not
include
the
element
in
the
sequential
tab
order.
tabindex="0"
,
set
the
focusable
state
and
include
it
in
the
sequential
tab
order.
tabindex
is
greater
than
zero,
set
the
focusable
state,
and
include
the
element
in
the
sequential
tab
order
according
to
the
value
of
the
tabindex
attribute
and
before
any
elements
with
tabindex
either
omitted
or
with
a
value
of
zero.
See
Sequential
focus
navigation
[
HTML5
]
for
details.
element.tabIndex
property
for
every
HTML
element
that
supports
the
tabindex
attribute.
focus
and
blur
methods
to
the
HTMLElement
interface
(available
to
script
for
every
type
of
element).
focus
,
blur
,
DOMFocusIn
,
and
DOMFocusOut
events
for
any
element
that
can
receive
focus.
keydown
event
is
cancelled,
also
cancel
the
keypress
event.
tabindex
attribute
in
a
manner
other
than
clicking
it,
such
as
by
pressing
Enter
,
and
the
element
has
no
defined
activation
behavior
,
fire
a
click
event.
click
on
the
element.
The
steps
to
simulate
a
click
include:
click
event
aria-activedescendant
When
implementing
aria-activedescendant
as
described
below,
the
user
agent
keeps
the
DOM
focus
on
the
container
element
but
communicates
desktop
focus
events
and
states
to
the
assistive
technology
as
if
the
active
descendant
has
focus.
It
is
the
responsibility
of
the
user
agent
to
ensure
that
keyboard
events
are
processed
at
the
container
element
that
has
DOM
focus.
Any
keyboard
events
directed
at
the
active
descendant
bubble
up
to
the
DOM
element
with
focus,
the
containter
container
element,
for
processing.
The
aria-activedescendant
property
may
be
used
to
enable
keyboard
accessibility
on
WAI-ARIA
elements
that
support
this
attribute
.
It
is
often
a
more
convenient
way
of
creating
container
widget
keyboard
navigation
(where
the
entire
widget
is
in
the
tab
order
just
once,
but
the
user
can
use
other
keys,
typically
arrow
keys,
to
navigate
to
descendant
items
of
the
container).
Typically,
the
author
will
use
host
language
semantics
to
put
the
container
element
in
the
sequential
tab
order
(
tabindex="0"
in
HTML
)
and
aria-activedescendant
to
point
to
the
ID
of
the
currently
active
descendant.
The
author,
not
the
user
agent
,
is
responsible
for
styling
the
currently
active
descendant
to
show
it
has
keyboard
focus.
The
author
cannot
use
:
focus
to
style
the
currently
active
descendant
since
actual
focus
is
on
the
container.
Note: Refer to the Table of accessibility APIs for focus states and events for the rules in this section.
The
user
agent
MUST
do
the
following
to
implement
aria-activedescendant
:
tabindex
.
aria-activedescendant
which
points
to
a
valid
ID
.
aria-activedescendant
attribute
changes
on
an
element
that
currently
has
DOM
focus,
remove
the
focused
state
from
the
previously
focused
object
and
fire
an
accessibility
API
desktop
focus
event
on
the
new
active
descendant.
If
aria-activedescendant
is
cleared
or
does
not
point
to
an
element
in
the
current
document,
fire
a
desktop
focus
event
for
the
container
object
that
had
the
attribute
change.
aria-activedescendant
attribute,
apply
the
following
accessibility
API
states
to
the
target
to
ensure
the
object
is
accessible:
aria-activedescendant
of
the
container
can
potentially
point
to
it.
It
is
not
absolutely
necessary
to
check
this
when
there
is
no
role,
because
HTML
elements
that
would
be
focusable
would
already
have
the
focusable
state.
aria-activedescendant
to
match
the
ID
of
this
descendant
and
the
container
widget
with
aria-activedescendant
has
DOM
Assistive technologies, such as screen readers, voice input software and on-screen keyboards, might request that the keyboard focus be moved using the following accessibility APIs :
accSelect(SELFLAG_TAKEFOCUS)
RaiseAutomationEvent
AtkComponent::grab_focus
AXFocusedUIElementChanged
Note: Refer to the Table of accessibility APIs for focus states and events for the rules in this section.
When an assistive technology requests a change of focus using one of the above APIs , user agents MUST do the following:
aria-activedescendant
attribute
present,
the
user
agent
MUST
set
DOM
focus
to
that
ancestor.
When
it
is
not
possible
for
the
user
agent
to
set
DOM
focus
to
the
containing
element
with
aria-activedescendant
,
the
user
agent
MAY
attempt
to
set
DOM
focus
to
the
child
element
itself.
aria-activedescendant
attribute
present,
the
user
agent
MUST
set
the
accessibility
API
focused
state
and
fire
an
accessibility
API
desktop
focus
event
on
the
new
active
descendant.
Note: the inability to set DOM focus to the containing element indicates an author error.
This section is normative .
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, 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 does not define mechanisms for assistive technologies to directly modify WAI-ARIA information.
The following elements are not exposed via the accessibility API and user agents MUST NOT include them in the accessibility tree :
presentation
as
the
first
mappable
role
in
the
role
attribute
string,
according
to
the
rules
for
presentation
role
defined
in
Accessible
Rich
Internet
Applications
(WAI-ARIA)
1.0
[
ARIA
].
display:none
or
visibility:hidden
or
HTML
5
hidden
attribute.
If not already excluded from the accessibility tree per the above rules, user agents SHOULD NOT include the following elements in the accessibility tree:
aria-hidden
="true".
In
other
words,
aria-hidden="true"
on
a
parent
overrides
aria-hidden="false"
on
descendants.
If
not
already
excluded
from
the
accessibility
tree
per
the
rules
above
in
Excluding
Elements
in
the
Accessibility
Tree
,
User
user
agents
MUST
provide
an
accessible
object
in
the
accessibility
tree
corresponding
to
for
DOM
elements
that
meet
any
of
the
following
criteria:
aria-activedescendant
attribute
that
matches
the
implicit
or
explicit
semantics
of
the
required
context
role.
In
either
case,
the
element
may
receive
focus
and
need
to
fire
a
FOCUS
event.
aria-hidden
="true"
.
(See
aria-hidden
.)
.)
aria-controls
,
aria-describedby
,
aria-flowto
,
aria-labelledby
or
aria-owns
)
and
Note:
Text
equivalents
for
presentation
role
defined
hidden
referenced
objects
may
still
be
used
in
Accessible
Rich
Internet
Applications
(WAI-ARIA)
1.0
[
ARIA
].
The
following
elements
are
not
exposed
via
the
accessibility
API
name
and
user
agents
SHOULD
NOT
include
them
description
calculation
even
when
not
included
in
the
accessibility
tree:
tree.
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",
isn't
correct
because
it
doesn't
properly
communicate
the
additional
features
of
a
spin
button.
The
author
will
add
the
WAI-ARIA
role
of
spinbutton
(
<input
type="text"
role="spinbutton"
...>
)
so
that
the
control
gets
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.
Editorial 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 .
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:
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
.
AriaRole
and
AriaProperties
properties
to
expose
semantics
that
are
not
directly
supported
in
the
control
Editorial 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.
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.
The following rules describe how to expose WAI-ARIA roles using the accessibility API :
The following steps will correctly identify the applicable WAI-ARIA role:
table
to
determine
what
platform
accessibility
API
role
to
use
according
to
the
host
language's
role
mapping.
For
<input
type="text"
role="bar">
,
use
the
platform
accessibility
API
for
a
text
input.
presentation
is
applied
to
an
element,
the
user
agent
MUST
implement
the
rules
for
presentation
role
defined
in
Accessible
Rich
Internet
Applications
(WAI-ARIA)
1.0
[
ARIA
].
xml-roles:"string"
)
AriaRole
property.
The
AriaRole
property
can
also
support
secondary
roles
using
a
space
as
a
separator.
xml-roles:"string"
)
WAI-ARIA role | MSAA + UIA Express role | MSAA + IAccessible2 role and other IAccessible2 features |
UIA
Control
| ATK / AT-SPI role |
Mac OS X
AXRole
|
---|---|---|---|---|---|
alert
|
ROLE_SYSTEM_ALERT
The
user
agent
SHOULD
fire
|
ROLE_SYSTEM_ALERT
The
user
agent
SHOULD
fire
|
Text
The user agent SHOULD fire a system alert event . [ Note 2 ] |
The user agent SHOULD fire a system alert event. [ Note 2 ] |
AXGroup
AXApplicationAlert
'alert'
The user agent SHOULD fire a system alert event. [ Note 2 ] |
alertdialog
|
ROLE_SYSTEM_DIALOG
The
user
agent
SHOULD
fire
|
ROLE_SYSTEM_DIALOG
The
user
agent
SHOULD
fire
|
The user agent SHOULD fire a system alert event. [ Note 2 ] |
The user agent SHOULD fire a system alert event. [ Note 2 ] |
AXGroup
AXApplictionAlertDialog
'alert
dialog'
The user agent SHOULD fire a system alert event. [ Note 2 ] |
application
|
ROLE_SYSTEM_APPLICATION
|
ROLE_SYSTEM_APPLICATION
|
Pane
|
|
AXGroup
AXLandmarkApplication
'application'
|
article
|
ROLE_SYSTEM_DOCUMENT
+
STATE_SYSTEM_READONLY
|
ROLE_SYSTEM_DOCUMENT
+
STATE_SYSTEM_READONLY
|
Expose
as
text
string
in
AriaRole
|
+
do
not
expose
STATE_EDITABLE
|
AXGroup
AXDocumentArticle
'article'
|
banner
|
AriaRole
|
IAccessible2:
Object
attribute
xml-roles:banner
|
Expose
as
text
string
in
AriaRole
|
Object
attribute
xml-roles:
banner
|
AXGroup
AXLandmarkBanner
'banner'
|
button
|
ROLE_SYSTEM_PUSHBUTTON
.
|
ROLE_SYSTEM_PUSHBUTTON
.
If
aria-pressed
is
not
undefined
,
it
SHOULD
be
exposed
as
IA2_ROLE_TOGGLE_BUTTON
|
Button
|
If
|
AXButton
<nil>
'button'
|
checkbox
|
ROLE_SYSTEM_CHECKBUTTON
|
ROLE_SYSTEM_CHECKBUTTON
IAccessible2:
Object
attribute
|
Checkbox
|
+
object
attribute
checkable:true
|
AXCheckBox
<nil>
'check
box'
|
columnheader
|
ROLE_SYSTEM_COLUMNHEADER
|
ROLE_SYSTEM_COLUMNHEADER
IAccessible2:
Used
to
help
support
|
|
|
Parent
table
also
implements
Parent
table
also
implements
|
combobox
|
ROLE_SYSTEM_COMBOBOX
+
STATE_SYSTEM_HASPOPUP
.
If
|
ROLE_SYSTEM_COMBOBOX
+
STATE_SYSTEM_HASPOPUP
.
If
|
Combobox
|
+
STATE_EXPANDABLE
+
object
attribute
haspopup:true
|
AXComboBox
<nil>
'combo
box'
|
complementary
|
AriaRole
|
IAccessible2:
Object
attribute
xml-roles:complementary
|
Expose
as
text
string
in
AriaRole
|
Object
attribute
xml-roles:
complementary
|
AXGroup
AXLandmarkComplementary
'complementary'
|
contentinfo
|
AriaRole
|
IAccessible2:
Object
attribute
xml-roles:contentinfo
|
Expose
as
text
string
in
AriaRole
|
Object
attribute
xml-roles:
contentinfo
|
AXGroup
AXLandmarkContentInfo
'content'
|
definition
|
AriaRole
|
IAccessible2:
Object
attribute
xml-roles:definition
|
Expose
as
text
string
in
AriaRole
|
Object
attribute
xml-roles:definition
|
AXGroup
AXDefinition
'definition'
|
dialog
|
ROLE_SYSTEM_DIALOG
|
ROLE_SYSTEM_DIALOG
|
|
|
AXGroup
AXApplicationDialog
'dialog'
|
directory
|
ROLE_SYSTEM_LIST
|
ROLE_SYSTEM_LIST
|
List
|
|
AXList
AXContentList
'content
list'
|
document
|
ROLE_SYSTEM_DOCUMENT
+
STATE_SYSTEM_READONLY
|
ROLE_SYSTEM_DOCUMENT
+
STATE_SYSTEM_READONLY
|
Document
|
+
do
not
expose
STATE_EDITABLE
|
AXGroup
AXDocument
'document'
|
form
|
AriaRole
|
IAccessible2:
IA2_ROLE_FORM
|
Expose
as
text
string
in
AriaRole
|
|
AXGroup
<nil>
'group'
|
grid
|
ROLE_SYSTEM_TABLE
|
ROLE_SYSTEM_TABLE
IAccessible2:
Use
|
Also
requires
|
|
AXTable
<nil>
'table'
|
gridcell
|
ROLE_SYSTEM_CELL
|
ROLE_SYSTEM_CELL
|
DataItem
Also
requires
|
|
AXCell
<nil>
'cell'
|
group
|
ROLE_SYSTEM_GROUPING
|
ROLE_SYSTEM_GROUPING
|
Group
|
|
AXGroup
<nil>
'group'
|
heading
|
ROLE_SYSTEM_TEXT
|
ROLE_SYSTEM_TEXT
or use
xml-roles
|
Text
|
|
AXHeading
<nil>
'heading'
|
img
|
ROLE_SYSTEM_GRAPHIC
|
ROLE_SYSTEM_GRAPHIC
|
Image
|
|
AXImage
<nil>
'image'
|
link
|
ROLE_SYSTEM_LINK
.
Also,
apply
special
rule
to
expose
|
ROLE_SYSTEM_LINK
.
Also,
apply
special
rule
to
expose
AccessibleHypertext
interface
|
HyperLink
|
|
AXLink
<nil>
'link'
|
list
|
ROLE_SYSTEM_LIST
+
STATE_SYSTEM_READONLY
|
ROLE_SYSTEM_LIST
+
STATE_SYSTEM_READONLY
|
When
the
|
+
do
not
expose
STATE_EDITABLE
|
AXList
AXContentList
'content
list'
|
If
child
of
or
owned
by
a
|
ROLE_SYSTEM_LIST
|
ROLE_SYSTEM_LIST
|
List
|
.
Special
case:
if
a
listbox
has
a
parent
or
is
owned
by
(via
aria-owns
)
a
combobox
,
it
SHOULD
be
exposed
with
.
|
AXList
<nil>
'list'
|
listitem
|
ROLE_SYSTEM_LISTITEM
+
STATE_SYSTEM_READONLY
|
ROLE_SYSTEM_LISTITEM
+
STATE_SYSTEM_READONLY
|
Also
requires
|
+
do
not
expose
STATE_EDITABLE
|
AXGroup
<nil>
'group'
|
log
|
ROLE_SYSTEM_PANE
|
IAccessible2:
object
attributes
|
Pane
|
|
AXGroup
AXApplicationLog
'log'
|
main
|
AriaRole
|
IAccessible2:
Object
attribute
xml-roles:main
|
Expose
as
text
string
in
AriaRole
|
Object
attribute
xml-roles:main
|
AXGroup
AXLandmarkMain
'main'
|
marquee
|
ROLE_SYSTEM_ANIMATION
|
IAccessible2:
object
attribute
|
Text
|
+
object
attributes
container-live:off;live:off
|
AXGroup
AXApplicationMarquee
'marquee'
|
math
|
ROLE_SYSTEM_EQUATION
|
ROLE_SYSTEM_EQUATION
|
Expose
as
text
string
in
AriaRole
|
|
AXGroup
AXDocumentMath
'math'
|
menu
|
ROLE_SYSTEM_MENUPOPUP
|
ROLE_SYSTEM_MENUPOPUP
|
Menu
|
These objects SHOULD NOT be exposed for a submenu if there is a parent menu item spawning the submenu |
AXMenu
<nil>
'menu'
|
menubar
|
ROLE_SYSTEM_MENUBAR
|
ROLE_SYSTEM_MENUBAR
|
MenuBar
|
|
AXMenuBar
<nil>
'menu
bar'
|
menuitem
|
ROLE_SYSTEM_MENUITEM
|
ROLE_SYSTEM_MENUITEM
|
MenuItem
|
If
|
If
the
option's
parent
has
a
group
role,
then
role="menuitem"
maps
to
AXMenuButton
If
the
option's
parent
has
a
|
menuitemcheckbox
|
ROLE_SYSTEM_CHECKBUTTON
or
ROLE_SYSTEM_MENUITEM
|
ROLE_SYSTEM_CHECKBUTTON
or
ROLE_SYSTEM_MENUITEM
|
+
Toggle
Pattern
|
+
object
attribute
checkable:true
|
If
|
menuitemradio
|
ROLE_SYSTEM_RADIOBUTTON
or
ROLE_SYSTEM_MENUITEM
|
|
|
+
object
attribute
checkable:true
|
If
|
navigation
|
AriaRole
|
IAccessible2:
Object
attribute
xml-roles:navigation
|
Expose
as
text
string
in
AriaRole
|
Object
attribute
xml-roles:navigation
|
AXGroup
AXLandmarkNavigation
'navigation'
|
note
|
AriaRole
|
IAccessible2:
IA2_ROLE_NOTE
|
Expose
as
text
string
in
AriaRole
|
Object
attribute
xml-roles:note
|
AXGroup
AXDocumentNote
'note'
|
option
|
ROLE_SYSTEM_LISTITEM
|
ROLE_SYSTEM_LISTITEM
IAccessible2:
If
|
ListItem
+
Invoke
pattern
|
If
Special
case:
if
an
|
If
the
option's
parent
has
a
menu
role,
then
role="option"
maps
to
AXMenuItem
If
the
option's
parent
has
a
|
presentation
|
|
If
the
object
is
in
the
accessibility
tree,
expose
as
ROLE_SYSTEM_PANE
|
If
the
object
is
in
the
accessibility
tree,
expose
as
|
If
the
object
is
in
the
accessibility
tree,
expose
as
|
Not mapped |
progressbar
|
ROLE_SYSTEM_PROGRESSBAR
+
STATE_SYSTEM_READONLY
|
ROLE_SYSTEM_PROGRESSBAR
+
STATE_SYSTEM_READONLY
|
If
any
of
the
|
+
do
not
expose
STATE_EDITABLE
|
AXProgressIndicator
<nil>
'progress
indicator'
|
radio
|
ROLE_SYSTEM_RADIOBUTTON
|
ROLE_SYSTEM_RADIOBUTTON
|
RadioButton
|
|
AXRadioButton
<nil>
'radio
button'
|
radiogroup
|
ROLE_SYSTEM_GROUPING
|
ROLE_SYSTEM_GROUPING
|
|
|
AXRadioGroup
<nil>
'radio
group'
|
region
|
ROLE_SYSTEM_PANE
|
ROLE_SYSTEM_PANE
|
Pane
|
|
AXGroup
AXDocumentRegion
'region'
|
row
|
ROLE_SYSTEM_ROW
unless
inside
a
tree
or
treegrid
,
in
which
case
ROLE_SYSTEM_OUTLINEITEM
|
ROLE_SYSTEM_ROW
unless
inside
a
tree
or
treegrid
,
in
which
case
ROLE_SYSTEM_OUTLINEITEM
IAccessible2:
Used
to
help
support:
|
Also
requires
|
|
AXRow
<nil>
'row'
|
rowgroup
|
Note:
the
|
Not mapped
Note:
the
|
Note:
the
|
Not mapped
Note:
the
|
No mapping
Note:
the
|
rowheader
|
ROLE_SYSTEM_ROWHEADER
|
ROLE_SYSTEM_ROWHEADER
IAccessible2:
Used
to
help
support
|
|
|
Parent
table
also
implements
|
scrollbar
|
ROLE_SYSTEM_SCROLLBAR
|
ROLE_SYSTEM_SCROLLBAR
|
|
|
AXScrollBar
<nil>
'scroll
bar'
|
search
|
AriaRole
|
Expose
as
text
string
in
AriaRole
|
Object
attribute
xml-roles:search
|
AXGroup
AXLandmarkSearch
'search'
| |
separator
|
ROLE_SYSTEM_SEPARATOR
|
ROLE_SYSTEM_SEPARATOR
|
Separator
|
|
AXSplitter
<nil>
'splitter'
|
slider
|
ROLE_SYSTEM_SLIDER
|
ROLE_SYSTEM_SLIDER
|
Slider
|
|
AXSplitter
<nil>
'splitter'
|
spinbutton
|
ROLE_SYSTEM_SPINBUTTON
|
ROLE_SYSTEM_SPINBUTTON
|
Spinner
|
|
AXIncrementor
<nil>
'stepper'
|
status
|
ROLE_SYSTEM_STATUSBAR
|
IAccessible2:
object
attributes
|
StatusBar
|
+
object
attributes
container-live:polite;live:polite;container-live-role:status
|
AXGroup
AXApplicationStatus
'status'
|
tab
|
ROLE_SYSTEM_PAGETAB
.
Expose
|
ROLE_SYSTEM_PAGETAB
.
Expose
|
TabItem
|
.
Expose
SELECTED
state
if
focus
is
inside
tabpanel
associated
with
aria-labelledby
.
|
AXRadioButton
<nil>
'tab'
|
tablist
|
ROLE_SYSTEM_PAGETABLIST
|
IAccessible2:
object
attributes
|
Also
requires
|
+
object
attributes
container-live:polite;live:polite;container-live-role:tablist
|
AXTabGroup
<nil>
'tabgroup'
|
tabpanel
|
ROLE_SYSTEM_PANE
or
ROLE_SYSTEM_PROPERTYPAGE
|
ROLE_SYSTEM_PANE
or
ROLE_SYSTEM_PROPERTYPAGE
|
Pane
|
|
AXGroup
TabPanel
'tab
panel'
|
textbox
|
ROLE_SYSTEM_TEXT
|
ROLE_SYSTEM_TEXT
|
|
+
STATE_SINGLE_LINE
if
aria-multiline
is
not
"true"
|
If
If
|
timer
|
AriaRole
|
IAccessible2:
Object
attribute
xml-roles:timer;container-live:off;live:off;container-live-role:timer
|
Expose
as
text
string
in
AriaRole
|
+
object
attributes
container-live:off;live:off;container-live-role:timer
|
AXGroup
AXApplicationTimer
'timer'
|
toolbar
|
ROLE_SYSTEM_TOOLBAR
|
ROLE_SYSTEM_TOOLBAR
|
ToolBar
|
|
AXToolbar
<nil>
'toolbar'
|
tooltip
|
ROLE_SYSTEM_TOOLTIP
|
ROLE_SYSTEM_TOOLTIP
|
ToolTip
|
|
AXGroup
AXUserInterfaceTooltip
'tooltip'
|
tree
|
ROLE_SYSTEM_OUTLINE
|
ROLE_SYSTEM_OUTLINE
|
Tree
|
|
AXOutline
<nil>
'outline'
|
treegrid
|
ROLE_SYSTEM_OUTLINE
|
ROLE_SYSTEM_OUTLINE
IAccessible2:
|
DataGrid
|
|
AXTable
<nil>
'table'
|
treeitem
|
ROLE_SYSTEM_OUTLINEITEM
|
ROLE_SYSTEM_OUTLINEITEM
IAccessible2:
If
|
TreeItem
|
+
if
aria-checked
is
not
undefined
,
support
object
attribute
checkable:true
|
AXRow
AXOutlineRow
'outline
row'
|
[ Note 1 ] User agent should return a user-presentable, localized string value for the AXRoleDescription.
[ Note 2 ] Editorial Note: 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 ).
This section describes how to expose WAI-ARIA states and object properties .
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
.
See
the
rules
in
Controlling
focus
with
aria-activedescendant
.
aria-labelledby
attribute
but
the
native
HTML
semantics
must
still
be
exposed.
aria-
"
prefix
from
the
name,
if
the
API
supports
it.
For
example,
aria-foo="bar"
would
be
exposed
with
a
text
string
foo=bar
in
UIA
,
since
aria-foo
is
not
a
currently
known
WAI-ARIA
property.
The
following
list
specifies
the
accessibility
APIs
for
exposing
properties
as
text
strings.
property:string
)
AriaProperties
(
property=string
)
property:string
)
aria-checked="true"
is
specified
on
<div
role="grid">
,
it
should
not
be
exposed
in
MSAA
implementations
as
STATE_SYSTEM_CHECKED
.
User
agents
MAY
expose
non-relevant
attributes
as
a
text
string
if
the
API
supports
it
as
described
above.
presentation
is
applied
to
an
element,
the
user
agent
MUST
implement
the
rules
for
presentation
role
defined
in
Accessible
Rich
Internet
Applications
(WAI-ARIA)
1.0
[
ARIA
].
WAI-ARIA State or Property | MSAA + UIA Express | MSAA + IAccessible2 | UIA | ATK / AT-SPI | Mac OS X |
---|---|---|---|---|---|
aria-activedescendant
|
See
Controlling
focus
with
aria-activedescendant
,
Handling
focus
changes
from
the
Assistive
Technology
,
and
ID
Reference
Error
Processing
in
Relations
.
In
cases,
however,
the
focus
can
be
transparent
in
an
accessibility
tree
as
it
may
be
exposed
as
focus
delegation
from
the
container
element
to
the
child
object
that
takes
active
focus.
This
is
represented
by
an
accessible
object
that
comes
with
|
See
Controlling
focus
with
aria-activedescendant
,
Handling
focus
changes
from
the
Assistive
Technology
,
and
ID
Reference
Error
Processing
in
Relations
.
In
cases,
however,
the
focus
can
be
transparent
in
an
accessibility
tree
as
it
may
be
exposed
as
focus
delegation
from
the
container
element
to
the
child
object
that
takes
active
focus.
This
is
represented
by
an
accessible
object
that
comes
with
|
See
Controlling
focus
with
aria-activedescendant
,
Handling
focus
changes
from
the
Assistive
Technology
,
and
ID
Reference
Error
Processing
in
Relations
.
|
See
Controlling
focus
with
aria-activedescendant
,
Handling
focus
changes
from
the
Assistive
Technology
,
and
ID
Reference
Error
Processing
in
Relations
.
In
cases,
however,
the
focus
can
be
transparent
in
an
accessibility
tree
as
it
may
be
exposed
as
focus
delegation
from
the
container
element
to
the
child
object
that
takes
active
focus.
This
is
represented
by
an
accessible
object
that
comes
with
|
array
AXSelectedRows
contains
pointer
to
active
descendant
node
|
aria-atomic
="true"
|
atomic=true
in
AriaProperties
|
IAccessible2:
|
Expose
atomic=true
in
AriaProperties
|
Expose
object
attribute
In
addition,
expose
object
attribute
|
boolean
AXARIAAtomic
|
aria-atomic
="false"
(default)
|
atomic=false
in
AriaProperties
| Not mapped |
Expose
atomic=false
in
AriaProperties
| Not mapped |
boolean
AXARIAAtomic
|
aria-autocomplete
="inline"
,
"list"
,
or
"both"
|
autocomplete=<value>
in
AriaProperties
|
IAccessible2:
|
Expose
autocomplete=<value>
in
AriaProperties
|
Object
attribute
autocomplete:<value>
Expose
the
| Not mapped |
aria-autocomplete
="none"
(default)
| Not mapped | Not mapped | Not mapped | Not mapped | Not mapped |
aria-busy
="true"
(state)
|
Expose
the
STATE_SYSTEM_BUSY
state
|
Expose
the
STATE_SYSTEM_BUSY
state
|
Expose
busy=true
in
AriaProperties
|
Expose
the
STATE_BUSY
state
|
boolean
AXARIABusy
|
aria-busy
="false"
(state)
(default)
|
Clear
the
STATE_SYSTEM_BUSY
state
|
Clear
the
STATE_SYSTEM_BUSY
state
|
Expose
busy=false
in
AriaProperties
|
Clear
the
STATE_BUSY
state
|
boolean
AXARIABusy
|
aria-checked
="true"
(state)
|
Toggle
Control
Pattern
|
Set
the
STATE_SYSTEM_CHECKED
state
IAccessible2:
Expose
object
attribute
|
Expose
as
ToggleState
property
in
Toggle
Control
Pattern
|
Expose
object
attribute
Set
the
|
AXValue:
1
|
aria-checked
="false"
(state)
|
Toggle
Control
Pattern.
|
Clear
the
STATE_SYSTEM_CHECKED
state
IAccessible2:
Expose
object
attribute
|
Expose
as
ToggleState
property
in
Toggle
Control
Pattern.
|
Clear
the
Expose
object
attribute
|
AXValue:
0
|
aria-checked
="mixed"
(state)
Treat
as
|
Toggle
Control
Pattern.
|
Set
the
STATE_SYSTEM_MIXED
state
IAccessible2:
Expose
object
attribute
|
Expose
as
ToggleState
property
in
Toggle
Control
Pattern.
|
Expose
STATE_INDETERMINATE
,
unless
on
a
role
of
radio
or
menuitemradio
(in
those
cases
treat
as
"false"
)
Expose
object
attribute
|
AXValue:
2
|
aria-checked
is
undefined
(state)
|
ToggleState
property
of
"0"
in
Toggle
Control
Pattern.
|
STATE_SYSTEM_CHECKED
state
|
ToggleState
property
of
"0"
in
Toggle
Control
Pattern.
|
STATE_CHECKED
state
| Not mapped |
aria-controls
|
ControllerFor
property
|
IAccessible2:
|
Expose
pointer
to
the
accessible
object
ControllerFor
property
|
Expose
pointer
to
the
accessible
object
RELATION_CONTROLLER_FOR
Expose reverse relations as described in Relations . |
array
AXLinkedUIElements
contains
pointers
to
nodes
matching
IDREFs
|
aria-describedby
|
Use
in
calculating
the
accessible
Description
as
described
in
Name
Computation
.
Expose
in
accDescription
property.
|
Use
in
calculating
the
accessible
Description
as
described
in
Name
Computation
.
Expose
in
accDescription
property.
IAccessible2:
|
Use in calculating the accessible Description as described in Name Computation .
Expose
pointer
to
the
accessible
object
in
|
Use
in
calculating
the
accessible
Description
as
described
in
Name
Computation
.
Expose
pointer
to
the
accessible
object
in
RELATION_DESCRIBED_BY
Expose reverse relations as described in Relations . |
Use
in
calculating
the
accessible
Description
as
described
in
Name
Computation
.
Expose
in
string
AXDescription
(reserved
for
non-visible
accessible
name
or
calculated
description)
|
aria-disabled
="true"
(state)
|
Set
|
Set
STATE_SYSTEM_UNAVAILABLE
Expose
Propagate
to
all
descendants
of
the
element
with
|
Set
IsEnabled
to
"false"
| Not mapped |
boolean
AXEnabled
|
aria-disabled
="false"
(state)
(default)
|
to
"true"
|
Clear
STATE_SYSTEM_UNAVAILABLE
|
Set
IsEnabled
to
"true"
|
Expose
STATE_ENABLED
|
boolean
AXEnabled
|
aria-dropeffect
="copy"
,
"move"
,
"link"
,
"execute"
,
or
"popup"
(state)
|
dropeffect=<value>
in
AriaProperties
|
IAccessible2:
Expose
as
object
attribute
dropeffect:<value>
|
Expose
dropeffect=<value>
in
AriaProperties
|
Expose
as
object
attribute
dropeffect:<value>
|
array
AXDropEffects
|
aria-dropeffect
="none"
(state)
(default)
| Not mapped |
IAccessible2:
Expose
as
object
attribute
Not mapped if not specified by the author. | Not mapped |
Expose
as
object
attribute
Not mapped if not specified by the author. | Not mapped |
aria-expanded
="true"
(state)
|
property
of
ExpandCollapse
Control
Pattern
|
Set
STATE_SYSTEM_EXPANDED
|
Expose
as
ExpandCollapseState
property
of
ExpandCollapse
Control
Pattern
|
Expose
STATE_EXPANDABLE
and
STATE_EXPANDED
|
boolean
AXExpanded
|
aria-expanded
="false"
(state)
|
property
of
ExpandCollapse
Control
Pattern
|
Set
STATE_SYSTEM_COLLAPSED
|
Expose
as
ExpandCollapseState
property
of
ExpandCollapse
Control
Pattern
|
Expose
STATE_EXPANDABLE
|
boolean
AXExpanded
|
aria-expanded
is
undefined
(state)
(default)
| Not mapped | Not mapped | Not mapped | Not mapped | Not mapped |
aria-flowto
|
FlowsTo
property
|
IAccessible2:
|
Expose
a
reference
to
the
accessible
object
in
FlowsTo
property
|
Expose
reference
to
the
accessible
object
in
RELATION_FLOWS_TO
Expose reverse relations as described in Relations . |
array
AXLinkedUIElements
contains
pointer
to
nodes
matching
IDREFs
|
aria-grabbed
="true"
(state)
|
grabbed=true
in
AriaProperties
|
IAccessible2:
Object
attribute
grabbed:true
|
Expose
as
grabbed=true
in
AriaProperties
|
Object
attribute
grabbed:true
|
boolean
AXGrabbed
|
aria-grabbed
="false"
(state)
|
grabbed=false
in
AriaProperties
|
IAccessible2:
Object
attribute
grabbed:false
|
Expose
as
grabbed=false
in
AriaProperties
|
Object
attribute
grabbed:false
|
boolean
AXGrabbed
|
aria-grabbed
is
undefined
(state)
(default)
| Not mapped | Not mapped | Not mapped | Not mapped | Not mapped |
aria-haspopup
="true"
(default
for
role
combobox
)
|
Expose
as
STATE_SYSTEM_HASPOPUP
.
If
on
a
push
button,
change
the
role
to
ROLE_SYSTEM_BUTTONMENU
.
|
Expose
as
STATE_SYSTEM_HASPOPUP
.
If
on
a
push
button,
change
the
role
to
ROLE_SYSTEM_BUTTONMENU
.
|
Expose
state
of
the
pop-up
activities
in
the
ExpandCollapseState
property
in
the
ExpandCollapse
Control
Pattern.
|
Object
attribute
haspopup:true
|
Expose
AXShowMenu
and
AXPress
actions
|
aria-haspopup
="false"
(default)
|
Clear
the
HASPOPUP
state.
If
specified
on
a
push
button,
change
the
role
to
ROLE_SYSTEM_BUTTONMENU
|
Clear
the
HASPOPUP
state.
If
specified
on
a
push
button,
change
the
role
to
ROLE_SYSTEM_BUTTONMENU
| Not mapped | Not mapped | Not mapped |
aria-hidden
="true"
(state)
|
See Including Elements in the Accessibility Tree . If the object is in the accessibility tree, map all attributes as normal.
|
See Including Elements in the Accessibility Tree .
If
the
object
is
in
the
accessibility
tree,
map
all
attributes
as
normal.
IAccessible2:
Expose
object
attribute
|
Expose
as
hidden=true
in
AriaProperties
|
See Including Elements in the Accessibility Tree .
If
the
object
is
in
the
accessibility
tree,
map
all
attributes
as
normal.
In
addition,
expose
object
attribute
|
Not
exposed
in
AX
API
unless
focused.
If
focused,
expose
as
normal.
|
aria-hidden
="false"
(state)
(default)
| Not mapped | Not mapped | Not mapped | Not mapped | Not mapped |
aria-invalid
="true"
,
"spelling"
,
or
"grammar"
(state)
|
IsDataValidForForm
property
|
IAccessible2:
|
Expose
status
in
IsDataValidForForm
property
| Expose the value as a text attribute (not object attribute). |
string
AXInvalid
|
aria-invalid
="false"
(state)
(default)
|
IsDataValidForForm
property
|
IAccessible2:
Clear
IA2_STATE_INVALID_ENTRY
or
equivalent
state.
|
Expose
status
in
IsDataValidForForm
property
| Not mapped |
string
AXInvalid
|
aria-label
|
Use
in
calculating
the
accessible
name
as
described
in
Name
Computation
.
Expose
in
accName
property.
|
Use
in
calculating
the
accessible
name
as
described
in
Name
Computation
.
Expose
in
accName
property.
|
Use
in
calculating
the
accessible
name
as
described
in
Name
Computation
.
Expose
in
Name
property.
| Use in calculating the accessible name as described in Name Computation . |
Calculate
accessible
name
as
described
in
Name
Computation
.
Expose
as
|
aria-labelledby
|
Use
in
calculating
the
accessible
name
as
described
in
Name
Computation
.
Expose
in
accName
property.
|
Use
in
calculating
the
accessible
name
as
described
in
Name
Computation
.
Expose
in
IAccessible2:
|
Use
in
calculating
the
accessible
name
as
described
in
Name
Computation
.
Expose
in
Expose
a
reference
to
the
accessible
object
in
the
|
Use in calculating the accessible name as described in Name Computation .
Expose
a
reference
to
the
accessible
object
in
Expose reverse relations as described in Relations . |
Use
in
calculating
the
accessible
name
as
described
in
Name
Computation
.
Expose
in
string
AXTitle
(reserved
for
visible
name)
|
aria-level
|
Expose
|
Expose
the
level
by
accValue
property
of
an
outline
object.
The
structure
should
be
reflected
in
the
accessibility
tree
as
directed
by
aria-level
.
IAccessible2:
|
Expose
as
|
Expose
as
object
attribute
level:<value>
|
integer
AXValue
|
aria-live
="assertive"
(default
for
role
alert
)
|
Set
|
IAccessible2:
|
Property
to
"assertive"
|
Expose
as
object
attribute
live
.
Expose
as
object
attribute
|
string
AXARIALive
|
aria-live
="polite"
(default
for
role
types
log
and
status
)
|
LiveSetting
Property
to
"polite"
|
IAccessible2:
|
Property
to
"polite"
|
Expose
as
object
attribute
live:polite
.
Expose
as
object
attribute
|
string
AXARIALive
|
aria-live
="off"
(default)
|
LiveSetting
property
to
"off"
|
IAccessible2:
|
LiveSetting
property
to
"off"
|
Expose
as
object
attribute
live:off
.
Expose
as
object
attribute
|
string
AXARIALive
|
aria-multiline
="true"
|
multiline=true
in
AriaProperties
|
IAccessible2:
Set
the
IA2_MULTI_LINE
state
and
clear
IA2_SINGLE_LINE
|
Expose
as
multiline=true
in
AriaProperties
|
Set
STATE_MULTI_LINE
and
clear
STATE_SINGLE_LINE
|
Not mapped.
See
|
aria-multiline
="false"
(default)
| Not mapped |
IAccessible2:
Clear
the
IA2_MULTI_LINE
state,
and
set
IA2_SINGLE_LINE
| Not mapped |
Set
STATE_SINGLE_LINE
and
clear
STATE_MULTI_LINE
|
Not mapped
See
|
aria-multiselectable
="true"
|
Set
See Selection for details. |
Set
the
IAccessible2:
For
text
elements,
support
the
selection
methods
defined
on
the
See Selection for details. |
Set
See Selection for details. |
Expose
See Selection for details. |
Not mapped See Selection for details. |
aria-multiselectable
="false"
(default)
|
|
Clear
the
STATE_SYSTEM_MULTISELECTABLE
state.
Expose
STATE_SYSTEM_EXTSELECTABLE
to
exactly
match
STATE_SYSTEM_MULTISELECTABLE
.
See Selection for details. | Not mapped | Not mapped | Not mapped |
aria-orientation
="horizontal"
(default)
|
Set
|
IAccessible2:
Set
IA2_STATE_HORIZONTAL
|
property
to
"horizontal"
|
Set
STATE_HORIZONTAL
|
AXOrientation:
AXHorizontalOrientation
|
aria-orientation
="vertical"
(default
for
role
scrollbar
)
|
Set
|
IAccessible2:
Clear
IA2_STATE_HORIZONTAL
|
Property
to
"vertical"
|
Set
STATE_VERTICAL
|
AXOrientation:
AXVerticalOrientation
|
aria-owns
|
The
structure
should
be
reflected
in
the
accessibility
tree
as
directed
by
aria-owns
.
Map
the
elements
that
are
referenced
by
this
property
as
children
of
the
current
element.
If
multiple
|
The accessibility tree should not be modified.
If
multiple
|
The
structure
should
be
reflected
in
the
accessibility
tree
as
directed
by
aria-owns
.
Map
the
elements
that
are
referenced
by
this
property
as
children
of
the
current
element.
If
multiple
|
Expose reverse relations as described in Relations
If
multiple
|
array
AXLinkedUIElements
contains
pointer
to
nodes
matching
IDREFs
|
If
not
provided
for
relevant
roles,
user
agents
calculate
|
Update
the
|
The
structure
should
be
reflected
in
the
accessibility
tree
as
directed
by
aria-posinset
.
IAccessible2:
Expose
as
object
attribute
|
Update
the
|
Expose
as
object
attribute
posinset:<value>
.
| Not mapped |
aria-pressed
="true"
(state)
|
Toggle
Control
Pattern
|
Set
the
STATE_SYSTEM_PRESSED
state.
IAccessible2:
|
Expose
as
ToggleState
property
of
Toggle
Control
Pattern
|
Expose
STATE_PRESSED
.
If
on
a
button,
expose
the
role
as
ROLE_TOGGLE_BUTTON
.
Expose
object
attribute
| Not mapped |
aria-pressed
="mixed"
(state)
|
Toggle
Control
Pattern
|
Set
the
STATE_SYSTEM_PRESSED
state.
IAccessible2:
|
Expose
as
ToggleState
property
of
Toggle
Control
Pattern
|
Expose
STATE_INDETERMINATE
/
STATE_SYSTEM_MIXED
.
If
on
a
button,
expose
the
role
as
ROLE_TOGGLE_BUTTON
.
Expose
object
attribute
| Not mapped |
aria-pressed
="false"
(state)
|
Toggle
Control
Pattern
|
Clear
the
STATE_SYSTEM_PRESSED
state
IAccessible2:
|
Expose
as
ToggleState
property
of
Toggle
Control
Pattern
|
If
on
a
button,
expose
the
role
as
ROLE_TOGGLE_BUTTON
.
Expose
object
attribute
| Not mapped |
aria-pressed
is
undefined
(state)
(default)
| Not mapped | Not mapped | Not mapped | Not mapped | Not mapped |
|
Set
|
Expose
as
STATE_SYSTEM_READONLY
|
|
|
AXValue
(not
writable)
|
(default)
|
|
IAccessible2:
Expose
|
|
Expose
|
AXValue
(writable)
|
,
"removals"
,
"text"
,
or
"all"
|
relevant=<value>
in
AriaProperties
|
IAccessible2:
|
Expose
as
relevant=<value>
in
AriaProperties
|
Expose
as
object
attribute
relevant:<value>
.
Expose
as
object
attribute
|
string
AXARIARelevant
|
(Default)
|
relevant=additions
text
in
AriaProperties
|
IAccessible2:
|
Expose
as
relevant=additions
text
in
AriaProperties
|
Expose
as
object
attribute
Expose
as
object
attribute
|
string
AXARIARelevant
|
|
IsrequiredForForm
property.
|
IAccessible2:
Expose
IA2_STATE_REQUIRED
|
Expose
as
IsrequiredForForm
property.
|
Expose
STATE_REQUIRED
|
boolean
AXRequired
|
| Not mapped | Not mapped | Not mapped | Not mapped | Not mapped |
aria-selected
="true"
(state)
|
Expose
STATE_SYSTEM_SELECTED
Expose
|
Expose
STATE_SYSTEM_SELECTED
Expose
IAccessible2:
If
not
|
Expose
IsSelected
property
on
SelectionItem
Control
Pattern.
The
availability
of
the
|
If
not
DISABLED
,
toggle
between
"true"
and
"false"
as
appropriate
when
the
AccessibleSelection
interface
is
used
on
an
ancestor
with
aria-multiselectable
as
described
in
Selection
.
Expose
STATE_SELECTED
|
boolean
AXSelected
|
aria-selected
="false"
(state)
|
Clear
STATE_SYSTEM_SELECTED
Expose
|
Clear
STATE_SYSTEM_SELECTED
Expose
IAccessible2:
If
not
| Not mapped | Not mapped |
boolean
AXSelected
|
aria-selected
is
undefined
(state)
(default)
| Not mapped | Not mapped | Not mapped | Not mapped | Not mapped |
If
not
provided
for
relevant
roles,
user
agents
calculate
|
Expose
as
Update
the
|
IAccessible2:
Expose
object
attribute
setsize:<value>
and
groupPosition
.
|
Expose
as
Update
the
|
Expose
object
attribute
setsize:<value>
.
| Not mapped. |
"descending"
,
or
"other"
|
Expose
as
If
on
an
element
that
maps
to
|
IAccessible2:
Expose
as
object
attribute
sort:<value>
|
Expose
as
If
on
an
element
that
maps
to
|
Expose
as
object
attribute
sort:<value>
|
AXSortDirection:
AXAscendingSortDirection
|
AXDescendingSortDirection
|
AXUnknownSortDirection
|
(default)
| Not mapped |
IAccessible2:
If
specified,
expose
as
object
attribute
sort:<value>
| Not mapped |
If
specified,
expose
as
object
attribute
sort:<value>
| Not mapped |
aria-valuemax
|
Maximum
property
in
RangeValue
Control
Pattern
See Widget values for additional information |
IAccessible2:
Expose
via
AccessibleValue
interface.
See Widget values for additional information |
Expose
the
Maximum
property
in
RangeValue
Control
Pattern
See Widget values for additional information |
Expose
via
AccessibleValue
interface.
See Widget values for additional information |
number
AXMaxValue
See Widget values for additional information |
aria-valuemin
|
Minimum
property
in
RangeValue
Control
Pattern
See Widget values for additional information |
IAccessible2:
Expose
via
AccessibleValue
interface
See Widget values for additional information |
Expose
the
Minimum
property
in
RangeValue
Control
Pattern
See Widget values for additional information |
Expose
via
AccessibleValue
interface
See Widget values for additional information |
number
AXMinValue
See Widget values for additional information |
aria-valuenow
|
If
aria-valuetext
is
not
defined,
expose
via
IAccessible::get_accValue
|
If
aria-valuetext
is
not
defined,
expose
via
IAccessible::get_accValue
IAccessible2:
Expose
via
See Widget values for additional information |
Expose
Value
property
in
RangeValue
Control
Pattern
See Widget values for additional information |
Expose
via
AccessibleValue
interface.
See Widget values for additional information |
number
AXValue
See Widget values for additional information |
aria-valuetext
|
Expose
property
in
Value
Control
Pattern
which
can
co-exist
with
RangeValue
Control
Pattern.
See Widget values for additional information |
Expose
via
IAccessible::get_accValue
IAccessible2:
Expose
as
object
attribute
See Widget values for additional information |
Expose
Value
property
in
Value
Control
Pattern
which
can
co-exist
with
RangeValue
Control
Pattern.
See Widget values for additional information |
Expose
as
object
attribute
valuetext:<value>
See Widget values for additional information |
string
AXValueDescription
See Widget values for additional information |
User agents MUST compute an accessible name using the rules outlined below in the section titled Text Alternative Computation .
HTML
Note:
Special
Case
:
If
the
element
is
an
img
element;
element
that
is
exposed
in
the
accessibility
tree;
and
the
computed
text
alternative
is
empty,
then
check
for
the
presence
of
role
presentation
or
any
labeling
attribute
that
specifies
an
empty
label,
specifically
aria-label
,
aria-labelledby
,
alt
or
title
.
The
presence
of
any
of
these
indicates
the
author's
intention
to
indicate
that
the
img
is
decorative
or
redundant.
In
this
case,
the
user
agent
MUST
set
the
name
to
an
empty
string.
If
none
of
these
attributes
are
present,
this
indicates
the
author
simply
did
not
provide
an
accessible
label
for
the
image,
and
the
implementation
MUST
return
an
accessible
name
of
NULL
instead
of
an
empty
string
if
the
API
supports
it.
This
hints
to
the
assistive
technology
to
do
its
own
heuristic
processing
to
repair
the
missing
accessible
name.
If
aria-describedby
is
present,
user
agents
MAY
MUST
compute
the
accessible
description
by
concatenating
the
text
alternatives
for
nodes
referenced
by
an
aria-describedby
attribute
on
the
current
node.
The
text
alternatives
for
the
referenced
nodes
are
computed
using
a
number
of
methods,
outlined
below
in
the
section
titled
Text
Alternative
Computation
.
The text alternative is reused in both the name and description computation, as described above. There are different rules provided for several different types of nodes and combinations of markup. Text alternatives are built up, when appropriate, from all the relevant content contained within an element . This is accomplished via rule 2C (which is recursive), using the full set of rules to retrieve text from its own children.
The text alternative for a given node is computed as follows:
aria-labelledby
or
aria-describedby
being
used
in
the
current
computation.
By
default,
users
of
assistive
technologies
won't
receive
the
hidden
information,
but
an
author
will
be
able
to
explicitly
override
that
and
include
the
hidden
text
alternative
as
part
of
the
label
string
sent
to
the
accessibility
API
.
aria-labelledby
attribute
takes
precedence
as
the
element's
text
alternative
unless
this
computation
is
already
occurring
as
the
result
of
a
recursive
aria-labelledby
declaration
(in
other
words,
aria-labelledby
is
not
recursive
when
referenced
from
another
element,
so
it
will
not
cause
loops).
However,
the
element's
aria-labelledby
attribute
can
reference
the
element's
own
IDREF
in
order
to
concatenate
a
string
provided
by
the
element's
aria-label
attribute
or
another
feature
lower
in
this
preference
list.
The
text
alternatives
for
all
the
elements
referenced
will
be
computed
using
this
same
set
of
rules.
User
agents
will
then
trim
whitespace
and
join
the
substrings
using
a
single
space
character.
Substrings
will
be
joined
in
the
order
specified
by
the
author
(IDREF
order
in
the
aria-labelledby
attribute).
In
the
following
example,
the
<span>
elements
would
have
text
alternatives
of
"Delete
Documentation.pdf"
and
"Delete
HolidayLetter.pdf",
respectively.
<h1>Files</h1>
<ul>
<li>
<a
id="file_row1"
href="./files/Documentation.pdf">Documentation.pdf</a>
<span
role="button"
tabindex="0"
id="del_row1"
aria-label="Delete"
aria-labelledby="del_row1
file_row1"></span>
</li>
<li>
<a
id="file_row2"
href="./files/HolidayLetter.pdf">HolidayLetter.pdf</a>
<span
role="button"
tabindex="0"
id="del_row2"
aria-label="Delete"
aria-labelledby="del_row2
file_row2"></span>
</li>
</ul>
aria-labelledby
is
empty
or
undefined,
the
aria-label
attribute,
which
defines
an
explicit
text
string,
is
used.
However,
if
this
computation
is
already
occurring
as
the
result
of
a
recursive
text
alternative
computation
and
the
current
element
is
an
embedded
control
as
defined
in
rule
2B,
ignore
the
aria-label
attribute
and
skip
directly
to
rule
2B.
aria-labelledby
and
aria-label
are
both
empty
or
undefined,
and
if
the
element
is
not
marked
as
presentational
(
role="
presentation
"
,
check
for
the
presence
of
an
equivalent
host
language
attribute
or
element
for
associating
a
label,
and
use
those
mechanisms
to
determine
a
text
alternative.
For
example,
in
HTML
,
the
img
element's
alt
attribute
defines
a
label
string
and
the
label
element
references
the
form
element
it
labels.
See
How
to
Specify
Alternate
Text
([
HTML
],
section
13.8)
and
HTML5
Requirements
for
providing
text
to
act
as
an
alternative
for
images
([
HTML5
],
section
4.8.1.1).
In
the
case
of
HTML
frame
and
iframe
elements,
the
title
element
in
the
head
element
of
the
document
inside
a
frame
or
iframe
is
used
in
this
step
of
the
calculation
of
the
name
of
the
frame
or
iframe
.
Editorial Note: We've asked the HTML5 WG to remove or reduce this section, so we may remove the reference to it.
spinbutton
or
slider
),
use
the
value
of
the
aria-valuetext
attribute
if
available,
or
otherwise
the
value
of
the
aria-valuenow
attribute.
Editorial Note: This bullet of the text alternative computation is currently normative. Its status is considered a feature at risk and may be changed from a normative requirement to an informative recommendation if interoperable implementations are not found.
title
attribute
in
HTML
).
This
is
used
only
if
nothing
else,
including
subtree
content,
has
provided
results.
:before
and
:after
pseudo-elements,
where
the
user
agent
combines
the
textual
content
specified
in
the
style
sheet
with
that
given
in
the
DOM.
The purpose of the flat text alternative string is to create a perceivable label in alternative presentations. At each step of the algorithm, an implementation will trim the existing text alternative string and the string to be added, then join those two strings with a single space. For example, a space character may be inserted between the text of two elements used one after the other in a description.
Some
WAI-ARIA
roles
are
Widgets
widgets
that
have
a
particular
value
within
a
range
of
values.
For
example
progressbar
,
spinbutton
,
and
slider
use
aria-valuemin
and
aria-valuemax
to
specify
the
range
of
valid
values,
aria-valuenow
to
specify
the
current
value,
and
optionally
aria-valuetext
to
specify
a
text
string
equivalent
for
the
current
value.
If the value is not set on a control that requires value, then user agents SHOULD return an error when the current value is requested.
When
assistive
technology
requests
the
current
value,
user
agents
are
not
required
to
ensure
that
aria-valuenow
is
greater
than
aria-valuemin
and
less
than
aria-valuemax
.
If
an
element
has
the
aria-valuetext
property
set,
but
not
aria-valuenow
,
user
agents
MUST
expose
the
string
value
of
aria-valuetext
as
specified
in
State
and
Property
Mapping
,
but
return
an
error
for
any
value
getter
that
only
returns
a
numeric
type.
.
Often
in
a
GUI
,
there
are
relationships
between
the
widgets
that
can
be
exposed
programmatically
to
assistive
technology
.
WAI-ARIA
provides
several
relationship
properties
which
are
globally
applicable
to
any
element
:
aria-controls
,
aria-describedby
,
aria-flowto
,
aria-labelledby
,
aria-owns
,
aria-posinset
,
and
aria-setsize
.
Therefore,
it
is
not
important
to
check
the
role
before
computing
them.
User
agents
can
simply
map
these
relations
to
accessibility
APIs
as
defined
in
the
section
titled
State
and
Property
Mapping
.
User agents SHOULD ignore ID references that do not match the ID of another element in the same document.
It
is
the
web
author's
responsibility
to
ensure
that
IDs
are
unique.
If
more
than
one
element
has
the
same
ID,
the
user
agent
SHOULD
use
the
first
element
found
with
the
given
ID.
The
behavior
will
be
the
same
as
getElementById
.
If the same element is specified multiple times in a single WAI-ARIA relation, user agents SHOULD return multiple pointers to the same object .
aria-activedescendant
is
defined
as
referencing
only
a
single
ID
reference.
Any
aria-activedescendant
value
that
does
not
match
an
existing
IDREF
exactly
is
an
author
error
and
will
not
match
any
element
in
the
DOM
.
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
following
table
when
an
element's
ID
is
referenced
by
a
relation
property
of
another
element.
element
and
the
referenced
element
is
in
the
accessibility
tree
according
to
the
rules
in
General
rules
for
exposing
WAI-ARIA
semantics
.
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-described
by
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.
WAI-ARIA Relation | IAccessible2 | ATK / AT-SPI |
---|---|---|
aria-controls
references
the
element's
ID
|
IA2_RELATION_CONTROLLED_BY
|
RELATION_CONTROLLED_BY
|
aria-describedby
references
the
element's
ID
|
IA2_RELATION_DESCRIPTION_FOR
|
RELATION_DESCRIPTION_FOR
|
aria-flowto
references
the
element's
ID
|
IA2_RELATION_FLOW_FROM
|
RELATION_FLOW-FROM
|
aria-labelledby
references
the
element's
ID
|
IA2_RELATION_LABEL_FOR
|
RELATION_LABEL_FOR
|
aria-owns
references
the
element's
ID
|
IA2_RELATION_NODE_CHILD_OF
|
RELATION_NODE_CHILD_OF
|
HTML
note:
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.
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="
,
when
treeitem
"
aria-owns
is
not
used,
user
agents
SHOULD
do
the
following
where
reverse
relations
are
supported
by
the
API
:
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.
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
:
aria-atomic
="true".
If
found,
user
agents
SHOULD
set
the
RELATION_MEMBER_OF
relation
to
point
to
the
ancestor
that
sets
aria-atomic
="true".
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
,
user
agents
implementing
IAccessible2
or
ATK
/
AT-SPI
MUST
compute
it
by
following
the
explicit
or
computed
RELATION_NODE_CHILD_OF
relations.
If
aria-posinset
and
aria-setsize
are
not
provided,
user
agents
MUST
compute
them
as
follows:
role="
treeitem
"
,
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.
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
.
As part of mapping roles to accessible objects as defined in Role Mapping , users agents expose a default action on the object.
DoDefaultAction
on
an
accessible
object,
the
user
agent
SHOULD
simulate
a
click
on
the
DOM
element
which
is
mapped
to
that
accessible
object.
IAccessibleAction
on
an
accessible
object,
the
user
agent
SHOULD
simulate
a
click
on
the
DOM
element
which
is
mapped
to
that
accessible
object.
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 .
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.
User
agents
MUST
notify
assistive
technology
of
state
changes
as
defined
in
the
table
below,
SHOULD
notify
assistive
technology
of
property
changes
if
the
accessibility
API
defines
a
change
event
for
the
property,
and
SHOULD
NOT
notify
assistive
technology
of
property
changes
if
the
accessibility
API
does
not
define
a
change
event
for
the
property.
For
example,
IAccessible2
defines
an
event
to
be
used
when
aria-activedescendant
changes.
WAI-ARIA
properties
that
are
expected
to
change
include
aria-activedescendant
,
aria-valuenow
,
and
aria-valuetext
.
Note: 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.
State or Property | MSAA + UIA Express event | MSAA + IAccessible2 event | UIA event | ATK / AT-SPI event | Mac OS X Notification |
---|---|---|---|---|---|
aria-activedescendant
| Not mapped |
See
Controlling
focus
with
In addition:
IAccessible2:
|
See
Controlling
focus
with
aria-activedescendant
|
See
Controlling
focus
with
aria-activedescendant
|
aria-activedescendant
In
addition:
|
aria-busy
(state)
|
EVENT_OBJECT_STATECHANGE
|
EVENT_OBJECT_STATECHANGE
|
PropertyChangedEvent
|
object:state-changed:busy
| Not mapped |
aria-checked
(state)
|
EVENT_OBJECT_STATECHANGE
|
EVENT_OBJECT_STATECHANGE
|
ToggleStateProperty
as
part
of
toggle
pattern
|
object:state-changed:checked
|
AXValueChanged
|
aria-disabled
(state)
|
EVENT_OBJECT_STATECHANGE
|
EVENT_OBJECT_STATECHANGE
| Not mapped |
object:state-changed:enabled
and
object:state-changed:sensitive
| Not mapped |
aria-dropeffect
(state)
| Not mapped |
IAccessible2:
IA2_EVENT_OBJECT_ATTRIBUTE_CHANGED
| Not mapped |
object:property-change
| Not mapped |
aria-expanded
(state)
|
EVENT_OBJECT_STATECHANGE
|
EVENT_OBJECT_STATECHANGE
|
expand
/
collapse
pattern
events
|
object:state-changed:expanded
|
AXRowExpanded
,
AXRowCollapsed
,
AXRowCountChanged
|
aria-grabbed
(state)
|
EVENT_OBJECT_SELECTION
|
IAccessible2:
| Not mapped |
object:property-change
| Not mapped |
aria-hidden
(state)
|
EVENT_OBJECT_HIDE
,
EVENT_OBJECT_SHOW
|
IAccessible2:
IA2_EVENT_OBJECT_ATTRIBUTE_CHANGED
|
StructureChangedEvent
|
object:property-change
|
AXUIElementDestroyed
,
AXUIElementCreated
|
aria-invalid
(state)
|
EVENT_OBJECT_STATECHANGE
|
EVENT_OBJECT_STATECHANGE
| Not mapped |
object:state-changed:invalid_entry
|
AXInvalidStatusChanged
|
aria-pressed
(state)
|
EVENT_OBJECT_STATECHANGE
|
EVENT_OBJECT_STATECHANGE
| Not mapped |
object:state-changed:pressed
| Not mapped |
aria-readonly
|
EVENT_OBJECT_STATECHANGE
|
EVENT_OBJECT_STATECHANGE
| Not mapped |
object:state-changed:readonly
| Not mapped |
aria-required
| Not mapped |
EVENT_OBJECT_STATECHANGE
| Not mapped |
object:state-changed:required
| Not mapped |
aria-selected
(state)
|
EVENT_OBJECT_SELECTIONADD
EVENT_OBJECT_SELECTIONREMOVE
|
EVENT_OBJECT_SELECTIONADD
EVENT_OBJECT_SELECTIONREMOVE
| Not mapped |
object:selection-changed
or
if
text,
object:text-selection-changed
|
AXSelectedChildrenChanged
|
aria-valuenow
|
EVENT_OBJECT_VALUECHANGE
|
EVENT_OBJECT_VALUECHANGE
|
ValueProperty
property
change
as
part
of
value
pattern
|
object:property-change:accessible-value
|
AXValueChanged
|
aria-valuetext
| Not mapped |
EVENT_OBJECT_VALUECHANGE
| Not mapped |
object:property-change:accessible-value
|
AXValueChanged
|
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.
Scenario | MSAA + UIA Express event | MSAA + IAccessible2 event | UIA event | ATK / AT-SPI event | Mac OS X Event |
---|---|---|---|---|---|
When text is removed |
TextPattern..::.TextChangedEvent
|
IAccessible2:
IA2_EVENT_TEXT_REMOVED
|
TextPattern..::.TextChangedEvent
|
text_changed::delete
|
If
in
a
live
region
,
AXLiveRegionChanged
|
When text is inserted |
TextPattern..::.TextChangedEvent
|
IAccessible2:
IA2_EVENT_TEXT_INSERTED
|
|
text_changed::insert
|
If
in
a
live
region,
AXLiveRegionChanged
|
When text is changed |
TextPattern..::.TextChangedEvent
followed
immediately
by
TextPattern..::.TextChangedEvent
|
IAccessible2:
IA2_EVENT_TEXT_REMOVE
followed
immediately
by
IA2_EVENT_TEXT_INSERTED
|
TextPattern..::.TextChangedEvent
followed
immediately
by
|
text_changed::delete
followed
immediately
by
text_changed::insert
|
If
in
a
live
region,
AXLiveRegionChanged
|
Fire these events for node changes where the node in question is an element and has an accessible object :
Scenario | MSAA | Microsoft UIA event | ATK / AT-SPI event | Mac OS X Event |
---|---|---|---|---|
When
|
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
|
If
in
a
live
region,
|
When
|
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
|
If
in
a
live
region,
|
When
|
EVENT_OBJECT_SHOW
|
children_changed::add
|
If
in
a
live
region,
| |
When
|
EVENT_OBJECT_REORDER
|
children_changed::add
|
If
in
a
live
region,
| |
When
| 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 |
If
in
a
live
region,
|
When
| Treat it as a removal and insertion | Treat it as a removal and insertion | Treat it as a removal and insertion |
If
in
a
live
region,
|
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.")
has
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
Mac
OS
X,
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:
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:
RELATION_MEMBER_OF
relation
on
the
accessible
aria-atomic
="true"
(if
any).
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:
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.
There are two cases for selection:
In the single selection case, selection follows focus. User agents MUST fire the following events:
Scenario | MSAA | Microsoft UIA | ATK / AT-SPI | Mac OS X |
---|---|---|---|---|
Focus change |
EVENT_OBJECT_SELECTION
then
EVENT_OBJECT_STATECHANGE
on
newly
focused
item,
but
arrange
events
so
state
change
does
not
occur
on
focused
item,
to
avoid
extra
selection
change
announcements
|
If
on
a
|
object::selection_changed
but
arrange
events
so
state
change
does
not
occur
on
focused
item,
to
avoid
extra
selection
change
announcement
|
AXSelectedChildrenChanged
|
The
multiple
selection
case
occurs
when
on
an
element
with
a
role
that
supports
that
property
.
There
are
several
important
aspects:
aria-multiselectable
="true"
Selection
and
SelectionItem
Control
Patterns
expose
the
selection
availability,
state,
and
methods.
aria-selected
changes
on
a
descendant,
as
follows:
Scenario | MSAA | Microsoft UIA | ATK / AT-SPI | Mac OS X |
---|---|---|---|---|
Toggle
aria-selected
|
EVENT_OBJECT_SELECTIONADD
/
EVENT_OBJECT_SELECTIONREMOVE
on
the
current
container
+
EVENT_OBJECT_STATECHANGE
on
the
item
|
SelectionItem
Control
Pattern
:
UIA_SelectionItem_ElementAddedToSelectionEventId
or
UIA_SelectionItem_ElementRemovedFromSelectionEventId
on
the
current
container
|
object::selection_changed
on
the
item
|
AXSelectedChildrenChanged
|
Selection follows focus |
EVENT_OBJECT_SELECTION
then
EVENT_OBJECT_STATECHANGE
on
newly
focused
item,
but
arrange
events
so
state
change
does
not
occur
on
focused
item,
to
avoid
extra
selection
change
announcements
|
FocusChangedEvent
should
be
fired
but
individual
selection
event
may
not
happen,
to
avoid
redundancy.
|
object::selection_changed
but
arrange
events
so
state
change
does
not
occur
on
focused
item,
to
avoid
extra
selection
change
announcement
|
AXSelectedChildrenChanged
|
Select or deselect many items at once |
EVENT_OBJECT_SELECTIONWITHIN
is
all
that
is
necessary.
The
state
change
events
MAY
be
trimmed
out
for
performance.
|
For
each
element
selected
or
deselected,
fire
Control
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
InvalidateLimit
constant
permits.
|
object::selection_changed
.
The
state
change
events
MAY
be
trimmed
out
for
performance
|
AXSelectedChildrenChanged
|
This section is normative .
Editorial Note: This section might be removed in a future version.
Support
for
attribute
selectors
MUST
include
WAI-ARIA
attributes.
For
example,
.fooMenuItem[aria-haspop="true"]
would
select
all
elements
with
class
fooMenuItem
,
and
WAI-ARIA
property
aria-haspopup
with
value
of
true
.
The
presentation
MUST
be
updated
for
dynamic
changes
to
WAI-ARIA
attributes.
This
allows
authors
to
match
styling
with
WAI-ARIA
semantics
.
In
general,
user
agents
do
not
do
much
validation
of
WAI-ARIA
properties
.
User
agents
MAY
do
some
minor
validation
on
request,
such
as
making
sure
valid
IDs
are
specified
for
WAI-ARIA
relations,
and
enforcing
things
like
aria-posinset
being
within
1
and
aria-setsize
,
inclusive.
User
agents
are
not
responsible
for
logical
validation,
such
as
the
following:
aria-activedescendant
being
a
DOM
-descendant
of
the
element
with
the
relation.
checkbox
actually
behaves
like
a
checkbox.
aria-activedescendant
actually
points
to
a
descendant
or
another
owned
element
.
If the author specifies a non-numeric value for a decimal or integer value type, the user agent SHOULD do the following:
If a WAI-ARIA property contains an unknown or disallowed value, the user agent SHOULD expose to platform accessibility APIs as follows:
Note: In UIA , the user agent might leave the corresponding property set to "unsupported."
User agent MUST NOT expose WAI-ARIA attributes that reference unresolved ID's. For example:
If a required WAI-ARIA attribute for a given role is missing, user agents SHOULD process as if the following values were provided:
WAI-ARIA role | Required Attribute | Default value |
---|---|---|
checkbox
|
aria-checked
| undefined |
combobox
|
aria-expanded
| undefined |
menuitemcheckbox
|
aria-checked
| undefined |
menuitemradio
|
aria-checked
| undefined |
radio
|
aria-checked
| undefined |
scrollbar
|
aria-controls
| no mapping |
scrollbar
|
aria-orientation
| vertical |
scrollbar
|
aria-valuemax
| 0 |
scrollbar
|
aria-valuemin
| 0 |
scrollbar
|
aria-valuenow
| 0 |
slider
|
aria-valuemax
| 0 |
slider
|
aria-valuemin
| 0 |
slider
|
aria-valuenow
| 0 |
spinbutton
|
aria-valuemax
| 0 |
spinbutton
|
aria-valuemin
| 0 |
spinbutton
|
aria-valuenow
| 0 |
This section is normative .
Resources referenced normatively are considered part of this specification. Implementations of this specification MUST implement the requirements of these resources.
Resources referenced informatively provide useful information relevant to this document, but do not comprise a part of its requirements.
The following people contributed to the development of this document.
Special thanks to Aaron Leventhal for effort and insight as he implemented a working prototype of accessibility API bindings. Special thanks to Al Gilman for his work while chair of the PFWG in bringing the ARIA technology to fruition.
Jim Allan (TSB), Simon Bates, Chris Blouch (AOL), Judy Brewer (W3C/MIT), Ben Caldwell (Trace), Charles Chen (Google, Inc.), Christian Cohrs, Dimitar Denev (Frauenhofer Gesellschaft), Donald Evans (AOL), Kentarou Fukuda (IBM Corporation), Becky Gibson (IBM), Alfred S. Gilman, Andres Gonzalez (Adobe Systems Inc.), Georgios Grigoriadis (SAP AG), Jeff Grimes (Oracle), Barbara Hartel, John Hrvatin (Microsoft Corporation), Masahiko Kaneko (Microsoft Corporation), Earl Johnson (Sun), Jael Kurz, Diego La Monica (International Webmasters Association / HTML Writers Guild (IWA-HWG)), Aaron Leventhal (IBM Corporation), Alex Li (SAP), Linda Mao (Microsoft), Anders Markussen (Opera Software), Matthew May (Adobe Systems Inc.), Lisa Pappas (Society for Technical Communication (STC)), Dave Pawson (RNIB), David Poehlman, Simon Pieters (Opera Software), T.V. Raman (Google, Inc.), Tony Ross (Microsoft Corporation), Martin Schaus (SAP AG), Marc Silbey (Microsoft Corporation), Henri Sivonen (Mozilla), Henny Swan (Opera Software), Vitaly Sourikov, Mike Squillace (IBM), Ryan Williams (Oracle), Tom Wlodkowski.
This publication has been funded in part with Federal funds from the U.S. Department of Education, National Institute on Disability and Rehabilitation Research (NIDRR) under contract number ED-OSE-10-C-0067. 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.