ARIA stands for Accessible Rich Internet Applications.
It’s a set of attributes defined by the W3C (World Wide Web Consortium) that can be added to HTML elements to improve accessibility of web applications, for users who rely on assistive technologies (AT) like screen readers, and voice recognition software.
What ARIA does is provide information about the purpose, role and state of web components, when these components can’t provide this information semantically or in cases where HTML5 elements don’t have accessibility support.
Example of an Accessible Accordion
Accordions aren’t a built-in part of HTML.
We need to create a custom UI component that works as an accordion and we must ensure that this component is accessible to keyboard and screen reader users.
Here, we utilize one ARIA property, one ARIA state and one role:
Properties provide additional descriptive information about elements.
Their syntax is aria-*.
In our example we use:
– aria-controls: This property links the button to the content panel.
States Indicate the current condition of an element, such as whether it’s expanded, disabled, or hidden.
Their syntax is similar to that of properties, aria-*.
Here we use :
– aria-expanded to tell screen readers whether the accordion is open or closed.
Roles describe the purpose of an element to assistive technologies.
In our case:
role=”region” helps identify the panel as a meaningful section.
When to use ARIA?
We should use ARIA when there is no other way to make a web component accessible. So it is a kind of last resort.
This is so important a think to remember that according to W3.org, the first rule of ARIA is:
In order to improve web accessibility, use native HTML5 elements whenever possible instead of repurposing an element by adding ARIA attributes.
There is always the possibility to use too many ARIA attributes, introducing more accessibility issues than the issues we would have with no ARIA at all.
For example, let’s see an example of using ARIA in the wrong way causing accessibility issues.
Here we have a bunch of redundant roles.
The <nav> element already has an implicit “navigation” role in HTML5. Adding role=”navigation” is unnecessary.
Also, the <ul> and <li> elements are natively recognized as a list and list items, respectively.
Same with the <a> tag which is natively a link. No need to assign the role=”link” here.
Assistive technologies like screen readers already identify them correctly without ARIA roles.
All these unnecessary ARIA roles can cause cognitive overload for users.
Screen readers announce extra information like:
“Navigation, navigation, list, list, list item, list item, link, link” etc
This repetition can overwhelm users, especially those with cognitive disabilities.
So we must use ARIA wisely.
Native HTML5 elements are often sufficient.
Although my blog doesn’t support comments, feel free to reply via email or X.