What Is ARIA In Accessibility & Why Should You Use It?

ARIA, short for Accessible Rich Internet Applications, is a specification that is used to add accessibility information to HTML elements, making Web content and Web applications more accessible for those with disabilities. The main guide you should follow when it comes to applying ARIA is written by W3. The guide details five rules of ARIA for developers – in this article we’ll guide you through the first two.

So, what is ARIA?

ARIA stands for Accessible Rich Internet Applications.

This essentially means applying native controls to custom HTML elements and it’s broken down into two areas:

Let’s go through this in a bit more detail. Basically, ARIA is a means for a developer to make a custom element behave like a native HTML element so that assistive technologies know how to present it to the user.

A custom accordion is a perfect example of this, but did you know that there’s a native HTML 5 accordion and you don’t even need any libraries?

While we’ll only be covering two of the five rules to ARIA in this article, we’d highly advise that you take the time to read all five at some point.

Rule one

According to W3’s guide, this is the first rule of ARIA:

“If you can use a native HTML element [HTML51] or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.”

Stop and think about what you’re going to be making. Do you really need to use some custom JS and HTML? Can’t you simply use a native HTML 5 element?  More often than not, you actually can use a native element and it will only require a bit of CSS styling to make it look close to the designs.

If you do go down the custom route, are you clear on how to use the roles and states accordingly? There’s a quite daunting list of things that will need to be applied to all the various interactions involved with this new component.

Rule two

W3’s guide states that this is the second rule of ARIA:

“Do not change native semantics, unless you really have to.”

A good example of one of the most common mistakes is applied to the humble button.

Wrong:

<a href=”#” role=”button” class=”button-class”>Button</a>

This technique also involves additional custom JS to stop the anchor behaving like an in page scrolling anchor and so on. Not only that but this implementation of a button is still not even accessible in the default tab indexing of the page due to the preventDefault() used in the JS to override the default browser scroll behaviour!

Correct:

<button class=”button-class”>Button</button>

Yes, it’s a button so make it one. It solves all the problems that you just had to work around.

Basically, do not use the ARIA roles to override default HTML 5 behaviour. Always retain default roles and states for a HTML element. It should be semantically correct, which is good for accessibility, SEO and probably all round usability in general.

If you do have to use ARIA

Take note of all the ARIA rules, but this list of tips should also provide some good guidance on debugging.

Try and think about user interactions with your custom element and how they’re getting feedback from the events that occur. Some people may have be completely blind or not use a mouse, so take this into consideration.

A massive downside to building a custom element is that it won’t contain any of the default keyboard navigation associated with it and you’ll have to replicate them all with ARIA states. This can sometimes be a huge task – but ignoring that fact, do you know what the default keyboard navigation is for that component you’re trying to replicate?

There’s a saying:

“No ARIA is better than bad ARIA.”

ARIA is a very powerful thing and if used incorrectly it can be incredibly destructive to those using assistive technologies. There’s a great article on this issue that you should take into consideration before you start.

A webAim survey of over one million homepages found that pages with ARIA implemented on them averaged over 41% more errors detected than those without any ARIA.

Keep in mind that if it is difficult to make a component accessible then maybe it’s too complicated for users to use without assistive technology. It might be time to rethink and simplify the component.

Round-up