The first step one should take towards understanding digital accessibility (though certainly not the last) is to wade into the shallow waters of WCAG. The Web Content Accessibility Guidelines (WCAG) is a landmark set of accessibility standards that have defined legal requirements, UX recommendations and testing criteria since the publication of version 2.0 in 2008. WCAG comes up in every ADA lawsuit ruling, every book about the field, every job posting for a web accessibility specialist. It is to accessibility what the Associated Press Stylebook is to journalism, or what Gray’s Anatomy is to medicine.
If you are a developer or designer interested in practical guidance for web accessibility, then WCAG will not be your be-all and end-all. For specific rules and technical solutions, your best source is blogs and competent online tutorials. What the WCAG does provide is a framework of qualitative rules against which you can compare the capabilities of your website or application. This set of rules is far more useful for documenting and classifying accessibility defects than for constructively guiding the development of an accessible website.
Although the principles of accessibility as presented in WCAG will not independently get your designers and developers to universal design, they do present an appropriate heuristic for structuring the framework of rules. The Web Content Accessibility Guidelines lay out the four principles of accessibility: digital interfaces should be perceivable, operable, understandable and robust.
Note: Although the rules in WCAG are web accessibility guidelines, the actual rules are referred to in literature as success criteria (SC).
Perceivable
The success criteria under the Perceivable principle govern the presentation layer of web applications. One aspect of this principle is visual presentation for users with vision. For example, SC 1.4.3 Contrast, SC 1.4.1 Use of Color, and SC 1.4.4 Resize Text impact users who are color-blind or have color sensitivity, or who may be visually impaired and need to magnify text in order to read effectively. There is furthermore a success criterion governing Captions (SC 1.2.2), which makes audio perceivable for users who have impaired hearing. There are also success criteria that oversee the presentation of information through non-visual modalities, such as the audio output of screen readers, SC 1.1.1 Non-Text Content, and audio description, SC 1.2.3 Audio Description.
Operable
The success criteria in the Operable category apply to the user’s ability to perform actions and to navigate a website, regardless of input device. Individuals with motor difficulties, such as tremors or arthritis, that make it difficult to use pointing devices, may rely entirely on a keyboard or a switch device to navigate a website; users with prosthetics may be completely barred from using a touch screen device; and screen reader users (typically) rely completely on the keyboard, so a mouse-requisite interface is not an option. The success criteria 2.1.1 Keyboard, 2.1.2 No Keyboard Trap, 2.4.3 Focus Order and 2.4.7 Focus Visible together guarantee that any action that can be accomplished with a mouse can also be performed with a keyboard. As another example, SC 2.4.4 Link Purpose means that a screen reader user can identify the destination to which a link is about to take them, and SC 2.4.2 Page Titled confirms that the user has indeed reached the intended destination.
Understandable
The success criteria under Understandable are meant to keep the information in a website coherent and keep feedback from interactions and website structure consistent with the user’s expectations. Conventions and familiar patterns of design and user experience should be employed whenever possible, and when new patterns are used they should be clearly explained. A user who cannot see the interface may be confused by system responses that contravene standard web conventions, and a user who has a learning disability or intellectual impairments may get frustrated and give up. SC 3.2.2 On Input ensures that a user’s keyboard or screen reader focus will not be moved without the user’s direction as soon as they enter a character into a form field. In those three-part fields for phone numbers, for example, how many times have you entered your area code incorrectly, only to have the system automatically move your focus to the next text field, forcing you to shift-Tab or click back to the area code field and re-enter it.
Furthermore, navigation within the website should not be labyrinthine and ever-changing. SC 3.2.4 Consistent Navigation, for instance, tells us that if a set of navigation links appears horizontally in the header on the Home page, it should not appear in a vertical sidebar menu on the About page in reverse order. Additionally, to make sure that users understand what they are supposed to enter into a form, Labels and Instructions (SC 3.3.2) should describe the form’s intent and there should be descriptive Error Identification (SC 3.3.1) so the user knows how to fix their mistakes. But also, in a more literal interpretation of “Understandable”, SC 3.1.1 Language of Page and SC 3.1.2 Language of Parts ensure that foreign languages are interpreted and pronounced correctly by screen readers (e.g., so a screen reader in Spanish doesn’t rhyme José with “hose”).
Robust
The success criteria under the Robust principle govern the technical markup of a website—without providing any specific guidance for what constitutes “good” markup. But fundamentally, the HTML and CSS used to frame and design the website should follow best practices so that the website can be effectively rendered in browsers and interpreted by assistive technologies such as screen readers. SC 4.1.2 Name, Role, Value requires that all user interface components come with—you guessed it—a name, role and value, because these properties are essential for users of screen readers and other assistive technologies to correctly interpret and navigate an interface.
WCAG Conformance
The WCAG success criteria are categorized into three levels of conformance based on the impact of each guideline on its target audience. The success criteria at Level A are the most basic and the easiest to satisfy without negatively impacting the look and feel of a website or development timelines. Level AA deals with the most common barriers for users with disabilities, and these criteria require more design and development commitment. Most businesses impacted by WCAG are required to meet Level A and AA requirements. The success criteria at Level AAA represent the most complex and stringent level of web accessibility. While Level AAA benchmarks ensure accessibility for a wider range of users, conformance to these criteria can often impact UI design in major ways; not all organizations have the ability to achieve Level AAA compliance within their business or user requirements. For this reason Level AAA conformance is not required for any corporate entity, but is instead considered more of a “gold standard.”
Understanding the structure of the WCAG success criteria can be helpful in applying these guidelines to your own website and app development. But, just as the rules of the AP Stylebook and Gray’s Anatomy will not by itself make you a successful journalist or physician, understanding WCAG will not by itself make your website or app accessible. Read expert advice online; test your application with screen readers and assistive technology; and iterate on your code until your implementation is universally effective.