WCAG primer

Posted on Friday, 10 April 2020 by Léonie Watson in Standards

The Web Content Accessibility Guidelines (WCAG) are a set of recommendations for making websites and apps accessible to people with disabilities. This article explains WCAG and how to use them.

History

WCAG has been the internationally recognised standard for web accessibility for more than 20 years. WCAG 1.0 was published by the W3C in 1999, WCAG 2.0 in 2008, WCAG 2.1 in 2018, and the current version WCAG 2.2 in 2023. The W3C is now working on WCAG 3.0, but publication is not expected for several years.

The Accessibility Guidelines Working Group (AGWG) is responsible for creating WCAG at the W3C. Members of AGWG include large technology companies like Adobe and Google, accessibility companies like TetraLogical, and many people who represent other organisations with an interest in accessibility. The AGWG also consults widely with the web community to make sure that each version of WCAG receives feedback from as many people who will use them as possible.

Principles

The structure of WCAG changed between WCAG 1.0 and WCAG 2.0. Since then there have been 4 principles in WCAG, designed to help you think about the ways people use web content:

Perceivable

Information and user interface components must be presentable to users in ways they can perceive.

People will perceive, or become aware of, content in different ways. For example, a sighted person will see the content, a blind person may listen to it as synthetic speech and a deaf-blind person will feel it with their fingertips as electronic Braille.

Operable

User interface components and navigation must be operable.

People will operate, or use, content in different ways. For example, someone with a physical disability that means they can't use a mouse may use the keyboard or voice recognition instead of a mouse or trackpad.

Understandable

Information and the operation of the user interface must be understandable.

People understand content differently. For example someone who has difficulty reading may want acronyms to be written out in full, someone who is blind will want their screen reader to speak foreign language content using the correct accent, and someone who has a learning disability will prefer things to work consistently wherever they find them.

Robust

Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.

People use different devices and browsers to access the web, many will use assistive technologies too, and web content needs to work reliably on them all. For example someone with low vision might use Safari on an iOS device with zoom enabled, someone who is blind might use Firefox on Windows 10 with the NVDA screen reader, or a person who is unable to use a mouse or keyboard might use Internet Explorer on Windows 7 with Dragon voice recognition software.

Guidelines

There are 13 guidelines that support the 4 principles in WCAG 2.2. Each guideline is broken down into individual requirements known as Success Criteria or SC for short.

Guideline 1.1 Text Alternatives

Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.

Not everyone is able to see graphical content, but text can be read by people who cannot see images and it can be adapted so people can read it in different ways. For example, a text description of an image can be converted into synthetic speech or electronic Braille using a screen reader.

There is one SC under Guideline 1.1 Text Alternatives:

1.1.1 Non-text Content (Level A)

Guideline 1.2 Time-based Media

Provide alternatives for time-based media.

Not everyone is able to see or hear time-based media, otherwise known as multi-media, so alternatives are needed. Text alternatives in the form of transcripts or real-time synchronised captions will enable people who are deaf or hard of hearing to experience audio content, and text also forms the basis for scripted audio description that describes video content to people unable to see it.

There are 9 SC under Guideline 1.2 Time-based Media:

Guideline 1.3 Adaptable

Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

People will adapt the way content is presented based on their needs or preferences. For example, someone with low vision may choose to use their own style sheets because they prefer a particular font, someone with a physical disability may need content to always be in the portrait orientation because their tablet is fixed to their wheelchair in that position, or someone with a cognitive disability may use a browser plug-in that helps them identify the purpose of form fields that ask for their personal data.

There are 6 SC under Guideline 1.3 Adaptable:

Guideline 1.4 Distinguishable

Make it easier for users to see and hear content including separating foreground from background.

Certain things can make it harder for people to see or hear content. For example if the colour of text doesn't show up clearly against the background it will be harder for people with low vision to make out, if a video plays automatically it may be so loud that a blind person cannot hear what their screen reader is saying or someone with a cognitive disability may find it so distracting they cannot use the page at all.

There are 13 SC under Guideline 1.4 Distinguishable:

Guideline 2.1 Keyboard Accessible

Make all functionality available from a keyboard.

Not everyone uses a mouse or a trackpad and there are different alternatives available. Many people with physical disabilities will use a keyboard, but some will use voice recognition software that is also dependent on the content being keyboard accessible. People who use other assistive technologies like screen readers or screen magnification often use a keyboard too.

There are 4 SC under Guideline 2.1 Keyboard Accessible:

Guideline 2.2 Enough Time

Provide users enough time to read and use content.

Not everyone is able to complete a task in a short amount of time. For example, someone who finds reading difficult may need more time to read instructions, someone with a physical disability may take longer to move through the content, and aggressive time limits may put someone with Anxiety Disorder under so much pressure they're unable to complete the task.

There are 6 SC under Guideline 2.2 Enough Time:

Guideline 2.3 Seizures and Physical Reactions

Do not design content in a way that is known to cause seizures or physical reactions.

Seizures are often serious and sometimes life-threatening so it is vital that content does not trigger them. For example, a seizure can be triggered in someone with Photo-sensitive Epilepsy if content flashes more than 3 times a second. Other physical reactions like dizziness and nausea can be triggered by moving or animated content particularly if it uses a parallax effect.

There are 3 SC under Guideline 2.3 Seizures and Physical Reactions:

Guideline 2.4 Navigable

Provide ways to help users navigate, find content, and determine where they are.

People can find it difficult to navigate web content or to be sure of where they are. For example, someone with a cognitive disability that affects memory may use the page title to remind themselves where they are, a sighted keyboard user will depend on a visible indicator that tells them where their keyboard is currently focused, and a screen reader user will find links easier to use if the link text makes it clear where the link leads.

There are 13 SC under Guideline 2.4 Navigable:

Guideline 2.5 Input Modalities

Make it easier for users to operate functionality through various inputs beyond keyboard.

As well as the keyboard, people will use touch-screen devices and voice recognition as alternatives to using a mouse or trackpad. And even if people do use a mouse or trackpad, they may not have the fine motor control necessary for certain types of interactions, such as accurately dragging interface elements. It's important to make sure people can still operate content. For example, making sure links and buttons have visible labels will help voice recognition users target them more accurately, not triggering actions the moment someone places a finger on a touch-screen will help prevent people with dexterity problems doing things unintentionally, and offering alternative ways to complete tasks that require multi-touch or dragging gestures is helpful to anyone unable to confidently operate a touch screen or mouse.

There are 8 SC under Guideline 2.5 Input Modalities:

Guideline 3.1 Readable

Make text content readable and understandable.

Not everyone finds text easy to read and understand. For example, someone who finds reading difficult may find it helpful if the meaning of unusual words is explained, or someone with a learning disability will find simple content easier to understand.

There are 6 SC under Guideline 3.1 Readable:

Guideline 3.2 Predictable

Make Web pages appear and operate in predictable ways.

Most people find content easier to use when it looks familiar and behaves consistently. For example, putting things like the logo and navigation in the same place on every page helps screen magnification users orient themselves, and using the same labels for links and buttons that do the same thing helps people with cognitive disabilities correctly identify them.

There are 6 SC under Guideline 3.2 Predictable:

Guideline 3.3 Input Assistance

Help users avoid and correct mistakes.

Nobody wants to make mistakes but avoiding mistakes or correcting them if they happen can be difficult for some people. For example, letting people review their answers before they submit a form that relates to a financial or legal agreement helps people with all disabilities avoid sending the wrong information, and presenting error messages as text means that people who cannot see warning colours or symbols know the errors are there.

There are 9 SC under Guideline 3.3.3 Input Assistance:

Guideline 4.1 Compatible

Maximize compatibility with current and future user agents, including assistive technologies.

Writing code in ways that support a range of different devices and technologies makes content more reliable. For example, writing HTML that avoids errors known to cause problems for assistive technologies like screen readers and voice recognition software, and making sure that custom components and notifications are created in ways that include all the accessibility information needed by people who use assistive technologies.

There are 2 SC under Guideline 4.1 Compatible:

Note: 4.1.1 Parsing was marked as obsolete and removed in WCAG 2.2.

Conformance

Each WCAG SC is assigned a conformance level: Level A, Level AA or Level AAA. In WCAG 2.2 there are:

31 Level A SC
24 Level AA SC
31 Level AAA SC

Level A is the most basic level of accessibility. When a website meets all Level A SC it has a good foundation of accessibility in place but it will still put obstacles in the way of many disabled people.

Level AA can only be achieved once Level A has been met. It is the level of accessibility referenced in many laws and policies around the world. When a website meets all Level A and Level AA SC it will be accessible to people with many different disabilities.

Level AAA is the highest level, and like Level AA it builds on top of the levels before it. Level AAA SC should be met wherever possible, but it is not expected that an entire website will meet Level AAA because the SC are only applicable in some circumstances. WCAG includes this note:

It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content.

It is worth noting that not all SC apply all of the time, no matter which level they're assigned. For example, if the website contains no multimedia content then none of the SC under Guideline 1.2 Time-based Media will apply.

The principles, guidelines and SC in WCAG are relevant to every part of a website or product created using web technologies. This includes the design, code, content and functionality, and it means that every member of a production team should be familiar with WCAG as a matter of course.

Next steps

Find out more about how assessments can help you identify accessibility issues in your products and services and how to pick representative samples for accessibility assessments.

Updated: 5 September 2023.