ARIA attributes: The forgotten ones of accessibility
Tags: a11y, accesibility, frontend, aria
Published: 2024-05-26 20:44:14

##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](https://developer.mozilla.org/en-US/docs/Glossary/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](https://www.html5accessibility.com/).
- 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](https://w3c.github.io/aria/#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](https://w3c.github.io/aria/#widget_roles): These roles define common interactive patterns, providing a standardized approach for enhancing user interactivity.
- [Document Structure Roles](https://w3c.github.io/aria/#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](https://w3c.github.io/aria/#landmark_roles): Landmark roles indicate the structure and organization of a web page.
- [Live Region Roles](https://w3c.github.io/aria/#live_region_roles): They define elements whose content will dynamically change
- [Window Roles](https://w3c.github.io/aria/#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](https://w3c.github.io/aria/#state_prop_taxonomy) according to W3C:

- [Drag-and-Drop Attributes](https://w3c.github.io/aria/#attrs_dragdrop): These attributes give information about drag-and-drop elements.
- [Relationship Attributes](https://w3c.github.io/aria/#attrs_relationships): They specify relationships between elements, enhancing the contextual understanding of content.
- [Widget Attributes](https://w3c.github.io/aria/#attrs_widgets): They define details about user input elements
- [Live Region Attributes](https://w3c.github.io/aria/#attrs_liveregions): 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>
```