An option in a set of choices contained by a menu or menubar.

The items or options available in the menu are the menu items. Menuitem role is specified for these items.

Authors may disable a menu item with the aria-disabled attribute. 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.

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. Authors may separate menu items into sets by use of a separator or an element with an equivalent role from the native markup language.

A menuitem with a checkable state whose possible values are true, false, or mixed.

The aria-checked attribute of a menuitemcheckbox indicates whether the menu item is checked (true), unchecked (false), or represents a sub-level menu of other menu items that have a mixture of checked and unchecked values (mixed).

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. Authors may separate menu items into sets by use of a separator or an element with an equivalent role from the native markup language.

A checkable menuitem in a set of elements with role menuitemradio, only one of which can be checked at a time.

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).

Authors must ensure that menu item radios are owned by an element with role group, menu, or menubar in order to identify that they are related widgets. Authors may separate menu items into sets by use of a separator or an element with an equivalent role from the native markup language.

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.

A collection of navigational elements (usually links) for navigating the document or related documents.

Navigation role is a landmark role. The navigation (role) is assigned to the portion of the page which provides the navigational elements. A navigation role is similar to the < nav> tag of HTML 5.

Sometimes websites may have more than one navigational panels. In such scenarios, we can have navigation roles for both panels and differentiate them with aria-label property.

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

Syntax

<div aria-label="primary" role="navigation">
Navigation panel goes here
</div>

A section whose content is parenthetic or ancillary to the main content of the resource.

A selectable item in a select list.

An option (role) is assigned to the items in a list which are selectable. 

Authors must ensure elements with role option are contained in, or owned by, an element with the role listbox. Options not associated with a listbox might not be correctly mapped to an accessibility API.

An element whose implicit native role semantics will not be mapped to the accessibility API.

The intended use is when an element is used to change the look of the page but does not have all the functional, interactive, or structural relevance implied by the element type, or may be used to provide for an accessible fallback in older browsers that do not support aria.

Example use cases:

• An element whose content is completely presentational (like a spacer image, decorative graphic, or clearing element);
• An image that is in a container with the img role and where the full text alternative is available and is marked up with aria-labelledby and (if needed) aria-describedby;
• An element used as an additional markup "hook" for CSS; or
• A layout table and/or any of its associated rows, cells, etc.

For any element with a role of presentation and which is not focusable, the user agent must not expose the implicit native semantics of the element (the role and its states and properties) to accessibility APIs. However, the user agent must expose content and descendant elements that do not have an explicit or inherited role of presentation. Thus, the presentation role causes a given element to be treated as having no role or to be removed from the accessibility tree, but does not cause the content contained within the element to be removed from the accessibility tree.

For example, according to an accessibility API, the following markup elements would appear to have identical role semantics (no role) and identical content.

<!-- 1. [role="presentation"] negates the implicit 'heading' role semantics but does not affect the contents. -->
<h1 role="presentation"> Sample Content </h1>

<!-- 2. There is no implicit role for span, so only the contents are exposed. -->
<span> Sample Content </span>

<!-- 3. This role declaration is redundant. -->
<span role="presentation"> Sample Content </span>

<!-- 4. In all cases, the element contents are exposed to accessibility APIs without any implied role semantics. -->
<!-- <> --> Sample Content <!-- </> -->

The presentation role is used on an element that has implicit native semantics, meaning that there is a default accessibility API role for the element. Some elements are only complete when additional descendant elements are provided. For example, in HTML, table elements (matching the grid role) require tr descendants (the row role), which in turn require th or td children (the gridcell, columnheader, rowheader roles). Similarly, lists require list item children. The descendant elements that complete the semantics of an element are described in aria as required owned elements.

When an explicit or inherited role of presentation is applied to an element with the implicit semantic of an aria role that has required owned elements, in addition to the element with the explicit role of presentation, the user agent must apply an inherited role of presentation to any owned elements that do not have an explicit role defined.

Also, when an explicit or inherited role of presentation is applied to a host language element which has required children as defined by the host language specification, in addition to the element with the explicit role of presentation, the user agent must apply an inherited role of presentation to any required children that do not have an explicit role defined.

For any element with an explicit or inherited role of presentation and which is not focusable, user agents must ignore role-specific aria states and properties for that element. For example, in HTML, a ul or ol element with a role of presentation will have the implicit native semantics of its li elements removed because the list role to which the ul or ol corresponds has a required owned element of listitem. Likewise, although an HTML table element does not have an implicit native semantic role corresponding directly to an aria role, the implicit native semantics of its thead/tbody/tfoot/tr/th/td descendants will also be removed, because the HTML specification indicates that these are required structural descendants of the tableelement. Explicit roles on a descendant or owned element override the inherited role of presentation, and cause the owned element to behave as any other element with an explicit role. If the action of exposing the implicit role causes the accessibility tree to be malformed, the expected results are undefined and the user agent may resort to an internal recovery mechanism to repair the accessibility tree.

Note: Only the implicit native semantics of elements that correspond to aria required owned elements are removed. All other content remains intact, including nested tables or lists, unless those elements also have a explicit role of presentation applied.

Note: There are other aria roles with required children for which this situation is applicable (e.g., radiogroups and listboxes), but tables and lists are the most common real-world cases in which the presentation inheritance is likely to apply.

For any element with an explicit or inherited role of presentation, user agents must apply an inherited role of presentation to all host-language-specific labeling elements for the presentational element. For example, a table element with a role of presentation will have the implicit native semantics of its caption element removed, because the caption is merely a label for the presentational table.

For any element with an explicit or inherited role of presentation, user agents must ignore any non-global, role-specific aria states and properties. However, the user agent must always expose global aria states and properties to accessibility APIs, even if an element has an explicit or inherited role of presentation.

For example, aria-hidden is a global attribute and would always be applied; aria-level is not a global attribute and would therefore only apply if the element was not in a presentational state.

<!-- 1. [role="presentation"] negates the implicit 'heading' role semantics but does not affect the global hidden state. -->
<h1 role="presentation" aria-hidden="true"> Sample Content </h1>

<!-- 1. [role="presentation"] negates the both the implicit 'heading' and the non-global level. -->
<h1 role="presentation" aria-level="2"> Sample Content </h1>

If an element with a role of presentation is focusable, user agents must ignore the normal effect of the role and expose the element with implicit native semantics, in order to ensure that the element is both understandable and operable. Authors should not provide meaningful alternative text (for example, use alt="" in HTML4) when the presentation role is applied to an image.

In the following code sample, the containing div element has an aria role of img and is appropriately labeled by the caption paragraph. In this example, the img element can be marked as presentation because the role and the text alternatives are provided by the containing element.

<div role="img" aria-labelledby="caption">
  <img src="/example.png" role="presentation" alt="">
  <p id="caption">A visible text caption labeling the image.</p>
</div>

In the following code sample, because the anchor (HTML a element) is acting as the treeitem, the list item (HTML li element) is assigned an explicit aria role of presentation to override the user agent's implicit native semantics for list items.

<ul role="tree">
  <li role="presentation">
    <a role="treeitem" aria-expanded="true">An expanded tree node</a> 
  </li> 
  … 
</ul>

An element that displays the progress status for tasks that take a long time.

A progressbar (role) is assigned to the portion of the page that displays the status of a lengthy task. A progress bar indicates that the user's request is received and is in the process of executing the task. Content authors should provide values of aria-valumin, aria-valuemax and aria-valuenow where the aria-valuemax is known. All these values should be updated when the visual content gets updated. The user should be provided with the current status using aria-valuenow. 

Eg: When a file of 100 mb is downloaded, a progressbar indicates aria-valuemin as 0, aria-valuemax as 100 and aria-valuenow with the current status of the download.

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. 

Note: Assistive technologies generally will render the value of aria-valuenow as a percent of the range between the value of aria-valuemin and aria-valuemax, unlessaria-valuetext is specified. It is best to set the values for aria-valuemin, aria-valuemax, and aria-valuenow in a manner that is appropriate for this calculation.

Microsoft Active Accessibility accRole Property: 

A checkable input in a group of radio roles, only one of which can be checked at a time.

A radio (role) is used for a checkable element when a group of elements are available and only one among them can be checked at a time. All the similar radio elements can be grouped and assigned with radiogroup role. A radio role is owned by radiogroup role.

Usually a radio role is assigned when elements contain few checkable options. Options such as yes or no, male or female, morning, noon, evening or night etc can be assigned with radio role. If the options are more such as states of a country a combobox role should be assigned.

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 radiogroupelement to indicate the relationship to its children.

A group of radio buttons.

A radiogroup (role) is assigned to the container that holds a similar type of radio buttons. Only one radio button in the group can be checked at a time.

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 (aria-checked="true"), the previously checked item becomes unchecked (aria-checked="false").