An element whose implicit native role semantics will not be mapped to the accessibility API. See synonym none.
Note regarding the ARIA 1.1 none role.
In ARIA 1.1, the working group introduced none as a synonym to the presentation
role, due to author confusion surrounding the intended meaning of the word "presentation" or "presentational." Many individuals erroneously consider role="presentation"
to be synonymous with aria-hidden="true"
, and we believe role="none"
conveys the actual meaning more unambiguously.
Until implementations include sufficient support for role="none"
, web authors are advised to use the presentation
role alone role="presentation"
or redundantly as a fallback to the none role role="none presentation"
.
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 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.
<h1 role="presentation"> Sample Content </h1>
<span> Sample Content </span>
<span role="presentation"> Sample Content </span>
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 table role) require tr
descendants (the row role), which in turn require th
or td
children (the cell, 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. 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.
In HTML, the <img>
element is treated as a single entity regardless of the type of image file. Consequently, using role="presentation"
or role="none"
on an HTML img
is equivalent to using aria-hidden="true"
. In order to make the image contents accessible, authors can embed the object using an <object>
or <iframe>
element, or use inline SVG code, and follow the accessibility guidelines for the image content.
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 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, the implicit native semantics of an HTML table
element's thead
/tbody
/tfoot
/tr
/th
/td
descendants will also be removed, because the HTML specification indicates that these are required structural descendants of the table
element.
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 an 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.
<ul role="presentation">
<li> Sample Content </li>
<li> More Sample Content </li>
</ul>
<foo>
<foo> Sample Content </foo>
<foo> More Sample Content </foo>
</foo>
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.
Authors SHOULD NOT provide meaningful alternative text (for example, use alt=""
in HTML) when the presentation
role is applied to an image.
In the following code sample, the containing 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>
Presentational Roles Conflict Resolution
There are a number of ways presentational role conflicts are resolved.
User agents MUST NOT expose elements having explicit or inherited presentational role in the accessibility tree, with these exceptions:
- If an element is focusable, or otherwise interactive, user agents MUST ignore the
presentation
role and expose the element with its implicit role, in order to ensure that the element is operable.
- If a required owned element has an explicit non-presentational role, user agents MUST ignore an inherited presentational role and expose the element with its explicit role. If the action of exposing the explicit role causes the accessibility tree to be malformed, the expected results are undefined.
- If an element has global WAI-ARIA states or properties, user agents MUST ignore the
presentation
role and expose the element with its implicit role. However, if an element has only non-global, role-specific WAI-ARIA states or properties, the element MUST NOT be exposed unless the presentational role is inherited and an explicit non-presentational role is applied.
For example, aria-describedby 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.
<h1 role="presentation" aria-describedby="comment-1"> Sample Content </h1>
<h1 role="presentation" aria-level="2"> Sample Content </h1>