Websites are often designed with a specific audience in mind: People who use a keyboard and mouse to navigate. Of course, actual internet users utilize a variety of other technologies. Some people use screen readers, which convert text to audio or braille; others prefer touchpads. People with mobility-related disabilities might use speech input software, head pointers, or eye-tracking devices.
Great web design should accommodate all of these users. Assistive technologies need to understand content, and appropriate use of semantic HTML can give these tools the information they need to function. However, basic HTML can be limited, particularly when defining attributes in complex web applications or interactive components.
WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications), also referred to as ARIA, is a technical specification designed to enhance accessibility by defining certain attributes in the HTML language. It’s a powerful tool for making the internet a more inclusive place — but when used improperly, ARIA can create serious barriers for people who use assistive tech.
If you’re considering ARIA implementation, you’ll need to use ARIA markup properly. To make that process easier, we’ll discuss a few common ARIA misconceptions and how they might affect your real-world users.
The purpose of ARIA is to provide semantics (clear, interpretable descriptions) for web elements that aren’t available through standard HTML. An ARIA attribute can give users context for why an element exists and how it functions.
The primary components of ARIA are roles, states, and properties. Roles define how a specific HTML element functions within the document, while states and properties are supported by the role. Together, these components identify elements semantically.
For example, if a widget contains a checkbox, the “checkbox" ARIA role might allow assistive tech to inform a user that they’re interacting with checkable controls. The “progressbar" role identifies — as you might expect — a progress bar, while other roles identify live regions and navigation elements to help assistive tools operate your website in a predictable way. Some of these semantic attributes aren’t available in standard HTML.
Read: Introduction to ARIA for Web Accessibility
However, ARIA isn’t always necessary. HTML is an evolving language, and as it changes, it’s becoming more effective for providing semantics.
For example, HTML5 introduced audio and video tags, for instance, along with various other multimedia attributes. Elements that once required ARIA markup can now be described effectively with standard HTML.
Developers shouldn’t avoid ARIA when it can improve page functionality. With that said, basic HTML is usually preferable to WAI-ARIA markup. All assistive technologies can understand standard HTML semantics, and HTML attributes are — generally speaking — less likely to create a usability issue when used improperly.
Of course, some web apps have functionality that HTML can’t define accurately. That’s where ARIA comes in — but it’s not a necessary addition to every website.
Read: How ARIA Can Help Make Your Website Accessible
In some cases, improper ARIA markup can make a page completely unusable for some visitors. For example:
Adding ARIA markup to your website can be a major undertaking. Regular testing is absolutely essential, and automated tools may miss some of the highly technical issues that can occur with WAI-ARIA.
Developers often focus on how ARIA markup affects screen reader users. While screen reader accessibility is extremely important, remember that ARIA is also useful for other types of assistive devices.
Additionally, different assistive technologies have different levels of ARIA implementation. Some software tools are extraordinarily effective at understanding WAI-ARIA, but others are less capable. One screen reader might prefer ARIA attributes, while others default to HTML5 attributes in certain instances. Those differences can affect your users' experiences.
In short: If you’re using ARIA, make sure you understand exactly how your markup will affect your visitors. Don’t test your ARIA with a single screen reader test. Check your markup frequently, and evaluate every aspect of your content for accessibility — not just your ARIA usage.