ARIA Spec for the Uninitiated: Part 1

Accessible Rich Internet Applications (ARIA) is a set of attributes that define ways to make web content and web applications (especially those developed with JavaScript) more accessible to people with disabilities using assistive technologies like screen readers. Depending on the application, using HTML alone is not enough and you will have to use ARIA in order to fill in the gaps. Unfortunately, ARIA is commonly misunderstood and therefore misused by developers – ultimately making the web more inaccessible than accessible.

In this first part of a 3-part series, I aim to combat this problem by first discussing the dangers of ARIA. Then, I will give you an introduction to the official ARIA standard, and review the 5 rules of ARIA.

In the 2nd part, I’ll go through the ARIA Authoring Practices to discuss their purpose, and explain how they are often misused.

In the third and final part, I’ll tie everything together by walking through a practical example of building and testing an expand/ collapse control using all the resources I have gone over in this series.

The Dangers of ARIA

First, I want to talk about the dangers of ARIA and why it is important to know and use it correctly. ARIA is essential to providing the level of dynamics possible in today’s web. However, using ARIA incorrectly can cause critical barriers for users of assistive technologies.

Why is ARIA so dangerous? Other than people not taking the time to learn it properly, one main reason is that ARIA support varies between platforms, accessibility APIs, browsers, and assistive technologies. There are a lot of hands in the pot by the time it reaches a user. Unlike supporting cross-browser CSS or JavaScript, there are no methods to programmatically test for support in order to provide alternatives. The only thing you can do is test your work with various browser/ assistive technology combinations to ensure you have implemented the expected experience.

Even when ARIA is supported by these platforms, there can sometimes be bugs in the implementation. In addition, as you would expect with any other type of web technologies or software, these implementations of ARIA can also suddenly break.

Because of these reasons, throwing ARIA at a problem is not always the solution. To prove that point, a survey of 1 million homepages by Webaim in April of 2021 states, “Home pages with ARIA present averaged 41% more detectable errors than those without ARIA.” Not only is throwing ARIA at a problem not the proper solution, but it could also be making things worse. This is why there is a very popular sentiment in the accessibility community that states, “No ARIA is better than bad ARIA!” with the point being that if you don’t know how to really use ARIA, it’s just better to leave it out. ARIA should ultimately be the last resort but, as mentioned previously, depending on the application sometimes HTML alone is not enough and you will have to rely on ARIA to fill in the gaps. In this series, hopefully, you will learn enough about ARIA to make things better, not worse.

Official ARIA Standard

The official ARIA standard is the first resource I want to highlight. Normally, visiting the official standard or spec for any kind of web technology is reserved for extremely academic types. Most of you have probably never read the official ECMAScript standard, but I want you to treat the official ARIA standard as an API guide to get the most up-to-date information on available properties and options.

If you want to learn more about ARIA, I urge you to go to the ARIA standard first. The latest version of the ARIA standard is 1.1, and you can always get to the latest version of the standard by going to www.w3.org/TR/wai-aria (make sure you bookmark this). I don’t expect you to read the whole thing at first, but there are a couple of sections that I want to point out that will serve as the basis for everything I talk about in this series and everything you will do related to ARIA from now on.

Roles

The first section I want to point out is section 5.3, the Categorization of Roles, which lists all the available roles that ARIA provides. Roles are how you provide semantics, which is extremely important to accessibility. Semantics are the way you let an assistive technology user know what something is, which is also an indication of how that thing is to be used. Once you’ve provided a role on an element, you also have to ensure that it has the correct functionality that role is meant to provide. It’s important to note that ARIA does not add any functionality, it only gives you a way to describe and communicate states or properties to assistive technologies.

The categorization of a role is key because it’s a clue as to what the purpose of the role is, and there are four categories that I want to point out to you:

1. Widget roles
2. Document structure
3. Live region
4. Window roles

Widget Roles

Widget roles are the roles that you use to indicate interactive elements. These interactive elements can be broken down into two groups, Standalone and Composite.

Standalone widgets either operate on their own or exist to be part of a Composite widget, and there are a total of 20 Standalone widgets available.

Next is a group of 9 Composite widget roles and these are essentially parent roles, or containers, for other Standalone widget roles. There is a very strict hierarchy when it comes to composite widgets. These must be composed with very specific Standalone roles, and often in a very specific order. In most cases, you cannot pick and choose which roles you use to compose a widget since some Standalone roles can only exist as a child or nested in Composite widget roles.

There are very strict parent-child relationships between certain roles, so some roles can only be used as a child to a specific Composite role. This is extremely important to understand, especially with how easy certain UI libraries make it to reuse components and render whenever, or wherever, necessary. Be very careful about how you nest components and roles because you could be breaking your well-intended accessibility.

Document Structure

The next set of roles are for document structure, which provides content organization. These 26 document structure roles are, in most cases, not interactive, but they provide semantics for content like headings, images, lists, and tables. A lot of these are already provided by HTML elements, and in most cases, it is better to use the HTML implementation over the ARIA.

Live Region Roles

The next group of roles is live region roles, which are essentially pieces of content that are updated dynamically and announced by assistive technologies. They don’t need to be actively focused in order to be announced.

Some examples of content that would be considered a good use for live regions are sports scores, chat logs, timers or dynamic error messaging. Live regions are extremely important and heavily used in today’s dynamic web applications, but they can also be abused and overused.

Window Roles

The last group of roles that I want to highlight is window roles. Window roles are considered to be dynamic, like window pop-ups. These could be considered composite widget roles except that they have special meaning in terms of document structure.

Other important sections to use as a resource

Below is a list of other resources you should bookmark for future reference:

• Definition of Roles.
• Global States and Properties.
• Taxonomy of WAI-ARIA States and Properties.
• Definitions of States and Properties (all aria-* attributes)

The Five Rules of ARIA

When it comes to ARIA, there are five very well-established rules that you need to be aware of. These high-level rules will always guide you in making the right decision when you’re developing your own ARIA widgets.

The First Rule of ARIA: Don’t use ARIA (if you can use HTML instead)

This may remind you of some sort of Fight Club rule (and ARIA can definitely cause a lot of fights), but you will often hear people say “Don’t use ARIA!” If you have heard this and were confused, it’s because “Don’t use ARIA” is actually an incomplete rule: the entire rule is don’t use ARIA if you can use HTML instead. The second part is almost always left off, but it’s really important.

As I mentioned in the overview of the ARIA standard, ARIA is used to describe widget role semantics and state. A lot of this can be covered by existing HTML elements and properties. If you can use the HTML counterpart first and it’s supported by browsers and assistive technologies, then you’re better off just using the HTML because it will provide all the same properties as ARIA while providing a more stable experience.

When discussing Landmark Roles, I mentioned that in almost all cases it was better to use the HTML implementation over ARIA, and here is a simple example:

ARIA Landmark Role Ex:

<div role=“banner”>

<div role=“complementary”>

<div role=“form”>

<div role=“main”>

<div role=“navigation”>

<div role=“region”>

<div role=“contentinfo”>

<div role=“search”>

Here I have applied various ARIA Landmark roles in order to describe sections of content. However, these roles (except for search) have HTML counterparts that you should use instead:

Correct ARIA Landmark Role Ex:

<!--div role=“banner”--> <header>

<!--div role=“complementary”--> <aside>

<!--div role=“form”--> <form>

<!--div role=“main”--> <main>

<!--div role=“navigation”--> <nav>

<!--div role=“region”--> <section [accessible name]>

<!--div role=“contentinfo”--> <footer>

<div role=“search”>

When these HTML tags were first introduced, it was advised to use both the tag and the ARIA role to be backward compatible, and this is a great example of using ARIA to fill in HTML gaps. Now that HTML5 is widely supported, it’s no longer necessary. In fact, if you make it a practice to validate your markup, which you absolutely should, you’ll get an error telling you not to double up on the semantics this way. You might get the same error if you do any kind of automated accessibility testing depending on the tool that you use.

The 2nd Rule of ARIA: Don’t Change Native Semantics

If you’re being responsible and using HTML first, you have to make sure that you don’t use ARIA on top of the semantics that native HTML provides. When you use an ARIA role on top of HTML, you are explicitly setting the semantics of that element; the ARIA role overrides the HTML semantics. In most cases, it’s better to start with the HTML tag counterpart to the ARIA role instead of replacing semantics with ARIA. This way, you will get all the functionality that is provided by the native HTML element.

The Third Rule of ARIA: All Interactive ARIA Roles Need To Be Operable By Keyboard

Hopefully, the third rule of ARIA should be familiar to you already: all interactive ARIA roles need to be operable by keyboard. If functionality is provided via mouse, touch or any other method of input, it also needs to be available by keyboard.

Keyboard support is absolutely fundamental to accessibility, and part of fulfilling the contract of semantics. Additionally, ensuring keyboard support will get you a long way with other input modalities you may not have expected, such as game controllers for example.

The Fourth Rule of ARIA: Don’t use role=“presentation” or aria-hidden=“true” on visible focusable elements

The role of presentation is a very special role because it actually removes the semantics of an element. If you do this to an interactive or focusable element, an assistive technology user will not know what that element is for or how to use it, it may even be ignored, even if it is still actionable.

Aria-hidden is a state that effectively hides that element from assistive technology users. Again, ARIA just describes things, it doesn’t affect appearance or functionality the way HTML attributes might. When you use aria-hidden=”true” on an element, it’s still rendered visibly on the screen. Doing this on an interactive element hides the presence of that element, which can again create a serious barrier to your users. Proper ways to hide elements is a separate subject, but for now, just know that role=”presentation” and aria-hidden=”true” can be very dangerous if not fully understood and used properly.

The Fifth Rule of ARIA: all interactive elements must have an accessible name

If semantics or roles give you the type, then the accessible name tells you what. Not only is it important for screen reader and braille users, it’s also important for voice recognition users to be able to identify and interact with controls on a page. In summary, make sure that all interactive elements have an accessible name.

The Five Rules of ARIA are documented here on the W3 site at https//www.w3.org/TR/aria-in-html, where you can read more information and examples. There’s a lot of really good information documented on this page, so I encourage you to check it out and learn more.

Conclusion

In this first part of the series, I discussed the importance of familiarizing yourself with the official ARIA standard and pointed out some of the most important sections to be aware of. I also went over the Five Rules of ARIA that should better guide you as to when to use ARIA.

In the next part of this blog series, I’ll go over the ARIA Authoring Practices, which is a series of examples of using ARIA to create accessible widgets. As with everything else related to ARIA, the purpose of these examples is often misunderstood leading to well-intentioned, but incorrect accessibility.