ARIA Spec for the Uninitiated: Part 1
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.
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.
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:
- Widget roles
- Document structure
- Live region
- Window 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.
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.
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:
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>
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.
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.