When to use role=”presentation” and when it is not recommended

What is ARIA

We have mentioned ARIA attributes several times before. But what is it and why can you often encounter it in code?

Simply put, it is a set of attributes and techniques introduced into the WCAG 2.0 standard in 2014. Broadly speaking, ARIA techniques are used to provide proper semantics to an element that lacks it for various reasons, such as design. On the other hand, there is also a need to exclude an element from the accessibility tree. Various object hiding techniques come to the rescue. Depending on the level at which we want to skip semantics, we have attributes such as:

•  disabled
• display: none
• aria-hidden=”true”
• role=”presentation” (synonym role=”none” introduced in 2016 ).

The first option completely disables the interactive element but remains visible to screen readers as a disabled element.

The second option hides the element both visually and for assisting tools. We will discuss both options in the next article because their use is related to other use cases.

Today, we will take a closer look at the remaining two attributes. The differences between them are relatively small, but significant and often (due to incorrect usage) cause confusion in assistive technology usage.

Are there similarities between role="presentation" and aria-hidden="true"

Only one: both in some way hide the element from assistive technologies. However, this is where the similarities end.

First, let’s talk about aria-hidden="true". This attribute completely hides the element from assistive technologies. This means that a screen reader user will not be aware of its existence. This is useful when a piece of code is not an interactive element such as a button, link, or text field. When working with SVG files, it is even necessary, but we will discuss this in another article 😊

Examples of using role="presentation"

The `role=”presentation”` has a subtle difference in usage. We use it to “erase” the semantics of an element. You can see the role’s effect on a simple example, such as a header:

<h2>Sample Header</h2>

After adding the attribute:

<h2 role=”presentation”>Sample header with role</h2>

The rendering is equivalent to plain text that has been properly styled:

<div>Sample header with role</div>

A screen reader will not treat the text as a header, although the visual formatting remains the same as for h2.

Initially, the role was used in solutions based on tabular layouts or graphics used only for spacing. Nowadays, websites are not designed in this way, and it is certainly not recommended. Does this mean that this role is no longer needed? No, you can still encounter it in navigations. Let’s expand on this simple usage:

<ul role="presentation"> <li> <a href="#">Link 1</a> </li> <li> <a href="#">Link 2</a> </li> <li> <a href="#">Link 3</a> </li> </ul>

In this case, we have removed the semantics of the list, but visually, the links are still arranged one after the other. We could also use the role on the list element:

<ul role="tree"> <li role="presentation"> <a role="treeitem" href="#">Link 1</a> </li> <li role="presentation"> <a role="treeitem" href="#">Link 2</a> </li> <li role="presentation"> <a role="treeitem" href="#">Link 3</a> </li> </ul>

In this case, semantically, we lack descendants in the <ul> list, so it does not meet the 1.3.1 WCAG criterion. Therefore, it is necessary to ensure that the list has semantic descendants. By adding role="tree" ; we have ensured WCAG compliance, but we had to know/remember to do so.
Other solutions are also presented at the following link: https://w3c.github.io/aria-practices/#presentation_role

Summary

As you can see, introducing role="presentation" can be helpful but also complicate the original code. Additionally, it is not acceptable to use this role on links, buttons, and other elements that receive focus, as the focus will still be drawn, but it may not always be semantically described as a link or button, causing inconsistencies that a person using assistive technologies may not understand how to use the element.

The same applies to elements that have any of the 21 states or properties described by ARIA attributes.