Design patterns and WCAG

Posted on Friday, 9 August 2024 by Graeme Coleman in Design and development

The ARIA Authoring Practices Guide (APG) contains an extensive range of design patterns aimed at helping developers to create accessible web experiences using WAI-ARIA. However, while we encourage web authors to follow these design patterns, a common misconception is that their usage is a prerequisite for conformance.

This is not the case.

Overview

Design patterns have a long history in software development. They provide practical solutions to common problems that occur when interacting with a user interface. For developers, design patterns help contextualise how low level, and often complex, code can be turned into something meaningful and understandable. For users, design patterns help foster familiarity and consistency.

The APG design patterns are often used as a basis for creating accessible user interfaces, and with good reason. They cover different types of user interface components from basic buttons through to carousels and complex grids. Each design pattern includes information about:

How WAI-ARIA roles, states, and properties should be applied
How keyboard accessibility should be supported, including suggested keystrokes

Additionally, many of the patterns include working examples and code samples that web authors can then adapt to their own specific needs. It's no wonder that widgets built using these design patterns tend to have strong support for accessibility.

However, design patterns are not rules or regulations. Good design patterns can be built upon or modified to meet the changing needs of people and technologies. Design patterns should therefore be treated as best practice guidelines for resolving current problems rather than immovable decrees.

Even so, we are often asked the following question: must my implementation follow the related APG design pattern, or any other design pattern, to conform to the Web Content Accessibility Guidelines (WCAG)?

Normative and informative requirements in WCAG

WCAG, like most specifications, uses the terms normative and informative to distinguish between the parts of the specification that must be met in order to conform (normative) and those that are advisory in nature and don't need to be met in order to conform (informative).

In WCAG, the principles, guidelines, and success criteria are normative, while everything else - including, but not limited to, the techniques and understanding documents - is informative.

While this distinction appears obvious, the terminology can lead to misunderstandings, particularly in terms of whether an approach "passes" or "fails" this success criterion.

Design patterns are informative

The APG's design patterns, like all design patterns and even WCAG's techniques themselves, are informative rather than normative. While it is important to follow common conventions like those built into these design patterns, you are free to produce your own design patterns as long as the resultant implementation meets the related success criteria when implemented.

For example, let's say you are implementing a tabbed navigation widget, and know that you need to ensure it is keyboard accessible. You therefore decide to implement the widget to follow the APG's tabs design pattern. You have implemented it so that, when the widget has focus, tabs can be accessed and selected by pressing the Left and Right arrow keys.

You then find out that a colleague has also implemented a tabbed navigation widget. However, it doesn't use the above keyboard interaction pattern. Although keyboard accessible, a user must press the Tab and Shift + Tab keys to navigate through the tablist, and separately press the Enter key or the Spacebar to select / activate the currently focused tab in order to display its related contents.

Does this mean that your implementation passes WCAG Success Criterion 2.1.1 Keyboard (Level A), but your colleague's implementation does not?

No.

Both approaches conform to the above success criterion. As I discussed in my earlier blog post on keyboard accessibility myths and WCAG, WCAG is primarily concerned with high level outcomes. Here, the tabbed navigation widget will meet this success criterion if it can be operated using the keyboard alone. This is the case in both of the above scenarios. There are no normative requirements for you to support specific keystrokes or follow any particular convention.

Caveats

Of course, conformance should never be viewed in a vacuum. Indeed, there are instances where you should follow design patterns, and indeed we often encourage web authors to follow design patterns like the APG's, even though it is not a WCAG requirement.

For instance, certain screen readers will often automatically announce the keystrokes required to interact with certain types of controls, based on generally accepted interaction methods. On encountering a combobox, JAWS will inform the user that they can change the current selection using the arrow keys. If your custom combobox relies on a different set of keystrokes, such as the Tab and Shift + Tab keys, your combobox will normatively meet the related success criterion, but may be confusing for people who use screen readers who discover that the arrow keys do not work as expected.

Summary

Normatively meeting WCAG success criteria is the minimum required to ensure your site works for people with disabilities. You can achieve this without following best practice guides like the APG design patterns.

However, following those design patterns goes beyond conformance, and benefits real people. Indeed, being consistent and borrowing from well-established design patterns is a key inclusive design principle, as people are more likely to understand how to operate a control when it supports familiar conventions for interaction.

Therefore, even though design patterns are not prerequisites for conformance, we strongly recommend you use them as the basis for designing and implementing an accessible user interface.

Next steps

For more information about the Web Content Accessibility Guidelines, read our WCAG primer or find out more about how our assessments can help you identify issues in your websites, mobile applications, design systems, and other products and services.