Best Practices for ARIA Implementation

Today, to mark the International Day of Persons With Disabilities, we are highlighting accessibility here at Envato Tuts+.

ARIA is an important feature that web developers can use to help make their sites more accessible. In previous pieces, we talked about how you can implement ARIA, whether you’re doing so on an eCommerce site or in more niche places.

So far, the focus of this series has been on how to implement ARIA—for example, how to add a role to an element or how to code more accessible forms. With this piece, the focus is going to shift a bit towards other aspects of online accessibility, like why and when we should use ARIA. We’ll also cover some common questions asked on previous posts throughout the series.

Alright, let’s begin!

What Is ARIA?

At its base, ARIA is an extension to current web development languages (mainly HTML) that allows for enhanced accessibility to end users.

What exactly does that mean, though?

Extending HTML With ARIA

HTML has some shortcomings when it comes to how elements are defined and how elements can be related to one another.

In many cases, HTML elements (such as the

tag) are too broadly defined to be useful to someone navigating a site with a screen reader, or an element may have too many possible meanings to be interpreted (e.g. an image could also be used as a button). ARIA adds additional attributes to HTML elements to allow for definitions that can be layered on top of the already existing markup language, adding clarity as needed.

The second major benefit is the relation of elements. With HTML, every element exists as a child and/or a parent of another element. But this structure doesn’t capture all semantic relationships. This can lead to scenarios like a controller and the element it controls not being clearly associated if they are placed in separate div containers. This becomes increasingly important in complex site structures or when altering the DOM using JavaScript.

Beyond those two benefits, there are a host of others that tend to get less attention, but provide excellent functionality nonetheless.

ARIA for Advanced Accessibility

Although much of the web is pushing towards easier-to-use UX, ARIA fills an important role for others who may not be able to simplify their structure. There are cases where a website might require tree controls, such as those commonly used by filesystems. By providing additional structure, ARIA makes these more advanced controls available to people who might not be able to access them otherwise—especially for users seeking to create a site with drag-and-drop capabilities.

Another key capability is that ARIA doesn’t just extend HTML—it can also be used to make other, less accessibility-friendly technologies available to more users. This is often the case for people using AJAX or DHTML for their web applications.

And really, those are just scratching the surface. If you’re interested in finding out more about the capabilities, attributes, and other useful parameters, take a look at the WAI-ARIA overview.

Why Should We Use ARIA?

As far as accessibility is concerned, ARIA has become one of the most widely adopted standards, with more than 25% of the top million websites using it to some extent.

The biggest boon of using WAI-ARIA is that it increases accessibility on your site. Users that rely on screen readers, have low vision, or use alternative interfaces for the web benefit greatly from the implementation—and in some cases, they may not be able to use a website to its full extent without it. For many, accessibility is seen as a core value of the web, and as developers, we should strive to provide it wherever possible.

Beyond the best practices aspect, there is also a business incentive to implement ARIA. With 2-3% of Americans having some form of low vision, there is a significant portion of most markets that would benefit from use of the standard. In addition, having an implementation in place now will be beneficial as adoption of ARIA increasingly grows among non-standard web interfaces and creeps into devices such as smart speakers.

Best Practices for ARIA Implementation

Until now, we’ve focused on the actual methods of implementation in this series. With the basics of how to add ARIA to your site in place now, let’s take a look at some key guidelines for putting together your own implementation.

Using a Light Touch Approach

A good implementation of ARIA doesn’t need additional attributes and roles at every opportunity.

When possible, using the least amount of additional code to convey the necessary information is ideal. As an example, the overuse of ARIA is similar to making your site’s homepage a full sitemap for a visual user. People using screen readers will be overwhelmed by the amount of notifications and additional markup on a page that overutilizes ARIA, achieving the opposite of what we were seeking.

Providing enough additional markup to make your important elements’ context clear is the goal, and anything beyond that is probably not necessary.

Avoiding Redundancy (Especially When Using HTML5)

Throughout the previous posts in this series, we talked about the role attribute quite a bit. We placed it in every place that we needed the user to be aware of. There’s an important exception to this, however, that we didn’t talk about before, and that’s the need to avoid redundancy.

Whenever an element that you want to add ARIA to already clearly defines what it is, then you can skip adding ARIA to it. Why is this? Because ARIA is meant to extend existing code to make it more readable, but in some cases, code is already clear, structured, and easy to understand.

This happens frequently for people using elements introduced in HTML5. For example, when using the