Accessibility of web content requires semantic information about widgets, structures, and behaviors, in order to allow assistive technologies to convey appropriate information to persons with
disabilities. This specification provides an ontology of roles, states, and properties that define accessible user interface elements and can be used to improve the accessibility and
interoperability of web content and applications. These semantics are designed to allow an author to properly convey user interface behaviors and structural information to assistive
technologies in document-level markup. This version adds features new since WAI-ARIA 1.1 [wai-aria-1.1] to improve interoperability with assistive technologies to form a more consistent
accessibility model for [HTML] and [SVG2]. This specification complements both [HTML] and [SVG2].
This document is part of the WAI-ARIA suite described in the
WAI-ARIA Overview.
Status of This Document
This section describes the status of this
document at the time of its publication. A list of current W3C
publications and the latest revision of this technical report can be found
in the
W3C standards and drafts index.
Publication as an Editor's Draft does not
imply endorsement by W3C and its Members.
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 a 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 that the individual believes contains
Essential Claim(s)
must disclose the information in accordance with
section 6 of the W3C Patent Policy.
expanding the accessibility information that can be supplied by the author;
requiring that supporting host languages provide full keyboard support that can 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
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
ARIA Authoring Practices Guide
[WAI-ARIA-PRACTICES-1.2] that introduces developers to the accessibility problems that WAI-ARIA is intended to solve, the fundamental concepts, and the technical approach of WAI-ARIA.
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 might 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 might look and act like a collapsible tree widget, but without appropriate semantics, the tree widget might not be perceivable to, or operable by, a person with a disability
because assistive technologies might 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 might look and act like a button widget, but without appropriate semantics, the button widget might not be perceivable to, or
operable by, a person with a disability because assistive technologies might 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 [CORE-AAM-1.2].
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.
Figure 1 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 1The contract model with accessibility APIs
Users of alternate input devices need keyboard accessible content. The new semantics, when combined with the recommended keyboard interactions provided in
ARIA Authoring Practices Guide, 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 can 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;
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:
WAI-ARIA Authoring Practices 1.2 addresses authoring recommendations for HTML, and is also of interest to developers of authoring tools and conformance checkers.
Assistive technologies use the enhanced information available in an accessibility API, or uses the WAI-ARIA markup
directly via the DOM, to convey semantic and interaction information to the user.
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 can be conveyed to assistive technologies.
Generally, authors using WAI-ARIA will provide the appropriate presentation and interaction features. Over time, host languages can
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 be used as an accessibility enhancement technology in markup-based host languages. Examples include
[HTML] and [SVG2], which both explicitly support the use of ARIA.
ARIA roles and properties clarify 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 can continue to use
WAI-ARIA, however, so the need for user agents to support
WAI-ARIA remains.
While specific features of WAI-ARIA might 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 might not implement all the semantics
WAI-ARIA provides, and various host languages can 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 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 can 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
1.5.1 Authoring Tools
Many of the requirements in the definitions of WAI-ARIA roles, states, and properties can be checked
automatically during the development process, similar to other quality control processes used for validating code. To assist authors who are creating custom widgets, authoring tools can
compare widget roles, states, and properties to those supported in WAI-ARIA as well as those supported in related and
cross-referenced roles, states, and properties. Authoring tools can notify authors of errors in widget design patterns, and can also prompt developers for information that cannot be
determined from context alone. For example, a scripting library can determine the labels for the tree items in a tree view, but would need to prompt the author to label the entire tree. To
help authors visualize a logical accessibility structure, an authoring environment might provide an outline view of a web resource based on the
WAI-ARIA markup.
In both HTML and SVG, tabindex is an important way browsers support keyboard focus navigation for implementations of
WAI-ARIA; authoring and debugging tools can check to make sure tabindex values are properly set. For example, error
conditions can include cases where more than one treeitem in a tree has a tabindex value greater than or equal to 0, where tabindex is not set on any treeitem, or
where aria-activedescendant is not defined when the element with the role tree has a tabindex value of greater than or equal to 0.
1.5.2 Testing Practices and Tools
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 might 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 might 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 can 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 might be appropriate to replace a custom user interface control with something that is easier to navigate with a keyboard, or touch screen device.
2. Important Terms
This section is non-normative.
While some terms are defined in place, the following definitions are used throughout this document.
relies on services provided by a user agent to retrieve and render Web content
works with a user agent or web content itself through the use of APIs, and
provides services beyond those offered by the user agent to facilitate user interaction with web content by people with disabilities
This definition might differ from that used in other documents.
Examples of assistive technologies that are important in the context of this document include the following:
screen magnifiers, which are used to enlarge and improve the visual readability of rendered text and images;
screen readers, which are most-often used to convey information through synthesized speech or a refreshable Braille display;
text-to-speech software, which is used to convert text into synthetic speech;
speech recognition software, which is used to allow spoken control and dictation;
alternate input technologies (including head pointers, on-screen keyboards, single switches, and sip/puff devices), which are used to simulate the keyboard;
alternate pointing devices, which are used to simulate mouse pointing and clicking.
Deprecated
A deprecated role, state, or property is one which has been
outdated by newer constructs or changed circumstances, and which might be removed in future versions of the
WAI-ARIA specification. user agents are encouraged to continue to support items identified as deprecated for backward
compatibility. For more information, see Deprecated Requirements in the Conformance section.
Defines
Used in an attribute description to denote that the value type is an integer,
number, or string.
Event from/to the host operating system via the accessibility API, notifying of a change of input focus.
Event
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.
An element or area matching the definition of focusable area in the HTML Specification.
Graphical Document
A document containing graphic representations with user-navigable parts. Charts, maps, diagrams, blueprints, and dashboards are examples of graphical documents. A graphical document is
composed using any combination of symbols, images, text, and graphic primitives (shapes such as circles, points, lines, paths, rectangles, etc).
Hidden
Indicates that the element is excluded from the accessibility tree and therefore not exposed to accessibility APIs.
Used in an attribute description to denote that the value type is an ID reference (identifying a single element) or
ID reference list (identifying one or more elements).
A type of region on a page to which the user might want quick access. Content in such a region is different from that of other regions on the page and relevant to a specific user
purpose, such as navigating, searching, perusing the primary content, etc.
Live Region
Live regions are perceivable regions of a web page that are typically updated as a result of an external event. These regions are not always updated as a result of a user interaction and
can receive these updates even when they do not have focus. Examples of live regions include a chat log, stock ticker, or a sport scoring section that updates periodically to reflect
game statistics. Since these asynchronous areas are expected to update outside the user's area of focus, assistive technologies such as screen readers have either been unaware of their
existence or unable to process them for the user. WAI-ARIA has provided a collection of properties that allow the author to identify these live regions and process them: aria-live,
aria-relevant, aria-atomic, and aria-busy.
Managed State
Accessibility APIstate 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.
Nemeth Braille
The Nemeth Braille Code for Mathematics is a braille code for encoding mathematical and scientific notation. See
Nemeth Braille on Wikipedia.
Object
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 can represent one or more DOM objects. Accessibility APIs have defined interfaces
that are distinct from DOM interfaces.
Ontology
A description of the characteristics of classes and how they relate to each other.
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 can 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.
Relationship
A connection between two distinct things. Relationships can be of various types to indicate which object labels another, controls another, etc.
Role
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.
Semantics
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.
State
A state is a dynamic property expressing characteristics of an object that can 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.
Target Element
An element specified in a WAI-ARIA relation. For example, in <div aria-controls=”elem1”>, where
“elem1” is the ID for the target element.
Unicode Braille Patterns
In Unicode, braille is represented in a block called Braille Patterns (U+2800..U+28FF). The block contains all 256 possible patterns of an 8-dot braille cell; this includes the complete
6-dot cell range which is represented by U+2800..U+283F. In all braille systems, the braille pattern dots-0 (U+2800) is used to represent a space or the lack of content; it is also
called a blank Braille pattern. See Braille Patterns on Wikipedia.
Widget
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).
3. Conformance
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 authors and 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.
Non-normative (informative) sections provide information useful to understanding the specification. Such sections might 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 agentMUST 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 might 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, authors SHOULD update the web
application accordingly when notified of a change request from the user agent or assistive technology.
3.4 Conformance Checkers
Any application or script verifying document conformance or validity SHOULD include a test for all of the normative author requirements in this specification. If testing for a given
requirement, conformance checkers MUST issue an error if an author "MUST" requirement isn't met, and MUST issue a warning if an author "SHOULD" requirement isn't met.
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.
4. Using WAI-ARIA
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
ARIA Authoring Practices Guide). 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.
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.
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 can 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.
<lirole="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.
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.
<lirole="menuitemcheckbox"aria-checked="true"><imgsrc="checked.gif"alt=""><!-- note: additional scripts required to toggle image source -->
Sort by Last Modified
</li>
4.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 can 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 can also activate
the container by clicking on one of the descendants within it. When the container or its active descendant has focus, the user can 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.
4.3.1 Information for Authors
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.
Implement the host language method for keyboard navigation so that widgets that support aria-activedescendant can 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.
Focusable, if the element also has a WAI-ARIA role. The element needs to be focusable because it
could be referenced by the aria-activedescendant attribute. Native elements that have no role attribute do not need to be checked; their native
semantics determine the focusable state.
When an assistive technology uses its platform's accessibility 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 agentMUST set the
DOM focus to it.
Otherwise, if the element being focused has an ID and the ID is referenced by the aria-activedescendant attribute of an element that is focusable, the user agent MUST
set DOM focus to the element that has the aria-activedescendant attribute.
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 element being focused has an ID and is an accessibility descendant of either a container element with both an aria-activedescendant attribute and has
DOM focus, or by a container element that is controlled by an element with both an aria-activedescendant attribute and has
DOM focus, the user agent MUST set the accessibility API focused state and fire an
accessibility API focus event on the element identified by the value of aria-activedescendant.
5. The Roles Model
This section defines WAI-ARIA roles and describes their characteristics and properties.
The roles, their characteristics, the states and properties they support, and specification of how they can be used in markup, shall be considered normative.
In order to reflect the content in the DOM, user agents SHOULD map the role attribute to the appropriate value in the implemented accessibility API, and user agents SHOULD update the mapping
when the role attribute changes.
5.1 Relationships Between Concepts
The Roles Model uses the following relationships to relate WAI-ARIA roles to each other and to concepts from other specifications,
such as HTML.
5.1.1 Superclass Role
The role that the current subclassed role extends in the Roles Model. This extension causes all the states and properties of the superclass role to propagate to the subclass role.
Other than well known stable specifications, inheritance can be restricted to items defined inside this specification, so that external items cannot be changed and affect inherited
classes.
5.1.2 Subclass Roles
Informative list of roles for which this role is the superclass. This is provided to facilitate reading of the specification but adds no new information.
5.1.3 Related Concepts
Informative data about a similar or related idea from other specifications. Concepts that are related are not necessarily identical. Related concepts do not inherit properties from each
other. Hence if the definition of one concept changes, the properties, behavior, and definition of its related concept is not affected.
For example, a progress bar is like a status indicator. Therefore, the progressbarwidget has a related concept which includes status. However, if the
definition of status is modified, the definition of a progressbar is not affected.
5.1.4 Base Concept
Informative data about objects that are considered prototypes for the role. Base concept is similar to type, but without inheritance of limitations and properties. Base
concepts are designed as a substitute for inheritance for external concepts. A base concept is like a related concept except that the base concept is almost
identical to the role definition.
For example, the checkbox defined in this document has similar functionality and anticipated behavior to a <input type="checkbox"> defined in
HTML. Therefore, a checkbox has an [HTML] checkbox as a baseConcept. However, if the original [HTML] checkbox baseConcept definition is modified,
the definition of a checkbox in this document will not be affected, because there is no actual inheritance of the respective type.
5.2 Characteristics of Roles
Roles are defined and described by their characteristics. Characteristics define the structural function of a role, such as what a role is, concepts behind it, and what instances the role
can or must contain. In the case of widgets this also includes how it interacts with the user agent based on mapping to HTML forms. States and properties from
WAI-ARIA that are supported by the role are also indicated.
Roles define the following characteristics.
5.2.1 Abstract Roles
Abstract roles are the foundation upon which all other WAI-ARIA roles are built. Authors MUST NOT use abstract roles
because they are not implemented in the API binding. User agents MUST NOT map abstract roles to the standard role mechanism of the
accessibility API. Abstract roles are provided to help with the following:
Organize the Roles Model and provide roles with a meaning in the context of known concepts.
Streamline the addition of roles that include necessary features.
5.2.2 Required States and Properties
States and properties specifically required for the role and subclass roles. Authors MUST provide a non-empty value for required states and properties.
Authors MUST NOT use the value undefined for required states and properties, unless undefined is an explicitly-supported value of that state or property.
When an object inherits from multiple ancestors and one ancestor indicates that property is supported while another ancestor indicates that it is required, the property is required
in the inheriting object.
States and properties specifically applicable to the role and child roles. Authors MAY provide values for supported states and properties, but need not
in cases where default values are sufficient. user agentsMUST map all supported states and properties for the role to an accessibility API. If the state or property is undefined and
it has a default value for the role, user agentsSHOULD expose the default value.
Informative list of properties that are inherited by a role from superclass roles. States and properties are inherited from superclass roles in the Roles Model, not
from ancestor elements in the DOM tree. These properties are not explicitly defined on the role, as the inheritance of properties is
automatic. This information is provided to facilitate reading of the specification. The set of supported states and properties combined with inherited states and properties forms the full
set of states and properties supported by the role.
5.2.5 Prohibited States and Properties
List of states and properties that are prohibited on a role. Authors MUST NOT specify a prohibited state or property.
Note
A host language attribute with the appropriate implicit WAI-ARIA semantic would also prohibit a state or property in this section.
5.2.6 Allowed Accessibility Child Roles
A list of roles which are allowed on an accessibility child (simplified as "child") of the element with this role. Authors MUST only add child element with allowed roles. For
example, an element with the role list can own child elements with the role listitem, but cannot own elements with the role option.
To determine whether an element is the child of an element, user agentsMUST ignore any intervening elements with the role generic or none.
Descendants which are not children of an element ancestor are not constrained by allowed accessibility child roles. For example, an image is not an allowed child of a
list, but it is a valid descendant if it is also a descendant of the list's allowed child listitem.
Note
A role that has 'allowed accessibility child roles' does not imply the reverse relationship. Elements with roles in this list do not always have to be found within elements of the given
role. See required accessibility parent roles for requirements about the context where elements of a given role will be contained.
Note
An element with a subclass role of the 'allowed accessibility child role' does not fulfill this requirement. For example, the listbox role allows
a child element using the option or group role. Although the group role is the superclass of row, adding a child element with a role of
row will not fulfill the requirement that listbox allows children with option or group roles.
The required accessibility parent (simplified as "parent") role defines the container where this role is allowed. If a role has a required accessibility parent, authors MUST
ensure that an element with the role is an accessibility child of an element with the required accessibility parent role. For example, an element with role listitem is
only meaningful when it is a child of an element with role list.
To determine whether an element has a parent with the required role, user agentsMUST ignore any elements with the role generic or none.
Also, user agentsSHOULD ignore the role if it occurs outside the context of a required accessibility parent role.
author: name comes from values provided by the author in explicit markup features such as the aria-label attribute, the aria-labelledby attribute, or the host
language labeling mechanism, such as the alt or title attributes in HTML, with HTML title attribute
having the lowest precedence for specifying a text alternative.
contents: name comes from the text value of the element node. Although this might be allowed in addition to "author" in some roles, this is used in content only if higher
priority "author" features are not provided. Priority is defined by the Accessible Name and Description Computation [ACCNAME-1.2].
prohibited: the element does not support name from author. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.
Indicates whether DOM descendants are presentational. user agentsSHOULD NOT expose descendants of this element through the platform
accessibility API. If user agents do not hide the descendant nodes, some information might be read twice.
Authors MUST NOT specify aria-owns on an element which has Presentational Children.
5.2.10 Implicit Value for Role
Many states and properties have default values. Occasionally, the default value when used on a given role should be different from the usual default. Roles that require a state or property
to have a non-standard default value indicate this in the "Implicit Value for Role". This is expressed in the form "Default for state or property name is
new default value". Roles that define this have the new default value for the state or property if the author does not provide an explicit value.
5.3 Categorization of Roles
To support the current user scenario, this specification categorizes roles that define user interface widgets (sliders, tree controls, etc.) and those that define page
structure (sections, navigation, etc.). Note that some assistive technologies provide special modes of interaction for regions marked with role application or
document.
A visual description of the relationships among roles is available in the ARIA 1.2 Class Diagram.