Notes on ARIA use in HTML
First rule of ARIA use
If you can use a native HTML element [[!HTML5]] or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
Under what circumstances may this not be possible?
- If the visual design constraints rule out the use of a particular native element, because the element cannot be styled as required.
- If the feature is not currently available in HTML.
- If the feature is available in HTML [[!HTML5]] but it is not implemented or it is implemented, but accessibility support is not.
Second rule of ARIA use
Do not change native semantics, unless you really have to.
For example: Developer wants to build a heading that's a button.
Do not do this:
<h1 role=button>heading button</h1>
Do this:
<h1><button>heading button</button></h1>
Or if you can't possibly use the correct element, do this:
<h1><span role=button>heading button</span></h1>
Note: if a non interactive element is used as the basis for an interactive element, developers have to add the semantics using ARIA and the appropriate interaction behaviour using scripting. In the case of a button, for example, it is much better and easier to Just use a (native HTML) button.
Note: it is OK to use native HTML elements, that have similar semantics to ARIA roles used, for fallback. For example using HTML list elements for the skeleton of an ARIA enabled, scripted tree widget.
Third rule of ARIA use
All interactive ARIA controls must be usable with the keyboard.
If you create a widget that a user can click or tap or drag or drop or slide or scroll, a user must also be able to navigate to the widget and perform an equivalent action using the keyboard.
All interactive widgets must be scripted to respond to standard key strokes or key stroke combinations where applicable.
For example if using role=button the element must be able to recieve focus and a user must be able to activate the action associated with the element using both the enter and the space key.
Refer to the keyboard and structural navigation and design patterns sections of the WAI-ARIA 1.0 Authoring Practices
What does adding a role do to the native semantics?
Adding an ARIA role overrides the native role semantics.
For example:
<h1 role=button>text</h1>
Becomes this in the accessibility tree:
<button>text</button>
What adding a role does not do?
Adding an ARIA role does not change the behaviours, states and properties
For example:
This:
<button role="heading" aria-level="1">text</button>
Becomes this in the accessibility tree:
<h1>text</h1>
But it can still be pressed, it is still in the default tab order, still looks like a button, still triggers any associated actions when pressed. That's why it is a HTML5 conformance error to change a button into a heading.
Note: likewise, changing the role of an element does not add behaviours, properties or states of the role used. You must add those yourself.
Add ARIA inline or via script?
If the ARIA role or aria-* attribute does not rely on scripting to provide interaction behaviour, then it is safe to include the ARIA markup inline. For example, it is fine to add ARIA landmark roles or ARIA labelling and describing roles inline. If the content and interaction is only supported in a scripting enabled browsing context, for example Google docs applications require JavaScript enabled to work, so it is safe for them to include the ARIA markup inline.
Otherwise add ARIA via scripting.
ARIA validation
The easiest method is to use the HTML5 DOCTYPE with ARIA markup and validate using the W3C Nu Markup Validation Service. ARIA works equally well with any other DOCTYPE, but validation tools will produce errors when they encounter ARIA markup as the associated DTDs have not been updated to recognise ARIA markup and it is unlikely they ever will be.
Note: The W3C Nu Markup Validation Service support for ARIA checking is a work in progress, so cannot be wholly relied upon to provide the correct results. It is recommended that if you encounter a result that conflicts with the ARIA conformance requirements in the ARIA specification or the HTML5 specification, please raise a bug report.
Use of role=presentation
role=presentation removes the semantics from the element it is on.
For example, this:
<h1 role="presentation">text</h1>
becomes this:
<>text</>
For elements with no required children, any elements nested inside the element with role=presentation preserve their semantics.
For example, this:
<h1 role="presentation"><abbr>API</abbr></h1>
becomes this:
<><abbr>API</abbr></>
For elements with required children (such as ul or table) any required child elements nested inside the element with role=presentation also have their semantics removed.
For example, this:
<table role="presentation">
<tr><td><abbr>API</abbr></td><tr>
</table>
becomes this:
<>
<><><abbr>API</abbr></></>
</>
Note: Any elements that are not required children of the element with a role=presentation keep their semantics. This includes other elements with required children.
For example, this:
<table role="presentation">
<tr><td>
<table>
<tr><td><abbr>API</abbr></td><tr>
</table>
</td><tr>
</table>
Becomes this:
<>
<><>
<table>
<tr><td><abbr>API</abbr></td><tr>
</table>
</><>
</>aria-labelledby and aria-describedby
Currently aria-labelledby and aria-describedby are more robustly supported for associating text content to a subset of interactive content elements, they do not work correctly on links, support on embedded content is unknown, but can be safely used on form controls including the many input types.
In Internet Explorer, if you use aria-labelledby with multiple id references or aria-describedby with single or multiple id references, the referenced elements must be what Microsoft terms as accessible HTML elements.
The following example of aria-labelledby with multiple references uses the label element as it makes sense and it's an accessible element (in IE terms). The example could have used a span (for example) but then tabindex=-1 would have to be added. Refer to Making Non accessible Elements Accessible.
<label id="l1" for="f3">label text</label>
<input type="text" id="f3" aria-labelledby="l1 l2">
<p>other content</p>
<label id="l2">more label text</label>
Note: elements also become accessible HTML elements in Internet Explorer when the element has an ARIA role. For example:
<div aria-describedby="test" tabindex="0">text</div>
<div id="test" role="tooltip">tooltip text</div>
Using ARIA role=application
So when should I use it, and when not?
You do not use it if a set of controls only contains these widgets, that are all part of standard HTML. This also applies if you mark them up and create an interaction model using WAI-ARIA roles instead of standard HTML widgets:
text box. This also applies to password, search, tel and other newer input type derivativestextareacheck boxbuttonradio button(usually inside a fieldset/legend element wrapper)select + option(s)links,paragraphs,headings, and other elements that are classic/native to documents on the web.
You also do not use the application role if your widget is one of the following more dynamic and non-native widgets. Screen readers and other assistive technologies that support WAI-ARIA will support switching between browse and focus modes for these by default, too:
tree viewslidertablethat has focusable items and is being navigated via the arrow keys, for example a list of e-mail messages where you provide specific information. Other examples are interactive grids, tree grids etc.- A list of tabs (
tab, tablist) where the user selects tabs via the left and right arrow keys. Remember that you have to implement the keyboard navigation model for this! dialogandalertdialog. These cause screen readers to go into a sort of application mode implicitly once focus moves to a control inside them. Note that for these to work best, set thearia-describedbyattribute of the element whose role isdialogto theidof the text that explains the dialog's purpose, and set focus to the first interactive control when you open it:
<div role="dialog" aria-label="login" aria-describedby="log1">
<div id="log1" tabindex="-1">Provide user name and password to login.</div>
...
...
</div>toolbarandtoolbar buttons,menusandmenu items, and similar.
You only want to use role=application if the content you’re providing consists of only interactive controls, and of those, mostly advanced widgets, that emulate a real desktop application. Note that, despite many things now being called a web application, most of the content these web applications work with are still document-based information, be it FaceBook posts and comments, blogs, Twitter feeds, even accordions that show and hide certain types of information dynamically. We primarily still deal with documents on the web, even though they may have a desktop-ish feel to them on the surface.
In short: The times when you actually will use role=application is probably going to be in very rare cases!
So where do I put role=application in the rare cases it is useful?
Put it on the closest containing element of your widget, for example the parent div of your element that is your outer most widget element. If that outer div wraps only widgets that need the application interaction model, this will make sure focus mode is switched off once the user tabs out of this widget.
Only put it on the body element if your page consists solely of a widget or set of widgets that all need the focus mode to be turned on. If you have a majority of these widgets, but also have something you want the user to browse, use role=document on the outer-most element of this document-ish part of the page. It is the counterpart to role=application and will allow you to tell the screen reader to use browse mode for this part. Also make this element tabbable by setting a tabindex=0 on it so the user has a chance to reach it.
As a rule of thumb: If your page consists of over 90 or even 95 percent of widgets, role=application may be appropriate. Even then, find someone knowledgeable who can actually test two versions of this: One with and one without role=application set to see which model works best.
NEVER put it on a widely containing element such as body if your page consists mostly of traditional widgets or page elements such as links that the user does not have to interact with in focus mode. This will cause huge headaches for any assistive technology user trying to use your site/application.
For further information on the use of role=application refer to If you use the WAI-ARIA role "application", please do so wisely!
Recommendations Table:
legend
'Should authors explicitly define default ARIA semantics? ' column
- NO = the default semantics are already implemented by browsers, so the default implied role, state or property associated with an element or attribute does not need to be used. There are notes indicating under certain circumstances default semantics are useful.
- N/A = there are no default ARIA semantics, but there may well be accessibility API semantics implemented by the browser.
- Yes = the default semantics are not implemented across browsers, so the default implied role, state, property, or suggested semantics (if no ARIA default) may be used.
'What Other ARIA roles, states and properties may be used?' column
NONE = the element does not support ARIA roles, states and properties, this is usually because the element is not displayed in the document.
| HTML language feature | Default ARIA semantics | Should authors explicitly define default ARIA semantics? | What Other ARIA roles, states and properties may be used? |
|---|---|---|---|
| All elements | varies | varies | Role: presentation, except focusable elements or those with the warning 'Not role=presentation' or those indicated: NONE |
a element with a href |
role=link |
NO | Roles: Any global Not |
address
| NONE | N/A | Role: |
area with a href |
role=link |
NO | Any Not |
article |
role=article |
YES note 0 | Roles: Note 0: NO if a child of an |
aside |
role=complementary |
YES | Roles: |
audio |
NONE | N/A | Role: |
base
| NONE | N/A | NONE |
body |
role=document |
NO | Any global aria-* attributes |
button
| role=button |
NO note 0a | Roles: Note 0a: YES If the Not |
button type="menu"
| role=button with aria-haspopup=true |
NO note 0b | Roles: Note 0b: YES If Not |
caption
| NONE | N/A | Any global aria-* attributes |
| NONE | N/A | NONE | |
datalist
| role=listbox, with aria-multiselectable=false |
NO note 1 | Any global Note 1: YES If |
dd, dt
| NONE | N/A | Any global aria-* attributes |
details
| role=group |
YES | Any global aria-* attributes and any aria-* attributes applicable to the group role. |
dialog element with no open attribute |
role=dialog, with aria-hidden =true |
YES | Any global Not |
div
| NONE | N/A | Role: Any Any global Note: It is recommended that any scripted widgets use the semantically neutral |
dl
| role=list |
NO | |
embed
| NONE | N/A | Role: Any global |
figure
| NONE | N/A | Role:Any, recommend Any global |
footer
| NONE | N/A | Use |
form |
role=form |
NO | |
grouping content elements not listed elsewhere:
|
NONE | N/A | Role: any Note: Although the listed elements do not have any default ARIA semantics they do have meaning and this meaning may be represented in roles, states and properties not provided by ARIA, but present in accessibility APIs. It is therefore recommended that authors consider adding a Any global |
h1 to h6 element |
role=heading, with the aria-level = element's outline depth |
NO | Any global aria-* attributes |
head
| NONE | N/A | NONE |
header
| NONE | YES | Use |
hr
| role=separator |
NO | Any global aria-* attributes and any aria-* attributes applicable to the separator role. |
html
| NONE | N/A | NONE |
iframe
| NONE | N/A | Role: Any global |
iframe (seemless)
| EDITOR: okay to override with any general grouping role. | N/A | Role: Any global |
img with alt="" |
role=presentation |
NO | NONE |
img with alt="some text" |
role=img |
NO | Role: Any Any global |
input type= button |
role=button |
NO note 1b | Role: Any global Note 1a: YES If the Not |
input type= checkbox |
aria-checked=mixed if the element's indeterminate IDL attribute is true, or aria-checked=true if checked attribute is present. |
NO note 2 |
Note 2: YES If you are using Not |
input type = color |
NONE | N/A |
Not |
input type = date |
NONE | N/A |
Not |
input type = datetime |
NONE | N/A |
Not |
input type = datetime-local |
NONE | N/A |
Not |
input type = email with no list attribute |
role=textbox |
NO |
Not |
input type = file |
NONE | N/A |
Not |
input type = hidden |
NONE | N/A | NONE |
input type= image |
role=button |
NO note 2a | Role: Any global Note 2a: YES If the Not |
input type = month |
NONE | N/A |
Not |
input type = number |
role=spinbutton, the aria-valuemax = maximum, the aria-valuemin = minimum, and, if the result of applying the rules for parsing floating point number values to the element's value is a number, with the aria-valuenow property set to that number |
NO note 3 | Any global Note 3: YES If It is okay to use aria-valuetext, with or without an explicit role. Not |
input type = password |
role=textbox |
NO |
Not |
input type = radio |
role=radio |
NO | Role: Any global Not |
input type = range |
role=slider role, with the aria-valuemax= maximum, the aria-valuemin = minimum, and the aria-valuenow property set to the result of applying the rules for parsing floating point number values to the element's value, if that results in a number, or the default value otherwise |
NO note 4 | Any global Note 4: YES If It is okay to use aria-valuetext, with or without an explicit role. Not |
input type= reset |
button role |
NO |
Not |
input type = search, with no list attribute |
textbox role |
NO |
Not |
input type = submit |
button role |
NO |
Not |
input type = tel with no list attribute |
textbox role |
NO |
Not |
input type = text with no list attribute |
textbox role |
NO |
Not |
input type = text, search, tel, url, or email with a list attribute |
combobox role, with the aria-owns property set to the same value as the list attribute |
NO note 5 | Any global Note 5: YES If Not |
input type= time |
NONE | NO |
Not |
input type = url with no list attribute |
textbox role |
NO |
Not |
input type = week |
NONE | NO |
Not |
| NONE | N/A | Role: any Note: Although the listed elements do not have any default ARIA semantics they do have meaning and this meaning may be represented in roles, states and properties not provided by ARIA, but present in accessibility APIs. It is therefore recommended that authors consider adding a Any global |
|
keygen
| NONE | N/A |
Not |
label
| NONE | N/A | Any global aria-* attributes |
li element whose parent is an ol or ul
| role=listitem |
NO note 5a | Role: Note 5a: YES if |
link element with a href |
role=link |
NO | NONE |
main |
role=main |
YES | Any global aria-* attributes |
map |
NONE | N/A | NONE |
math |
YES | Any global aria-* attributes |
|
menu type = popup menu |
role=menu with aria-haspopup="true" |
NO note 6 | Note 6: YES if Any global Not |
menu type = toolbar |
role=toolbar |
NO note 7 | Note 7: YES if Any global Not |
menuitem
type = command
| role=menuitem |
NO note 7a | Note 7a: YES if Any global Not |
menuitem type = checkbox
| role=menuitemcheckbox |
NO note 7b | Note 7b: YES if Any global Not |
menuitem type = radio
| role=menuitemradio |
NO note 7c | Note 7c: YES if Any global Not |
meta
| NONE | N/A | NONE |
meter
| role=progressbar | N/A | Any global aria-* attributes |
nav
| role=navigation |
YES | Any global aria-* attributes |
noscript
| NONE | N/A | NONE |
object
| NONE | N/A | Role: Any global |
optgroup
| NONE | N/A | Any global aria-* attributes |
| option element that is in a list of options or that represents a suggestion in a datalist | role=option, with aria-selected=true if the selected attribute is present, aria-selected=false otherwise. |
NO |
Not |
ol
| role=list |
NO | Role: directory, listbox, menu, menubar, tablist, toolbar, tree |
output
| role=status |
DEPENDS | Role: Any, use in conjunction with Any global Note: If role="status" is added, it will force this to be a broadcasting live region. In some cases, this is fine, but if this is an element whose value changes constantly due to scripted updates rather than explicit user action (like a progressbar), it'd be more appropriate to set aria-live="off". Otherwise some AT users are going to find this very distracting, even impossible to use. Even "polite" live regions can be annoying if they are overused. |
param
| NONE | N/A | NONE |
progress
| progressbar role, with, if the progress bar is determinate, the aria-valuemax property set to the maximum value of the progress bar, the aria-valuemin property set to zero, and the aria-valuenow property set to the current value of the progress bar |
NO note 8 | Note 8: YES if it's okay to use aria-valuetext on this (e.g. "Step 2 of 10"), with or without an explicit role. Any global |
script
| NONE | N/A | NONE |
section
| role=region |
NO | Role: Any global |
select element with a multiple attribute |
role=listbox, with aria-multiselectable=true |
NO |
Not |
select element with no multiple attribute |
role=listbox, with aria-multiselectable=false |
NO |
Not |
source
| NONE | N/A | NONE |
span
| NONE | N/A | Role: Any Any global Note: It is recommended that any scripted widgets use the semantically neutral |
style
| NONE | N/A | NONE |
SVG
| NONE | N/A | Role: Any global |
summary
| NONE | N/A | if Any global |
table
| NONE | N/A | Role: any Note 1: It is recommended to not override the Note 2: It is recommended that the Any global |
textarea
| role=textbox |
NO |
Not |
| role=rowgroup | No | Role: any Note: addition of roles does not appear to have any effect upon these unrendered elements |
|
title
| NONE | N/A | NONE |
td
| NONE | N/A | Role: any Note: It is recommended to not override the Any global |
| Text level semantic elements not listed elsewhere:
|
NONE | N/A | Role: any Note: Although the listed elements do not have any default ARIA semantics they do have meaning and this meaning may be represented in roles, states and properties not provided by ARIA, but present in accessibility APIs. It is therefore recommended that authors consider adding a Any global |
th
| NONE | N/A | Role: any Note: It is recommended to not override the Any global |
| NONE | N/A | Role: any Note: It is recommended to not override the Any global |
|
track
| NONE | N/A | NONE |
| ul | role=list |
NO | Role: Any global |
video
| NONE | N/A | Role: Any global |
An element that defines a command, with type="checkbox", and is a descendant of a menu type = list |
role=menuitemcheckbox, with aria-checked="true" if checked attribute is present |
NO note 9 | Note 9: YES if the element is being used in a scripted polyfill. Any global Not |
An element that defines a command, type="command", and is a descendant of a menu type = list |
role=menuitem |
NO note 10 | Note 10: YES if the element is being used in a scripted polyfill. Any global Not |
An element that defines a command, type="radio", and is a descendant of a menu type = list |
menuitemradio role, with the aria-checked="true" if checked attribute is present |
NO note 11 | Note 11: YES if the element is being used in a scripted polyfill. Any global Not |
Element with a disabled attribute |
aria-disabled="true" |
NO | Use the Only use the |
Element with an inert attribute |
aria-hidden="true" |
YES (DEPENDS) |
Note:Inert content is used for things like the background contents while showing a modal dialog. In this case, it would be appropriate and recommended to use aria-hidden="true"… If there are cases where inert is being used to deactivate foreground content that is still intended for consumption, @inert should be combined with an explicit aria-hidden="false" to override the default rendering engine behavior. |
Element with a required attribute |
The aria-required="true" |
Yes | Use the Also use the |
Element with a readonly attribute |
aria-readonly=true |
NO | Use the Only use the |
Element with a hidden attribute |
aria-hidden=true |
NO | Use the hidden attribute in conjunction with the CSS display:none property |
| Element is natively focusable (links, buttons, etc.) | NONE | NO | Not role=presentation |
| Element is not natively focusable (li, span, div, etc.) | DEPENDS | YES | Not role=presentation
For example, is focusable but has no role in most rendering engines. Needs a role in a lot of cases. (NEED TO GIVE EXAMPLES). |
| Element that is a candidate for constraint validation but that does not satisfy its constraints | aria-invalid=true |
NO | Only use the (Editor's NOTE) Provide link to what HTML defines what constitutes the user has interacted with the control "significantly." ARIA defines aria-invalid="grammar" and aria-invalid="spelling" |
ARIA Role, State, and Property Quick Reference
(Reformatted and reorganized information from: Accessible Rich Internet Applications (WAI-ARIA) 1.0)
In addition to the states and properties shown in the table, the following global states and properties are supported on all roles.
Global states and properties
| Role | Description | Required Properties | Supported Properties - Global + |
|---|---|---|---|
alert |
A message with important, and usually time-sensitive, information. See related alertdialog and status. | NONE | |
alertdialog |
A type of dialog that contains an alert message, where initial focus goes to an element within the dialog. See related alert and dialog. | NONE | |
application |
A region declared as a web application, as opposed to a web document. | NONE | |
article |
A section of a page that consists of a composition that forms an independent part of a document, page, or site. | NONE | |
banner |
A region that contains mostly site-oriented content, rather than page-specific content. | NONE | |
button |
An input that allows for user-triggered actions when clicked or pressed. See related link. | NONE | |
checkbox |
A checkable input that has three possible values: true, false, or mixed. | |
|
columnheader |
A cell containing header information for a column. | NONE | |
combobox |
A presentation of a select; usually similar to a textbox where users can type ahead to select an option, or type to enter arbitrary text as a new item in the list. See related listbox. | ||
complementary |
A supporting section of the document, designed to be complementary to the main content at a similar level in the DOM hierarchy, but remains meaningful when separated from the main content. | NONE | |
contentinfo |
A large perceivable region that contains information about the parent document. | NONE | |
definition |
A definition of a term or concept. | NONE | |
dialog |
A dialog is an application window that is designed to interrupt the current processing of an application in order to prompt the user to enter information or require a response. See related alertdialog. | NONE | |
directory |
A list of references to members of a group, such as a static table of contents. | NONE | |
document |
A region containing related information that is declared as document content, as opposed to a web application. | NONE | |
form |
A landmark region that contains a collection of items and objects that, as a whole, combine to create a form. See related search. | NONE | |
grid |
A grid is an interactive control which contains cells of tabular data arranged in rows and columns, like a table. | NONE | |
gridcell |
A cell in a grid or treegrid. | NONE | |
group |
A set of user interface objects which are not intended to be included in a page summary or table of contents by assistive technologies. | NONE | |
heading |
A heading for a section of the page. | NONE | |
img |
A container for a collection of elements that form an image. | NONE | |
link |
An interactive reference to an internal or external resource that, when activated, causes the user agent to navigate to that resource. See related button. | NONE | |
list |
A group of non-interactive list items. See related listbox. | NONE | |
listbox |
A widget that allows the user to select one or more items from a list of choices. See related combobox and list. | NONE | |
listitem |
A single item in a list or directory. | NONE | |
log |
A type of live region where new information is added in meaningful order and old information may disappear. See related marquee. | NONE | |
main |
The main content of a document. | NONE | |
marquee |
A type of live region where non-essential information changes frequently. See related log. | NONE | |
math |
Content that represents a mathematical expression. | NONE | |
menu |
A type of widget that offers a list of choices to the user. | NONE | |
menubar |
A presentation of menu that usually remains visible and is usually presented horizontally. | NONE | |
menuitem |
An option in a group of choices contained by a menu or menubar. | NONE | |
menuitemcheckbox |
A checkable menuitem that has three possible values: true, false, or mixed. | |
|
menuitemradio |
A checkable menuitem in a group of menuitemradio roles, only one of which can be checked at a time. | ||
navigation |
A collection of navigational elements (usually links) for navigating the document or related documents. | NONE | |
note |
A section whose content is parenthetic or ancillary to the main content of the resource. | NONE | |
option |
A selectable item in a select list. | NONE | |
presentation |
An element whose implicit native role semantics will not be mapped to the accessibility API. | NONE | |
progressbar |
An element that displays the progress status for tasks that take a long time. | NONE | |
radio |
A checkable input in a group of radio roles, only one of which can be checked at a time. | ||
radiogroup |
A group of radio buttons. | NONE | |
region |
A large perceivable section of a web page or document, that the author feels is important enough to be included in a page summary or table of contents, for example, an area of the page containing live sporting event statistics. | NONE | |
row |
A row of cells in a grid. | NONE | |
rowgroup |
A group containing one or more row elements in a grid. | NONE | |
rowheader |
A cell containing header information for a row in a grid. | NONE | |
scrollbar |
A graphical object that controls the scrolling of content within a viewing area, regardless of whether the content is fully displayed within the viewing area. | ||
search |
A landmark region that contains a collection of items and objects that, as a whole, combine to create a search facility. See related form. | NONE | |
separator |
A divider that separates and distinguishes sections of content or groups of menuitems. |
|
|
slider |
A user input where the user selects a value from within a given range. | ||
spinbutton |
A form of range that expects the user to select from among discrete choices. | ||
status |
A container whose content is advisory information for the user but is not important enough to justify an alert, often but not necessarily presented as a status bar. See related alert. | NONE | |
tab |
A grouping label providing a mechanism for selecting the tab content that is to be rendered to the user. | NONE | |
tablist |
A list of tab elements, which are references to tabpanel elements. | NONE | |
tabpanel |
A container for the resources associated with a tab, where each tab is contained in a tablist. | NONE | |
textbox |
Input that allows free-form text as its value. | NONE | |
timer |
A type of live region containing a numerical counter which indicates an amount of elapsed time from a start point, or the time remaining until an end point. | NONE | |
toolbar |
A collection of commonly used function buttons represented in compact visual form. | NONE | |
tooltip |
A contextual popup that displays a description for an element. | NONE | |
tree |
A type of list that may contain sub-level nested groups that can be collapsed and expanded. | NONE | |
treegrid |
A grid whose rows can be expanded and collapsed in the same manner as for a tree. | NONE | |
treeitem |
An option item of a tree. This is an element within a tree that may be expanded or collapsed if it contains a sub-level group of treeitems. | NONE |
Definitions of States and Properties (all aria-* attributes)
Below is an alphabetical list of ARIA states and properties to be used by rich internet application authors. A detailed definition of each ARIA state and property can be found by following the attribute links (to their definitions in Accessible Rich Internet Applications (WAI-ARIA) 1.0.
aria-activedescendant- Identifies the currently active descendant of a composite widget.
aria-atomic- Indicates whether assistive technologies will present all, or only parts of, the changed region based on the change notifications defined by the aria-relevant attribute. See related aria-relevant.
aria-autocomplete- Indicates whether user input completion suggestions are provided.
aria-busy (state)- Indicates whether an element, and its subtree, are currently being updated.
aria-checked (state)- Indicates the current "checked" state of checkboxes, radio buttons, and other widgets. See related aria-pressed and aria-selected.
aria-controls- Identifies the element (or elements) whose contents or presence are controlled by the current element. See related aria-owns.
aria-describedby- Identifies the element (or elements) that describes the object. See related aria-labelledby.
aria-disabled (state)- Indicates that the element is perceivable but disabled, so it is not editable or otherwise operable. See related aria-hidden and aria-readonly.
aria-dropeffect- Indicates what functions can be performed when the dragged object is released on the drop target. This allows assistive technologies to convey the possible drag options available to users, including whether a pop-up menu of choices is provided by the application. Typically, drop effect functions can only be provided once an object has been grabbed for a drag operation as the drop effect functions available are dependent on the object being dragged.
aria-expanded (state)- Indicates whether the element, or another grouping element it controls, is currently expanded or collapsed.
aria-flowto- Identifies the next element (or elements) in an alternate reading order of content which, at the user's discretion, allows assistive technology to override the general default of reading in document source order.
aria-grabbed (state)- Indicates an element's "grabbed" state in a drag-and-drop operation.
aria-haspopup- Indicates that the element has a popup context menu or sub-level menu.
aria-hidden (state)- Indicates that the element and all of its descendants are not visible or perceivable to any user as implemented by the author. See related aria-disabled.
aria-invalid (state)- Indicates the entered value does not conform to the format expected by the application.
aria-label- Defines a string value that labels the current element. See related aria-labelledby.
aria-labelledby- Identifies the element (or elements) that labels the current element. See related aria-label and aria-describedby.
aria-level- Defines the hierarchical level of an element within a structure.
aria-live- Indicates that an element will be updated, and describes the types of updates the user agents, assistive technologies, and user can expect from the live region.
aria-multiline- Indicates whether a text box accepts multiple lines of input or only a single line.
aria-multiselectable- Indicates that the user may select more than one item from the current selectable descendants.
aria-orientation- Indicates whether the element and orientation is horizontal or vertical.
aria-owns- Identifies an element (or elements) in order to define a visual, functional, or contextual parent/child relationship between DOM elements where the DOM hierarchy cannot be used to represent the relationship. See related aria-controls.
aria-posinset- Defines an element's number or position in the current set of listitems or treeitems. Not required if all elements in the set are present in the DOM. See related aria-setsize.
aria-pressed (state)- Indicates the current "pressed" state of toggle buttons. See related aria-checked and aria-selected.
aria-readonly- Indicates that the element is not editable, but is otherwise operable. See related aria-disabled.
aria-relevant- Indicates what user agent change notifications (additions, removals, etc.) assistive technologies will receive within a live region. See related aria-atomic.
aria-required- Indicates that user input is required on the element before a form may be submitted.
aria-selected (state)- Indicates the current "selected" state of various widgets. See related aria-checked and aria-pressed.
aria-setsize- Defines the number of items in the current set of listitems or treeitems. Not required if all elements in the set are present in the DOM. See related aria-posinset.
aria-sort- Indicates if items in a table or grid are sorted in ascending or descending order.
aria-valuemax- Defines the maximum allowed value for a range widget.
aria-valuemin- Defines the minimum allowed value for a range widget.
aria-valuenow- Defines the current value for a range widget. See related aria-valuetext.
aria-valuetext- Defines the human readable text alternative of aria-valuenow for a range widget.
Abstract roles
Do not use the following abstract roles as they do not do anything!
Abstract roles are used for the ontology. Authors MUST NOT not use abstract roles in content.