In March 2014 the Web Content Accessibility Guidelines (WCAG) Working Group (WG) published several new ARIA techniques for WCAG 2 and updated several failure techniques. A primary change is the allowance of new methods other than the alt attribute for non-text elements (e.g. images). This post serves to describe the change in position, its roots, and implications for use.
A New sufficient technique to promote ARIA for elements that don’t support alt
The sufficient technique ARIA10 was created to provide an example of how ARIA could be used to provide alternative text for an element that does not support the
alt attribute by using aria-labelledby. In the technique an example is given a of a rating bar with several image elements wrapped in a
div element with a
role of “img”.
A sufficient technique is not a requirement but one documented way of meeting a success criteria (in this case SC 1.1.1 Non-text Content) that is known to be accessibility supported (supported by major browsers and assistive technology).
Softening the failure to provide alt
Failure technique F65 for WCAG 2 SC 1.1.1 Non-Text Content is an existing documented failure to check for the presence of an alt attribute for an
input type image or
area element (either with a text alternative or null to indicate the image was decorative
img). Failures are stronger than sufficient techniques and when a failure occurs it generally means a success criteria was not met unless another sufficient technique for the same element occurred or an alternative conforming page was present.
This failure was updated by the WCAG working group to loosen the requirement that alt be mandated for these element types as long as another method is used and the method is accessibility supported. The WCAG WG is not endorsing these methods for elements that can use alt i.e. no sufficient technique was created — they are simply softening the failure to allow for newer techniques that are accessibility supported.
Methods indicated in the check for the failure indicate that the
alt could be used to provide alternatives.
What does this all mean?
In general, when the alt attribute can be used developers should continue to use the alt attribute. If alt cannot be used or it doesn’t make sense for alt to be used in the situation, teams must determine if the method used is accessibility supported.
Accessibility supported is different depending on the environment. For example, in a corporation or university and internal site may dictate the set of browsers and AT that are used/supported and thus determining whether something is AT supported may simply mean evaluating those dictated technologies. In a public environment what is accessibility supported may very but it will certainly require conformance with multiple browsers and AT and platform accessibility features. There is no prescribed set of AT that is required but several different configurations of technology will almost certainly be needed to meet the accessibility supported definition. Accessibility supported is not a new concept — it has always been a conformance requirement of WCAG 2. However, it is likely the first time it is specifically called out in a WCAG failure.
If the technique is accessibility supported, a site can use it. There are however several factors to consider. Not all techniques are the same.
Is ARIA the only option?
The various options to provide alternative text without the alt attribute were determined based on the rules described in the working draft HTML to Platform Accessibility API Guide proposal and are also rooted in the ARIA Specification’s Accessible Name calculation for text alternative computation. The HTML Accessibility API indicates the following order shall be used to expose the alternative text for images in the accessibility API of the platform:
- Use aria-labelledby
- Otherwise use aria-label
- Otherwise use alt attribute
- Otherwise use title attribute
- If none of the above yield a usable text string there is no accessible name
In practical terms the alt attribute is not displayed by browsers to users with disabilities. Thus, the use of the
aria-labelledby promotes use of on-screen text to provide alternatives to images. This can be beneficial to users with low vision as well as users with cognitive disabilities. The
aria-label property however is much like the alt attribute and will likely only be seen by users of screen readers. The
title attribute is also now an option. Historically, the use of title on images was seen as not valid from an HTML perspective as the
title attribute was indicated as a way to provide supplementary information and not replacement information for people who could not see the image. The
title attribute is displayed for images when the user places the mouse pointer over the image — although this title is not keyboard accessible. Use of the
title also has benefits to users with low vision and cognitive impairments that use the mouse.
Specific scenarios to consider
There are some situations where non-text content can appear as the only element in a link, etc. Support for these situations with AT would need to be evaluated before the technique can be used. It is also important to know for situations like these that AT such as speech recognition software often doesn’t support ARIA and the lack of alt text may prevent users from clicking image only links with direct voice commands. Most speech recognition software provide additional methods to choose links to activate by number and thus there are work-arounds to be considered.
There are some additional considerations on how certain browsers handle ARIA attributes. For example, Internet Explorer has historically not correctly combined multiple elements comprising a label via aria-labelledby into the accessible name. Solutions have required setting a tabindex of -1 on all elements that are referenced by aria-labelledby to get Internet Explorer to properly create the accessible name.
Automated testing tools will also have to be updated to consider these new options for providing alternative text. While tools can check for the presence or absence of these properties they are not able to determine if something is accessibility supported. Therefore we recommend that evaluators still be apprised of the potential issues by the testing tool providing guided automatic results for the evaluator to review for a given site.
We recommend creating a matrix of the browsers, OS, and assistive technology determined to part of the technology stack for a site and test the technique to determine the outcomes. This document not only informs design and development but also provides documentation of your accessibility plans and efforts and can be used as support information.
Website teams now have greater flexibility to provide text alternatives for non-text content. However, everyone should be aware of the accessibility supported requirements and properly access the support for the chosen technique. Until specific automated testing tools are updated evaluated stakeholders may get results for non-text content that should be analyzed in the frame of the technologies supported.