Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) is a technology published by the World Wide Web Consortium (W3C) that defines a way to make web content and applications more accessible to people with disabilities.
Before applying ARIA, certain web functions might not be available to users with disabilities. For example, people who are visually impaired and use a screen reader might not be able to access a drop-down menu or to choose items off of that menu. ARIA addresses these challenges by defining the way in which that functionality will be accessible to assistive technology.
This sounds fantastic, right? ARIA allows web developers to make their products more accessible to people with disabilities. Let’s throw it at every application on every site!
Not so fast. While ARIA is a solid technology with the potential to do good things, it is not a cure-all. Some web developers apply ARIA without much consideration of what the end result will be. Unfortunately, this approach can end up doing much more harm than good.
Why ARIA Isn’t Always the Right Choice for Web Accessibility
ARIA is intended to supplement the existing native HTML elements, not replace them.
According to W3C, the first rule of ARIA use is “If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of repurposing an element and adding an ARIA role, state or property to make it accessible, then do so.”
HTML provides the Internet with its main structure. It consists of codes and tags, each with their own native semantics. When you write an HTML tag, those semantics communicate something specific to the browser. For example, a <menu> tag tells the browser “this is a menu.”
When someone reads your webpage using a screen reader, that assistive technology access the tag’s native semantics and use that information to navigate the page. Without the native semantics, the screen reader is lost, which is why W3C’s second rule of ARIA use is this:
“Do not change native semantics, unless you really have to.” It is important that the assistive technology can read those semantics in order to navigate properly.
In addition, when you are using ARIA, it is often preferable to use native HTML elements as a fallback for your ARIA roles. For example, you might use HTML list elements for the skeleton of an ARIA-scripted tree widget.
This means that developers need to take care to evaluate their HTML elements and attributes for their accessibility potential. Don’t just toss ARIA at everything. Check to see if it’s needed first. Then determine to what extent accessibility requires the use of ARIA, and use it to plug any holes that are preventing full accessibility.
How to Use ARIA the Right Way
We’re not suggesting ARIA is never the right solution. It is absolutely true that web developers can and should thoughtfully and skillfully apply ARIA to make their products more accessible to people with disabilities.
You want all users to experience your websites as an effortless and intuitive way to access content they are looking for. ARIA can help remove the frustration of constantly having to find a workaround for content that doesn’t communicate well with assistive technology.
Before you hack away at your HTML elements, start with a simple markup. Semantically describe all the content. Test everything multiple times using all available assistive technologies. If you detect deficiencies in which the HTML semantics are not properly communicating, apply ARIA.
Build Better Websites
Here’s something else for you to consider. Part of the reason that the ARIA technology was created in the first place is that many websites were not built with accessibility in mind. Before you start creating any new site, you should think about how all people, including those with disabilities, will access it.
You can break this trend. Learn about all of the available HTML tags and the best way to use them. Pay special attention to page templates and their semantics. Learn about the best uses for ARIA as well.
Then apply these considerations to the foundation of your website as you’re building it.
When you run your tests, be sure to conduct several manual tests with screen readers. Plenty of them are available for free. Have a human being sit with a screen reader and navigate through the site. Does everything make sense? Is anything confusing? Is there information missing?
Navigating a website that was not built to accommodate your technology can be a frustrating, difficult experience. Help people with disabilities to access your products and pages by first using native HTML elements with the appropriate semantics, then supplementing with ARIA when necessary.