A Look Into: ARIA Web Standards & HTML Apps Accessibility

A truly open and inclusive web needs technologies that allow disabled users relying on assistive technologies to enjoy dynamic web content and modern web apps. W3C’s accessibility web standards aim to populate the web with Accessible Rich Internet Applications (ARIA) that users with disabilities can efficiently use.

ARIA is one of the numerous accessibility standards and guidelines published by the Web Accessibility Intitiative (WAI). It provides an additional markup that can be easily inserted into HTML documents. WAI-ARIA is a cross-platform an cross-device solution that targets the Open Web Platform, so don’t only think about websites, but also about games, digital entertainment, healthcare, mobile, and other kinds of apps.

In this post we will take a look at how you can add accessibility to your HTML documents with the help of WAI-ARIA standards.

The ARIA Framework

The syntax of HTML doesn’t always allow developers to describe elements properly, to identify their roles, and specify the relationships between them.

While that’s rarely a problem for visitors who are in full possession of their senses, it can impede assistive technology users from understanding what’s happening on the screen and exploring their options.

This is the point where ARIA comes to our help, as it makes possible to define the purpose of different elements with the help of landmark roles, and describe their nature with aria-prefixed attributes.

Aria-prefixed attributes have two types: properties that describe features that are less likely to change throughout the page life-cycle, and states that provide information about things that may frequently change due to user interaction.

Landmark Roles

Landmark roles are the most well-known forms of ARIA’s Roles Model (others are the Abstract Roles, the Widget Roles, and the Document Structure Roles). Landmark roles enable developers to identify large perceivable regions on the web page that assistive technology users may want to quickly access.

There are 8 types of ARIA landmark roles, and they need to be added as attributes to the related HTML tags.

role=”banner”

The banner role is intended to be used mainly for content that is related to the entire site, not just to individual pages. It’s usually added as an attribute to the main header of the site for the logo and other important site-wide information.

It’s important that you can use the banner role only once within any HTML documents or apps.

role=”main”

The main landmark role is related to the main content of the document. It can’t be used more than once on any HTML page. It usually follows the <div role="main"> syntax, or in HTML5 the more semantic <main role="main">. The latter was added to the W3C specs with the purpose of mapping the main ARIA landmark role to a semantic HTML element.

role=”navigation”

The navigation role is meant to be used for indicating an area that contains navigational elements such as links and lists on a site.

role=”complementary”

The complementary landmark role describes additional content that is related to the main content of the site. It needs to be placed to the similar level in the DOM hierarchy as role="main". Related posts, popular articles, latest comments are typical examples of autonomous complementary content.

role=”contentinfo”

The contentinfo role informs user agents about the presence of a region where different kinds of metadata, such as copyright info, legal and privacy statements can be found. It’s typically used for the footer of a site.

role=”form”

The form landmark role indicates a form waiting for user input. For search forms you should use role="search" instead.

role=”search”

The search role is pretty self-explanatory, it’s intended to help assistive technologies identify the search functionality of a website.

role=”application”

You can use the application landmark role for a region that you want to declare as a web app, rather than a web document. It’s not recommended to include it in traditional websites, as it hints to assistive technologies to switch from normal browsing mode to application browsing mode. You should only use this landmark role with great care.

States and Properties

While roles enable you to define the meaning of HTML tags, states and properties provide the user with extra information on how to interact with them. Both states and properties are marked with aria-prefixed attributes with the syntax aria-*.

The most well-known ARIA attributes are probably the aria-required property and the aria-checked state. Aria-required is a property because it’s a permanent feature of an input element (i.e. the user must fill it in), while aria-checked is a state because a checkbox may frequently change its value due to user interaction.

The Syntax of Aria-prefixed Attributes

States and properties sometimes take token values (a limited set of predefined values), for instance the aria-live property can have 3 different values: off, polite, assertive. The syntax in this example looks like this: <div id="some-id" class="some-class" aria-live="assertive"><div>.

In other cases the values of aria-prefixed attributes are represented by strings, numbers, integers, ID references or true/false values.

How to Make Use of ARIA States and Properties

1. Build Relationships Between Elements With Relationship Attributes

Use relationship attributes to indicate relationships between different elements on your site, that can’t be otherwise determined from the document structure. For example the aria-labelledby property identifies the element that labels the current element.

aria-labelledby – among many other things – can bind headings to ARIA landmark regions in the following way:

<div role="main" aria-labelledby="some-id">

	<h1 id="some-id">This Is A Heading</h1>

	Main content...

</div>

2. Synchronize States and Properties With The Element’s Lifecycle

After you set an ARIA landmark role for a perceivable area on your HTML page, it can help assistive technologies a lot if you change the ARIA-prefixed states and properties of child elements in accordance with events happening on the screen.

This can be crucial where users have to interact with the site, for example filling in a form or running a search query.

3. Match The Visual and The Accessible Interfaces

The general rule of thumb of accessibility design is that the current state of the user interface always needs to be perceivable by assistive technologies. For instance if the user chooses an option in a form, it needs to appear selected for assistive technologies too.

This can be easily achieved by utilizing the aria-selected state with the following syntax: <option aria-selected="true"></option>.

W3C’s WAI-ARIA Authoring Practices guideline can give you many other great ideas about how to properly harmonize the visual and the accessible interfaces of your site.

Don’t Overuse ARIA

Using ARIA roles and attributes sometimes can be redundant. When you use semantic tags of HTML5 such as <button></button> or <form></form>, modern web browsers add the appropriate ARIA semantics by default. In this case it has no sense to separately set the ARIA landmark roles.

For example it’s unnecessary to use the form landmark role to define the <form> element. Instead of the <form role="form"></form> syntax it’s perfectly enough to use just <form></form>. It’s also superfluous to use HTML’s native attributes along with the appropriate ARIA attribute.

So if you’ve already added the hidden HTML attribute to a form input, it’s unnecessary to add the aria-hidden state, as the browser includes it by default.