Best Practices for ARIA Implementation

 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 element, you no longer need to add in the attribute role="button", since the role is already explicitly defined by the HTML code.

Testing With a Screen Reader

Another key to creating a good ARIA implementation is to make sure that you are testing your site with a screen reader or two. You’re likely to be surprised at the details of how they function and how easy it is to make your website annoying to use by accident.

Many ARIA attributes can create notifications or alerts for the end user, and if you are utilizing an aria-live content area that changes every 10 seconds, it’s possible that the implementation is making it more difficult to use your website.

Iterative Accessibility for the Web

When adding additional accessibility measures to your site, it’s important to remember that it isn’t an all or nothing task. You don’t have to completely deck out your entire website in one attempt, and iterative additions are probably the best way to go.

Starting with major content areas and navigations and then spreading throughout the site slowly is a solid strategy, completing more as time goes on. Even if you schedule 15 or 30 minutes each month to add just a bit of accessibility to your site, it’s a step in the right direction.

Good UX Is Good Accessibility (And Vice Versa)

ARIA isn’t a cure-all for accessibility issues. It is crucial to place a heavy focus on good UX design, especially when it comes to text readability, as another tool in your accessibility toolkit.

If you’d like to delve deeper into the specifics of how UX and development (outside of ARIA) can be wielded to improve accessibility, take a look at the Web Content Accessibility Guidelines.

You can also take a look at our Complete Learning Guide to Web Accessibility.

Frequently Asked Questions About ARIA

This series on ARIA resonated with a lot of readers and sparked discussion in the community. Let’s keep it up! Increasing awareness and improving these tutorials is the best way to bring accessibility to the forefront.  

Here are some of the most common questions and commentary that popped up around the web:

What Browsers Support WAI-ARIA?

A bunch! Most modern browsers support the features of ARIA to some extent, though this slightly changes from browser to browser. If you want to see specifics for each browser, you can use a tool like Can I Use?

Can ARIA Be Used With WordPress?

Yep! A few WordPress themes already have ARIA integrated, but you can add it to any theme that you can edit the source code for. In addition, you can also use ARIA with almost any Content Management System!

What Happens If ARIA Isn’t Supported?

Since ARIA doesn’t affect rendering, nothing! In most cases, if a device doesn’t support ARIA, it’ll just be ignored entirely.

Make the Web a Better Place!

Putting all of the articles from this series together, I hope you now have all of the tools needed to improve the accessibility of your site!

If you have any questions, feedback, or have a correction for something I’ve said, please let me know in the comments!