Status
of
This
Document
This
is
a
preview
Do
not
attempt
to
implement
this
version
of
the
specification.
Do
not
reference
this
version
as
authoritative
in
any
way.
Instead,
see
https://w3c.github.io/aria/
for
the
Editor's
draft.
This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
Other
documents
may
supersede
this
document.
A
list
of
current
W3C
publications
and
the
latest
revision
of
this
technical
report
can
be
found
in
the
W3C
technical
reports
index
at
https://www.w3.org/TR/.
The
Accessible
Rich
Internet
Applications
Working
Group
seeks
feedback
on
any
aspect
of
the
specification.
When
submitting
feedback,
please
consider
issues
in
the
context
of
the
companion
documents.
To
comment,
file
an
issue
in
the
W3C
ARIA
GitHub
repository
.
If
this
is
not
feasible,
send
email
to
public-aria@w3.org
(
comment
archive
).
In-progress
updates
to
the
document
may
be
viewed
in
the
publicly
visible
editors'
draft
.
This
document
was
published
by
the
Accessible
Rich
Internet
Applications
Working
Group
as
an
Editor's
Draft.
Comments
regarding
this
document
are
welcome.
Please
send
them
to
public-aria@w3.org
(
archives
).
Publication
as
an
Editor's
Draft
does
not
imply
endorsement
by
the
W3C
Membership.
This
is
a
draft
document
and
may
be
updated,
replaced
or
obsoleted
by
other
documents
at
any
time.
It
is
inappropriate
to
cite
this
document
as
other
than
work
in
progress.
This
document
was
produced
by
a
group
operating
under
the
W3C
Patent
Policy
.
W3C
maintains
a
public
list
of
any
patent
disclosures
made
in
connection
with
the
deliverables
of
the
group;
that
page
also
includes
instructions
for
disclosing
a
patent.
An
individual
who
has
actual
knowledge
of
a
patent
which
the
individual
believes
contains
Essential
Claim(s)
must
disclose
the
information
in
accordance
with
section
6
of
the
W3C
Patent
Policy
.
This
document
is
governed
by
the
1
March
2019
W3C
Process
Document
.
1.
Introduction
This
section
is
non-normative.
The
goals
of
this
specification
include:
-
expanding
the
accessibility
information
that
may
be
supplied
by
the
author;
-
requiring
that
supporting
host
languages
provide
full
keyboard
support
that
may
be
implemented
in
a
device-independent
way,
for
example,
by
telephones,
handheld
devices,
e-book
readers,
and
televisions;
-
improving
the
accessibility
of
dynamic
content
generated
by
scripts;
and
-
providing
for
interoperability
with
assistive
technologies
.
WAI-ARIA
is
a
technical
specification
that
provides
a
framework
to
improve
the
accessibility
and
interoperability
of
web
content
and
applications.
This
document
is
primarily
for
developers
creating
custom
widgets
and
other
web
application
components.
Please
see
the
WAI-ARIA
Overview
for
links
to
related
documents
for
other
audiences,
such
as
WAI-ARIA
Authoring
Practices
[
WAI-ARIA-PRACTICES-1.1
]
that
introduces
developers
to
the
accessibility
problems
that
WAI-ARIA
is
intended
to
solve,
the
fundamental
concepts,
and
the
technical
approach
of
WAI-ARIA
.
This
draft
currently
handles
two
aspects
of
roles
:
user
interface
functionality
and
structural
relationships
.
For
more
information
and
use
cases,
see
[
WAI-ARIA-PRACTICES-1.1
]
for
the
use
of
roles
in
making
interactive
content
accessible.
Roles
defined
by
this
specification
are
designed
to
support
the
roles
used
by
platform
accessibility
APIs
.
Declaration
of
these
roles
on
elements
within
dynamic
web
content
is
intended
to
support
interoperability
between
the
web
content
and
assistive
technologies
that
utilize
accessibility
APIs
.
The
schema
to
support
this
standard
has
been
designed
to
be
extensible
so
that
custom
roles
can
be
created
by
extending
base
roles.
This
allows
user
agents
to
support
at
least
the
base
role,
and
user
agents
that
support
the
custom
role
can
provide
enhanced
access.
Note
that
much
of
this
could
be
formalized
in
[
XMLSCHEMA11-2
].
However,
being
able
to
define
similarities
between
roles,
such
as
baseConcepts
and
more
descriptive
definitions,
would
not
be
available
in
XSD
.
WAI-ARIA
1.2
is
a
member
of
the
WAI-ARIA
1.2
suite
that
defines
how
to
expose
semantics
of
WAI-ARIA
and
other
web
content
languages
to
accessibility
APIs
.
1.1
Rich
Internet
Application
Accessibility
The
domain
of
web
accessibility
defines
how
to
make
web
content
usable
by
persons
with
disabilities.
Persons
with
certain
types
of
disabilities
use
assistive
technologies
(
AT
)
to
interact
with
content.
Assistive
technologies
can
transform
the
presentation
of
content
into
a
format
more
suitable
to
the
user,
and
can
allow
the
user
to
interact
in
different
ways.
For
example,
the
user
may
need
to,
or
choose
to,
interact
with
a
slider
widget
via
arrow
keys,
instead
of
dragging
and
dropping
with
a
mouse.
In
order
to
accomplish
this
effectively,
the
software
needs
to
understand
the
semantics
of
the
content.
Semantics
is
the
science
of
meaning;
in
this
case,
used
to
assign
roles,
states,
and
properties
that
apply
to
user
interface
and
content
elements
as
a
human
would
understand.
For
instance,
if
a
paragraph
is
semantically
identified
as
such,
assistive
technologies
can
interact
with
it
as
a
unit
separable
from
the
rest
of
the
content,
knowing
the
exact
boundaries
of
that
paragraph.
An
adjustable
range
slider
or
collapsible
list
(a.k.a.
a
tree
widget
)
are
more
complex
examples,
in
which
various
parts
of
the
widget
have
semantics
that
need
to
be
properly
identified
for
assistive
technologies
to
support
effective
interaction.
New
technologies
often
overlook
semantics
required
for
accessibility,
and
new
authoring
practices
often
misuse
the
intended
semantics
of
those
technologies.
Elements
that
have
one
defined
meaning
in
the
language
are
used
with
a
different
meaning
intended
to
be
understood
by
the
user.
For
example,
web
application
developers
create
collapsible
tree
widgets
in
HTML
using
CSS
and
JavaScript
even
though
HTML
has
no
semantic
tree
element.
To
a
non-disabled
user,
it
may
look
and
act
like
a
collapsible
tree
widget,
but
without
appropriate
semantics,
the
tree
widget
may
not
be
perceivable
to,
or
operable
by,
a
person
with
a
disability
because
assistive
technologies
may
not
recognize
the
role.
Similarly,
web
application
developers
create
interactive
button
widgets
in
SVG
using
JavaScript
even
though
SVG
has
no
semantic
button
element.
To
a
non-disabled
user,
it
may
look
and
act
like
a
button
widget,
but
without
appropriate
semantics,
the
button
widget
may
not
be
perceivable
to,
or
operable
by,
a
person
with
a
disability
because
assistive
technologies
may
not
recognize
the
role.
The
incorporation
of
WAI-ARIA
is
a
way
for
an
author
to
provide
proper
semantics
for
custom
widgets
to
make
these
widgets
accessible,
usable,
and
interoperable
with
assistive
technologies.
This
specification
identifies
the
types
of
widgets
and
structures
that
are
commonly
recognized
by
accessibility
products,
by
providing
an
ontology
of
corresponding
roles
that
can
be
attached
to
content.
This
allows
elements
with
a
given
role
to
be
understood
as
a
particular
widget
or
structural
type
regardless
of
any
semantics
inherited
from
the
implementing
host
language.
Roles
are
a
common
property
of
platform
accessibility
APIs
which
assistive
technologies
use
to
provide
the
user
with
effective
presentation
and
interaction.
The
Roles
Model
includes
interaction
widgets
and
elements
denoting
document
structure.
The
Roles
Model
describes
inheritance
and
details
the
attributes
each
role
supports.
Information
about
mapping
of
roles
to
accessibility
APIs
is
provided
by
the
Core
Accessibility
API
Mappings
1.1
[
CORE-AAM-1.1
].
Roles
are
element
types
and
will
not
change
with
time
or
user
actions.
Role
information
is
used
by
assistive
technologies,
through
interaction
with
the
user
agent,
to
provide
normal
processing
of
the
specified
element
type.
States
and
properties
are
used
to
declare
important
attributes
of
an
element
that
affect
and
describe
interaction.
They
enable
the
user
agent
and
operating
system
to
properly
handle
the
element
even
when
the
attributes
are
dynamically
changed
by
client-side
scripts.
For
example,
alternative
input
and
output
technology,
such
as
screen
readers
and
speech
dictation
software,
need
to
be
able
to
recognize
and
effectively
manipulate
and
communicate
various
interaction
states
(e.g.,
disabled,
checked)
to
the
user.
While
it
is
possible
for
assistive
technologies
to
access
these
properties
directly
through
the
Document
Object
Model
[
DOM4
],
the
preferred
mechanism
is
for
the
user
agent
to
map
the
states
and
properties
to
the
accessibility
API
of
the
operating
system.
See
the
Core
Accessibility
API
Mappings
1.1
[
CORE-AAM-1.1
]
and
the
Accessible
Name
and
Description:
Computation
and
API
Mappings
1.1
[
ACCNAME-1.1
]
for
details.
Figure
1.0
illustrates
the
relationship
between
user
agents
(e.g.,
browsers),
accessibility
APIs
,
and
assistive
technologies.
It
describes
the
"contract"
provided
by
the
user
agent
to
assistive
technologies,
which
includes
typical
accessibility
information
found
in
the
accessibility
API
for
many
of
our
accessible
platforms
for
GUIs
(role,
state,
selection,
event
notification,
relationship
information,
and
descriptions).
The
DOM
,
usually
HTML
,
acts
as
the
data
model
and
view
in
a
typical
model-view-controller
relationship,
and
JavaScript
acts
as
the
controller
by
manipulating
the
style
and
content
of
the
displayed
data.
The
user
agent
conveys
relevant
information
to
the
operating
system's
accessibility
API
,
which
can
be
used
by
any
assistive
technologies,
such
as
screen
readers.
Figure
1:
The
contract
model
with
accessibility
APIs
For
more
information
see
WAI-ARIA
Authoring
Practices
[
WAI-ARIA-PRACTICES-1.1
]
for
the
use
of
roles
in
making
interactive
content
accessible.
Users
of
alternate
input
devices
need
keyboard
accessible
content.
The
new
semantics,
when
combined
with
the
recommended
keyboard
interactions
provided
in
WAI-ARIA
Authoring
Practices
[
WAI-ARIA-PRACTICES-1.1
],
will
allow
alternate
input
solutions
to
facilitate
command
and
control
via
an
alternate
input
solution.
WAI-ARIA
introduces
navigational
landmarks
through
its
Roles
Model
and
the
XHTML
role
landmarks,
which
can
help
persons
with
dexterity
and
vision
impairments
by
providing
for
improved
keyboard
navigation.
WAI-ARIA
may
also
be
used
to
assist
persons
with
cognitive
learning
disabilities.
The
additional
semantics
allow
authors
to
restructure
and
substitute
alternative
content
as
needed.
Assistive
technologies
need
the
ability
to
support
alternative
inputs
by
getting
and
setting
the
current
value
of
widget
states
and
properties.
Assistive
technologies
also
need
to
determine
what
objects
are
selected
and
manage
widgets
that
allow
multiple
selections,
such
as
list
boxes
and
grids.
Speech-based
command
and
control
systems
can
benefit
from
WAI-ARIA
semantics
like
the
role
attribute
to
assist
in
conveying
audio
information
to
the
user.
For
example,
upon
encountering
an
element
with
a
role
of
menu
with
child
elements
of
role
menuitem
each
containing
text
content
representing
a
different
flavor,
a
speech
system
might
state
to
the
user,
"Select
one
of
three
choices:
chocolate,
strawberry,
or
vanilla."
WAI-ARIA
is
intended
to
be
used
as
a
supplement
for
native
language
semantics,
not
a
replacement.
When
the
host
language
provides
a
feature
that
provides
equivalent
accessibility
to
the
WAI-ARIA
feature,
use
the
host
language
feature.
WAI-ARIA
should
only
be
used
in
cases
where
the
host
language
lacks
the
needed
role
,
state
,
and
property
indicators.
Use
a
host
language
feature
that
is
as
similar
as
possible
to
the
WAI-ARIA
feature,
then
refine
the
meaning
by
adding
WAI-ARIA
.
For
instance,
a
multi-selectable
grid
could
be
implemented
as
a
table,
and
then
WAI-ARIA
used
to
clarify
that
it
is
an
interactive
grid,
not
just
a
static
data
table.
This
allows
for
the
best
possible
fallback
for
user
agents
that
do
not
support
WAI-ARIA
and
preserves
the
integrity
of
the
host
language
semantics.
1.2
Target
Audience
This
specification
defines
the
basic
model
for
WAI-ARIA
,
including
roles,
states,
properties,
and
values.
It
impacts
several
audiences:
-
User
agents
that
process
content
containing
WAI-ARIA
features;
-
Assistive
technologies
that
present
content
in
special
ways
to
user
with
disabilities;
-
Authors
who
create
content;
-
Authoring
tools
that
help
authors
create
conforming
content;
and
-
Conformance
checkers
that
verify
appropriate
use
of
WAI-ARIA
.
Each
conformance
requirement
indicates
the
audience
to
which
it
applies.
Although
this
specification
is
applicable
to
the
above
audiences,
it
is
not
specifically
targeted
to,
nor
is
it
intended
to
be
the
sole
source
of
information
for,
any
of
these
audiences.
The
following
documents
provide
important
supporting
information:
1.3
User
Agent
Support
WAI-ARIA
relies
on
user
agent
support
for
its
features
in
two
ways:
Aside
from
using
WAI-ARIA
markup
to
improve
what
is
exposed
to
accessibility
APIs
,
user
agents
behave
as
they
would
natively.
Assistive
technologies
react
to
the
extra
information
in
the
accessibility
API
as
they
already
do
for
the
same
information
on
non-web
content.
User
agents
that
are
not
assistive
technologies,
however,
need
do
nothing
beyond
providing
appropriate
updates
to
the
accessibility
API
.
The
WAI-ARIA
specification
neither
requires
nor
forbids
user
agents
from
enhancing
native
presentation
and
interaction
behaviors
on
the
basis
of
WAI-ARIA
markup.
Mainstream
user
agents
might
expose
WAI-ARIA
navigational
landmarks
(for
example,
as
a
dialog
box
or
through
a
keyboard
command)
with
the
intention
to
facilitate
navigation
for
all
users.
User
agents
are
encouraged
to
maximize
their
usefulness
to
users,
including
users
without
disabilities.
WAI-ARIA
is
intended
to
provide
missing
semantics
so
that
the
intent
of
the
author
may
be
conveyed
to
assistive
technologies.
Generally,
authors
using
WAI-ARIA
will
provide
the
appropriate
presentation
and
interaction
features.
Over
time,
host
languages
may
add
WAI-ARIA
equivalents,
such
as
new
form
controls,
that
are
implemented
as
standard
accessible
user
interface
controls
by
the
user
agent.
This
allows
authors
to
use
them
instead
of
custom
WAI-ARIA
enabled
user
interface
components.
In
this
case
the
user
agent
would
support
the
native
host
language
feature.
Developers
of
host
languages
that
implement
WAI-ARIA
are
advised
to
continue
supporting
WAI-ARIA
semantics
when
they
do
not
adversely
conflict
with
implicit
host
language
semantics,
as
WAI-ARIA
semantics
more
clearly
reflect
the
intent
of
the
author
if
the
host
language
features
are
inadequate
to
meet
the
author's
needs.
1.4
Co-Evolution
of
WAI-ARIA
and
Host
Languages
WAI-ARIA
is
intended
to
augment
semantics
in
supporting
languages
like
[
HTML
]
and
[
SVG2
],
or
to
be
used
as
an
accessibility
enhancement
technology
in
other
markup-based
languages
that
do
not
explicitly
include
support
for
ARIA.
It
clarifies
semantics
to
assistive
technologies
when
authors
create
new
types
of
objects,
via
style
and
script,
that
are
not
yet
directly
supported
by
the
language
of
the
page,
because
the
invention
of
new
types
of
objects
is
faster
than
standardized
support
for
them
appears
in
web
languages.
It
is
not
appropriate
to
create
objects
with
style
and
script
when
the
host
language
provides
a
semantic
element
for
that
type
of
object.
While
WAI-ARIA
can
improve
the
accessibility
of
these
objects,
accessibility
is
best
provided
by
allowing
the
user
agent
to
handle
the
object
natively.
For
example,
it's
better
to
use
an
h1
element
in
HTML
than
to
use
the
heading
role
on
a
div
element.
It
is
expected
that,
over
time,
host
languages
will
evolve
to
provide
semantics
for
objects
that
currently
can
only
be
declared
with
WAI-ARIA
.
This
is
natural
and
desirable,
as
one
goal
of
WAI-ARIA
is
to
help
stimulate
the
emergence
of
more
semantic
and
accessible
markup.
When
native
semantics
for
a
given
feature
become
available,
it
is
appropriate
for
authors
to
use
the
native
feature
and
stop
using
WAI-ARIA
for
that
feature.
Legacy
content
may
continue
to
use
WAI-ARIA
,
however,
so
the
need
for
user
agents
to
support
WAI-ARIA
remains.
While
specific
features
of
WAI-ARIA
may
lose
importance
over
time,
the
general
possibility
of
WAI-ARIA
to
add
semantics
to
web
pages
is
expected
to
be
a
persistent
need.
Host
languages
may
not
implement
all
the
semantics
WAI-ARIA
provides,
and
various
host
languages
may
implement
different
subsets
of
the
features.
New
types
of
objects
are
continually
being
developed,
and
one
goal
of
WAI-ARIA
is
to
provide
a
way
to
make
such
objects
accessible,
because
web
authoring
practices
often
advance
faster
than
host
language
standards.
In
this
way,
WAI-ARIA
and
host
languages
both
evolve
together
but
at
different
rates.
Some
host
languages
exist
to
create
semantics
for
features
other
than
the
user
interface.
For
example,
SVG
expresses
the
semantics
behind
production
of
graphical
objects,
not
of
user
interface
components
that
those
objects
may
represent.
Host
languages
might,
by
design,
not
provide
native
semantics
that
map
to
WAI-ARIA
features.
In
these
cases,
WAI-ARIA
could
be
adopted
as
a
long-term
approach
to
add
semantic
information
to
user
interface
components.
1.5
Authoring
Practices
The
accessibility
of
interactive
content
cannot
be
confirmed
by
static
checks
alone.
Developers
of
interactive
content
should
test
for
device-independent
access
to
widgets
and
applications,
and
should
verify
accessibility
API
access
to
all
content
and
changes
during
user
interaction.
1.6
Assistive
Technologies
Programmatic
access
to
accessibility
semantics
is
essential
for
assistive
technologies.
Most
assistive
technologies
interact
with
user
agents,
like
other
applications,
through
a
recognized
accessibility
API
.
Perceivable
objects
in
the
user
interface
are
exposed
to
assistive
technologies
as
accessible
objects,
defined
by
the
accessibility
API
interfaces.
To
do
this
properly,
accessibility
information
–
role,
states,
properties
as
well
as
contextual
information
–
needs
to
be
accurately
conveyed
to
the
assistive
technologies
through
the
accessibility
API
.
When
a
state
change
occurs,
the
user
agent
provides
the
appropriate
event
notification
to
the
accessibility
API
.
Contextual
information,
in
many
host
languages
like
HTML
,
can
be
determined
from
the
DOM
itself
as
it
provides
a
contextual
tree
hierarchy.
While
some
assistive
technologies
interact
with
these
accessibility
APIs
,
others
may
access
the
content
directly
from
the
DOM
.
These
technologies
can
restructure,
simplify,
style,
or
reflow
the
content
to
help
a
different
set
of
users.
Common
use
cases
for
these
types
of
adaptations
may
be
the
aging
population,
persons
with
cognitive
impairments,
or
persons
in
environments
that
interfere
with
use
of
their
tools.
For
example,
the
availability
of
regional
navigational
landmarks
may
allow
for
a
mobile
device
adaptation
that
shows
only
portions
of
the
content
at
any
one
time
based
on
its
semantics.
This
could
reduce
the
amount
of
information
the
user
needs
to
process
at
any
one
time.
In
other
situations
it
may
be
appropriate
to
replace
a
custom
user
interface
control
with
something
that
is
easier
to
navigate
with
a
keyboard,
or
touch
screen
device.
2.
Using
WAI-ARIA
This
section
is
non-normative.
Complex
web
applications
become
inaccessible
when
assistive
technologies
cannot
determine
the
semantics
behind
portions
of
a
document
or
when
the
user
is
unable
to
effectively
navigate
to
all
parts
of
it
in
a
usable
way
(see
WAI-ARIA
Authoring
Practices
[
WAI-ARIA-PRACTICES-1.1
]).
WAI-ARIA
divides
the
semantics
into
roles
(the
type
defining
a
user
interface
element)
and
states
and
properties
supported
by
the
roles.
Authors
need
to
associate
elements
in
the
document
to
a
WAI-ARIA
role
and
the
appropriate
states
and
properties
(aria-*
attributes
)
during
its
life-cycle,
unless
the
elements
already
have
the
appropriate
implicit
WAI-ARIA
semantics
for
states
and
properties.
In
these
instances
the
equivalent
host
language
states
and
properties
take
precedence
to
avoid
a
conflict
while
the
role
attribute
will
take
precedence
over
the
implicit
role
of
the
host
language
element.
2.1
WAI-ARIA
Roles
A
WAI-ARIA
role
is
set
on
an
element
using
a
role
attribute
,
similar
to
the
role
attribute
defined
in
Role
Attribute
[
ROLE-ATTRIBUTE
].
<
li
role
=
"menuitem"
>
Open
file…
</
li
>
The
definition
of
each
role
in
the
model
provides
the
following
information
:
-
an
informative
description
of
the
role;
-
hierarchical
information
about
related
roles
(e.g.,
a
searchbox
is
a
type
of
textbox
);
-
context
of
the
role
(e.g.,
a
listitem
is
contained
inside
a
list
);
-
references
to
related
concepts
in
other
specifications;
-
supported
states
and
properties
for
each
role
(e.g.,
a
checkbox
supports
being
checked
via
aria-checked
).
Attaching
a
role
gives
assistive
technologies
information
about
how
to
handle
each
element.
When
WAI-ARIA
roles
override
host
language
semantics,
there
are
no
changes
in
the
DOM
,
only
in
the
accessibility
tree
.
User
agents
MUST
use
the
first
token
in
the
sequence
of
tokens
in
the
role
attribute
value
that
matches
the
name
of
any
non-abstract
WAI-ARIA
role
.
The
following
steps
will
correctly
identify
the
applicable
WAI-ARIA
role:
-
Use
the
rules
of
the
host
language
to
detect
that
an
element
has
a
role
attribute
and
to
identify
the
attribute
value
string
for
it.
-
Separate
the
attribute
value
string
for
that
attribute
into
a
sequence
of
whitespace-free
substrings
by
separating
on
whitespace.
-
Compare
the
substrings
to
all
the
names
of
the
non-abstract
WAI-ARIA
roles.
Case-sensitivity
of
the
comparison
inherits
from
the
case-sensitivity
of
the
host
language.
-
Use
the
first
such
substring
in
textual
order
that
matches
the
name
of
a
non-abstract
WAI-ARIA
role.
2.2
WAI-ARIA
States
and
Properties
WAI-ARIA
provides
a
collection
of
accessibility
states
and
properties
which
are
used
to
support
platform
accessibility
APIs
on
various
operating
system
platforms.
Assistive
technologies
may
access
this
information
through
an
exposed
user
agent
DOM
or
through
a
mapping
to
the
platform
accessibility
API
.
When
combined
with
roles
,
the
user
agent
can
supply
the
assistive
technologies
with
user
interface
information
to
convey
to
the
user
at
any
time.
Changes
in
states
or
properties
will
result
in
a
notification
to
assistive
technologies,
which
could
alert
the
user
that
a
change
has
occurred.
In
the
following
example,
a
list
item
(
html:li
)
has
been
used
to
create
a
checkable
menu
item,
and
JavaScript
events
will
capture
mouse
and
keyboard
events
to
toggle
the
value
of
aria-checked
.
A
role
is
used
to
make
the
behavior
of
this
simple
widget
known
to
the
user
agent.
Attributes
that
change
with
user
actions
(such
as
aria-checked
)
are
defined
in
the
states
and
properties
section.
<
li
role
=
"menuitemcheckbox"
aria-checked
=
"true"
>
Sort
by
Last
Modified
</
li
>
Some
accessibility
states,
called
managed
states
,
are
controlled
by
the
user
agent.
Examples
of
managed
state
include
keyboard
focus
and
selection.
Managed
states
often
have
corresponding
CSS
pseudo-classes
(such
as
:focus
and
::selection
)
to
define
style
changes.
In
contrast,
the
states
in
this
specification
are
typically
controlled
by
the
author
and
are
called
unmanaged
states.
Some
states
are
managed
by
the
user
agent,
such
as
aria-posinset
and
aria-setsize
,
but
the
author
can
override
them
if
the
DOM
is
incomplete
and
would
cause
the
user
agent
calculation
to
be
incorrect.
User
agents
map
both
managed
and
unmanaged
states
to
the
platform
accessibility
APIs
.
Most
modern
user
agents
support
CSS
attribute
selectors
([
CSS3-SELECTORS
]),
and
can
allow
the
author
to
create
UI
changes
based
on
WAI-ARIA
attribute
information,
reducing
the
amount
of
scripts
necessary
to
achieve
equivalent
functionality.
In
the
following
example,
a
CSS
selector
is
used
to
determine
whether
or
not
the
text
is
bold
and
an
image
of
a
check
mark
is
shown,
based
on
the
value
of
the
aria-checked
attribute.
[aria-checked="true"] { font-weight: bold; }
[aria-checked="true"]::before
{
background-image:
url(checked.gif);
}
If
CSS
is
not
used
to
toggle
the
visual
representation
of
the
check
mark,
the
author
could
include
additional
markup
and
scripts
to
manage
an
image
that
represents
whether
or
not
the
menuitemcheckbox
is
checked.
<li role="menuitemcheckbox" aria-checked="true">
<img src="checked.gif" role="presentation" alt="">
Sort by Last Modified
</
li
>
2.3
Managing
Focus
and
Supporting
Keyboard
Navigation
When
using
standard
HTML
interactive
elements
and
simple
WAI-ARIA
widgets
,
application
developers
can
manipulate
the
tab
order
or
associate
keyboard
shortcuts
with
elements
in
the
document.
WAI-ARIA
includes
a
number
of
"managing
container"
widgets,
also
known
as
"composite"
widgets.
When
appropriate,
the
container
is
responsible
for
tracking
the
last
descendant
that
was
active
(the
default
is
usually
the
first
item
in
the
container).
It
is
essential
that
a
container
maintain
a
usable
and
consistent
strategy
when
focus
leaves
a
container
and
is
then
later
refocused.
While
there
may
be
exceptions,
it
is
recommended
that
when
a
previously
focused
container
is
refocused,
the
active
descendant
be
the
same
element
as
the
active
descendant
when
the
container
was
last
focused.
Exceptions
include
cases
where
the
contents
of
a
container
widget
have
changed,
and
widgets
like
a
menubar
where
the
user
expects
to
always
return
to
the
first
item
when
focus
leaves
the
menu
bar.
For
example,
if
the
second
item
of
a
tree
group
was
the
active
descendant
when
the
user
tabbed
out
of
the
tree
group,
then
the
second
item
of
the
tree
group
remains
the
active
descendant
when
the
tree
group
gets
focus
again.
The
user
may
also
activate
the
container
by
clicking
on
one
of
the
descendants
within
it.
When
the
container
or
its
active
descendant
has
focus,
the
user
may
navigate
through
the
container
by
pressing
additional
keys,
such
as
the
arrow
keys,
to
change
the
currently
active
descendant.
Any
additional
press
of
the
main
navigation
key
(generally
the
TAB
key)
will
move
out
of
the
container
to
the
next
widget.
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
significantly
complex
widgets
,
such
as
a
menu
or
spreadsheet,
and
uses
the
arrow
keys
to
navigate
within
the
widget.
The
changes
that
WAI-ARIA
introduces
to
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
,
aria-activedescendant
provides
another
mechanism
for
keyboard
operation.
Most
other
aspects
of
WAI-ARIA
widget
development
depend
on
keyboard
navigation
functioning
properly.
When
implementing
aria-activedescendant
as
described
below,
the
user
agent
keeps
the
DOM
focus
on
the
container
element
or
on
an
input
element
that
controls
the
container
element.
However,
the
user
agent
communicates
desktop
focus
events
and
states
to
the
assistive
technology
as
if
the
element
referenced
by
aria-activedescendant
has
focus.
User
agents
are
not
expected
to
validate
that
the
active
descendant
is
a
descendant
of
the
container
element.
It
is
the
responsibility
of
the
user
agent
to
ensure
that
keyboard
events
are
processed
at
the
element
that
has
DOM
focus.
Any
keyboard
events
directed
at
the
active
descendant
bubble
up
to
the
DOM
element
with
focus
for
processing.
If
the
author
removes
the
element
with
focus,
the
author
SHOULD
move
focus
to
a
logical
element.
Similarly,
authors
SHOULD
not
scroll
the
element
with
focus
off
screen
unless
the
user
performed
a
scrolling
action.
Authors
SHOULD
ensure
that
all
interactive
elements
are
focusable
and
that
all
parts
of
composite
widgets
are
either
focusable
or
have
a
documented
alternative
method
to
achieve
their
function.
Authors
MUST
manage
focus
on
the
following
container
roles:
User
agents
that
support
WAI-ARIA
expand
the
usage
of
host
language
mechanisms
such
as
tabindex
,
focus
,
and
blur
to
allow
them
on
all
elements
.
Where
the
host
language
supports
it,
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
supported
in
both
[
HTML
]
and
[
SVG2
].
Authors
MAY
use
aria-activedescendant
to
inform
assistive
technologies
which
descendant
of
a
widget
element
is
treated
as
having
keyboard
focus
in
the
user
interface
if
the
role
of
the
widget
element
supports
aria-activedescendant
.
This
is
often
a
more
convenient
way
of
providing
keyboard
navigation
within
widgets,
such
as
a
listbox
,
where
the
widget
occupies
only
one
stop
in
the
page
Tab
sequence
and
other
keys,
typically
arrow
keys,
are
used
to
focus
elements
inside
the
widget.
Typically,
the
author
will
use
host
language
semantics
to
put
the
widget
in
the
Tab
sequence
(e.g.,
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
the
actual
focus
is
on
the
container.
More
information
on
managing
focus
can
be
found
in
the
Developing
a
Keyboard
Interface
section
of
the
WAI-ARIA
Authoring
Practices
[
WAI-ARIA-PRACTICES-1.1
].
The
user
agent
MUST
do
the
following
to
implement
aria-activedescendant
:
-
Implement
the
host
language
method
for
keyboard
navigation
so
that
widgets
that
support
aria-activedescendant
may
be
included
in
the
tab
order.
-
For
platforms
that
expose
desktop
focus
or
accessibility
API
focus
separately
from
DOM
focus,
do
not
expose
the
focused
state
in
the
accessibility
API
for
any
element
when
it
has
DOM
focus
and
also
has
aria-activedescendant
which
points
to
a
valid
ID
reference
.
-
When
the
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
element
referenced
by
aria-activedescendant
.
If
aria-activedescendant
is
cleared
or
does
not
point
to
an
element
in
the
current
document,
fire
a
desktop
focus
event
for
the
object
that
had
the
attribute
change.
-
For
any
element
with
an
ID
attribute,
where
the
element
is
a
descendant
of
an
element
with
the
aria-activedescendant
attribute,
apply
the
following
accessibility
API
states
to
the
target
to
ensure
the
object
is
accessible:
-
Focusable,
if
the
element
also
has
a
WAI-ARIA
role
,
because
the
aria-activedescendant
of
the
container
can
potentially
point
to
it.
It
is
not
absolutely
necessary
to
check
this
when
there
is
no
role,
because
elements
that
would
be
focusable
would
already
have
the
focusable
state.
-
Focused,
whenever
the
container
element
sets
aria-activedescendant
to
match
the
ID
of
this
descendant
and
the
container
widget
with
aria-activedescendant
has
DOM
focus.
When
an
assistive
technology
uses
its
platform's
acessibility
API
to
request
a
change
of
focus,
user
agents
MUST
do
the
following:
-
Remove
the
platform's
focused
state
from
the
previously
focused
object.
-
Set
the
DOM
focus:
-
If
the
element
can
take
DOM
focus,
the
user
agent
MUST
set
the
DOM
focus
to
it.
-
Otherwise,
if
the
current
element
has
an
ID
and
an
ancestor
with
the
aria-activedescendant
attribute
present,
and
that
ancestor
is
focusable,
the
user
agent
MUST
set
DOM
focus
to
that
ancestor.
Note
The
inability
to
set
DOM
focus
to
the
containing
element
indicates
an
author
error.
-
Otherwise,
the
user
agent
MAY
attempt
to
set
DOM
focus
to
the
child
element
itself.
-
If
the
current
element
has
an
ID
and
an
ancestor
with
the
aria-activedescendant
attribute
present,
the
user
agent
MUST
set
the
accessibility
API
focused
state
and
fire
an
accessibility
API
focus
event
on
the
new
active
descendant.
As
well
as
sections
marked
as
non-normative,
all
authoring
guidelines,
diagrams,
examples,
and
notes
in
this
specification
are
non-normative.
Everything
else
in
this
specification
is
normative.
The
key
words
MAY
,
MUST
,
MUST
NOT
,
OPTIONAL
,
RECOMMENDED
,
REQUIRED
,
SHALL
,
SHALL
NOT
,
SHOULD
,
and
SHOULD
NOT
in
this
document
are
to
be
interpreted
as
described
in
BCP
14
[
RFC2119
]
[
RFC8174
]
when,
and
only
when,
they
appear
in
all
capitals,
as
shown
here.
The
main
content
of
Accessible
Rich
Internet
Applications
is
normative
and
defines
requirements
that
impact
conformance
claims.
Introductory
material,
appendices,
sections
marked
as
"non-normative"
and
their
subsections,
diagrams,
examples,
and
notes
are
informative
(non-normative).
Non-normative
material
provides
advisory
information
to
help
interpret
the
guidelines
but
does
not
create
requirements
that
impact
a
conformance
claim.
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
an
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.
Normative
sections
provide
requirements
that
authors,
user
agents
and
assistive
technologies
MUST
follow
for
an
implementation
to
conform
to
this
specification.
Non-normative
(informative)
sections
provide
information
useful
to
understanding
the
specification.
Such
sections
may
contain
examples
of
recommended
practice,
but
it
is
not
required
to
follow
such
recommendations
in
order
to
conform
to
this
specification.
3.1
Non-interference
with
the
Host
Language
WAI-ARIA
processing
by
the
user
agent
MUST
NOT
interfere
with
the
normal
operation
of
the
built-in
features
of
the
host
language.
If
a
CSS
selector
includes
a
WAI-ARIA
attribute
(e.g.,
input[aria-invalid="true"]
),
user
agents
MUST
update
the
visual
display
of
any
elements
matching
(or
no
longer
matching)
the
selector
any
time
the
attribute
is
added/changed/removed
in
the
DOM
.
The
user
agent
MAY
alter
the
mapping
of
the
host
language
features
into
an
accessibility
API
,
but
the
user
agent
MUST
NOT
alter
the
DOM
in
order
to
remap
WAI-ARIA
markup
into
host
language
features.
3.2
All
WAI-ARIA
in
DOM
A
conforming
user
agent
which
implements
a
document
object
model
that
does
not
conform
to
the
W3C
DOM
specification
MUST
include
the
content
attribute
for
role
and
its
WAI-ARIA
role
values
,
as
well
as
the
WAI-ARIA
States
and
Properties
in
the
DOM
as
specified
by
the
author,
even
though
processing
may
affect
how
the
elements
are
exposed
to
accessibility
APIs
.
Doing
so
ensures
that
each
role
attribute
and
all
WAI-ARIA
states
and
properties,
including
their
values,
are
in
the
document
in
an
unmodified
form
so
other
tools,
such
as
assistive
technologies,
can
access
them.
A
conforming
W3C
DOM
meets
this
criterion.
3.3
Assistive
Technology
Notifications
Communicated
to
Web
Applications
Assistive
technologies
,
such
as
speech
recognition
systems
and
alternate
input
devices
for
users
with
mobility
impairments,
require
the
ability
to
control
a
web
application
in
a
device-independent
way.
WAI-ARIA
states
and
properties
reflect
the
current
state
of
rich
internet
application
components.
The
ability
for
assistive
technologies
to
notify
web
applications
of
necessary
changes
is
essential
because
it
allows
these
alternative
input
solutions
to
control
an
application
without
being
dependent
on
the
standard
input
device
which
the
user
is
unable
to
effectively
control
directly.
User
agents
MUST
provide
a
method
to
notify
the
web
application
when
a
change
occurs
to
states
or
properties
in
the
system
accessibility
API
.
Likewise,
web
application
authors
SHOULD
update
the
web
application
accordingly
when
notified
of
a
change
request
from
the
user
agent
or
assistive
technology.
Note
Many
state
and
properties
can
be
changed
by
assistive
technologies
through
existing
accessibility
APIs
by
responding
to
a
default
action
event.
For
example,
the
aria-selected
state
of
a
tab
in
a
tabpanel
can
be
changed
by
triggering
the
default
action
on
the
element.
3.5
Deprecated
Requirements
As
the
technology
evolves,
sometimes
new
ways
to
meet
a
use
case
become
available,
that
work
better
than
a
feature
that
was
previously
defined.
But
because
of
existing
implementation
of
the
older
feature,
that
feature
cannot
be
removed
from
the
conformance
model
without
rendering
formerly
conforming
content
non-conforming.
In
this
case,
the
older
feature
is
marked
as
"deprecated".
This
indicates
that
the
feature
is
allowed
in
the
conformance
model
and
expected
to
be
supported
by
user
agents,
but
it
is
recommended
that
authors
do
not
use
it
for
new
content.
In
future
versions
of
the
specification,
if
the
feature
is
no
longer
widely
used,
the
feature
could
be
removed
and
no
longer
expected
to
be
supported
by
user
agents.
8.
Implementation
in
Host
Languages
The
roles
,
state
,
and
properties
defined
in
this
specification
do
not
form
a
complete
web
language
or
format.
They
are
intended
to
be
used
in
the
context
of
a
host
language.
This
section
discusses
how
host
languages
are
to
implement
WAI-ARIA
,
to
ensure
that
the
markup
specified
here
will
integrate
smoothly
and
effectively
with
the
host
language
markup.
Although
markup
languages
look
alike
superficially,
they
do
not
share
language
definition
infrastructure.
To
accommodate
differences
in
language-building
approaches,
the
requirements
are
both
general
and
modularization-specific.
While
allowing
for
differences
in
how
the
specifications
are
written,
the
intent
is
to
maintain
consistency
in
how
the
WAI-ARIA
information
looks
to
authors
and
how
it
is
manipulated
in
the
DOM
by
scripts.
WAI-ARIA
roles,
states,
and
properties
are
implemented
as
attributes
of
elements
.
Roles
are
applied
by
placing
their
names
among
the
tokens
appearing
in
the
value
of
a
host-language-provided
role
attribute.
States
and
properties
each
get
their
own
attribute,
with
values
as
defined
for
each
particular
state
or
property
in
this
specification.
The
name
of
the
attribute
is
the
aria-prefixed
name
of
the
state
or
property.
8.1
Role
Attribute
An
implementing
host
language
will
provide
an
attribute
with
the
following
characteristics:
-
The
attribute
name
MUST
be
role
;
-
The
attribute
value
MUST
allow
a
token
list
as
the
value;
-
The
appearance
of
the
name
literal
of
any
concrete
WAI-ARIA
role
as
one
of
these
tokens
MUST
NOT
in
and
of
itself
make
the
attribute
value
illegal
in
the
host-language
syntax;
and
-
The
first
name
literal
of
a
non-abstract
WAI-ARIA
role
in
the
list
of
tokens
in
the
role
attribute
defines
the
role
according
to
which
the
user
agent
MUST
process
the
element.
User
Agent
processing
for
roles
is
defined
in
the
Core
Accessibility
API
Mappings
[
CORE-AAM-1.1
].
8.2
State
and
Property
Attributes
An
implementing
host
language
MUST
allow
attributes
with
the
following
characteristics:
Host
languages
that
support
XML
Namespaces
[
XML-NAMES
]
MAY
require
that
WAI-ARIA
attributes
be
used
with
a
namespace.
In
this
case,
the
namespace
for
WAI-ARIA
state
and
property
attributes
MUST
be
http://www.w3.org/ns/wai-aria/
.
To
use
WAI-ARIA
in
host
languages
that
do
not
explicitly
describe
support
for
it,
authors
SHOULD
use
this
namespace
as
well,
if
the
host
language
supports
namespaces
and
there
is
expectation
that
user
agents
will
recognize
the
WAI-ARIA
namespace.
The
namespace
prefix
is
not
defined
by
this
specification
but
generally
is
expected
to
be
"
aria
".
Note
The
WAI-ARIA
state
and
property
attributes
have
a
naming
convention
such
that
they
all
begin
with
the
string
"
aria-
".
This
is
not
a
namespace
prefix,
it
is
a
part
of
the
state
or
property
name.
Therefore,
when
using
WAI-ARIA
states
and
properties
with
namespace
prefixes,
the
complete
attribute
name
will
be
like
"
aria:aria-foo
".
Some
host
languages
do
not
use
namespaces
with
WAI-ARIA
state
and
property
attributes,
either
because
the
host
language
does
not
support
namespaces
or
because
the
designers
wish
to
incorporate
WAI-ARIA
into
the
core
feature
set.
In
these
host
languages,
the
namespace
name
for
these
attributes
has
no
value.
The
names
of
these
attributes
do
not
have
a
prefix
offset
by
a
colon;
in
the
terms
of
namespaces
they
are
unprefixed
attribute
names.
The
ECMAScript
binding
of
the
DOM
interface
getAttributeNS
for
example,
treats
an
empty
string
(
""
)
as
representing
this
condition,
so
that
both
getAttribute("aria-busy")
and
getAttributeNS("",
"aria-busy")
access
the
same
aria-busy
attribute
in
the
DOM
.
Note
According
to
the
requirements
of
this
section,
some
user
agents
recognize
WAI-ARIA
state
and
property
attributes
with
namespaces,
some
without
namespaces,
and
some
might
recognize
both.
Authors
are
advised
to
be
aware
of
which
form
is
supported
for
the
host
language
they
are
using.
Unless
the
host
language
and
supporting
user
agents
explicitly
indicate
that
the
namespace
is
required,
authors
are
advised
to
use
the
attribute
without
namespaces.
Even
user
agents
that
support
namespaces
generally
do
not
publish
namespaced
WAI-ARIA
states
and
properties
to
accessibility
APIs
.
In
particular,
current
implementations
of
HTML
,
including
XHTML
,
do
not
support
this
namespace.
8.3
Focus
Navigation
An
implementing
host
language
MUST
provide
support
for
the
author
to
make
all
interactive
elements
focusable,
that
is,
any
renderable
or
event-receiving
elements.
An
implementing
host
language
MUST
provide
a
facility
to
allow
web
authors
to
define
whether
these
focusable,
interactive
elements
appear
in
the
default
tab
navigation
order.
The
tabindex
attribute
in
HTML
5
is
an
example
of
one
implementation.
8.4
Implicit
WAI-ARIA
Semantics
WAI-ARIA
is
designed
to
provide
semantic
information
about
objects
when
host
languages
lack
native
semantics
for
the
object.
WAI-ARIA
is
designed,
however,
to
provide
additional
semantics
for
many
host
languages.
Furthermore,
host
languages
over
time
can
evolve
and
provide
new
native
features
that
correspond
to
WAI-ARIA
features.
Therefore,
there
are
many
situations
in
which
WAI-ARIA
semantics
are
redundant
with
host
language
semantics.
These
host
language
features
can
be
viewed
as
having
"implicit
WAI-ARIA
semantics".
User
agent
processing
of
features
with
implicit
WAI-ARIA
semantics
would
be
similar
to
the
processing
for
the
WAI-ARIA
feature.
The
processing
might
not
be
identical
because
of
lexical
differences
between
the
host
language
feature
and
the
WAI-ARIA
feature,
but
generally
the
user
agent
would
expose
the
same
information
to
the
accessibility
API
.
Features
with
implicit
WAI-ARIA
semantics
satisfy
WAI-ARIA
structural
requirements
such
as
required
owned
elements,
required
states
and
properties,
etc.
and
do
not
require
explicit
WAI-ARIA
semantics
to
be
provided.
On
elements
with
implicit
WAI-ARIA
roles,
authors
can
also
use
WAI-ARIA
states
and
properties
supported
by
those
roles
without
requiring
explicit
indication
of
the
WAI-ARIA
role.
For
example,
if
an
element
with
the
functionality
already
exists,
such
as
a
checkbox
or
radio
button,
use
the
native
semantics
of
the
host
language.
WAI-ARIA
markup
is
only
intended
to
be
used
to
enhance
the
native
semantics
(e.g.,
indicating
that
the
element
is
required
with
aria-required
),
or
to
change
the
semantics
to
a
different
purpose
from
the
standard
functionality
of
the
element.
Implicit
WAI-ARIA
semantics
affect
the
conflict
resolution
procedures
in
the
following
section,
Conflicts
with
Host
Language
Semantics.
Therefore,
implicit
WAI-ARIA
semantics
need
to
be
defined
in
a
normative
specification,
such
as
the
host
language
specification
or
the
Core
Accessibility
API
Mappings
[
CORE-AAM-1.1
].
8.5
Conflicts
with
Host
Language
Semantics
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
non-identical
semantics
(for
example,
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.
In
addition
to
these
normal
situations
in
which
WAI-ARIA
is
expected
to
override
native
semantics,
there
are
elements
that
are
inappropriate
to
override
with
WAI-ARIA
.
This
could
be
because
identical
host
language
semantics
exist,
so
WAI-ARIA
is
not
needed,
or
because
semantics
from
WAI-ARIA
directly
conflict
with
host
language
semantics.
When
a
feature
in
the
host
language
with
identical
role
semantics
and
values
is
available,
and
the
author
has
no
compelling
reason
to
avoid
using
the
host
language
feature,
authors
SHOULD
use
the
host
language
features
rather
than
repurpose
other
elements
with
WAI-ARIA
.
Host
languages
can
have
features
that
have
implicit
WAI-ARIA
semantics
corresponding
to
roles.
When
a
WAI-ARIA
role
is
provided,
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
(for
example,
the
HTML
'checked'
attribute
and
the
'aria-checked'
attribute
could
have
conflicting
values),
and
authors
are
expected
to
have
valid
reason
to
provide
a
WAI-ARIA
role
even
on
elements
that
would
not
normally
be
repurposed.
When
WAI-ARIA
states
and
properties
correspond
to
host
language
features
that
have
the
same
implicit
WAI-ARIA
semantic
,
it
can
be
particularly
problematic
to
use
the
WAI-ARIA
feature.
If
the
WAI-ARIA
feature
and
the
host
language
feature
are
both
provided
but
their
values
are
not
kept
in
sync,
user
agents
and
assistive
technologies
cannot
know
which
value
to
use.
Therefore,
to
prevent
providing
conflicting
states
and
properties
to
assistive
technologies,
host
languages
MUST
explicitly
declare
where
the
use
of
WAI-ARIA
attributes
on
each
host
language
element
conflicts
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
MAY
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
.
Conformance
checkers
MAY
signal
an
error
or
warning
when
a
WAI-ARIA
role
is
used
on
elements
with
strong
native
semantics,
but
as
described
above,
user
agents
MUST
still
use
the
value
of
the
semantic
of
the
WAI-ARIA
role
when
exposing
the
element
to
accessibility
APIs
unless
the
native
host
language
semantic
is
permanently
presentational.
The
opportunity
for
host
languages
to
create
exceptions
to
the
WAI-ARIA
override
of
native
features
is
meant
to
avoid
potential
author
errors
or
problems
with
intrinsic
processing
of
host
language
features.
Author
errors
could
happen
when
a
host
language
and
WAI-ARIA
provide
similar
but
not
identical
features,
where
it
might
not
be
clear
how
changing
one
but
not
the
other
affects
the
accessibility
API
.
Intrinsic
processing
refers
to
the
way
a
feature
is
processed,
beyond
simple
rendering
and
exposure
to
the
Accessibility
API
,
that
cannot
reasonably
be
changed
in
response
to
a
ARIA
feature,
and
would
lead
to
unpredictable
results
were
ARIA
allowed.
In
these
situations,
there
is
good
reason
for
host
languages
to
limit
the
scope
of
WAI-ARIA
.
However,
this
provision
does
not
give
blanket
permission
for
host
languages
to
forbid
the
use
of
WAI-ARIA
simply
by
documenting,
feature
by
feature,
that
it
may
not
be
used.
Host
languages
should
create
restrictions
on
the
use
of
ARIA
only
when
it
is
critical
to
effective
processing
of
content.
Certain
ARIA
features
are
critical
to
building
a
complete
model
in
the
accessibility
API
.
Such
features
are
not
expected
to
conflict
with
native
host
language
semantics
(though
they
may
complement
them).
Therefore,
host
languages
MUST
NOT
declare
strong
native
semantics
that
prevent
use
of
the
following
ARIA
features:
8.6
State
and
Property
Attribute
Processing
State
and
property
attributes
are
included
in
host
languages,
and
therefore
syntax
for
representation
of
their
value
types
is
governed
by
the
host
language.
For
each
of
the
value
types
defined
in
Value
,
an
appropriate
value
type
from
the
host
language
is
used.
Recommended
correspondences
between
WAI-ARIA
value
types
and
various
host
language
value
types
are
listed
in
Mapping
WAI-ARIA
Value
types
to
languages
.
This
is
a
non-normative
mapping
in
order
to
accommodate
new
host
languages
supporting
WAI-ARIA
.
The
list
value
types—ID
reference
list
and
token
list—allow
more
than
one
value
of
the
given
type
to
be
provided.
The
values
are
separated
by
delimiter
characters
recognized
by
the
host
language
for
list
attributes,
such
as
space
characters,
commas,
etc.
Some
languages
may
require
a
specific,
single
delimiter,
while
others
may
allow
various
delimiters.
Global
states
and
properties
are
supported
on
any
element
in
the
host
language.
However,
authors
MUST
only
use
non-global
states
and
properties
on
elements
with
a
role
supporting
the
state
or
property;
either
defined
as
an
explicit
WAI-ARIA
role,
or
as
defined
by
the
host
language
implicit
WAI-ARIA
semantic
matching
an
appropriate
WAI-ARIA
role.
When
a
role
attribute
is
added
to
an
element,
the
semantics
and
behavior
of
the
element,
including
support
for
WAI-ARIA
states
and
properties,
are
augmented
or
overridden
by
the
role
behavior.
User
agents
MUST
ignore
non-global
states
and
properties
used
on
an
element
without
a
role
supporting
the
state
or
property;
either
defined
as
an
explicit
WAI-ARIA
role,
or
as
defined
by
the
host
language
WAI-ARIA
semantic
matching
an
appropriate
WAI-ARIA
role.
For
example,
the
aria-valuetext
attribute
may
be
used
on
a
progressbar
.
WAI-ARIA
roles
have
associated
states
and
properties
that
are
qualified
as
"supported"
or
"required".
An
example
of
a
property
supported
by
the
combobox
role
is
aria-autocomplete
.
The
property
is
designated
"supported"
in
this
case
because
a
given
combobox
might
or
might
not
implement
auto
completion.
In
contrast,
the
combobox
role
requires
the
aria-expanded
state
in
order
to
indicate
that
it
is
expandable.
Comboboxes
have
a
descendant
listbox
that
is
either
open
or
closed.
If
the
listbox
is
open,
the
combobox
is
in
its
expanded
state;
otherwise
it
is
collapsed.
When
WAI-ARIA
roles
are
used,
supported
states
and
properties
that
are
not
present
in
the
DOM
are
treated
according
to
their
default
value.
Keeping
with
the
combobox
example,
a
missing
aria-autocomplete
attribute
is
equivalent
to
aria-autocomplete="none"
,
meaning
the
combobox
does
not
offer
auto
completion.
However,
required
states
and
properties
that
are
absent
are
an
author
error.
Missing
required
states
and
properties
are
treated
as
if
they
were
present
and
have
an
implicit
neutral
value
that
is
not
necessarily
their
default
value.
For
example,
the
default
value
of
aria-expanded
is
undefined
,
meaning
neither
expandable
nor
collapsible.
But
that
does
not
apply
to
the
case
of
a
combobox
.
In
this
case,
aria-expanded
is
needed
to
convey
the
expandable/collapsible
nature
of
the
combobox
.
Thus,
the
implicit
value
of
aria-expanded
for
the
combobox
role
is
false
,
meaning
expandable
(and
currently
collapsed).
The
characteristics
table
associated
with
each
WAI-ARIA
role
has
an
"
Implicit
Value
for
Role
"
entry
that
specifies
the
value
of
a
state
or
property
to
use
in
the
context
of
that
role
when
the
state
or
property
is
missing.
Elements
that
have
implicit
WAI-ARIA
semantics
support
the
full
set
of
WAI-ARIA
states
and
properties
supported
by
the
corresponding
role.
Therefore,
authors
MAY
omit
the
role
when
setting
states
and
properties.
The
role
is
only
needed
when
the
implicit
WAI-ARIA
role
of
the
element
needs
to
be
changed.
Sometimes
states
and
properties
are
present
in
the
DOM
but
have
a
zero-length
string
("")
as
their
value.
Authors
MAY
specify
a
zero-length
string
("")
for
any
supported
(but
not
required)
state
or
property.
User
agents
SHOULD
treat
state
and
property
attributes
with
a
value
of
""
the
same
as
they
treat
an
absent
attribute.
For
supported
states
and
properties,
this
corresponds
to
the
default
value,
but
if
it
is
a
required
attribute,
it
signals
an
author
error,
and
the
implicit
value
for
the
role
is
used.
8.6.1
ID
Reference
Error
Processing
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
element
.
aria-activedescendant
is
defined
as
referencing
only
a
single
ID
reference.
Any
aria-activedescendant
value
that
does
not
match
an
existing
ID
reference
exactly
is
an
author
error
and
will
not
match
any
element
in
the
DOM
.
8.7
CSS
Selectors
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
.