Accessible Accessibility
By: Gustavo Siñovsky
Tags: Accessibility, UX Design

About 15% of the world’s population lives with some form of disability, of whom 2–4% experience significant difficulties in functioning. With the current ubiquitousness of the Internet, it’s become more and more important to translate the need for accessible tools into the virtual world.

When talking about accessibility oriented to web applications, it relates to the design of digital content so it can be used by everyone, inclusive of those with (varying) limitations of the following abilities:

Visual : blindness, low vision, and color-blindness

: blindness, low vision, and color-blindness Motor : reduced ability to use a mouse, slow response time, limited fine motor control

: reduced ability to use a mouse, slow response time, limited fine motor control Auditory : profound deafness and hard of hearing

: profound deafness and hard of hearing Cognitive: learning difficulty, easily distracted, an inability to focus on large quantities of information or data

So where to begin? If you are working on a large project and you are tasked with increasing its accessibility reach far into its development lifetime, it can be daunting to try figuring out where to start. When I found myself in this very same situation, I had to sift through several heavily dense — not so easy to read — articles to try understanding where the basics are at.

This article aims to help to provide a clean and very simplified summary of basic guidelines, which, when properly applied, make up for a decent effort when it comes to making a web application accessible to everybody.

Basic concepts

First, let’s kick off with the basest of concepts.

ARIA: the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.

Assistive Technologies: assistive, adaptive, and rehabilitative devices for people with disabilities or the elderly population.

In practice, ARIA is a set of special HTML attributes and rules that help assistive technologies interpret and understand better your application, so in turn, people employing them will make better use of the app. The most common are role , aria-label and tabindex . The latter, although not officially an ARIA attribute, it’s very helpful in making an element keyboard focusable.

Principles

How to apply these concepts? Here are several principles to follow:

A role is a promise

<div role="button">Place Order</div>

The code above is a promise that the author of that <div> has also incorporated JavaScript that provides the keyboard interactions expected for a button. To fulfill the promise requires you to replicate all the interactions builtin in the native <button> tag. This is why always it’s best to use the native HTML tags, whenever possible.

ARIA Can Both Cloak and Enhance, Creating Both Power and Danger

Some of ARIA is like a cloak, it covers up or overrides, the original semantics or content.

<a role="menuitem">Assistive tech users perceive this element as an item in a menu, not a link.</a> <a aria-label="Assistive tech users can only perceive the contents of this aria-label, not the link text">Very Important Link Text</a>

The most important rule to follow is to use native HTML at all times, unless it’s absolutely, impossible to make an element accessible otherwise. This is because the native elements already come with accessibility considerations builtin, so in most cases, no extra work is necessary.

Do not change native HTML semantics unless you absolutely have to. In almost all cases, native HTML will work just fine.

Instead of:

<span role=“button” onClick=“submitForm();”>Submit</span>

Do this:

<button type=“submit” onClick=“submitForm();”>Submit</button>

All interactive ARIA controls must be keyboard accessible.

<div tabindex=“0”>This is going to be focused when hitting tab on the keyboard</div>

For all elements that are focusable, do not ever add role=“presentation” or aria-hidden=“true”, which are used to let assistive technologies know what elements of the site are safe to disregard, since they offer no semantic meaning, and are merely presentational.

Use labels to increase expressivity

Start by giving all interactive elements an accessible name.

Instead of:

<input type=“text” id=“search” />

Do this:

<label for=“search”>Search</label>: <input type=“text” id=“search” />

Or:

<input type=“text” id=“search” aria-label=“Search” />

No ARIA is better than Bad ARIA

As we saw, ARIA attributes can be also used to mislead the user, so one rule of thumb is to never use ARIA if we’re not sure of it. In these cases is best to use native elements. However, is very easy to recognize when to properly apply the basic ARIA concepts.

When to use ARIA

Describing labels: when you need to add more descriptive labels to HTML elements like buttons or links (i.e. Read More, Learn More, etc.), you can use the ARIA aria-label to accomplish this:

Before:

<a href=“/path/to/your/page”>Read More</a>

After:

<a aria-label=“Click here to read More about this very important topic” href=“/path/to/your/page”>Read More</a>

Alerts: in order for events to get announced to screen readers, you must add ARIA live regions and alert messages to those elements for them to be detected and read aloud.

Before:

<div class=“alert-message”>You’ve successfully completed the contact form and you will soon receive a confirmation email.</div>

After:

<div class=“alert-message” role=“alert”>You’ve successfully completed the contact form and you will soon receive a confirmation email.</div>

Relationships: to create a relationship between elements (parent/child), you’ll need to add ARIA attributes to each of the elements.

<nav id=“main-nav”>

<button id=“menu-button-1” aria-haspopup=“true” aria-controls=“menu-list”>Menu List</button>

<ul id=“menu-list” role=“menu” aria-labelledby=“menu-button-1”>

<li role=“none”><a role=“menuitem” href=“...”>Link1</a></li>

<li role=“none”><a role=“menuitem” href=“...”>Link2</a></li>

<li role=“none”><a role=“menuitem” href=“...”>Link3</a></li>

</ul>

</nav>

Explicitly describe visual elements: In the example below, a button is styled to look like a typical “close” button, with an X in the middle. Since there is nothing indicating that the purpose of the button is to close the dialog, the aria-label attribute is needed to provide semantic meaning to any assistive technologies.

<button aria-label="Close" onclick="myDialog.close()">X</button>

Tools

There are many tools to help you audit the accessibility of your web application.

I want to highlight the simplest of them all. Already builtin in Chrome, there is the Accessibility Tree, which shows you what an assistive technology see when reading your app:

This is the easiest way of understanding how accessible your application is. The aXe extension it’s also a great starting point when improving the accessibility of a big application since it automates the process of checking for many basic rules of accessibility.

More resources

If you want to dive deeper into this topic, I highly recommend the A11ycasts with Rob Dodson, a series of easily digestible videos teaching the fundamentals of web accessibility. An article by the creators can also be read here.