Main content

presentation

Characteristics

Superclass Role:

  • structure

Inherited States and Properties:

  • aria-atomic
  • aria-busy (state)
  • aria-controls
  • aria-describedby
  • aria-disabled (state)
  • aria-dropeffect
  • aria-flowto
  • aria-grabbed (state)
  • aria-haspopup
  • aria-hidden (state)
  • aria-invalid (state)
  • aria-label
  • aria-labelledby
  • aria-live
  • aria-owns
  • aria-relevant

Name From:

  • author (if role discarded by error conditions)

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>

Microsoft Active Accessibility accRole Property: 

  • ROLE_SYSTEM_PANE

UI Automation ControlType Property: 

  • Pane

UI Automation AriaRole Property: 

  • presentation
More in this category: « progressbar option »