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!
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?
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
<div> 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.
Beyond those two benefits, there are a host of others that tend to get less attention, but provide excellent functionality nonetheless.
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.
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.
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.
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.
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
<button> element, you no longer need to add in the attribute
role="button", since the role is already explicitly defined by the HTML code.
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.
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.
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.
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:
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?
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!
Since ARIA doesn’t affect rendering, nothing! In most cases, if a device doesn’t support ARIA, it’ll just be ignored entirely.
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!