ARIA: singing from the same hymn sheet 💻

05 Apr 2020

3 min read

Nope. Not that kind of aria!

What is ARIA?

We’re talking about accessibility!

Accessibility refers to the creation of digital content that can be used by everyone.

The W3C documentation is not easy reading, but finally I have read through the specification and guides to understand it properly for myself.

Tell me already

If you create your own whizz-bang Date Picker, how will a screen reader know what it is?

You need to tell it with ARIA (Accessible Rich Internet Applications).

ARIA is a World Wide Web Consortium (W3C) specification with the aim of improving accessibility for modern web applications, in particular for dynamic content and custom user interface (UI) controls. It defines a set of attributes that can provide additional semantics to elements.

ARIA has no effect on how elements are displayed or behave in browsers. Its purpose is to provide extra description for Assistive Technologies (ATs) when needed.

Use Cases

The most common Use Cases for ARIA are:

Assist in identifying the major regions of your page to make navigation easier (these are called landmarks);
Identify and describe a custom UI control;
Tell a user when you are loading dynamic content;
Alert a user when something important pops up;
Tell screen readers when the state of the page changes.

ARIA is our last stop for accessibility, the previous post spoke about what you should be doing already.

Rules of ARIA

The W3C made some rules to help you use ARIA properly.

The first rule of ARIA is, do not use ARIA, if possible!

These are the rules:

If you can use a native HTML element or attribute with the semantics and behaviour you require already built in, then use it!
Do not change native semantics, unless you really have to. If you give a div a role="button", there is no ‘hey presto, now I am button’ moment. It does not have all of the typical keyboard events you associate with a button.
HTML
```
<div role="button">Faker</button>
```
All interactive ARIA controls must be usable with the keyboard. For example, if you use role=button, the element must be able to receive focus and a user must be able to activate the action associated with the element using both the enter (on WIN OS); or return (MAC OS) and space.
Do not use role="presentation" or aria-hidden="true" on a focusable element .
All interactive elements must have an accessible name. We must label them. We discuss it more in Labels.

Features

There are three main features of ARIA:

Roles — These define what an element is or does.
Properties — Properties are attributes that are inherent to an object. Properties are less likely to change than states, but that is not a rule. For example, aria-label="signup form" gives a form an accessible name.
States — A state is a property of an object that may change in response to user action or automated process. For example, aria-disabled="true" specifies that the element is currently disabled.

The distinction between states and properties is not great, they both are attributes prefixed with “aria-”. It is of little consequence to most web content authors which is which, so you may see them simply referred to as attributes. I will speak about them together later.

Labels

If you write HTML well, you probably have a label for each input and button. Nothing else needs to be done for them if you do that.

There are other cases when you need to label an element, and thats when ARIA steps in.

You may want users to be able to navigate to your form, when we add an aria-label, screen readers identify it as a landmark. We try to keep the text in the label short.

HTML

<form aria-label="product feedback">
  ... content ...
</form>

For a longer label, we can use aria-labelledby to point to a heading, or another element.