Accessible Rich Internet Applications (WAI-ARIA) 1.0

A message with important, and usually time-sensitive, information. Also see alertdialog and status.

Alerts are used to convey messages to alert the user. In the case of audio warnings this is an accessible alternative for a hearing-impaired user. The alert role goes on the node containing the alert message. Alerts are specialized forms of the status role, which will be processed as an atomic live region.

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

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

A type of dialog that contains an alert message, where initial focus goes to the dialog or an element within it. Also see alert and dialog.

Alert dialogs are used to convey messages to alert the user. 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.

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

Note: Elements with the role alertdialog have an implicit aria-live value of assertive.

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

When a user navigates an element assigned the role of application, assistive technology that typically intercepts standards 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 technology 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 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 main content element of the host language (such as the body element in HTML) to define entire page as an application. However, if the main content element is defined as having a role of application, user agents MUST NOT use the element as a navigational landmark. If assistive technology uses an interaction mode that intercepts standard keyboard events, when encountering the application role, assistive technology SHOULD switch to an interaction mode that passes keyboard events through to the web application.

A section of a page that consists of a composition that forms an independent part of a document, page, or site.

An article is not a navigational landmark, but may be nested to form a discussions where an assistive technology could pay attention to article nesting to assist the user in following the discussion. An article could be a forum post, a magazine or newspaper article, a web log entry, a user-submitted comment, or any other independent item of content. It is independent in that its contents could stand alone, for example in syndication. However, the element is still associated with its ancestors; for instance, contact information that applies to a parent body element still covers the article as well. When nesting articles, the child articles represent content that is related to the content of the parent article. For instance, a web log entry on a site that accepts user-submitted comments could represent the comments as articles nested within the article for the web log entry. Author, heading, date, or other information associated with an article does not apply to nested articles.

When a user navigates an element assigned the role of article, assistive technology that typically intercepts standards keyboard events SHOULD switch to document browsing mode, as opposed to passing keyboard events through to the web application. Assistive technologies MAY provide a feature allowing the user to navigate the hierarchy of any nested article elements.

A region that contains mostly site-oriented content, rather than page-specific content.

Site-oriented content typically includes things such as the logo or identity of the site sponsor, and site-specific search tool. A banner usually appears at the top of the page and typically spans the full width.

User agents SHOULD treat elements with the role of banner as navigational landmarks.

Within any document or application, the author SHOULD mark no more than one element with the banner role.

Note: Because document and application elements can be nested in the DOM, they may have multiple banner elements as DOM descendants, assuming each of those is associated with different document nodes, either by a DOM nesting (e.g., document within document) or by use of the aria-owns attribute.

An input that allows for user-triggered actions when clicked or pressed.

Buttons are mostly used for discrete, atomic actions. Standardizing the appearance of buttons enhances a user's recognition of the widgets as buttons and allows for a more compact display in toolbars.

Buttons support the optional attribute aria-pressed. Buttons with a non-empty aria-pressed attribute are toggle buttons. When aria-pressed is true the button is in a "pressed" state, when aria-pressed is false it is not pressed. If the attribute is not present, the button is a simple command button.

A checkable input that has three possible values: true, false, or mixed.

The aria-checked attribute of a checkbox indicates whether the input is checked (true), unchecked (false), or represents a group of elements that have a mixture of checked and unchecked values (mixed). Many checkboxes do not use the mixed value, and thus are effectively boolean checkboxes.

A cell containing header information for a column.

columnheader can be used as a column header in a table or grid. It could also be used in a pie chart to show a similar relationship in the data.

The columnheader establishes a relationship between it and all cells in the corresponding column. It is the structural equivalent to an HTML th element with a column scope.

Note: Because cells are organized into rows, there is not a single container element for the column. The column is the set of gridcell elements in a particular position within their respective row containers.

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. Also see listbox.

combobox is the combined presentation of a single line text box with a list box popup. The combobox may be editable. Typically editable combo boxes are used for autocomplete behavior, and the aria-autocomplete property may be used on the child textbox.

Note: In XForms [XFORMS] the same select can have one of 3 appearances: combo-box, drop-down box, or group of radio-buttons. Many browsers allow users to type ahead to existing choices in a drop-down select widget. This specification does not constrain the presentation of the combo box.

To be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus.

Note: Elements with the role combobox have an implicit aria-haspopup value of true.

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.

There are various types of content that would appropriately have this role. For example, in the case of a portal, this may include but not be limited to show times, current weather, related articles, or stocks to watch. The complementary role indicates that contained content is relevant to the main content. If the complementary content is completely separable main content, it may be appropriate to use a more general role.

User agents SHOULD treat elements with the role of complementary as navigational landmarks.

A widget that may contain navigable descendants or owned children.

Authors SHOULD ensure that a composite widget exist as a single navigation stop within the larger navigation system of the web page. 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.

Note: composite is an abstract role used for the ontology. Authors must not use this role in content.

A large perceivable region that contains information about the parent document.

Examples of information included in this region of the page are copyrights and links to privacy statements.

User agents SHOULD treat elements with the role of contentinfo as navigational landmarks.

Within any document or application, the author SHOULD mark no more than one element with the contentinfo role.

Note: Because document and application elements can be nested in the DOM, they may have multiple contentinfo elements as DOM descendants, assuming each of those is associated with different document nodes, either by a DOM nesting (e.g., document within document) or by use of the aria-owns attribute.

A definition of a term or concept.

The WAI-ARIA specification does not provide a role to specify the definition term, but host languages may provide such an element. 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. Authors SHOULD identify the definition term by using an aria-labelledby attribute on each element with a role of definition.

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. Also see alertdialog.

Authors SHOULD provide a dialog label. Labels may be provided with the aria-label or aria-labelledby attribute if other mechanisms are not available. Authors SHOULD ensure each active dialog has a focused descendant element that has keyboard focus.

A list of references to members of a group, such as a static table of contents.

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.

A region containing related information that is declared as document content, as opposed to a web application.

When a user navigates an element assigned the role of document, assistive technology that typically intercepts standards keyboard events SHOULD switch to document browsing mode, as opposed to passing keyboard events through to the web application. The document role informs user agents of the need to augment browser keyboard support in order to allow users to visit and read any content within the document region. In contrast, additional commands are not necessary for screen reader users to read text within an region with the application role, where if coded in an accessible manner, all text will be semantically associated with focusable elements. An important trait of documents is that they have text which is not associated with widgets or groups thereof.

Authors SHOULD set the role of document on the element that encompasses the entire 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.

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.

Authors SHOULD provide a title or label for documents. Authors SHOULD use label text that 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 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.

A region of the document that represents a collection of form-associated elements, some of which can represent editable values that can be submitted to a server for processing.

Authors SHOULD provide a visible label for the form referenced with aria-labelledby. 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.

User agents SHOULD treat elements with the role of form as navigational landmarks.

A grid contains cells of tabular data arranged in rows and columns, like a table.

Grids do not necessarily imply presentation. The grid construct describes relationships between data such that it may be used for different presentations. Grids allow the user to move focus between cells using two dimensional navigation. For example, grid might be used as the invisible data model (hidden with CSS but still operable by assistive technologies) for a presentational chart.

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. If the author applies any non-global WAI-ARIA states or properties to a native markup element that is acting as a row (such as the tr element in HTML), the author MUST also apply the role of row, as stated in @@Host-Language-Integration. Authors MAY make cells focusable. Authors MAY define grids that are empty, containing no rows or cells. Authors MAY provide row and column headers for grids, by using rowheader and columnheader roles.

Since WAI-ARIA can augment an element in the host language, grids can reuse existing functionality of native table grids. When WAI-ARIA grid or gridcell roles overlay host language table elements they reuse the host language semantics for that table. For instance, WAI-ARIA does not specify general attributes for gridcell elements that span multiple rows or columns. When the author needs a gridcell to span multiple rows or columns, use the host language markup, such as the colspan and rowspan attributes in HTML.

Authors MAY determine the contents of a gridcell through calculation of a mathematical formula. Authors MAY make a cell's formula editable by the user. In a spreadsheet application for example, the text alternative of a cell may be the calculated value of a formula. However, when the cell is being edited, the text alternative may be the formula itself.

gridcell elements with the aria-selected attribute set can be selected for user interaction, and if the aria-multiselectable attribute of the grid is set to true, multiple cells in the grid may be selected. Grids may be used for spreadsheets like those in desktop spreadsheet applications.

A grid is considered editable unless otherwise specified. To make a grid read-only, set the aria-readonly attribute of the grid to true. The value of the grid 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, as described in Managing Focus.

A cell in a grid or treegrid.

Cells may be active, editable, and selectable. Cells may have relationships such as aria-controls to address the application of functional relationships.

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.

In a treegrid, authors MAY define cells as expandable by using the aria-expanded attribute. If the aria-expanded attribute is provided, it applies only to the individual cell. It is not a proxy for the container row, which also can be expanded. The main use case for providing this attribute on a cell is pivot table behavior.

A set of user interface objects which are not intended be included in a page summary or table of contents by assistive technologies.

Contrast with region which is a grouping of user interface objects that will be included in a page summary or table of contents.

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. However, when a group is used in the context of list, authors MUST limit its children to listitem elements. Therefore, proper handling of group by authors and assistive technology is determined by the context in which it is provided.

Authors MAY nest group elements. If the author believes a section is significant enough to warrant inclusion in the web page's table of contents, the author SHOULD assign the section a role of region or a standard landmark role.

A heading for a section of the page.

Often, heading elements will be referenced with the aria-labelledby attribute of the section for which they serve as a heading. If headings are organized into a logical outline, the aria-level attribute may be used to indicate the nesting level.

A container for a collection of elements that form an image.

An img can contain captions and descriptive text, as well as multiple image files that when viewed together give the impression of a single image. An img represents a single graphic within a document, whether or not it is formed by a collection of drawing objects. In order for elements with a role of img be perceivable, authors SHOULD provide alternative text or a label determined by the accessible name calculation.

A generic type of widget that allows user input.

A region of the page intended as a navigational landmark.

Assistive technology SHOULD allow the user to quickly navigate to landmark regions. Mainstream user agents MAY allow the user to quickly navigate to landmark regions.

Note: landmark is an abstract role used for the ontology. Authors must not use this role in content.

An interactive reference to an internal or external resource that, when activated, causes the user agent to navigate to that resource.

If this is a native link in the host language (such as an HTML anchor with an href value), activating the link causes the user agent to navigate to that resource. If this is a simulated link, the web application author is responsible for managing navigation.

A group of non-interactive list items. Also see listbox.

Lists contain children whose role is listitem, or elements whose role is group which in turn contains children whose role is listitem.

A widget that allows the user to select one or more items from a list of choices. Also see combobox and list.

Items within the list are static and, unlike standard HTML select elements, may contain images. List boxes contain children whose role is option.

To be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus.

Although listbox inherits the aria-expanded attribute, if there is a valid reason to expand the listbox, the combobox role may be more appropriate.

A single item in a list or directory.

A type of live region where new information is added in meaningful order and old information may disappear. Also see marquee.

Examples include chat logs, messaging history, game log, or an error log. In contrast to other live regions, in this role there is a relationship between the arrival of new items in the log and the reading order. The log contains a meaningful sequence and new information is added only to the end of the log, not at arbitrary points.

Note: Elements with the role log have an implicit aria-live value of polite.

The main content of a document.

This marks the content that is directly related to or expands upon the central topic of the document. The main role is a non-obtrusive alternative for "skip to main content" links, where the navigation option to go to the main content (or other landmarks) is provided by the user agent through a dialog or by assistive technologies.

User agents SHOULD treat elements with the role of main as navigational landmarks.

Within any document or application, the author SHOULD mark no more than one element with the main role.

Note: Because document and application elements can be nested in the DOM, they may have multiple main elements as DOM descendants, assuming each of those is associated with different document nodes, either by a DOM nesting (e.g., document within document) or by use of the aria-owns attribute.

A type of live region where non-essential information changes frequently. Also see log.

Common usages of marquee include stock tickers and ad banners. The primary difference between a marquee and a log is that logs usually have a meaningful order or sequence of important content changes.

Note: Elements with the role marquee maintain the default aria-live value of off.

An element that represents a mathematical expression.

The math role is used to indicate sections that represent math. Authors SHOULD use a formal mathematical language such as MathML to express mathematical concepts. However, since there exists significant amounts of legacy content that use images and textual approximations using ASCII art or HTML tags (eg, sub and sup) to represent mathematical expressions, the math role also allows assistive technologies to deliver to the user the text alternative provided which could be converted to Braille or text-to-speech. In order for images to be perceivable, authors SHOULD label them with text that describes the math formula as it would be spoken in plain language, using the aria-label or aria-labelledby attribute. If using the aria-label attribute, authors SHOULD NOT include any special markup used to control a speech device. When providing extended descriptions, either as the contents of the element or associated by use of the aria-describedby attribute, authors SHOULD use valid MathML or TeX as the description for images.

MathML example:

<div role="math" aria-label="6 divided by 4 equals 1.5">
  <math xmlns="http://www.w3.org/1998/Math/MathML">
    <mfrac>
      <mn>6</mn>
      <mn>4</mn>
    </mfrac>
    <mo>=</mo>
    <mn>1.5</mn>
  </math>
</div>

TeX example:

<div role="math" aria-label="6 divided by 4 equals 1.5">
  \frac{6}{4}=1.5
</div>

A type of widget that offers a list of choices to the user.

A menu is often a list of common actions or functions that a user can invoke. The menu role is appropriate when a list of menu items is presented in a manner similar to a menu on a desktop application.

To be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus.

A presentation of menu that usually remains visible and is usually presented horizontally.

The menubar role is used to create a menu bar similar to those found in Windows, Mac, and Gnome desktop applications. A menu bar is used to create a consistent set of frequently used commands. 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.

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

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 SHOULD 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 groups by use of a separator or an element with an equivalent role from the native markup language.

A checkable menuitem that has three possible values: 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 SHOULD 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 groups by use of a separator or an element with an equivalent role from the native markup language.

A checkable menuitem in a group of menuitemradio roles, 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 SHOULD ensure that menu item radios 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 groups 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.

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

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

A selectable item in a select list.

Authors MUST ensure elements with role option are contained in, or owned by, an element 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 WAI-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 role-specific 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, but does not cause the content contained within the element to be removed from the accessible 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>

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 WAI-ARIA as required owned elements.

When an explicit or inherited role of presentation is applied to an element with the implicit semantic of a WAI-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. For any element with an explicit or inherited role of presentation and which is not focusable, user agents MUST ignore role-specific WAI-ARIA states and properties for that element. For example, in HTML, a table element with a role of presentation will have the implicit native semantics of its tr element removed because the grid role to which the table corresponds has a required owned element of row. In turn, the implicit native semantics of the th and td elements will also be removed, because the row has required owned elements of role gridcell/columnheader/rowheader, which correspond to th and td elements. The same principle applies to list elements with required owned listitem elements: ul and ol elements with a role of presentation will have the implicit semantics of their li children removed as well.

Note: Only the implicit native semantics of elements that correspond to WAI-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.

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

<!-- 1. [role="presentation"] negates the implicit 'list' and 'listitem' role semantics but does not affect the contents. -->
<ul role="presentation">
  <li> Sample Content </li>
  <li> More Sample Content </li>
</ul>

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

Note: There are other WAI-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 WAI-ARIA states and properties. However, the user agent MUST always expose global WAI-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.

In the following code sample, the containing div element has a WAI-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 WAI-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 indicates that the user's request has been received and the application is making progress toward completing the requested action. 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. Authors SHOULD update these values when the visual progress indicator is updated. 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 a user to alter the value of a progressbar because it is always readonly.

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

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.

A group of radio buttons.

A radiogroup is a type of select list that can only have a single entry checked at any one 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, the previously checked item becomes unchecked (its aria-checked attribute becomes false).

An input representing a range of values that can be set by the user.

Note: range is an abstract role used for the ontology. Authors must not use this role in content.

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.

The 'page summary' summary referenced above is a structure created dynamically from the page after it is loaded as a means of quickly describing its overall organization. It may be created by the author using a script, or by assistive technology.

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.

When defining regions of a web page, authors are advised to consider using standard document landmark roles. If the definitions of these regions are inadequate, authors can use the region role and provide the appropriate accessible name.

The base role from which all other roles in this taxonomy inherit.

Properties of this role describe the structural and functional purpose of objects that are assigned this role (known in RDF terms as "instances"). A role is a concept that can be used to understand and operate instances.

Note: roletype is an abstract role used for the ontology. Authors must not use this role in content.

A row of cells in a grid.

Rows contain gridcell elements, and thus serve to organize the grid.

In a treegrid, authors MAY mark rows as expandable, using the aria-expanded attribute to indicate the present status. This is not the case for an ordinary grid, in which the aria-expanded attribute is not present.

A group containing one or more row elements in a grid.

The rowgroup role establishes a relationship between owned row elements. It is a structural equivalent to the thead, tfoot, and tbody elements in an HTML table element.

Note: This role does not differentiate between types of row groups (e.g. thead vs. tbody), but an issue has been raised for WAI-ARIA 2.0.

A cell containing header information for a row in a grid.

Rowheader can be used as a row header in a table or grid. The rowheader establishes a relationship between it and all cells in the corresponding row. It is a structural equivalent to setting scope="row" on an HTML th element.