📚 ARIA attributes: The forgotten ones of accessibility

ARIA attributes?

Accessible Rich Internet Applications (ARIA) attributes might not be on every developer's radar, yet they play a pivotal role in fostering accessibility within web products. By augmenting HTML elements, ARIA attributes convey vital information to assistive technologies, enriching the accessibility tree, by modifying or providing additional details to incomplete code.

ARIA attributes are imperceptible to most users, as they neither alter functionality nor influence visual appearance; their impact is predominantly felt by assistive technology users.

When to use ARIA

ARIA is not a panacea for correcting faulty code nor does it automatically enhance a website's accessibility. Consider utilizing ARIA under the following circumstances:

• When a specific feature lacks HTML support.
• When HTML features are present but lack proper accessibility support.
• When styling requirements prevent the use of a native element.

ARIA features

The main features of ARIA are:

• state: Allows elements to change their state. For instance, when using a non-native HTML element as a checkbox, the aria-checked attribute informs assistive technologies about the checkbox's status.

<div aria-checked="true" role="checkbox" >Checkbox input </div>

• role: Expresses the purpose or nature of an element. For example, defining a button using the role attribute.

<div role="button">Close Modal</div>

• properties: Define the relationship or characteristics between elements.

<button aria-describedby="close-description">Close modal</button>
<p id="close-description">This button will close a modal</p>

Categorization of Roles

ARIA roles are categorized into Abstract Roles, Widget Roles, Document Structure Roles, Landmark Roles, Live Region Roles, and Window Roles. Each serves a distinct purpose in organizing and describing elements within a web page.

• Abstract Roles: Abstract Roles are intended solely for browser use in organizing a document. Developers should refrain from utilizing them to ensure optimal performance. Avoid incorporating these roles—command, composite, input, landmark, range, roletype, section, sectionhead, select, structure, widget, and window—into your projects.
• Widget Roles: These roles define common interactive patterns, providing a standardized approach for enhancing user interactivity.
• Document Structure Roles: The various Document Structure Roles serve the purpose of conveying information about the structure within a section of a document.
• Landmark Roles: Landmark roles indicate the structure and organization of a web page.
• Live Region Roles: They define elements whose content will dynamically change
• Window Roles: Window Roles specify roles for sub-windows within the main window, offering a structured hierarchy in web application interfaces.

States and properties

There are 38 properties in ARIA for states and properties and they fall into 4 categories according to W3C:

• Drag-and-Drop Attributes: These attributes give information about drag-and-drop elements.
• Relationship Attributes: They specify relationships between elements, enhancing the contextual understanding of content.
• Widget Attributes: They define details about user input elements
• Live Region Attributes: Live Region Attributes signal elements where content changes dynamically, even when those elements may not currently have focus. These attributes play a crucial role in creating dynamic and responsive content areas.

Tips for ARIA

Don't use ARIA

Follow ARIA's principle: the less you use it, the better. Prioritize solving accessibility challenges through HTML and UI adjustments before resorting to ARIA.

Use Semantic HTML

Prefer using HTML tags with implicit meaning or roles over ARIA attributes whenever possible. Semantic HTML tags, such as <button> or <main>, inherently provide accessibility benefits.

<button>Use this</button>
<div role="button">Not this</div>

<main>Use this</main>
<div role="main">Not this</div>

Besides, HTML5 tags already have landmark roles so it's unnecessary to add them and they are redundant.

Elements should be focusable

Make sure interactive ARIA controls are keyboard-accessible. If an element lacks native keyboard focus, include it in the logical tab order using tabindex="0".

<p tabindex=“0”>I recieve focus!</p>

Don't hide elements

Focusable elements shouldn't be hidden, so avoid using aria-hidden="true" or role="presentation". If a user tries to navigate through the keyboard, that person may end up focusing on nothing and it can be confusing.

Check ARIA syntax

Many common mistakes with ARIA could have been solved just by checking the syntax. For example: roles should be written in lowercase. Some browsers might be able to interpret the roles even in uppercase, however, but other browsers might not.

Don't overwrite semantics

Use ARIA only when HTML semantics prove inadequate or unavailable. Developers should avoid overwriting HTML native semantics. For example: If you want to build a heading tag, the <h2> itself has its own semantic meaning. However, a <div> can receive this role.

<div role=tab><h2>Do this</h2></div>
<h2 role=tab>Don't do this</h2>