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:
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.
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.
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:
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.
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.
Understandable - The information must be understandable, easy to understand. Do you remember what I was asking before?
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.
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.
<!-- 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
Rules of ARIA
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
summaryto create an accordion instead of using
roleadded. If you need a table, use
Do not change the implicit (native) semantics unless strictly necessary.
h1has an implicit role of type
headingand 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.
All interactive controls should be triggered using a keyboard.
acan 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.
Do not use
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.
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
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.
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
role attributes, do it with sense, because according to the documentation “No ARIA is better than Bad ARIA”
ARIA FAQScomments powered by Disqus