Before we get into details, some background information on the relevant W3C specifications will help provide some context for why developers should learn to use WAI-ARIA when they are developing custom interactivity for the Web.
The Web Content Accessibility Guidelines (i.e., WCAG 2.0 and the recent WCAG 2.1, pronounced wuh-kag) is the primary specification adopted around the world and describes how web content should be created so it will be accessible to people with disabilities. WAI-ARIA can help developers create content that conforms with recommendations in WCAG. WCAG is covered in more detail in Introduction to Web Accessibility, so we will just provide a basic introduction here. For those who are not already familiar with WCAG, follow the link to the W3C WCAG Specification for details.
WCAG revolves around four principles that help group guidelines with common characteristics. The acronym POUR can be used to remember the principles, described below.
Content must be:
- Perceivable: It must be possible to perceive web content through multiple senses so that those who have lost a sense are able to perceive the content through another sense. Some good examples of making content perceivable are alternative text with images, so people who are blind can perceive images, and captions with audio or video, so people who are deaf are able to perceive sounds and speech.
- Understandable: Content needs to be understood by a range of people, which includes people with cognitive disabilities, sensory disabilities, people reading in a second language, and even typically able users. Some good examples include making link text meaningful (“click here” tells one nothing about the link’s destination) and consistent navigation elements (so users only have to learn the navigation structure of a website once).
- Robust: Content needs to work across multiple platforms, and it needs to continue to work into the future as technology evolves. This generally means developing content based on standards. And, when non-standard uses of HTML, etc. are provided, a standard version is available as a backup. Some uses of WAI-ARIA fall into this category of guidelines.
WCAG also introduces conformance levels. Conformance levels can be thought of in terms of their importance toward removing barriers, with Level A being the most important. It is helpful to think of levels as things you must do, should do, and could do.
- Level A: These issues must be resolved or some group will not be able to access the content. The issues at this level represent significant barriers that may not be overcome with workarounds. An example of a Level A barrier is missing alternative text to describe an image. There is little a person who is blind can do on their own to understand the content of an image without a text description.
- Level AA: These issues should be resolved or some group will find it difficult to access or use the content. These issues can often be circumvented with some effort but will make using or understanding web content more effortful. An example of a Level AA barrier is not being able to follow the focus of the cursor when navigating through content with a keyboard. For a person with low vision navigating with a keyboard, or a fully able keyboard user for that matter, navigating through content can be very difficult if he or she cannot see where the cursor is located and is unable to tell when to press the Enter key to activate a link or button.
- Level AAA: These issues could be resolved to improve usability for all groups. Web content may be technically accessible, but usability can be improved by resolving these issues. An example of a Level AAA barrier would be presenting acronyms or abbreviations without providing their full wording. For a person who is blind, an acronym pronounced by a screen reader may sound like gibberish. For a fully able user who is not familiar with a short form, an acronym or abbreviation may have no useful meaning, at least not without having to search out the meaning elsewhere.
Level AA is the generally accepted level of conformance most websites should aim for, with perhaps a few Level AAA items addressed. Very few websites will comply at Level AAA, apart from the most basic of sites. Level AAA compliance is generally unattainable, and in some cases undesirable.
The following suggested readings provide links to additional WCAG–related resources.
The instruction here focuses on the WAI-ARIA specification and how it is used to ensure interactive web content is accessible to people with disabilities. The acronyms stand for Web Accessibility Initiative, the W3C subgroup that developed the specification, and Accessible Rich Internet Applications, the specification itself. It is typically referred to as WAI-ARIA, rather than ARIA, to distinguish it from other uses of the acronym. WAI-ARIA can be used to help developers create widgets, applications, and web interactivity in general that meet WCAG recommendations.
The WAI-ARIA specification was initially released as a recommendation in March 2014 (WAI-ARIA 1.0). WAI-ARIA 1.1 was released in December 2017 and is the current stable version, with WAI-ARIA 1.2 in the works, available as an editor’s draft.
For now introduce yourself to WAI-ARIA, if you are not already familiar, by scanning over the specification to develop a general understanding of why it is needed, how it is used, and when to use it. We will go into much more detail as we proceed through the activities.