WCAG for humans
The Web Content Accessibility Guidelines (WCAG) summarised on one page in 7 themes.
WCAG is the main international minimum standard making websites work for disabled people. This is my handwritten interpretation of version 2.2 level AA - the latest version and most commonly used level.
This is only a summary of WCAG, not a replacement, to give you a broad idea of what it involves. You will still need to read the finer detail when doing any accessibility work. More about WCAG.
7 themes (colourful stripes)
This guide groups WCAG by 7 practical themes instead of the traditional structure of Perceivable, Operable, Understandable and Robust (POUR). Overall, it covers 55 success criteria — testable things to ensure you pass WCAG.
To meet WCAG 2.2 AA, websites need to:
This guide uses the term "website". However, the same comments largely apply to documents and to mobile apps too.
The following themes are the same as the WCAG map but each success criterion only appears in one section, to keep this page simple.
How success criteria map to this guide
If you already know which success criterion you're interested in, here's how it maps to this guide.
| Success criterion | Theme | Requirement |
|---|---|---|
| 1.1.1 Non-text content (A) | Sensory | Images need text alternatives |
| 1.2.1 Audio/video only (A) | Sensory | Audio and video need alternatives |
| 1.2.2 Captions (prerecorded) (A) | Sensory | Audio and video need alternatives |
| 1.2.3 Audio description or media alternative (A) | Sensory | Audio and video need alternatives |
| 1.2.4 Captions (live) (AA) | Sensory | Audio and video need alternatives |
| 1.2.5 Audio description (AA) | Sensory | Audio and video need alternatives |
| 1.3.1 Info and relationships (A) | Code and labels | Code must reflect how structured content looks |
| 1.3.2 Meaningful sequence (A) | Code and labels | Code must reflect how structured content looks |
| 1.3.3 Sensory characteristics (A) | Forms | Forms must be easy to complete |
| 1.3.4 Orientation (AA) | Gestures | Content must work in portrait and landscape |
| 1.3.5 Identify input purpose (AA) | Forms | Forms must be easy to complete |
| 1.4.1 Use of colour (A) | Sensory | Information must not rely on colour |
| 1.4.2 Audio control (A) | Sensory | Content must not disrupt you |
| 1.4.3 Contrast (AA) | Sensory | Things need enough contrast |
| 1.4.4 Resize text (AA) | Zoom and legibility | Content must be readable at different zoom levels |
| 1.4.5 Images of text (AA) | Sensory | Images need text alternatives |
| 1.4.10 Reflow (AA) | Zoom and legibility | Content must be readable at different zoom levels |
| 1.4.11 Non-text contrast (AA) | Sensory | Things need enough contrast |
| 1.4.12 Text spacing (AA) | Zoom and legibility | Content must be readable at different zoom levels |
| 1.4.13 Content on hover or focus (AA) | Gestures | Hover and focus content must be usable |
| 2.1.1 Keyboard (A) | Keyboard | Functionality must work with a keyboard |
| 2.1.2 No keyboard trap (A) | Keyboard | Keyboard focus must be able to move through the page |
| 2.2.1 Timing adjustable (A) | Forms | Forms must be easy to complete |
| 2.2.2 Pause, stop, hide (A) | Sensory | Content must not disrupt you |
| 2.3.1 Three flashes or below threshold (A) | Sensory | Content must not disrupt you |
| 2.4.1 Bypass blocks (A) | Keyboard | Keyboard focus must be able to move through the page |
| 2.4.2 Page titled (A) | Whole site | It must be easy to find your way around a site |
| 2.4.3 Focus order (A) | Keyboard | Keyboard focus must be visible and logical |
| 2.4.4 Link purpose (A) | Code and labels | Things need appropriate labels |
| 2.4.5 Multiple ways (AA) | Whole site | It must be easy to find your way around a site |
| 2.4.6 Headings and labels (AA) | Code and labels | Things need appropriate labels |
| 2.4.7 Focus visible (AA) | Keyboard | Keyboard focus must be visible and logical |
| 2.4.11 Focus not obscured (AA) | Keyboard | Keyboard focus must be visible and logical |
| 2.5.1 Pointer gestures (A) | Gestures | Functionality must not rely on gestures |
| 2.5.2 Pointer cancellation (A) | Gestures | Pointer mistakes must be prevented |
| 2.5.3 Label in name (A) | Code and labels | Things need appropriate labels |
| 2.5.4 Motion actuation (A) | Gestures | Functionality must not rely on gestures |
| 2.5.7 Dragging movements (AA) | Gestures | Functionality must not rely on gestures |
| 2.5.8 Target size (AA) | Gestures | Pointer mistakes must be prevented |
| 3.1.1 Language of page (A) | Code and labels | Languages must be specified in code |
| 3.1.2 Language of parts (AA) | Code and labels | Languages must be specified in code |
| 3.2.1 On focus (A) | Keyboard | Focus must work predictably on focus or input |
| 3.2.2 On input (A) | Keyboard | Focus must work predictably on focus or input |
| 3.2.3 Consistent navigation (AA) | Whole site | Things must be consistent across pages |
| 3.2.4 Consistent identification (AA) | Whole site | Things must be consistent across pages |
| 3.2.6 Consistent help (A) | Whole site | Things must be consistent across pages |
| 3.3.1 Error identification (A) | Forms | Forms must help you avoid errors |
| 3.3.2 Labels or instructions (A) | Forms | Forms must be easy to complete |
| 3.3.3 Error suggestion (AA) | Forms | Forms must help you avoid errors |
| 3.3.4 Error prevention (AA) | Forms | Forms must help you avoid errors |
| 3.3.7 Redundant entry (A) | Forms | Forms must be easy to complete |
| 3.3.8 Accessible authentication (AA) | Forms | Logging in must not require a test |
| 4.1.2 Name, role, value (A) | Code and labels | Information on interactive things must be available in code |
| 4.1.3 Status messages (AA) | Code and labels | Information on interactive things must be available in code |
1. Keyboard
Not everyone can use a mouse or touchscreen, so websites must work with a keyboard. This also benefits people who use screen readers and voice control software.
Functionality must work with a keyboard
Common controls are:
- tab to move through links, buttons and forms
- enter or space to activate things
- arrow keys to navigate some menus
- escape (esc) to dismiss some content
Keyboard issues often occur when developers use custom components instead of standard HTML (Hypertext Markup Language).
References for keyboard working
Keyboard focus must be visible and logical
When you navigate using a keyboard, interactive elements must show a visible indicator to show you where the focus currently is.
The order that things receive keyboard focus must be meaningful and usable.
Focused components must not be hidden by other objects.
References for Keyboard focus
Keyboard focus must be able to move through the page
Keyboard focus must never get trapped in part of a page. While it's fine to limit focus to a currently highlighted section like a cookie banner, there must be a way to exit that section using the keyboard.
Where there are repeated menus, there must be an easy way to skip past them, like a "skip to main content" link.
References for Focus not stuck
Focus must work predictably on focus or input
Keyboard focus must stay where you expect it to when you focus on a form field, or update an interactive element like a checkbox.
References for On focus or input
2. Zoom and legibility
Content must be readable at different zoom levels
Text must be readable at 200% zoom, to help people who need to read larger text.
Content and functionality must also work on a small screen (320 pixels wide), without requiring you to scroll side by side, unless the layout is essential.
Text must also be readable when spaced out to a reasonable level.
References for Readable content
3. Sensory
Things need enough contrast
Text, interactive components and graphics all need to have enough contrast against their surroundings to make them easy to see.
Contrast is measured using a ratio and there's a contrast checker on this site. To meet level AA:
- Standard text contrast must be at least 4.5 to 1.
- Larger text contrast must be at least 3 to 1. Larger text is at least 18 points (approx. 24 pixels) or 14 point bold (approx. 19 pixels).
- Interactive components and graphics must be at least 3 to 1. This includes focus indicators.
References for Contrast
Information must not rely on colour
Colour must not be the only way to convey or distinguish information.
References for Colour
Images need text alternatives
Meaningful images (or anything else that isn't text) must be described in text for people who cannot see them. In HTML, this is commonly done using the alt attribute on an image img element.
Images that are purely decorative need to be marked as such, for example with alt="".
Important text should not be visually embedded within images as it can be difficult for some people to see. If images do include text, the same text must be available nearby as text rather than in an image.
References for Text Alternatives
Audio and video need alternatives
Audio and video need to work for d/Deaf and blind people, or people with a visual or hearing impairment. In particular, when pre-recorded:
- Videos with audio (such as documentaries) need to have captions and an audio description for all meaningful content.
- Video-only content (such as a video showcasing a city with background music) needs a transcript or an audio description.
- Audio-only content (such as a podcast) needs a transcript.
Some extra points:
- Live videos (such as live presentations) only need to have captions to meet level AA.
- Captions or transcripts are not needed when audio or video is clearly an alternative presentation of text already on the page.
References for Media
- 1.2.1 Audio/video only (A)
- 1.2.2 Captions (prerecorded) (A)
- 1.2.3 Audio description or media alternative (A) (this criterion is redundant when aiming to meet level AA)
- 1.2.4 Captions (live) (AA)
- 1.2.5 Audio description (AA)
Content must not disrupt you
In particular:
- Any moving content (such as videos or carousels) must be able to be paused or hidden if it lasts longer than 5 seconds.
- Flashing content can cause seizures, so content must not flash more than 3 times a second.
- Autoplaying audio must be able to be stopped or turned down if it lasts longer than 3 seconds.
References for Disruptive content
4. Code and labels
People who use assistive technology, such as screen readers or voice control software, need content to use appropriate code and accessible names (which are read to assistive technologies).
Code must reflect how structured content looks
Common examples:
- Headings must be coded as headings rather than just large, bold text. The visible heading hierarchy must also be correctly coded.
- Lists must be coded as lists, rather than manually adding bullets or numbers.
- Table header rows (usually the first row) or columns must be coded as headers.
This can usually be achieved by using HTML correctly. Where HTML alone cannot communicate structure, additional code called ARIA (Accessible Rich Internet Applications) may be used to complete any information given to assistive technology users.
The page must also be readable in a logical order to everyone including screen reader users.
References for Consistent code
Information on interactive things must be available in code
An interactive component must include the following information in its code so that it can be conveyed to assistive technology users:
- An accessible name (such as "I have read the terms and conditions")
- A role which says what it is (such as "checkbox")
- A value or state, where applicable (such as a state of "checked")
This is easiest to achieve by using HTML correctly.
Also, whenever a status update appears dynamically on a page (like an error message or the number of search results available), that update must be read out "live" to screen reader users.
References for Interactive info
Things need appropriate labels
A link's purpose needs to be clear either from its text alone or its immediate context.
All headings and labels need to be descriptive.
Whenever there's a visible text label (for example "Search"), that must be part of the component's accessible name that's used by assistive technologies. For example, a speech recognition user might say "Click Search".
References for Labels
Languages must be specified in code
The language of the text - for example English - must be specified in the code. If there's a section of text in different language, the change must also be marked.
References for Languages
5. Forms
Forms must be easy to complete
Forms must have labels or instructions to help you complete them.
To make it easier to fill in forms:
- Instructions must not rely solely on sensory descriptions (for example, "click the green button").
- Any time limits below 20 hours must be extendable (with a warning), unless the time limit is essential.
- Input fields asking for personal information must automatically fill in the data, if available. This is done by adding
autocompletevalues to the code. - You must not have to manually enter the same information twice.
References for Easy forms
Forms must help you avoid errors
When filling in a form and an error is generated, it must be clear where the error lies. The error must also be described in text, and suggestions on how to fix it must be provided whenever possible.
When submitting a form related to legal, financial or other important data, there must be a way to either reverse the submission, automatically check it for errors, or invite you to check the data before you submit it.
References for Error handling
Logging in must not require a test
When logging in, you must not have to rely on memorising a passcode, or any kind of test like solving a puzzle. It's OK if the field where a passcode allows text to be pasted into it, or if there's an accessible alternative.
References for Login
6. Gestures
Functionality must not rely on gestures
Functionality must not require you to:
- move your pointer in a gesture (along a path, or with more than one finger - for example, pinch to zoom)
- drag your pointer (for example, swiping in a menu)
- move yourself or your device (for example, shake to undo)
"Pointer" means input from a device such as a mouse, touchscreen or stylus.
It's fine to have this functionality as long as there's an accessible alternative.
References for Relying on gestures
Pointer mistakes must be prevented
For clickable things such as links and buttons, to avoid errors:
- They must work when you release a click or tap, not the moment you click or tap them.
- They must be big enough or spaced far enough apart - at least 24 pixels from centre to centre.
References for Pointer mistakes
Hover and focus content must be usable
When extra content becomes visible on hover or keyboard focus, it must be there as long as you need it, including when you hover over it. You must also be able to dismiss overlapping content without moving the hover or focus.
References for Hover and focus
Content must work in portrait and landscape
On a mobile device, the content must work in both portrait and landscape orientations.
References for Portrait and landscape
7. Whole site
It must be easy to find your way around a site
Pages must have descriptive titles (this is the text that appears in the browser tab, which comes from the HTML title element). They should also usually be different for every page.
There must be more than one way to get to anything that's not part of a process - like a navigation menu, search or a sitemap.
References for Wayfinding
Things must be consistent across pages
The following things need to be the same between pages:
- component names (like search buttons)
- the relative order of any navigational menu items
- the relative order of any help options, such as contact details or self help
References for Consistency
More about WCAG
WCAG structure
WCAG is grouped into four principles:
- Perceivable — people need to know that content or functionality is there
- Operable — people need to be able to use things
- Understandable — things need to be easy to understand
- Robust — things need to be compatible with different technology
A principle like 2. Operable has guidelines within it, such as 2.4 Navigable. Within those, there are success criteria such as 2.4.7 Focus visible. However, criteria that are closely related in practice can sometimes appear under different guidelines.
This guide uses an alternative approach, grouping by practical theme (such as Keyboard), then requirements (such as Keyboard focus must be visible and logical), then the same success criteria (such as 2.4.7 Focus visible).
To understand each success criterion in more detail, go to the official Understanding documents or read one of the other explainers below.
WCAG levels (A, AA, AAA)
Every WCAG criterion has a level: A, AA or AAA:
- Level A: top priority
- Level AA: important criteria
- Level AAA: more specialist areas
To pass at any level, you also need to pass the ones before it. For example, a level AA pass includes all level A and AA criteria.
The legal standard in many countries is to pass at level AA, and most accessible websites aim for this as a minimum.
Other guides
My work
The WCAG 2.2 map illustrates the 7 themes as a transport map.
If you're testing, the WCAG decision tree follows a similar structure to help you check against every criterion.
Other WCAG explainers
There are plenty of other WCAG explainers out there which approach WCAG from different angles (some of which I've contributed to). The official summary is WCAG 2 at a glance.
Guides from the UK Government:
- WCAG Primer
- Doing a basic accessibility check if you cannot do a detailed one
- Accessibility testing guide
Other interpretations:
- WCAG 2.2 Card Deck by Johannes Lehner
- WCAG in Plain English by AAArdvark
About this guide
This project was inspired by Martin Underhill's WCAG, but in language I understand. However, I wanted to group WCAG by theme rather than numerically.
It's intentionally simple and does not replace WCAG – I believe that it's fine (possibly even good) to skip some of the finer details of WCAG if it helps more people understand the core intent behind it.
The themes in this guide are not official but they have been used elsewhere, including the card deck and WCAG in Plain English mentioned above.
Feedback is welcome via the contact details at the end of this page.
Thanks
Many thanks to Martin Glancy for reading an initial draft.
Also thank you to Adrian Roselli and Eric Eggert for the constructive suggestions.
Licence
Thanks for visiting! This work is licensed under Creative Commons: CC BY-NC 4.0
I'm happy for anyone to use or adapt this guide but please:
- add credit, with a link back to AndrewHick.com/humans
- share or rework it accessibly (for example, add alternative text to any images)
- ask me before using it commercially