A collection of commonly used function buttons or controls represented in compact visual form.

The toolbar is often a subset of functions found in a menubar, designed to reduce user effort in using these functions. Authors must supply an aria-label property on each toolbar when the application contains more than one toolbar.

Authors may manage focus of descendants for all instances of this role.

A contextual popup that displays a description for an element.

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. The use of an aria tooltip is a supplement to the normal tooltip behavior of the user agent.

Authors should ensure that elements with the role tooltip are referenced through the use of aria-describedby by the time the tooltip is displayed.

Note: Typical tooltip delays last from one to five seconds.

A type of list that may contain sub-level nested groups that can be collapsed and expanded.

A tree role is assigned to the list that has the capability to expand and collapse. A tree element will have sub elements called tree items. The treeitem can be marked with treeitem role.

To be keyboard accessible, authors should manage focus of descendants for all instances of this role.

A grid whose rows can be expanded and collapsed in the same manner as for a tree.

A treegrid role is similar to a tree role element but a treegrid is by default an editable element. To make a treegrid read-only, set the aria-readonly attribute of the treegrid to true. The value of the treegrid element's aria-readonly attribute is implicitly propagated to all of its owned gridcell elements, and will be exposed through the accessibility API. An author may override an individual gridcell element's propagated aria-readonly value by setting the aria-readonly attribute on the gridcell.

To be keyboard accessible, authors should manage focus of descendants for all instances of this role.

An option item of a tree. 

A treeitem role is assigned to the element which is an option within the tree role element. A treeitem can have sub elements within a treeitem. A treeitem which has sub items will have a capability to expand and collapse. A collection of treeitems that have expand/collapse capability should be grouped together using the group role.

Authors must ensure elements with role treeitem are contained in, or owned by, an element with the role group or tree.

An interactive component of a graphical user interface (GUI).

Widgets are discrete user interface objects with which the user can interact. Widget roles map to standard features in accessibility APIs. When the user navigates an element assigned any of the non-abstract subclass roles of widget, assistive technologies that typically intercept standard keyboard events should switch to an application browsing mode, and pass keyboard events through to the web application. The intent is to hint to certain assistive technologies to switch from normal browsing mode into a mode more appropriate for interacting with a web application; some user agents have a browse navigation mode where keys, such as up and down arrows, are used to browse the document, and this native behavior prevents the use of these keys by a web application.

Note: widget is an abstract role used for the ontology. Authors are instructed not to use this role in content.

A browser or application window.

Elements with this role have a window-like behavior in a graphical user interface (GUI) context, regardless of whether they are implemented as a native window in the operating system, or merely as a section of the document styled to look like a window.

Note: window is an abstract role used for the ontology. Authors are instructed not to use this role in content.

A region declared as a web application, as opposed to a web document.

The application role is a landmark role. When the web page contains any non-browsing elements such as flash, video etc, role="application" is marked to the region where the non-browsing content is available.  This application role informs the users of assistive technologies to convert from browse mode to a more appropriate mode that can best interact with the application content.

When the user navigates an element assigned the role of application, assistive technologies that typically intercept standard keyboard events should switch to an application browsing mode, and pass keyboard events through to the web application. The intent is to hint to certain assistive technologies to switch from normal browsing mode into a mode more appropriate for interacting with a web application; some user agents have a browse navigation mode where keys, such as up and down arrows, are used to browse the document, and this native behavior prevents the use of these keys by a web 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.

For example, an email application has a document and an application in it. The author would want to use typical application navigation mode to cycle through the list of emails, and much of this navigation would be defined by the application author. However, when reading an email message the content will appear in a region with a document role in order to use browsing navigation.

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.

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.

User agents should treat elements with the role of application as navigational landmarks.

Authors may use the application role on the primary content element of the host language (such as the body element in HTML) to define an entire page as an application. However, if the primary content element is defined as having a role of application, user agents must not use the element as a navigational landmark. If assistive technologies use an interaction mode that intercepts standard keyboard events, when encountering the application role, those assistive technologies should switch to an interaction mode that passes keyboard events through to the web application.

Note: Where appropriate, assistive technologies that typically intercept other standard device input events, such as touch screen input, could switch to an application browsing mode that passes some or all of those events through to the web application.

Syntax

<div role=”application”> Any content / functionality of the application area.</div>

A type of dialog that contains an alert message, where initial focus goes to an element within the dialog.

An alertdialog role is also used to alert the user with a message. Unlike the alert role, the user can interact with the message. The initial focus goes to an element in the alert and user can navigate within the alert dialog box using keyboard and mouse. Developers should take care that the keyboard and mouse interactions are within the alert dialog when it is opened. Provide the alert message to the user with aria-describedby property to ensure that the message is conveyed to the screen reader user.

For example, when you delete a file or folder from the recycle bin in the windows operating system an alert is displayed asking the user "Are you sure you want to permanently delete this item?" Providing the focus on "Yes" button. When you access the same dialog box using the JAWS or NVDA screen reader it will read the file name, file type etc but it will not read the message "Are you sure you want to permanently delete this item?" Using aria-describedby property will help in overcoming such problems.

The alertdialog role goes on the node containing both the alert message and the rest of the dialog. Content authors should make alert dialogs modal by ensuring that, while the alertdialog is shown, keyboard and mouse interactions only operate within the dialog.

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.

Authors should use aria-describedby on an alertdialog to point to the alert message element in the dialog. If they do not, assistive technologies will resort to their internal recovery mechanism to determine the contents of an alert message.

A message with important, and usually time-sensitive, information.

An alert role is a simple way of providing a message to the user. The alert role is used when the user interaction is not required but the message should be conveyed.  Alerts are specialized forms of the status role, which will be processed as an atomic live region.

For example, in a chat application, information of people coming online and going offline should be intimated to the user. This will be a simple yet important message which do not require any user interaction. In some chat applications, only an audio intimation will be provided when a buddy comes online or goes away. It do not provide any information on who has come online and who has gone away. In such cases, an alert message can be an alternate for sound intimation.

Role="alert" should be provided in the node containing the alert message. Focus is not required to be set for these kinds of alert messages.

Alerts are assertive live regions and will be processed as such by assistive technologies. 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 alert is created. If an alert requires focus to close the alert, then content authors should use alertdialog instead.

Note: Elements with the role alert have an implicit aria-live value of assertive, and an implicit aria-atomic value of true.