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.
Basics of ARIA
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:
- Creating relationships outside of the parent-child association: HTML only allows for relationships between parent and child elements, but the associations we want to define aren’t always nested within each other. ARIA let’s us define element relationships outside of this constraint.
- Defining advanced controls and interactivity: HTML covers many basic UI elements, but there are many more advanced controls that are used around the web that are hard to define outside of their visual component. ARIA helps with that.
- Providing access to “live” area update attributes: the
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.
ARIA and Web Applications
Before, we had 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 more 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.
Controlling Live Updates with Buttons
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 it clear what the use of the buttons are using aria-label and HTML . 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:
ARIA Popups and Hover Tooltips
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 before using an appropriate role, like this:
There are a few issues with this implementation though. Users may not 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:
Tooltip text
Accessible Input Tooltips
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.
To correct for this, we’ll wrap our tooltips within their own elements. Each of these can be nested near their related input, have their relations established with ARIA, and then can be triggered with JavaScript (or just CSS if you’re crafty).
Here’s how that could look:
Status Alerts
“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 this type of status alert up like this:
Creating a Toolbar
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 aria-pressed attribute.
When using the aria-pressed attribute, its important to note that you’ll have to update these elements as the user interacts with them. This will likely require changing the attributes through JavaScript or jQuery.
Here’s what our toolbar code looks like:
Adding ARIA to Your Own Web Apps
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!
Leave a Reply