WCAG, but in language I can understand
First posted 28th January 2022 in Accessibility; updated 12th May 2022
The Web Content Accessibility Guidelines (WCAG) make for difficult reading, so I thought I’d write a short article on each success criterion, explaining it in easy to understand language.
But then I changed my mind! There are a 50 success criteria at levels A and AA in WCAG 2.1, a further 28 success criteria at level AAA, and WCAG 2.2 has another 9 criteria. That’s a lot of articles! I have other things I’d like to write about, and, besides, DigitalA11Y have already done a good job of it.
Instead, I’ve decided to write a single article summing up each success criterion in WCAG 2.1 in as close to a single paragraph as I can manage. Some things worth mentioning before I dive in:
- This is for me, but hopefully it will help you get your head around what each rule is driving at
- It’s far from a full explanation; you’ve got WCAG itself and Understanding WCAG for that:
- There’s plenty of over-simplification in order to get to the essence of each rule
- Lots of exceptions that criteria mention are missing in the name of brevity
- There are very few measurements (for example the actual text spacing values in 1.4.12 Text Spacing)
- Some success criteria have been grouped as they kind of feel like the same thing
- I haven’t gone into why each criterion is helpful
- There are very few examples, except where they help keep things brief
Can people read the content?
1.1.1 Non-text Content
Images should have descriptive (
1.2.1 Audio-only and Video-only (Prerecorded)
Any audio-only content should also be conveyed in text. Any video content with no audio track should also be described in text, but could also be described with audio.
1.2.2 Captions (Prerecorded)
The audio in videos should be captioned.
1.2.5 Audio Description (Prerecorded)
Actions, descriptions, and other important non-audio content in videos should be described in captions or a separate audio track.
(The level A 1.2.3 Audio Description or Media Alternative (Prerecorded) allows for a text-based alternative, like a screenplay, but only captions meet AA, so 1.2.5 trumps 1.2.3.)
1.2.4 Captions (Live)
Live videos that include audio should be captioned.
1.3.1 Info and Relationships
Information or relationships between content that is visual is also conveyed through the code, via HTML or ARIA (for example the
for attribute on a form label, or
aria-describedby on an input that has hint text).
1.3.2 Meaningful Sequence
The visual presentation of the content matches what’s read out by a screen reader.
1.3.3 Sensory Characteristics
Nothing is referred to just by its colour, size, position, shape, and so on.
Rotating a device from portrait to landscape doesn’t stop everything being perfectly readable and usable.
1.3.5 Identify Input Purpose
The purpose of form fields can be identified by the browser, so that auto-complete suggestions can be offered in a dropdown.
1.4.1 Use of Color
Colour shouldn’t be the only thing used to convey meaning.
1.4.2 Audio Control
Auto playing audio that lasts more than 3 seconds can be turned down or stopped.
1.4.3 Contrast (Minimum) and 1.4.11 Non-text Contrast
Text has a contrast ratio of 4.5 to 1. Large text can be a 3 to 1 ratio if it’s over 24px, or bold and over 19px.
Usable components like form fields and buttons, and graphics like pie charts and line graphs should have a contrast ratio of 3 to 1.
1.4.5 Images of Text
Text is actual text; not images of text.
1.4.4 Resize text, 1.4.10 Reflow, and 1.4.12 Text Spacing
The page is fully responsive. The content adjusts and is readable and usable:
- When the zoom is set to 200% in the browser’s settings
- At viewport sizes from 320px and up
- When custom styles are added to increase the spacing of letters, words, lines, and/or paragraphs
1.4.13 Content on Hover or Focus
Tooltips can be dismissed, usually via the esc key, the text in the tooltip can be selected, and they don’t time out on their own.
Can people use the content?
Can you get around using the keyboard alone.
2.1.2 No Keyboard Trap
There shouldn’t be a situation where you enter a modal with the keyboard and can’t get back to where you were.
2.1.4 Character Key Shortcuts
Keyboard shortcuts should use modifier keys, like ctrl, command, or alt/option.
2.2.1 Timing Adjustable
Time limits should be avoided unless they’re able to be extended.
2.2.2 Pause, Stop, Hide
Automatically moving/animating content that lasts more than 5 seconds should be able to be stopped or hidden.
Seizures and Physical Reactions
2.3.1 Three Flashes or Below Threshold
Nothing flashes, blinks, or flickers more than three times in one second.
2.4.1 Bypass Blocks
‘Skip links’ are available for keyboard users to jump past navigation.
2.4.2 Page Titled
Each page has a unique
<title> that describes what’s on that page.
2.4.3 Focus Order
When a keyboard user tabs through a page, the order goes from top to bottom and left to right, as you would read the page.
2.4.4 Link Purpose (In Context)
It is clear where a link will take you from either:
- The link text itself
- The information in the sentence leading up to the link
2.4.5 Multiple Ways
Header navigation is not the only way to get around a website; there’s another way, such as on-page links, a sitemap, or a site-wide search.
2.4.6 Headings and Labels
Headings are descriptive of the content that they contain, form labels clearly describe what information is required, and buttons inform the user what will happen when they’re pressed.
2.4.7 Focus Visible
There’s visible keyboard focus styling to indicate which element you’re currently focused on.
2.5.1 Pointer Gestures
All actions that are carried out using a gesture (swiping, pinching, and so on) or drawing, can also be done with a button or buttons.
2.5.2 Pointer Cancellation
Actions (like pressing a button) aren’t triggered on mouse-down; rather on mouse-up.
2.5.3 Label in Name
The visible text of a form field, button, or link matches the text in the underlying code.
2.5.4 Motion Actuation
There is no reliance on device motion, like shaking or tilting, to carry out an action.
Can people understand the content?
3.1.1 Language of Page
lang attribute on the
<html> element that matches the language of the page.
3.1.2 Language of Parts
Any parts of the page that are in a different language to the page itself are marked up with the appropriate
lang value. Names and phrases derived from other languages, like “Déjà vu” in English, don’t need this.
3.2.1 On Focus and 3.2.2 On Input
Nothing unexpected changes when:
- something on the page receives keyboard focus, like a
- the value of a form field, like an
<select>, is chosen
3.2.3 Consistent Navigation
Navigation is consistent from page to page.
3.2.4 Consistent Identification
Things that carry out a particular function should always look and work the same.
3.3.1 Error Identification and 3.3.3 Error Suggestion
Error/validation messages should be communicated in text, and should provide suggestions to help the user successfully proceed.
3.3.2 Labels or Instructions
As much help as is needed is offered to prevent triggering a form error; the form label may be enough, but hint text may also be required.
3.3.4 Error Prevention (Legal, Financial, Data)
Important forms like a legal agreement or submitting financial information offer the opportunity to check the information entered before sending.
Can machines (browsers, screen readers, etc.) read the code?
The markup has been validated and there are no errors, such as duplicate
ids, missing tags, and invalid child elements.
4.1.2 Name, Role, Value
The semantic meaning of every interactive element (form controls, links, headings, landmarks, tables, and so on) is correct, and each has an accessible name.
4.1.3 Status Messages
Messages like form errors and success pop-ups are communicated to assistive technology like screen readers.