Skip to content

Latest commit

 

History

History
152 lines (92 loc) · 6.58 KB

README.md

File metadata and controls

152 lines (92 loc) · 6.58 KB
Raw

Introduction

Accessible Rich Internet Applications (ARIA)

ARIA attributes have been designed as a tool to make web content and applications more accessible to end users with disabilities. They provide information that can be used by assistive technology (such as screen-readers) and are often seen prefixed in HTML with aria- or describe a role for an element. In short: ARIA helps to fill any gaps that Semantic HTML doesn't fill implicitly.

The information assistive technologies need about the meaning and purpose of user interface elements is called "accessibility semantics".

The W3C Working Group have created a set of authoring best practice notes to help guide developers. ARIA is a pretty extensive area to explore, and something you'll use on a regular basis. In this guide we'll cover some of the key areas to be aware of.

Contents

  1. Types of ARIA
  2. Principles
  3. Examples
  4. Useful Tools
  5. Bibliography

Types of ARIA

ARIA consists of three component types: Roles, states, and properties. States and properties (often collectively just referred to as "attributes") exist to help define roles in more detail.

Roles

This is a static description of what an element does (so it doesn't change). For example <a role="button">Order pizza</a>.

States

States describe the current condition of an element on the page, and can change (either with or without user interaction). Examples of states are aria-checked and aria-disabled.

Properties

Properties describe what an element is, and are less likely to change once set. Examples of properties are aria-label and aria-describedby.

Principles

Poorly implemented ARIA can be detrimental to assistive technology users. W3C specify two key principles to help developers:

Principle 1: A role is a promise that an action will take place, where it would otherwise not be obvious to a browser.

For example the following being used as a tab. This would not usually appear as a button to the user but it would appear as a button to screen-readers if a role of 'tab' had not been assigned.

<button role="tab">Tab</button>

Principle 2: ARIA attributes can both cloak and enhance information.

While ARIA attributes can improve experience for assistive technology users, incorrect attributes or values can achieve the opposite. Some examples of this in practice:

<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">Link Text</a>

<table role="log">
    <!--
    Table that assistive technology users will not perceive as a table.
    The log role tells browser this is a log, not a table.
    -->
</table>

Conversely, when used correctly ARIA can provide essential context to a component:

<button aria-pressed="false">Mute</button>

You should therefore avoid overriding default roles or adding redundant roles, and be cautious of potential side effects.

Device support

As you would expect from any web technology, device or software support can't be considered to be universal. Different operating systems, browsers, and even versions of the assistive technologies themselves can contribute to partial or complete lack of support.

For this reason, while emulated/automated testing is beneficial at a development level, it's important to test ARIA with actual assistive technology before release.

Examples

Below are a few commonly used attributes and what they achieve. You can view a more comprehensive list here.

button role

The button role is for clickable elements that trigger a response when activated by the user. Adding role="button" tells the screen reader the element is a button, but provides no button functionality. Use
<button> or
<input> with type="button" instead.

<div tabindex="0" role="button" aria-pressed="false">Send message</div>

aria-label

The aria-label attribute is used to define a string that labels the current element. Use it in cases where a text label is not visible on the screen. If there is visible text labelling the element, use aria-labelledby instead.

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

aria-labelledby

The aria-labelledby attribute establishes relationships between objects and their label(s), and its value should be one or more element IDs, which refer to elements that have the text needed for labelling.

<div role="dialog" aria-labelledby="dialogheader">
    <h2 id="dialogheader">Choose a File</h2>
    ... Dialog contents
</div>

aria-hidden

Adding aria-hidden="true" to an element removes that element and all of its children from the accessibility tree.

This is especially useful for decorative content, or offscreen content such as modals or menus. It's worth noting that aria-hidden="false" however can perform inconsistently across browsers.

Useful Tools

W3C provide a helpful table of HTML elements, their implicit ARIA semantics, and their allowed roles.

a11ysupport.io allows you to search by ARIA attribute or HTML element and see support across different assistive technologies and browsers.

Bibliography

An overview of ARIA support

Screen reader compatibility

Using ARIA: Roles, states, and properties

What the Heck is ARIA? A Beginner's Guide to ARIA for Accessibility

Global States and Properties