Terms of use of ARIA in HTML

The Internet Applications Suite (WAI-ARIA, or simply ARIA) is a set of tools and guidelines for making web content and applications more accessible.

In particular, it includes a set of attributes that we can add to HTML elements to give them semantic information that can be read using special features (assistive technologies).

Although ARIA can be quite useful, we should be careful how and when to use it. Here are 5 rules to consider when using ARIA in HTML.

1. Use semantic HTML in favor of ARIA

If you can use a native HTML element or attribute with a semantic meaning and behavior, use it instead of adding ARIA roles, states or properties to make it available.

Rule number one - do not try to use ARIA if it is not necessary. HTML5 provides us with a wide range of semantic elements.

Therefore, if possible, we should use a semantic HTML element, and not an ARIA attribute.

Instead of creating a <div> element and adding an ARIA role:

 <div role="button">Click Me</div>   

We should use the <button> element:

 <button>Click Me</button> 

2. Do not change the values ​​of semantic elements by ARIA roles.

Do not change the native semantics of the element, if you do not need it.

As I have already noted, many semantic HTML elements have their meaning. When we use <button> , for example, it indicates the user agents that this is an interactive element (you can interact with it with a mouse click, the Enter key or the spacebar), which will trigger some action on the page. On the other hand, if we use the <a> element, it indicates user agents that interacting with such an element (by clicking or pressing a key) will cause the user to be directed to another page or to another part of the same page. .

 <h1 role="button">Heading Button</h1>   

Instead of overriding the semantic value of an element, we should use the corresponding element:

 <h1><button>Heading Button</button></h1>   

Or, as a last resort, we can add an ARIA role to an element that does not have such meaning.

 <h1><span role="button">Heading Button</span></h1> 

3. ARIA Interactive Elements Must be Available for All Media.

All ARIA interactive controls must be suitable for keyboard operation.

It is not enough to use the ARIA role on an element to truly change its role. If we try to change, for example, <div> to <buton> , we must manually add interaction possibilities suitable for the button.

The ARIA manual has a list of features that each element should have. For example, a real button must meet the following requirements:

• Must be clickable with the cursor
• Must be clickable with Enter
• Must be clickable with spacebar

When using ARIA roles, we need to consider these requirements. Creating an item like a button does not make it a button. We need to consider how users in all environments interact with the element.

4. Use appropriate roles for visible focusable elements.

Do not use role="presentation" or aria-hidden="true" on visible focusable elements.

The ARIA attribute role="presentation" implies that the element is intended for visual interaction and is not interactive. The aria-hidden="true" attribute indicates that the element should not be visible. When we use these attributes, we need to know to which elements they apply and whether these elements are visible and interactive. For example, both of these buttons will cause some users to focus on an element that does not exist for them.

 <button role="presentation">Click Me</button> <button aria-hidden="true">Click Me</button>   

These attributes should be applied only to elements that are not interactive or are invisible.

 <button role="presentation" tabindex="-1">Don't Click Me</button> <button aria-hidden="true" style="display: none;">Don't Click Me</button> 

5. Interactive elements must have an accessible description.

All interactive elements must have an accessible description.

Elements that can be interacted with, such as buttons and links, must have a “description available”.

Available description (accessible name) - the name of the user interface element.

It is very easy to explain this with the “OK” button as an example. The text “OK” is an accessible description. (approx. translator)

The available description for the item may be specified depending on the type of the item. Inputs in the form, as a rule, receive their accessible description from the labels corresponding to them.

( more info ).

 <label> Username <input type="text"> </label> <label for="password">Password</label> <input type="password" id="password"> 

Other elements, such as buttons and links, can get my Available Description from their content or label attribute ( more ).