Assistive devices, like screen readers, need to understand web content and applications before they can communicate the information to persons with disabilities. Much of the time the HTML we write provides those semantics. Sometimes it doesn’t, and that’s where WAI-ARIA comes in.
For the last few weeks I’ve been talking about accessibility. I shared my thoughts as I approached the series, tried to define what accessibility is and means. and then walked through the Web Content Accessibility Guidelines (WCAG 2.0). Here’s the series up to this point.
- A Journey Into Web Accessibility
- What Does It Mean To Develop Accessible Websites?
- WCAG 2.0 — Accessibility Principles And Guidelines
- WCAG 2.0 — Criteria And Techniques For Successful Accessibility Conformance
As you can probably guess from the first paragraph, today I want to talk about ARIA, more specifically the Web Accessibility Initiative for Accessible Rich Internet Applications, otherwise known as WAI-ARIA.
Consider today an introduction. I want talk about some basic ideas and concepts and then walk you though an example using ARIA. I think the example helps explain the reasons for using ARIA.
Over the next few weeks, I’ll dig a little deeper into ARIA specifics and point you to resources for the complete details.
Introduction to WAI-ARIA
For web content to be accessible, it must convey semantic information about its structure and behavior to assistive devices. WAI-ARIA exists to convey the semantics when native HTML isn’t enough.
Working with ARIA isn’t any different than adding markup to a line of text to convey to a browser that the text is a level 2 heading or a list item inside an ordered list or a checkbox. The WAI-ARIA spec defines a number or roles, states, and properties that you can use to markup your document and deliver the appropriate semantic information.
Like many of the documents guiding us in creating accessible sites, and like HTML itself, the ARIA spec is ultimately a list of markup that you’ll slowly memorize as you begin to use it.
There are far too many roles, states, and properties to try to do justice to them in a post or series. My goal is once again to offer an overview of ARIA and then point you in the right direction for more learning and reference.
Speaking of more, Šime, pointed me to an article that offers a very good introduction to WAI-ARIA. I’ll cover much of what the article discusses over the next few weeks and I recommend giving the article a read.
Roles, States, and Properties
ARIA allows you to add semantics that override those that HTML elements and their attributes provide natively. It allows you to add semantic meaning when developing something in a non-standard way. For example using a div or span to create a button.
ARIA offers three ways to communicate semantics.
- roles define the component’s purpose in the interface
- properties define characteristics of the component
- states define the current conditions of the component
Together states and properties are called ARIA attributes and they all start with aria- as in the aria-checked state, which can be set to true or false. Either states or properties can be used to show that something about the component has changed.
Again, when the native semantics of the HTML being used aren’t enough you should add the appropriate roles, states, and properties that communicate the necessary semantic information to assistive devices.
An Example of WAI-ARIA in HTML
Before diving into roles, states, and properties over the next few weeks, I want to present a simple example that makes use of all three. I think the example will be easy enough to follow and I think it will provide some useful context for the deeper look.
Here are a couple lines of code you might use to develop a checkbox as a required form field. No ARIA is used, but the code still communicates important information to assistive devices.
<input type="checkbox" id="check" required="true" /> <label for="check">Check Me (required)</label>
An input with type=“checkbox” communicates its role in the interface as a checkbox and with it come some properties and attributes that can be set with HTML such as required (property) or checked (state). Since the checked attribute isn’t set, the default state of the checkbox is unchecked.
I added the HTML5 required attribute and the word required in the label to indicate the checkbox must be checked. Maybe it’s a checkbox to show you’ve read the terms and conditions of something.
Not all browsers support the required attribute, but for those that do, which includes some screen readers, this code conveys the necessary semantic information. It has a role, a property, and a state, and the label uses a for attribute to indicate it goes with the input.
We might start with code like this:
<span id="check"></span> <label for="check">Check Me (required)</label>
We’ll use ARIA to convey the semantics. Let’s start by adding a role of checkbox.
<span id="check" role="checkbox"></span> <label for="check">Check Me (required)</label>
Now assistive devices will understand this span should be treated as a checkbox.
We still need to communicate that this checkbox is required and unchecked by default. We can communicate the first by adding the aria-required property and the second by adding the aria-checked state.
<span id="check" role="checkbox" aria-required="true" aria-checked="false"></span> <label for="check">Check Me (required)</label>
It’s also important to keep in mind that the reason we added ARIA to this example is because we started with an element that didn’t communicate the appropriate semantics. Had we stuck with an input of type checkbox with required and checked attributes, the ARIA wouldn’t be necessary.
As I worked my way through this series I linked to articles I think you might find helpful. Some never found there way in so I thought I would present a few additional resources.
- List of ARIA resources from Mozilla
- Designing Accessibility with HTML5
- Accessibility, Part 3: ARIA
- The WAI Forward
- Nu Html Checker
- How Dragon Naturally Speaking works with ARIA
- Open Ajax Accessibility
ARIA exists to help web designers and developers communicate semantic information to assistive devices, when the native semantics of the HTML aren’t enough. Ideally you want to stick with the native semantics, but sometimes you can’t for one reason or another.
When you need to you add the semantic information through different ARIA roles, states, and properties, depending on the specifics of your interface component.
Another reason why you might add ARIA is when no HTML element carries the proper semantics. Some roles, states, and properties are currently not available natively in HTML5 and you have to use the ARIA to communicate the semantics.
Hopefully this served as a good introduction if WAI-ARIA is new to you or a simple review if you’re more familiar. There’s certainly more to ARIA than what I’ve shown here.
Over the next two weeks I want to dig a little deeper into roles, states, and properties and look at the roles model including ARIA’s supported states and properties. I’ll finish this part of the series the following week with some general guidelines for working with ARIA.
Download a free sample from my book, Design Fundamentals.