WAI ARIA

Learning Goals

• Review ways we already make websites accessible
• Be able to use the three different types of ARIA attributes
• Determine when ARIA is and is not needed to make websites more accessible

Vocab

• Accessibility Broadly, creating an experience that is available to anyone and everyone
• ARIA Accessible Rich Internet Applications
• Role The function an element serves on the page. “What is this element?”
• State The state of an element on a page (e.g., expanded, disabled). “What is the status of this element?” (Boolean, changes and must be updated/kept current with JS as application is used)
• Property Additional information about an element or other elements its related to. “What other info is important about this element?”

WAI-ARIA

Web Accessibility Initiative - Accessible Rich Internet Applications.

WAI-ARIA is a set of attributes we can add to our HTML tags to make our code more semantically meaningful for screen readers.

Think about the information provided by a set of <div></div> tags. What do we know about the content within those tags? Really, we know nothing. It’s a semantically void element that controls the APPEARANCE of its content - by default it is a block style element, but beyond that it could theoretically be literally any kind of data - a title, a paragraph, an image, a random red decorative sidebar…etc.

ARIA provides a series of tools and approaches to enhancing the meaning of your code. Today we will look at the three main aspects of ARIA - Roles, States, and Properties.

• Roles
• States
• Properties

An element can only have one role at a time, but can have as many properties and states as necessary

An important point about WAI-ARIA attributes is that they don’t affect the appearance or functionality of a web page, except for the information exposed by the browser’s accessibility APIs (where screen readers get their information from). WAI-ARIA doesn’t affect webpage structure, the DOM, etc., although the attributes can be useful for selecting elements by CSS.

Rules of ARIA Use

The core rules to keep in mind when using ARIA are:

If you can use native HTML elements and attributes to communicate the proper semantics (like <header>, <nav>, <main>, <footer>, <button> etc.) and then do so. Adding ARIA support where it’s not needed is redundant code that isn’t doing anything. For the most part it won’t lead to problems, but it is a waste of time, and will annoy your screen reader users.

Many “accessibility flags” come from developers overusing ARIA. Only use ARIA as a last resort!!

Aria Roles, States, and Properties

Roles

Roles define what an element is - what function it serves on the page. They give screen readers more information about how to interact with the element (What am I?)

These can be either implicit or explicit.

Implicit roles are those that are pre-defined by default in HTML. Ie: <h1></h1>, <button></button>, <ul></ul>. The semantic meanings of these elements are already clear by the element themselves and assistive technologies have this information too.

If you are writing good semantic HTML, the role will likely be implicit. Remember you can always check the role here

Implicit Role Example:

<h1>Hello World</h1>
<!-- The above markup has an implicit role of "heading level 1" -->

<nav></nav>
<!-- The above markup has an implicit role of "navigation" -->

Explicit Role Example:

<form role='search'></form>
A form element has a role of 'form' by default. We can override that role using the `role` attribute and providing it another value. Like in the case above where we are using the role of search.

States

States describe how you are interacting with an element (What am I doing right now?) and rely on boolean logic.

For example, think about websites that have a sidebar menu that can be toggled open or closed. You might see something like this:

<button>
  Toggle Menu
</button>

Here we have a button with text that says “Toggle Menu”, probably indicating that when you click on said button it will toggle the menu open or closed.

What this doesn’t tell you is if the menu is already open or closed, which is fine if you are a sighted user, but probably not great if you use assistive technology.

Luckily ARIA provides state information that we can add to our markup.

<button
  id="menu-button"
  aria-expanded="true"
>
  Toggle Menu
</button>

let button = document.getElementById("menu-button");

button.addEventListener("click", function() {
  let attr = button.getAttribute("aria-expanded");

  if (attr === 'true') {
     button.setAttribute("aria-expanded", false);
  } else {
     button.setAttribute("aria-expanded", true);
  }
});

This also allows you to target these elements using the aria-expanded attribute when interacting with them in your JavaScript or CSS.

States can also be implicit, imagine a checkbox element in html. If you toggle the checked property that state will change as well.

Properties

Properties give an element special characteristics that you can relate to other documents or elements.

For example, take the button we mentioned when discussing states. That button specifically controlled the sidebar-menu, but what if there are multiple menus that have similar buttons? ARIA lets us add additional properties that link elements together.

<button
  aria-expanded="true"
  aria-controls="sidebar-menu"
>
    Toggle Menu
</button>

<nav id="sidebar-menu">
  <!-- ...nav code here... -->
</nav>

The aria-controls property has a value of the ID of the element it is attached to. So in this case, we see that there is <nav> element with an id of sidebar-menu that is controlled by this button.

You can also use something called an aria-label property. Think of this like an alt tag for accessibility - this property allows you to enter additional text that provides more information to the user. This information won’t show up on the page but will be read by the screen reader.

<button
  aria-expanded="true"
  aria-controls="sidebar-menu"
  aria-label="Close sidebar navigation menu"
>
    Toggle Menu
</button>

You can then use JavaScript to keep this information up to date - for example, once aria-expanded="false", you’d set your aria-label to "Open sidebar navigation menu".

NOTE: Use aria-label with caution. The screen reader will now REPLACE whatever exists as the default button text and instead read the aria-label content.

Other Properties

• aria-label - Described above. Provides additional information about an element.
• aria-required - Tells a user if they need to provide input on an element before a form is submitted.
• aria-controls - Seen above. References an element that is controlled by the current element.
• aria-labelledby - Sister to aria-label, references the ID of another element, which is a short title for the element.
• aria-describedby - is just like aria-labelledby – but is meant for longer descriptions instead of short titles. This is read after the field-type is stated

Accessibility in Practice Moving forward

• Most of the above mentioned aria attributes should be used sparingly.
• The time to use them is if the answers to the following questions are yes:
  • Will sighted users see content that people with visual disabilities cannot?
  • Is there information about that content that screen readers might need that isn’t already indicated in the HTML tags that make it up?

Below are some things that you should ALWAYS incorporate in your web applications

meh...
<img src="mountain.jpg" alt="mountain">

yes!
<img src="mountain.jpg" alt="The cascade mountains at sunset in January">

<a class="facebook-icon" aria-label="Link to Facebook"><a/>

<html lang="en">
</html>

<h1 lang="es">¿Donde está la biblioteca?</h1>

<label for="firstName">First name</label>
<input id="firstName" type="text" placeholder="Clementine">

<input type="text" aria-label="First name" placeholder="Clementine">

Additional Resources

• MDN Documentation
• Aria Documentation
• Aria Examples & Design Patterns
• Web Accessibility in Mind
• 9 Tools for Website Accessibility Testing

Tools

• aXe Chrome Plugin
• ChromeVox Plugin
• Colorblind
• Screen Reader Plugin

Videos

• Aria Roles, States, and Properties
• ARIA, Accessibility APIs and Coding Like You Give A Damn!
• describedBy vs labeledBy video
• History of Accessibility Tech