This website is being built in public and is very much under construction

Accessibility Specialist

Introduction to WCAG

Posted

Whether you are new to accessibility or a seasoned veteran, understanding The Web Content Accessibility Guidelines (WCAG) can be challenging.

In this post I'm going to be break down the basics of WCAG before deep diving into individual requirements (Success Criteria) in future posts.

What is WCAG?

The Web Content Accessibility Guidelines (WCAG - pronounced WUH-CAG) are a set of internationally recognised recommendations for improving web accessibility. Its developed by the Web Accessibility Initiative (WAI), a part of the World Wide Web Consortium (W3C), with contributions from many individuals and organisations from around the world. Its goal is to provide a single shared standard for web content accessibility.

WCAG outlines how to make websites and digital content accessible to everyone, including those with impairments to their:

  • Vision - severely sight impaired (blind), sight impaired (partially sighted) or colour blind
  • Hearing - deafness or hearing loss
  • Mobility - who may find it hard to use a mouse or keyboard
  • Thinking and understanding - dyslexia, dyscalculia, autism or learning difficulties
  • Seizure disorders - like epilepsy

Principles

WCAG focused on four core principles, often remembered by the acronym POUR. While it aimed at web content, it focuses more on the principles rather than specific technologies.

1. Perceivable

Information and user interface components must be presented in ways that people can perceive with the senses that are available to them.

This means doing things like:

  • providing text alternatives for non-text content, like images, video and audio
  • ensuring colours used for things like text, form controls, icons and graphs contrast enough with surrounding colours and background
  • making sure pages are responsive and work with different screen and font sizes

2. Operable

People must be able to interact with interface elements, such as navigation and controls, using different input methods (keyboard, voice, assistive tech, etc.).

This means doing things like:

  • making sure all everything works for keyboard-only users
  • using descriptive page titles
  • using meaningful heading and form input labels

3. Understandable

People should be able to understand your content and how to operate the user interface.

This means doing things like:

  • making sure it's clear what language content is written in
  • making features look consistent and behave predictably
  • making it easy to identify and correct errors

4. Robust

Content must be robust enough to be interpreted reliably by a wide range of devices, including assistive technologies.

This means doing things like:

  • making sure code lets assistive technology know what every interface component does and what state it's in
  • making sure status messages and modals are marked up correctly and informs people of their presence and purpose

Guidelines

Under the 4 principles are 13 guidelines. Think of these guidelines as the basic goals that you should follow in order to make content more accessible to people with different abilities.

Examples of guidelines:

  • 1.2 Time-based media - provide alternatives for time-based content
  • 1.3 Adaptable - Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
  • 1.2 Keyboard Accessible - Make all functionality available from a keyboard.

A full list of the guidelines can be found in the WCAG 2.2 table of contents.

The guidelines are not in themselves testable but rather provide the objectives to help understand the testable parts of WCAG - the success criteria. Each guideline contains a number of testable success criteria.

Success Criteria (SCs)

Think of SCs as tests or checkpoints. Each describe what must be done to conform to WCAG. SCs are binary, so when tested the outcome will be a pass or fail against specific requirements (though that can require some interpretation depending on the situation).

Each SC has:

  • an "understanding" page, that provides extra information on how to meet the SC
  • example techniques and failures
  • a conformance level - A, AA or AAA

The current version of WCAG (2.2) contains a total of 86 success criteria.

Techniques

Techniques are grouped into two categories - Sufficient Techniques and Advisory Techniques. Sufficient Techniques give examples of how to meet the SC in certain situations whereas Advisory Techniques offer best practices that can be used to make things more accessible but aren't strictly needed for WCAG conformance. It's worth noting that the while useful, the techniques don't cover every situation or solution.

Failures

Many SCs also include examples of failures within their understanding page. As with Techniques, these can be useful but aren't exhaustive and don't cover every situation.

Levels of conformance

  • Level A – The minimum level of accessibility. Essential criteria that if not met would prevent a large group of people from accessing content or functionality.
  • Level AA – The most common target for legal compliance and usability. High priority criteria that ensure a reasonable level of accessibility for many people.
  • Level AAA – The highest level of WCAG conformance, sometimes difficult to achieve site-wide. Not always achievable for all types of content.

To claim conformance to a certain level, all the SCs from that level and any lower levels must be met. For example, to claim a site conforms to level AA, all level A and AA success criteria must be met. It's worth noting that many best practices exist in addition to AAA.

Testing

While some SCs can be tested by automated tools (opinion differs but it's roughly ~30%) the majority require human testers. Content should be tested by someone who understands how people with different disabilities use the web.

Remember to include people with disabilities

WCAG provides a great baseline for accessibility but there is always room for improvement. It's essential to include people with real disabilities when designing, developing and testing content and functionality.

Versions

The guidelines have evolved over time through multiple versions. Each version builds upon the last, refining requirements and expanding coverage for more disability types and use cases. Most versions are backward compatible.

WCAG Versions
Version Published Overview
1.0 May 1999 14 guidelines, with checkpoints of different priority levels. Conformance measured by checkpoints.
2.0 December 2008 Major update. Reorganised around the four principles (POUR). Introduction of success criteria. Conformance measured by meeting success criteria.
2.1 June 2018 Builds on 2.0. Adds 17 new success criteria with more focus on smaller screens and people with low vision and thinking disabilities
2.2 September 2023 Builds on 2.1. Adds 9 new success criteria, with more focus on people with mobility, low vision and thinking disabilities. 1 success criteria removed.
3.0 Unreleased Early draft, major update with format restructure. Final version likely years away.

WCAG also serves as the technical standard for many accessibility-related laws and regulations around the world. In the UK, the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations (PSBAR) require WCAG 2.2 at level AA as the benchmark for compliance for public sector websites. Similarly, in the United States, WCAG serves as the foundation for the legal requirements in Section 508 of the Rehabilitation Act and Title II of the Americans with Disabilities Act (ADA).

Further reading