Managing Multiple WCAG Failures

This is an article pulled from KnowledgeBase, a digital accessibility repository available through TPGi’s ARC Platform. KnowledgeBase is maintained and consistently updated by our experts, and can be accessed by anyone with an ARC Essentials or Enterprise tier subscription. Contact us to learn more about KnowledgeBase or the ARC Platform.

Web developers, designers and content authors may produce web content that inadvertently causes multiple failures of the Web Content Accessibility Guidelines (WCAG).

When this content is tested against WCAG Success Criteria (SC), auditors may wonder whether there is a benefit in reporting the multiple nature of these failures, and whether their multiple nature might change remediation advice.

This article is based on the belief that it does help to recognize and report multiple failures, and sets out to distinguish and name several different types of multiple failures.

The aim is to create greater understanding in order to help web creators prevent multiple failures and help auditors to address them efficiently when they do occur.

The first thing to understand is that all multiple failures are not the same. We identified four distinct types, each with differing characteristics, impact and ways to remediate.

Cascading failures

Cascading failures are where one component causes multiple failures that are related and can be addressed by a single solution.

An example of this is a link that contains only an image with no alternative text and no accessible name.

<a href="destination.html">
  <img src="image.gif">
</a>

This potentially fails WCAG SC:

• 1.1.1 Non-text Content – the image has no alt attribute
• 2.4.4 Link Purpose (In Context) – the user can’t determine the purpose of the link, even in the context of the page
• 2.4.9 Link Purpose (Link Only) – the user can’t determine the purpose of the link by itself
• 4.1.2 Name, Role, Value – the link has no accessible name

A simple way to address all these cascading failures is to give the image alt text that states the destination of the link.

<a href="destination.html">
  <img src="image.gif" alt="link destination">
</a>

Note that if the image was marked up with alt="" to mark it as decorative, the other three failures would still apply, as the user has nothing to tell them where the link takes them.

You might think that’s an uncommon scenario, but in fact it comes up quite often when a linked image is adjacent to a text link to the same destination.

<a href="destination.html">
   <img src="image.gif" alt="">
</a>
<a href="destination.html">
   Link destination
</a>

The recommended way to remediate this is to address the whole cascade of failures at once: put the image and the text in the same anchor element:

<a href="destination.html">
   <img src="image.gif" alt="">
   Link destination
</a>

There is a clear efficiency benefit in identifying cascading failures and identifying a single solution to address them.

Coinciding failures

Coinciding failures are where one component causes failures of multiple success criteria that are not related to each other and require separate solutions.

An example of this could be a number that is indicated as being negative only by being displayed in red (#FF0000) text on a white (#FFFFFF) background. This fails both SC 1.4.1 Use of Color for using color alone to convey information, and SC 1.4.3 Contrast (Minimum) for having insufficient contrast between the text and the background.

Darkening the shade of red from #FF0000 (contrast ratio 3.99:1) to #E60000 (contrast ratio 4.81:1) will address the SC 1.4.3 failure but not the SC 1.4.1 failure, which requires using something other than just color to indicate the negative, such as putting a minus symbol in front of the number.

Coinciding failures can be easy to miss because the auditor finds and reports one failure and moves on without testing the same content for additional failures.

Automated testing tools are very useful in these scenarios, detecting SC failures that manual testing alone might miss. The reverse is also true, in that manual testing may pick up a coinciding failures that automated testing doesn’t check for.

Experienced developers and auditors will also come to realize that certain WCAG SC failures often coincide, color and contrast being a good example.

Detecting and remediating coinciding failures in advance or during auditing ensures more complete accessibility in web content.

Consequent failures

Consequent failures are where addressing a failure of one success criterion in one component creates a failure of another success criterion, either in the same component or in another component.

Scenarios where the fix for one SC failure causes another SC failure are, fortunately, not all that common but they can be hard to pick up when they do occur.

An example of this is an input field on a form that requires a date to be entered in a specific format but provides no instruction as to what that format is, creating a failure of SC 3.3.2 Labels or Instructions.

<div>
	<label>Preferred Expiry Date:</label>
	<input type="text">
</div>

Once that issue is picked up, visible instructions are then added to the form.

<div>
	<label>Preferred Expiry Date (standard format required):</label>
	<input type="text">
</div>

However, the visible instructions are not clear or descriptive, creating a new failure of SC 2.4.6 Headings or Labels.

<div>
	<label>Preferred expiry date (format as DD/MM/YY):</label>
	<input type="text">
</div>

In addition, if the instructions are not programmatically associated with the field, an additional failure of SC 1.3.1 Info and Relationships is created as a screen reader user might not understand which field the instructions apply to.

It would have been useful for the tester not just to focus on the initial issue but to anticipate the consequent failures and advise that using input="date" would address the first issue and prevent the consequent issues.

<div>
	<label for="expire">Preferred expiry date:</label>
	<input type="date" name="expire" id="expire">
</div>

Consequent failures are most often encountered when retesting web content after an initial audit, but they can be anticipated by an alert and experienced auditor.

In the scenario described here, the auditor could add a note to their report pointing out that not only are instructions required but they must be descriptive and they must be programmatically associated with the field.

It might seem like extra work but ultimately the auditor is saving themselves retesting work, as well as delivering a benefit to the developer.

Contextual failures

Contextual failures are when several components used in a specific context, such as a form or a table, fail the same success criterion. The tendency is to report these issues individually – and that may be all that’s possible, depending on your auditing and reporting tools – but there may be a benefit to noting that they are all parts of a common context, and offering advice and resources that relate to that context.

A common example of this is when a form has a number of components that all fail SC 1.3.1, although they may fail in different ways. It’s the context of the form that identifies them as multiple failures.

Such a multiple failure could be triggered by issues as disparate as styling text to look like a header rather using markup, not programmatically associating visible form field labels with their fields, not grouping related field forms visibly or programmatically, or placing two form fields on a page with the same label but requiring different input.

It wouldn’t be unusual to find a form like this also has components that fail other WCAG Success Criteria, such as SC 4.1.2 in relation to information about form controls not being made available programmatically.

It’s not unusual to find of all of these SC 1.3.1 failures in a single form on a web page. To some extent, a designer or developer who is unaware of one issue may also be likely to be unaware of the others and perhaps be unfamiliar with the requirements of SC 1.3.1. In other words, they may not be familiar with the principles of accessible form design.

This still qualifies as a contextual failure because it is the context of the form that creates the multiple failures.

Since the individual SC failures require different remediation techniques, they are typically reported as separate issues and that is appropriate.

However, it might also be appropriate to note their related nature and suggest a resource focused on creating accessible forms, to put the noted failures in context and perhaps preempt other form failures.

Conclusion

What difference does all this make? Do these arbitrary naming conventions for multiple failures actually help anyone?

While it’s entirely reasonable to report each WCAG SC failure you encounter on an individual basis, there are some potential efficiency benefits to identifying and pointing out multiple failures.

Recognizing and distinguishing the different kinds of multiple failures may make it easier to:

• identify a single solution for cascading failures
• catch coinciding failures and ensure completeness
• anticipate consequent failures, reducing future work
• reveal knowledge gaps indicated by contextual failures

Identifying the different kinds of multiple failures and understanding their nature will ultimately help web developers, designers, and content authors create more accessible web content and auditors to provide better guidance when they don’t – which can only be a good thing.