Hiding Semantics
Intentionally Hiding Semantics with the presentation
Role
While ARIA is primarily used to express semantics, there are some situations where hiding an
element’s semantics from assistive technologies is helpful. This is done with the
presentation
role, which declares that an element is being used only for presentation and therefore does
not have any accessibility semantics. The ARIA 1.1 specification also includes role
none,
which serves as a synonym for presentation
.
For example, consider a tabs widget built using an HTML ul
element.
<ul role="tablist">
<li role="presentation">
<a role="tab" href="#">Tab 1</a>
</li>
<li role="presentation">
<a role="tab" href="#">Tab 2</a>
</li>
<li role="presentation">
<a role="tab" href="#">Tab 3</a>
</li>
</ul>
Because the list is declared to be a tablist, the list items are not in a list context. It
could confuse users if an assistive technology were to render those list items. Applying role
presentation
to the li
elements tells browsers to leave those
elements out of their accessibility tree. Assistive technologies will thus be unaware of the
list item elements and see the tab elements as immediate children of the tablist.
Three common uses of role presentation
are:
- Hiding a decorative image; it is equivalent to giving the image null alt text.
- Suppressing table semantics of tables used for layout in circumstances where the table semantics do not convey meaningful relationships.
- Eliminating semantics of intervening orphan elements in the structure of a composite widget, such as a tablist, menu, or tree as demonstrated in the example above.
Effects of Role presentation
When role="presentation"
is specified on an element, if a
condition that requires a browser to ignore the presentation
role
does not exist, it has the following three effects.
- The element’s implied ARIA role and any ARIA states and properties associated with that role are hidden from assistive technologies.
-
Text contained by the element, i.e., inner text, as well as inner text of all its
descendant elements remains visible to assistive technologies except, of course, when the
text is explicitly hidden, e.g., styled with
display: none
or hasaria-hidden="true"
. -
The roles, states, and properties of each descendant element remain visible to assistive
technologies unless the descendant requires the context of the presentational
element. For example:
- If
presentation
is applied to aul
orol
element, each childli
element inherits thepresentation
role because ARIA requires thelistitem
elements to have the parentlist
element. So, theli
elements are not exposed to assistive technologies, but elements contained inside of thoseli
elements, including nested lists, are visible to assistive technologies. -
Similarly, if
presentation
is applied to atable
element, the descendantcaption
,thead
,tbody
,tfoot
,tr
,th
, andtd
elements inherit rolepresentation
and are thus not exposed to assistive technologies. But, elements inside of theth
andtd
elements, including nested tables, are exposed to assistive technologies.
- If
Conditions That Cause Role presentation
to be Ignored
Browsers ignore role="presentation"
, and it therefore has no effect, if either of the following are true about the element to which it is applied:
- The element is focusable, e.g. it is natively focusable like an HTML link or input, or it has a
tabindex
attribute. -
The element has any of the
twenty-one global ARIA states and properties,
e.g.,
aria-label
.
Example Demonstrating Effects of the presentation
Role
This code:
<ul role="presentation">
<li>Date of birth:</li>
<li>January 1, 3456</li>
</ul>
when parsed by a browser, is equivalent to the following from the perspective of a screen reader or other assistive technology that relies on the browser's accessibility tree:
<div>Date of birth:</div>
<div>January 1, 3456</div>
Roles That Automatically Hide Semantics by Making Their Descendants Presentational
There are some types of user interface components that, when represented in a platform
accessibility API, can only contain text. For example, accessibility APIs do not have a way of
representing semantic elements contained in a button. To deal with this limitation, WAI-ARIA
requires browsers to automatically apply role presentation
to all descendant
elements of any element with a role that cannot support semantic children.
The roles that require all children to be presentational are:
- button
- checkbox
- img
- meter
- menuitemcheckbox
- menuitemradio
- option
- progressbar
- radio
- scrollbar
- separator
- slider
- switch
- tab
For instance, consider the following tab element, which contains a heading.
<li role="tab"><h3>Title of My Tab</h3></li>
Because WAI-ARIA requires descendants of tab to be presentational, the following code is equivalent.
<li role="tab"><h3 role="presentation">Title of My Tab</h3></li>
And, from the perspective of anyone using a technology that relies on an accessibility API, such as a screen reader, the heading does not exist since the previous code is equivalent to the following.
<li role="tab">Title of My Tab</li>
See the
section about role presentation
for a detailed explanation of what it does.