What is ARIA?
ARIA stands for Accessible Rich Internet Applications, a specification designed by the Web Accessibility Initiative (WAI) in the W3C. Its purpose is to supplement the accessibility and semantics of a website or web application.
In practicality, this achieved by adding aria- attributes to a HTML element. (These mostly have no bearing on layout or browser functionality, but provides additional information for assistive technologies)
Why should you care about ARIA?
As the name suggests, ARIA is for making websites and webapps more accessible. I have written about why we need to care about semantics in HTML.
However, there are where native HTML isn't enough for all use cases or for the dynamic, interactive or complex layouts of today's webapps. This can range from a simple pop-up to a novel interaction pattern. This is where aria- attributes comes to the rescue.
Some common problems which aria- is used to address are:
- Adding signposts/landmarks for better navigation in assistive technologies
- Conveying functionality of component
- Conveying states and properties of components
- Indicating change in dynamic content
What can ARIA do?
ARIA can modify existing element semantics or add semantics to elements where no native semantics exist.
ARIA attributes can be of three types - roles, properties, and states.
1. Roles
Roles define what an element is or does. Most HTML elements have a default role that is presented to assistive technology (AT). For example, <button> has a default role of "button" and <form> has a default role of "form". With aria-role, we can tell the AT the functionality or role of non-semantic tags.
Role is an important information used by screenreaders to help their users easily navigate a page.
Ex: when creating tabs
<ul role="tablist">
<li class="active" role="tab">
<a href="#home">Home</a>
</li>
<li role="explore">
<a href="#explore">Home</a>
</li>
</ul>
Notes
-
aria-roleshould not be used as a substitute for semantic HTML! - Default HTML roles need not be duplicated using ARIA. Ex:
<button role="button"> -
Do not over-ride native semantics with HTML (ex:
<h2 role ="tab">Home</h2>). This (Wrong ARIA use) is more detrimental to accessibility than no ARIA.
Here is a list of WAI-ARIA defined roles.
2. States and Properties
ARIA states and properties offer the user further information on how to interact with a particular component.
ARIA States describe the current state of the element such as if something is collapsed or expanded (aria-expanded = "false") or if a formfield is disabled ( aria-disabled="true"). They are dynamic in nature, and usually updated with JavaScript.
ARIA properties are used to provide additional additional semantics not supported in standard HTML. Ex: aria-haspopup="true" added to a button will let TA know that the button, if clicked, will trigger a pop-up. aria-live applied to a dynamically updating element (chats, content refresh, etc.) will cause screenreaders to read out the content that is updated (exact behavior depends on the value of 'aria-live').
"States" and "Properties" refer to similar features - with a subtle difference: properties are often less likely to change throughout the application life-cycle than the values of states.
Both states and properties are denoted by aria-prefixed markup attributes.
Here is a list of all WAI-defined states and properties. Some of them may be global, while others are to be used in conjunction with specific roles - W3C has a table with how the ARIA roles and attributes work together.
When to not use ARIA?
The attempt should be keep its usage as low as possible - we only use ARIA when a problem can't be solved with native HTML. Here is W3C guide on using ARIA.
Top comments (1)
@poulami, thank you for the article! A helpful review. I am a DHS certified 508 conformance tester for my company (developing and deploying distance learning courses). With the fallout of COVID, 508 conformant software and courses have quickly come to forefront.