Draft 1.0
Author: Lisa Seeman
Roles are element types and authors MUST NOT change role values over time or with user actions. Authors wishing to change a role MUST do so by deleting the associated element and its children and replacing it with a new element with the appropriate role.
When multiple roles are specified as required owned elements for a role or required context, at least one instance of one required owned element is expected.
Role | Should/Must | Required state | Required context | Must own or contain | Testable Statement |
---|---|---|---|---|---|
alert | Alerts are assertive live regions and will be processed as such by assistive technologies. Neither authors nor user agents are required to set or manage focus to them in order for them to be processed. Since alerts are not required to receive focus, content authors SHOULD NOT require users to close an alert. If the operating system allows, the user agent SHOULD fire a system alert event through the accessibility API when the WAI-ARIA alert is created. If an alert requires focus to close the alert, then content authors SHOULD use alertdialog instead. | - | - | - | - |
alertdialog | Content authors SHOULD make alert dialogs modal by ensuring that, while the alertdialog is shown, keyboard and mouse interactions only operate within the dialog. | - | - | - | - |
alertdialog | Unlike alert, alertdialog can receive a response from the user. For example, to confirm that the user understands the alert being generated. When the alert dialog is displayed, authors SHOULD set focus to an active element within the alert dialog, such as a form edit field or an OK button. ( The user agent SHOULD fire a system alert event through the accessibility API when the alert is created, provided one is specified by the intended accessibility API.) | - | - | - | - |
application | Authors SHOULD set the role of application on the element that encompasses the entire application. If the application role applies to the entire web page, authors SHOULD set the role of application on the root node for content, such as the body element in HTML or svg element in SVG | - | - | - | - |
application | For all instances of non-decorative static text or image content inside an application, authors SHOULD either associate the text with a form widget or group (via aria-label, aria-labelledby, or aria-describedby) or separate the text into an element with role of document or article. | - | - | - | - |
application | Authors SHOULD provide a title or label for applications. Authors SHOULD use label text that is suitable for use as a navigation preview or table-of-contents entry for the page section. Content authors SHOULD provide the label through one of the following methods: If the application includes the entire contents of the web page, use the host language feature for title or label, such as the title element in both HTML and SVG. This has the effect of labeling the entire application. Otherwise, provide a visible label referenced by the application using aria-labelledby. | - | - | - | - |
artical | - | - | - | - | - |
banner | Within any document or application, the author SHOULD mark no more than one element with the banner role. | - | - | - | - |
button | - | - | - | - | - |
checkbox | - | aria-checked | - | - | - |
columnheader | - | - | row | - | - |
combobox | authors SHOULD set aria-autocomplete attribute on the textfield. | - | - | - | - |
combobox | If an author sets a combobox's value of aria-autocomplete to 'none' (default), authors MUST manage and set focus on the associated listbox, so assistive technologies can follow the currently selected value. | - | - | - | - |
combobox | If an author sets a combobox's value of aria-autocomplete to 'inline' or 'both', authors MUST update the value of the focused textfield, so assistive technologies can announce the currently selected value | - | - | - | - |
combobox | If an author sets a combobox's value of aria-autocomplete to 'list', user agents or assistive technologies MUST follow the aria-activedescendant of the combobox, and authors SHOULD associate the combobox textfield with its listbox using aria-owns. | - | - | - | Success:
|
combobox | To be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus. | - | - | - | - |
combobox | - | aria-expanded (state) | - | - | - |
combobox | - | - | - | listbox | - |
combobox | - | - | - | textbox | - |
command | - | - | - | - | |
complementary | - | - | - | - | |
composite | Authors SHOULD ensure that a composite widget exist as a single navigation stop within the larger navigation system of the web page. | - | - | - | - |
composite | Once the composite widget has focus, authors SHOULD provide a separate navigation mechanism for users to navigate to elements that are descendants or owned children of the composite element. | - | - | - | - |
contentinfo | Within any document or application, the author SHOULD mark no more than one element with the contentinfo role. | - | - | - | - |
definition | If a host language has an appropriate element for the term (e.g. dfn or dt in HTML), authors SHOULD include the term in that element. | - | - | - | - |
definition | Authors SHOULD identify the definition term by using an aria-labelledby attribute on each element with a role of definition. | - | - | - | - |
dialog | Authors SHOULD provide a dialog label. Labels may be provided with the aria-label or aria-labelledby attribute if other mechanisms are not available. | - | - | - | - |
dialog | Authors SHOULD ensure each active dialog has a focused descendant element that has keyboard focus. | - | - | - | - |
directory | Authors SHOULD use this role for a static table of contents, whether linked or unlinked. This includes tables of contents built with lists, including nested lists. Dynamic tables of contents, however, might use a tree role instead. | - | - | - | - |
document | Authors SHOULD set the role of document on the element that encompasses the entire document. | - | - | - | - |
document | If the document role applies to the entire web page, authors SHOULD set the role of document on the root node for content, such as the body element in HTML or svg element in SVG. | - | - | - | - |
document | Content authors SHOULD provide the label through one of the following methods: If the document includes the entire contents of the web page, use the host language feature for title or label, such as the title element in both HTML and SVG. This has the effect of labeling the entire document. Otherwise, provide a visible label referenced by the document using aria-labelledby. | - | - | - | - |
document | Authors SHOULD use label text that suitable for use as a navigation preview or table-of-contents entry for the page section. | - | - | - | - |
form | For search facilities, authors SHOULD use the search role and not the generic form role. | - | - | - | - |
form | Authors SHOULD provide a visible label for the form referenced with aria-labelledby. | - | - | - | - |
form | If an author uses a script to submit a form based on a user action that would otherwise not trigger an onsubmit event (for example, a form submission triggered by the user changing a form element's value), the author SHOULD provide the user with advance notification of the behavior. | - | - | - | - |
grid | Authors MUST ensure that elements with role gridcell are owned by elements with role row, which in turn are owned by an element with role rowgroup, grid or treegrid. | - | - | row rowgroup -> row |
- |
grid | To be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, | - | - | - | - |
gridcell | Authors MUST ensure elements with role gridcell are contained in, or owned by, an element with the role row. Characteristics of gridcell | - | row | - | - |
gridcell | If headers cannot be determined from the DOM structure, authors SHOULD explicitly indicate which header cells are relevant to the cell by referencing elements with role rowheader or columnheader using the aria-describedby attribute. | - | - | - | - |
group | Authors SHOULD use a group to form logical collection of items in a widget such as children in a tree widget forming a collection of siblings in a hierarchy, or a collection of items having the same container in a directory. | - | - | - | - |
group | When a group is used in the context of list, authors MUST limit its children to listitem elements. | - | - | - | - |
heading | - | - | - | - | |
img | - | - | - | - | |
input | - | - | - | - | |
link | - | - | - | - | |
list | - | - | - | group -> listitem listitem |
- |
listbox | To be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus. See http://www.w3.org/TR/2011/CR-wai-aria-20110118/usage#managingfocus. | - | - | - | - |
listbox | - | - | - | option | - |
listitem | Authors MUST ensure elements with role listitem are contained in, or owned by, an element with the role list. | - | list | - | - |
log | - | - | - | - | |
main | Within any document or application, the author SHOULD mark no more than one element with the main role. | - | - | - | - |
marquee | - | - | - | - | |
math | For purposes of repair, if an image has been used to represent a mathematical expression, the text equivalent defined for that image SHOULD be valid MathML or TeX. Such images SHOULD also be labeled by text that describes the mathematical expression as it might be spoken, using the aria-describedby attribute. | - | - | - | Math ml example:
\frac{6}{4}=1.5
|
Menu | To be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus. See http://www.w3.org/TR/2011/CR-wai-aria-20110118/usage#managingfocus | - | - | - | - |
Menu | - | - | - | group -> menuitemradio menuitem menuitemcheckbox menuitemradio | - |
Menubar | Authors SHOULD ensure that menubar interaction is similar to the typical menu bar interaction in a desktop graphical user interface. To be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus. | See http://www.w3.org/TR/2011/CR-wai-aria-20110118/usage#managingfocus- | - | - | - |
menuitem | If the menu item has its aria-haspopup attribute set to true, it indicates that the menu item may be used to launch a sub-level menu, and authors SHOULD display a new sub-level menu when the menu item is activated. | - | - | - | - |
menuitem | Authors MUST ensure that menu items are owned by an element with role menu or menubar in order to identify that they are related widgets | - | menu or menubar | - | - |
menuitemcheckbox | Authors MUST ensure that menu item checkboxes are owned by an element with role menu or menubar in order to identify that they are related widgets. | - | menu or menubar | - | - |
menuitemradio | Authors MUST ensure that menu item radios are owned by an element with role menu or menubar in order to identify that they are related widgets. | - | menu or menubar | - | - |
menuitemradio | Authors SHOULD enforce that only one menuitemradio in a group can be checked at the same time. When one item in the group is checked, the previously checked item becomes unchecked (its aria-checked attribute becomes false). | - | - | - | - |
menuitem | If a menu or menubar contains more than one group of menuitemradio elements, or if the menu contains one group and other, unrelated menu items, authors SHOULD nest each set of related menuitemradio elements in an element using the group role, and authors SHOULD delimit the group from other menu items with an element using the separator role. | - | - | - | - |
navigation | - | - | - | - | |
note | - | - | - | - | |
option | Authors MUST ensure elements with role option are contained in, or owned by, an element with the role listbox. | - | listbox | - | - |
presentation | Authors SHOULD NOT provide meaningful alternative text (for example, use alt="" in HTML4) when the presentation role is applied to an image. | - | - | - | |
progressbar | The author SHOULD supply values for aria-valuenow, aria-valuemin, and aria-valuemax, unless the value is indeterminate, in which case the author SHOULD omit the aria-valuenow attribute. | - | - | - | - |
progressbar | Authors SHOULD update these values when the visual progress indicator is updated. | - | - | - | - |
progressbar | If the progressbar is describing the loading progress of a particular region of a page, the author SHOULD use aria-describedby to point to the status, and set the aria-busy attribute to true on the region until it is finished loading. It is not possible for the user to alter the value of a progressbar because it is always readonly. | - | - | - | - |
Radio | Authors SHOULD ensure that elements with role radio are explicitly grouped in order to indicate which ones affect the same value. This is achieved by enclosing the radio elements in an element with role radiogroup. If it is not possible to make the radio buttons DOM children of the radiogroup, authors SHOULD use the aria-owns attribute on the radiogroup element to indicate the relationship to its children. | - | - | - | - |
radiogroup | - | - | - | radio | - |
radiogroup | Authors SHOULD enforce that only one radio button in a group can be checked at the same time. When one item in the group is checked, the previously checked item becomes unchecked (its aria-checked attribute becomes false). | - | - | - | - |
range | - | - | - | - | |
region | Authors SHOULD ensure that a region has a heading referenced by aria-labelledby. This heading is provided by an instance of the standard host language heading element or an instance of an element with role heading that contains the heading text. | - | - | - | - |
roletype | Note: widget is an abstract role used for the ontology. Authors are instructed not to use this role in content. | - | - | - | - |
row | Authors MUST ensure elements with role row are contained in, or owned by, an element with the role grid, rowgroup, treegrid. | - | grid, or rowgroup, or treegrid | columnheader gridcell rowheader | - |
rowgroup | Authors MUST ensure elements with role rowgroup are contained in, or owned by, an element with the role grid. | - | grid | - | - |
rowgroup | - | - | - | row | - |
rowheader | Authors MUST ensure elements with role rowheader are contained in, or owned by, an element with the role row. | - | row | - | - |
search | User agents SHOULD treat elements with the role of search as navigational landmarks. | - | - | - | - |
section | Note: Section is an abstract role used for the ontology. Authors are instructed not to use this role in content. | - | - | - | |
sectionhead | Note: This is an abstract role used for the ontology. Authors are instructed not to use this role in content. | - | - | - | |
select | Note: select is an abstract role used for the ontology. Authors are instructed not to use this role in content. | - | combobox, listbox, menu, radiogroup, or tree or other sibling | - | - |
select | Authors MUST ensure elements with role option are contained in an element using one of the non-abstract child roles of select, such as combobox, listbox, menu, radiogroup, or tree. | - | combobox, listbox, menu, radiogroup, or tree or other sibling | - | - |
separator | - | - | - | - | |
scrollbar | Authors MUST set the aria-controls attribute on the scrollbar element to reference the scrollable area it controls. | - | - | - | - |
slider | - | - | - | - | |
spinbutton | Authors SHOULD ensure this functionality is accomplished programmatically through the use of up and down arrows on the keyboard. | - | - | - | - |
spinbutton | - | aria-valuemax | - | - | - |
spinbutton | - | aria-valuemin | - | - | - |
spinbutton | - | aria-valuenow | - | - | - |
status | Authors MUST provide status information content within a status object. | - | - | - | - |
status | Authors SHOULD ensure this object does not receive focus | - | - | - | - |
status | Status is a form of live region. If another part of the page controls what appears in the status, authors SHOULD make the relationship explicit with the aria-controls attribute. | - | - | - | - |
structure | Note: structure is an abstract role used for the ontology. Authors are instructed not to use this role in content. | - | - | - | - |
tab | Authors MUST ensure elements with role tab are contained in, or owned by, an element with the role tablist. | - | - | - | - |
tab | Authors SHOULD ensure the tabpanel associated with the currently active tab is perceivable to the user: | - | - | - | - |
tab | For a single-selectable tablist, authors SHOULD hide other tabpanel elements from the user until the user selects the tab associated with that tabpanel. | - | - | - | - |
tab | For a multi-selectable tablist, authors SHOULD ensure each visible tabpanel have its aria-expanded (state) attribute set to true, and that the remaining hidden tabpanel elements have their aria-expanded attributes are set to false. | - | - | - | - |
tab | In either case, authors SHOULD ensure that the currently active tab has its aria-selected attribute set to true, that other tab elements have their aria-selected attribute set to false, and that the currently selected tab provides a visual indication that it is selected | - | - | - | - |
tab | - | - | tablist | - | - |
tablist | To be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus. See http://www.w3.org/TR/2011/CR-wai-aria-20110118/usage#managingfocus | - | - | - | - |
tablist | - | - | - | tab | - |
tabpanel | Authors SHOULD associate a tabpanel element with its tab, either by using the aria-controls attribute on the tab to reference the tab panel, or by using the aria-labelledby attribute on the tab panel to reference the tab. | - | - | - | - |
textbox | - | - | - | - | - |
timer | The timer value is not necessarily machine parsable, but authors SHOULD update the text contents at fixed intervals, except when the timer is paused or reaches an end-point. | - | - | - | - |
toolbar | Authors MUST supply an aria-label property on each toolbar when the application contains more than one toolbar. | - | - | - | - |
tooltip | Authors SHOULD ensure that elements with the role tooltip are referenced through the use of aria-describedby by the time the tooltip is displayed. | - | - | - | - |
tooltip | The tooltip typically becomes visible in response to a mouse hover, or after the owning element receives keyboard focus. In each of these cases, authors SHOULD display the tooltip after a short delay. | - | - | - | - |
tree | To be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus. See http://www.w3.org/TR/2011/CR-wai-aria-20110118/usage#managingfocus | - | - | - | - |
tree | - | - | - | group -> treeitem treeitem |
- |
treegrid | To be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus. See http://www.w3.org/TR/2011/CR-wai-aria-20110118/usage#managingfocus | - | - | - | - |
treegrid | - | - | - | row | - |
treeitem | Authors MUST ensure elements with role treeitem are contained in, or owned by, an element with the role group or tree. | - | group tree |
- | - |
widget | Note: widget is an abstract role used for the ontology. Authors are instructed not to use this role in content. | - | - | - | - |
window | Note: widget is an abstract role used for the ontology. Authors are instructed not to use this role in content. | - | - | - | - |