Skip to Main Content


PRESENTER: This tutorial answers the question, what is ARIA and why use it? We're going to cover what does WAI-ARIA mean; why is ARIA needed; how does ARIA work; roles, states, and properties; support; ARIA versions; and specifications.

Section one, what does WAI-ARIA mean? The WAI from WAI-ARIA is an abbreviation for Web Accessibility Initiative. ARIA is an abbreviation for Accessible Rich Internet Applications.

Section two, why is ARIA needed? Most web applications use different types of widgets, such as modals, in-page tabs, button dropdowns, date pickers, and many more. These widgets often include dynamic interactions, such as the ability to select, check, drag and drop, resize, hide and show, and more. They're often called non-native because they rely on JavaScript to control interactions, rather than just using native HTML.

And because they rely on JavaScript, these widgets are often problematic for assistive technologies and, therefore, inaccessible to people with disabilities. For example, assistive technologies may not understand the purpose of the widget. They may not be aware of the state of the widget, whether it's open or closed. And they may not be aware that widget has changed in some way after the initial page is loaded. ARIA can be used to solve all these types of problems.

Section three, how does ARIA work? ARIA allows web developers to apply specific HTML attributes to HTML elements. These ARIA attributes don't modify the appearance or the behavior of any HTML elements. However, they do the following for assistive technologies only.

One, they add additional meaning to HTML elements. Two, they can modify the existing meaning of HTML elements. Three, they can add additional labeling or descriptions to HTML elements. Four, they can establish relationships between HTML elements. And five, they can inform assistive technologies that updates have occurred within specific areas of an HTML page.

Section four, roles, states, and properties. In reality, ARIA is just a series of HTML attributes, which are classified as either roles, states, or properties. Role attributes allow developers to inform assistive technologies what type of widget it is.

For example, is it a widget, a slider, a progress bar, or does it provide the structure of a web page? In this example, a widget has been defined using the role of Menu. In this second example, a widget has been given a landmark role of main.

State attributes allow us to inform assistive technologies what the current state of the widget is. For example, is the widget checked, disabled, or in some other state? In this example, the first element has an attribute that informs assistive technologies that the element is in a disabled state. The second element has an attribute that informs assistive technologies that the element is in a checked state.

Property attributes allow us to inform assistive technologies the purpose of the element, or whether it has a relationship to another element. In this example, the ARIA described-by attribute establishes a relationship between the input element and the additional content inside the span element. In this second example, the button element has been given additional information for assistive technologies only.

Section five, support. A wide range of browsers support ARIA, including Firefox 3 and above; Internet Explorer 8 and above; Safari OSX 4 and above; and Chrome 17 and above. Also, ARIA is supported by a wide range of assistive technologies, including JAWS 8 and above, which is from 2012 and up; ZoomText; VoiceOver for Mac OS and iOS; NVDA; and ORCA.

Keep in mind that support is a general term. Each browser and assistive technology combination has its own minor quirks and inconsistencies. Also, the ARIA specification is constantly evolving. So the concept of support is a shifting landscape. When in doubt, you should always test using a range of browsers and assistive technologies.

Section six, ARIA versions. WAI-ARIA 1.0 was published as a W3C recommendation on the 20th of March, 2014. WAI-ARIA 1.1 was published as a W3C recommendation on the 17th of December, 2017.

Section seven, specifications. There are a range of different specifications relating to WAI-ARIA. Each has a different purpose and a different intended audience. The WAI-ARIA technical specification is mainly for developers working on web browsers, assistive technologies, and accessibility evaluation tools.

The WAI-ARIA User Agent Implementation Guide describes how browsers and other user agents should support WAI-ARIA. The WAI-ARIA Authoring Practices describes how web developers can make accessible rich internet applications using ARIA. This resource has detailed advice and examples. Developers should review the most current Authoring Practices documentation when building any non-native widgets.

The WAI-ARIA Primer outlines a series of accessibility problems that ARIA is intended to solve. And finally, the WAI-ARIA Roadmap defines the past, present, and future of ARIA. Conclusion-- so there you have it, a simple explanation of WAI-ARIA.

Except where otherwise noted, this work is licensed under Creative Commons by Attribution-ShareAlike 4.0 license. Copyright 2018, California Community Colleges Chancellor's Office. These works are licensed under Creative Commons Attribution 4.0 international license. They're available to everyone and may be repurposed to meet the unique needs of educational institutions.