These examples work well with traditional HTML and CSS, but in today’s modern web development, many sites are created and updated dynamically. In addition, many interactions are exactly that — interactive, meaning driven by the user’s contributions and often based on movements such as drag and drop, or timed events. These actions are difficult if not impossible to make work with traditional HTML or CSS.
To this end, the Web Accessibility Initiative (WAI) provides a series of standards that help to create accessible rich internet applications. This series of standards is called WAI-ARIA, often referred to as just ARIA.
What is ARIA?
ARIA expands design methods to make content and applications on the web accessible. Sites that use Ajax, JavaScript and other dynamic content creation benefit from ARIA. ARIA also helps make custom actions that will make it possible for users with assistive technologies to have more effective ways of communicating what is happening.
There are, of course, many ways to accomplish these tasks with native HTML and CSS, but for situations where those interactions might be difficult, ARIA allows us more options. One example is form elements with labels. These are implemented in standard HTML and can easily be “spoken” through a screen reader by providing a label. However, if a special styling is desired and the format of that styling is located within a <div> block, then the screen reader may not be able to determine what the control is (or may interpret it as text and simply read out what the text says). More importantly, it may miss the fact that it has a state that can be changed. By inserting ARIA tags into basic HTML elements, we can help clarify what the element is and how it should respond.
At the time of this writing, the W3C-recommended version of ARIA is version 1.0. There is a later version, ARIA 1.1, but it is still in draft mode and has been for several years. Most of the 1.1 features are available and in use with a variety of products, but be aware that some older assistive technologies may require ARIA 1.0 to work correctly. See https://www.w3.org/WAI/PF/aria‑1.1/ for the current draft specifications.
There are a variety of ways that using ARIA can help make sites more usable with assistive technologies, as well as encourage overall better design. ARIA tags use three main aspects to add functionality to any element: Roles define what the element is or does. States define actions that have been or can be performed within a given role. And properties describe what the state value is, or provide literal text that will be used by the assistive technology when informing the user.
Design tips
This variety of aspects can be very useful when defining elements, actions, and values. Here are some things you can do to take advantage of ARIA capabilities and make sites more functional and accessible.
Make custom checkboxes
When working with checkboxes, I may want to make something that looks like it flows with the application or has a special styling that looks animated. To that end, creating a custom <div> with CSS formatting options defined can be called, but that means my screen reader software may not be able to interpret what has been created.
With ARIA, I can create additional semantics to help explain what the element is, what it does and how it responds. I can use the “role” keyword to define what the div element is (in this case, a checkbox) and give it a state of “checked” or “unchecked” (aria‑checked=”true” or aria‑checked=”false”).
Create accessible components
A common navigation option is to create an expandable list of items where the user selects the top-level item and then clicks on an icon to display the lower-level elements. This is easy with a mouse, but less so with a keyboard, especially if the control can be expressed as to what it is or what state it is in currently.
ARIA has a role of “tree” that allows grouping of content so that the item that is selected can be identified, and the elements within the uncollapsed node on the tree are accessible. With the tree keyword, I can change the state of the listing to “expanded” or “unexpanded” (aria‑expanded=“true” or aria‑expanded=”false”).
Provide labels for any element
If you have an item on the screen that doesn’t give the option of using an <alt> tag or some other method of providing a meaningful text string, ARIA provides the “aria‑label” option to give a name or more detailed description of an element.
For example, if I am creating a custom button that shows that you can upload a file, by providing aria‑label=”Press Shift-Enter to upload a file”, a screen reader will read out the label when the button is highlighted.
Create alerts for different types of users
Having the system make a noise, such as a beep, is a way to draw the attention of a user with a sight impairment. However, a beep is not useful for a user with a hearing impairment; a flashing effect would be a better option. With ARIA, I can make rules that allow me to do both and insert them into my elements.
Testing tips
Verify that roles are accurate
There are a variety of roles that can be applied to elements, so I recommend searching through an HTML document to determine whether a role that has been created is appropriate. If I’m looking at a navigation section, using roles appropriate for navigation and in the correct order will be important.
Confirm that state is being managed
States of an element are also important. If a checkbox tells me something when it is selected and tells me something else when it is not, I can focus on that element and verify that the text present is appropriate for the specific state.
Note that ARIA does not provide functionality itself to create the state; that happens elsewhere in the code. But I can use roles and create specific properties to be used within those states.
Test keyboard interactions
Because screen readers and other assistive technologies help the user determine what is being displayed or what action is required, I want to verify that the element is accessible from the keyboard by using the tab or shift-tab keys when appropriate. Additionally, if there is a specific keystroke sequence that is called to execute the needed action, I should confirm both that the appropriate keystrokes work and that a different set of keystrokes does not perform the specific action.
Again, ARIA itself does not provide guarantees that the element in question can interact with the keyboard. That happens with the code created for that element.
Conclusion
ARIA is a broad set of additions that can greatly improve the way we communicate to our users what the application should be doing. While this article just scratches the surface of ARIA possibilities, I encourage looking at ways we can go beyond the standard tags and design applications that are easier to use — by those with disabilities and those without. Giving structure to interactions benefits everyone.
