In the confusing world of web applications, ARIA can help improve accessibility and ease of use for your creations. HTML isn't able to handle many types of relationship between elements on the page, but ARIA is ideal for almost any kind of setup you can come up with. Let’s take a look at what ARIA is, how it can apply to your web app, and some quick recipes you can use for your own sites.
ARIA, also called WAI-ARIA, stands for the Web Accessibility Initiative–Accessible Rich Internet Applications. This initiative, updated by the W3C, aims to give developers a new set of schemas and attributes for making their creations more accessible. It specifically aims to cover the inherent gaps left by HTML. If you’re not familiar with what it does already, you should take a look at our primer on ARIA. You might also be interested in our pieces on ARIA for the Homepage and ARIA for eCommerce.
Briefly, though, ARIA has three main features that we'll be focusing on:
aria-liveattribute gives screen readers and other devices a listener for when content on the page changes. This allows for easier communication of when on-screen content changes.
Before, we looked at adding ARIA to the common elements of eCommerce pages and site homepages. With web apps, however, each one differs drastically from the last. Forms and functions shift between each app, and often even between versions of the same app. Because of this, we’ll treat our implementations here like recipes in a cookbook rather than a wholesale conversion of a page.
When it comes to web apps, a user’s intent is more difficult to discern in a generalized sense. With eCommerce, no matter which site you are on, it is likely that the visitors are looking to purchase a product or service. Web apps serve a variety of purposes, so instead, we’ll focus on creating nuanced controls that are accessible and user friendly.
Let’s get into some of these control types.
The first control we’re going to look at is a displayed value updated by a button press. These types of controls are commonly seen where an element is displaying a quantity that may be adjusted by buttons labelled ‘+’ and ‘-’, but can take many forms, such as arrow buttons that let you cycle through predefined statuses.
A standard implementation can leave some gaps in understanding for the user. It is unclear what elements the buttons affect, how they affect them, and when the element’s value changes.
Below, we’ll use ARIA to create a connection between the buttons and the value display element using the
aria-controls attribute. Then, we’ll make the use of the buttons clear by using
aria-label and HTML
<label>. Finally, we’ll utilize the aria
alert role and the
aria-live attribute to let our user know when the value is being updated.
Let’s take a look at what that code looks like:
<form action=""> <fieldset> <legend>Adjust Quantity</legend> <div> <label for="qty-element">Current Quantity</label> <input type="text" role="alert" aria-live="assertive" value="0" id="qty-element" /> <button type="button" aria-label='Add to Quantity' aria-controls="qty-element">+</button> <button type="button" aria-label='Subtract from Quantity' title="subtract 10" aria-controls="qty-element">=</button> </div> </fieldset> </form>
When outfitting a site with ARIA, it is common to use "progressive accessibility". The idea behind this term is that taking a site or web app from its basic form to fully accessible is a daunting task. To deal with this in a way that still makes forward movement, you can implement new features progressively and iteratively.
For a tooltip with a related popup or modal, this means that we can break the problem into two steps, rolling each out as we can. In this case, the tooltip we’re talking about is the common image of a small question mark that opens additional information when hovered over.
To let users know that the question mark image is actually a tooltip, we’ve defined it by using an appropriate role, like this:
<img src="question-mark.jpg" role='tooltip' />
There are a few issues with this implementation, though. Users may still not be aware that hovering over the tooltip initiates a popup with further information. Here’s how we can add that to our code:
<img src="question-mark.jpg" role='tooltip' aria-haspopup='true' aria-controls='tooltip-popup' /> <div id='tooltip-popup' aria-hidden='true'> Tooltip text </div>
Instead of a hover-based tooltip, it’s also common for a web app to utilize forms where each input has its own associated tooltip.
Without additional ARIA markup, it can be difficult to tell which tooltips apply to which input for a user. Not having this relation in place can render your helper text useless in some cases.
Here’s how that could look:
<form action=""> <fieldset> <legend>User Login</legend> <div> <input type="text" id="user" aria-describedby="user-tip" /> <label for="user">Your Username</label> <div role="tooltip" id="user-tip">Tooltip about their username</div> </div> <div> <input type="password" id="password" aria-describedby="password-tip" /> <label for="password">Your Username</label> <div role="tooltip" id="password-tip">Tooltip about their password</div> </div> </fieldset> </form>
“Our service is currently down”, “Your account is suspended”, and related status alerts are commonly used among web apps, and display important information for users. Without ARIA, they can get buried within the information on a page and cause a variety of issues.
Utilizing the ARIA
alert role and the
aria-live attribute, we can make sure that our users are aware of any issues quickly once they arrive on a page.
We can set up this type of status alert like this:
<div id="system-status" role="alert" aria-live="assertive"> <p>The system is offline!</p> </div>
Finally, let’s take a look at another common control element used within web apps: the toolbar. For our purposes, we’re going to be marking up a toolbar that works like this: our web app shows a large amount of data, oriented in a table. Above this table, our toolbar has several buttons that allow users to sort the table in various ways. These buttons include classic sort options such as A to Z and Z to A.
Relationally, these leave some problems concerning accessibility. First, it isn’t clear that those buttons affect the table—we’ll solve this using the
aria-controls attribute. It also isn’t clear that the buttons are associated with each other, which may be a useful piece of information for our users. To define this, we’ll be using the
toolbar role. Finally, a user doesn’t necessarily know which button was pressed last. To correct this, we’ll use the
When using the
Here’s what our toolbar code looks like:
<div role="toolbar" aria-label="Sorting Toolbs" aria-controls="data-table"> <button type="button" aria-pressed="false" aria-label='Sort Alphabetically, A to Z'>A to Z</button> <button type="button" aria-pressed="true" aria-label='Sort Alphabetically, Z to A'>Z to A</button> <button type="button" aria-pressed="false" aria-label='Sort Numerically'>Numerical</button> </div> <table id='data-table'> ... </table>
With this handful of new control schemes and relations under your belt, you’re well on your way to making your own web app fully accessible! After you’ve added these new markups in, think about how you could apply these attributes to other parts of your user interface to maximize the usability of your creation.
Are there attributes, roles, or other features of ARIA that you’d like to know about? Or maybe you have some questions about your own implementations, or corrections for this article? Get in contact using the comment section below, or by tagging kylejspeaker on Twitter!