Author testable requirements for Roles in ARIA 1.0

Draft 1.0
Author: Lisa Seeman

This Document contains requirements for roles for WAI-ARIA (see http://www.w3.org/TR/2011/CR-wai-aria-20110118/roles) for authors. It does not address user agents requirements.

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.

See http://www.w3.org/TR/2011/CR-wai-aria-20110118/usage#managingfocus
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:
  • Zebra
  • Zoom
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:
6 4 = 1.5
TeX 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. - - - -
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. - - -

A visible text caption labeling the 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. - - - -

Copyright © 2014 Athena ICT