The five rules of WAI-ARIA

When talking about accessibility, I fairly often find confusion, people confused because of the huge amount of terms and acronyms, people doubting about when is necessary or not to apply an extra accessible layer over our components. I always recommend to go to the docs looking for the original sources. It is known that docs use to be not always so clear or the information is difficult to extract, but in this case, the five rules of WAI-ARIA are easy to understand, short and simple. Furthermore, they are cool since they are written as the Fight Club rules are.

But before we dive in, we need to understand where they came from, so here it is a little context:

W3C

The W3C (World Wide Web Consortium) is the international organization that develops the Web standards, with the goal in mind to bring Internet to its maximum. It is the original source.

WAI

The WAI (Web Accesibility Initiaitive) is a working group that depends on the W3C, which is in charge to create standards, guidelines, good practices and resources to help to understand the techniques about accessibility and teach how to apply them. Its main goal is to helps us to improve the Web, making it an accessible place for everyone.

WCAG (Web Content Accessibility Guidelines) is probably the WAI’s most popular guidelines. It is written for web developers and web authors, but the WAI is also the author of ATAG (Authoring Tool Accessibility Guidelines) written for those who develop tools for testing accessibility, and also UAAG (User Agent Accessibility Guidelines), written for those who develop web browsers. This guidelines say, for instance, how a browser should handle a video element, supliying some mechanisms for controlling the player, volume or captions.

WCAG

This guidelines are useful to us when developing for the web because it helps us to know the techniques we have to use or rather which ones we have to avoid for improving the accessibility of our interfaces, for people with dissabilities or not.

Remember that when we talk about accessibility we are not only talking about people with visual difficulties but anyone who may encounter barriers when accessing or consuming our content. For example, elderly people who generally have less control over the environment may encounter barriers when browsing our pages, since we used to imagine what profile will visit our sites from the beginning of the creation process, and generally elderly people are not taking into count.

Another example, have you ever read any legal conditions to the end? a law approved by your country’s parliament? all the clauses of the income statement? the program of a political party?

Would you say it is easy to understand? would you say it is accessible?.

This guidelines about what we should comply with (or must avoid) establishes a lot of evaluations that are classified into 4 large groups or principles; Perceivable, Operable, Understandable and Robust. There is no need to comply with all of them, it will depend on the level of conformity you are seeking; A, AA or AAA (the more “A” the more restrictive -> the fewer barriers there will be).

As it is not the objective of today’s article, we are not going to go into them so much, but to summarize, here it is a small clarification:

1. Perceivable - The information and the components of the interface must be presented to the user in a clear way, so the user knows they are there, that there is no hidden information or secret mechanisms difficult to access.

2. Operable - The interface and the elements that make it up; navigation, a video, etc. Must be operable, that is, the user must be able to interact with them with his tools; keyboard, mouse or special devices.

3. Understandable - The information must be understandable, easy to understand. Do you remember what I was asking before?

4. Robust - The content must be robust, so it can be interpreted by different browsers and assistive technologies and we need to ensure that we do not use a technology that is not well supported.

Level AAA is very restrictive in many ways, so it is commonly accepted as a good practice to meet level AA but working towards level AAA, so even if you don’t have any minimum required, you can start with the AA.

WAI-ARIA

As we said, the WAI not only defines the WCAG standards but also creates other guidelines and specifications, such as ARIA (Accessible Rich Internet Applications). These are a series of resources and techniques to make complex web applications accessible, since it usually happens that as we increase the complexity of our interfaces, we tend to move away from web standards and consequently accessibility get harmed.

Following WAI-ARIA proposals can help us to create web applications that comply with WCAG recommendations and guidelines, either because we are going to provide extra information to our elements or because we are going to apply techniques correctly to fix our site. In any case, ARIA techniques do not have to be applied only to complex websites with AJAX or a large amount of JavaScript, we could have a static site in which the HTML markup of its pages are not correct.

<!-- Incorrect usage -->
<div onclick="myFuncion()">Button</div>

<!-- Correct usage Using WAI-ARIA -->
<div role="button" onclick="myFuncion()">Button</div>

👉 ARIA is not only aria-* attributes but also role attributes.

Rules of ARIA

1. First rule

   If there is an HTML element or semantic attribute or an implicit behavior like the one you need, use it instead of doing it from scratch on your own.

   For example, you can use details and summary to create an accordion instead of using div with role added. If you need a table, use table instead of div with roles.

2. Second rule

   Do not change the implicit (native) semantics unless strictly necessary.

   For instance, h1 has an implicit role of type heading and it has a strong semantic meaning (and weight) to indicate that it is the main heading of the page, that is, it has a purpose for which it was defined, and it makes no sense to change it to make it pass for another element. In that case surely there is another element.

3. Third rule

   All interactive controls should be triggered using a keyboard.

   For instance, button or a can be triggered using the keyboard, so if we make a custom component that is going to perform some action, we will have to make them comply with this principle.

4. Fourth rule

   Do not use role="presentation" or aria-hidden="true" on a focusable element.

   An element that focusable is because it needs it to be able to interact with it, so it will not be presentational, likewise, an element focusable should not be invisible to assistive technologies such as screen readers.

5. Fifth rule

   All interactive elements must have an accessible name, that is, it must be identified in some way so that the assistive technologies can recognize it.

ARIA or WAI-ARAI?

These terms are used interchangeably but refer to the same thing. On the WAI FAQ’s page, they recommend explicitly using WAI-ARIA instead of ARIA if you mean Accessible Rich Internet Applications.

What is the relationship between WCAG and ARIA?

Direct. WCAG is the set of guidelines to adhere to, and ARIA is the techniques that describe how to make use of the aria-* and role attributes to achieve this.

What guides should I read?

If you are looking for good practices or example about how to build common interface components, or how to apply ARIA, take a look at this list of patterns.

Conclusion

As we said in our previous article about accessibility, web technology is accessible by default, and now we know that it is through browsers because they follow the UAAG guidelines established by the WAI.

We also know that to comply with the WCAG guidelines sometimes it is not necessary to implement WAI-ARIA techniques to add extra information to our markup, but we have to keep in mind that as we complicate our interfaces or if we do not take care of our HTML, we will need to apply them. In any case, testing our mockup regularly is an effective way to stay calm and make sure you’re on the right way. And finally, when it is necessary to use the aria or role attributes, do it with sense, because according to the documentation “No ARIA is better than Bad ARIA”

Resources

ARIA Specification

ARIA Patterns

ARIA FAQS