Kris’s WCAG Checklists are $0 to download with no email subscription required.
Below you will find downloadable PDF checklists for WCAG 2.1 AA and 2.2 AA along with the text version of each checklist on this page (WCAG 2.0 AA is included in 2.1).
Written in plain English, Kris Rivenburgh explains the Web Content Accessibility Guidelines (WCAG) in easy to understand terms, with examples and illustrations to help readers learn each WCAG success criterion.
Kris provides two PDF documents for learning WCAG: a checklist and a full guide.
The checklist PDFs contain quick summaries for each WCAG success criterion. The guides greatly expand upon the checklists to provide fuller, more detailed explanations.
WCAG 2.1 AA conformance is a best practice for compliance with the law.
Reader Note: For mobile viewing, this page displays best on landscape orientation because there are tables that include longer success criteria.
Note that WCAG 2.1 AA includes WCAG 2.0 AA (38 success criteria) + 12 additional AA success criteria added in version 2.1 for a total of 50 success criteria or requirements.
Each PDF contains important disclaimers, copyright, and attribution information.
| Success Criterion | Accessibility Requirement | Role(s) |
|---|---|---|
| 1.1.1 | All images and non-text content must have a text alternative. | Developer, Content Editor |
| 1.2.1 | All video-only and audio-only content must have a text transcript, labeled and accessible. | Content Editor |
| 1.2.2 | All videos with sound must have closed captioning. | Content Editor |
| 1.2.3 | Videos must have transcripts or audio descriptions if necessary information isn’t audible. | Content Editor |
| 1.2.4 | Formal live presentations must have closed captions. | Content Editor |
| 1.2.5 | Audio descriptions are required, providing both transcripts and audio descriptions is best. | Content Editor |
| 1.3.1 | Use proper HTML markup to structure content programmatically accessible. | Developer, Content Editor |
| 1.3.2 | Present content in a meaningful sequence for readability. | Developer |
| 1.3.3 | Instructions should not rely on a single sensory ability. | Content Editor |
| 1.4.1 | Do not use color alone to convey information. | Designer, Content Editor |
| 1.4.2 | Provide controls to pause, stop, or mute audio. | Developer |
| 1.4.3 | Ensure color contrast ratios meet minimum requirements. | Designer |
| 1.4.4 | Text must be able to be resized up to 200% without loss of content or functionality. | Designer |
| 1.4.5 | Do not use images of text unless necessary (e.g., logo). | Designer, Content Editor |
| 2.1.1 | All functionality of the website must be accessible by keyboard only, without requiring a mouse. | Developer |
| 2.1.2 | Keyboard-only users must be able to navigate through the website without getting stuck. | Developer |
| 2.2.1 | If there are any time limits on the website, users must have the ability to turn them off, adjust, or extend them. | Developer |
| 2.2.2 | If content blinks, scrolls, or moves, users must have the ability to pause, stop, or hide it. | Designer, Developer, Content Editor |
| 2.3.1 | Web pages do not contain anything that flashes more than three times in any one second period. | Designer, Content Editor |
| 2.4.1 | A “Skip to Content” or similar link allows users to bypass blocks of content that are repeated on multiple pages. | Developer, Designer |
| 2.4.2 | Each page of a website needs to have a unique and descriptive title. | Content Editor |
| 2.4.3 | Users must be able to navigate through the website in a logical order that preserves meaning. | Developer |
| 2.4.4 | The purpose of each link should be clear from its anchor text. | Content Editor |
| 2.4.5 | There must be multiple ways to find different pages and content on a website. | Designer |
| 2.4.6 | Headings and labels must be clear and descriptive. | Content Editor |
| 2.4.7 | Any user interface control that receives focus from a keyboard user should have a visible focus indicator. | Designer |
| 3.1.1 | Set the language of your website programmatically to aid user agents and assistive technologies. | Developer |
| 3.1.2 | Indicate any language changes within the content or for the entire page. | Content Editor |
| 3.2.1 | No context changes should occur merely because an item receives focus. | Developer, Designer |
| 3.2.2 | User interface changes should not automatically occur due to user input without a warning. | Developer |
| 3.2.3 | Keep navigation links and layout consistent throughout all pages of the website. | Designer |
| 3.2.4 | Components that have the same function within a website are consistently identified. | Developer, Designer |
| 3.3.1 | Make any form errors easy to identify, understand, and correct. | Developer, Designer |
| 3.3.2 | Provide clear visual and programmatic labels or instructions for user input fields. | Developer |
| 3.3.3 | If an input error is automatically detected, then suggestions for correcting the error should be provided. | Developer |
| 3.3.4 | For pages that create legal commitments or financial transactions, ensure that submissions are reversible, errors can be corrected, and confirmation is available before submission. | Developer |
| 4.1.1 | Ensure HTML code is clean and free of errors. All HTML elements must be properly nested and closed. | Developer |
| 4.1.2 | For all user interface components, ensure the name, role, state, and value can be programmatically determined. | Developer |
Note: 2.1 AA includes all of the preceding 2.0 AA success criteria plus the 12 additional success
criteria added in 2.1.
| Success Criterion | Accessibility Requirement | Role(s) |
|---|---|---|
| 1.3.4 | Your website does not lock on portrait or landscape mode, unless necessary. | Developer |
| 1.3.5 | The purpose of an input element can be determined so browsers and assistive technology can help guide and facilitate inputting information (e.g., provide autocomplete option). | Developer |
| 1.4.10 | Ensure someone can zoom in on your website without requiring scrolling or causing poor experience. | Designer |
| 1.4.11 | All meaningful non-text content (e.g., buttons, form fields, icons) on your website should have a minimum 3:1 color contrast ratio to ensure they stand out. | Designer |
| 1.4.12 | Make sure your text spacing can be adjusted without causing a poor experience. | Designer |
| 1.4.13 | Make it so any additional content (e.g., pop-ups, submenus) can be dismissed or remain visible if the user desires. | Designer, Developer |
| 2.1.4 | If you have a keyboard shortcut, make sure a user can either 1) turn it off, 2) there’s a way to add another key in the shortcut, and/or 3) have the shortcut only active while focusing on a specific component. | Developer |
| 2.5.1 | Provide simple alternatives (e.g., single tap vs. swipe) to potentially complex finger motions on touch screens. | Developer |
| 2.5.2 | Provide a way to cancel the trigger action when you activate a function using a mouse or press/touch with your finger. | Developer |
| 2.5.3 | Make sure any programmatic labels you make are aligned with the corresponding visual text. | Developer |
| 2.5.4 | For any functions that are activated by motion, provide a simpler, alternative means of action. Also, give users the option to turn off motion activation. | Developer |
| 4.1.3 | When a status message appears, it should be coded with role or properties so that people using assistive technologies (e.g., screen readers) are alerted without losing focus. | Developer |
Each PDF contains important disclaimers, copyright, and attribution information.
| Success Criterion | Accessibility Requirement | Role(s) |
|---|---|---|
| 2.4.11 | When an element receives focus, ensure it is not completely hidden or blocked by other content, such as sticky headers or footers. | Developer, Designer |
| 2.5.7 | For functions requiring a dragging movement, provide an alternative using a single point (click or touch) to accomplish the task. | Developer |
| 2.5.8 | Ensure the target size for interactive elements is at least 24 by 24 CSS pixels, with specified exceptions. | Designer |
| 3.2.6 | Help options such as support links, contact information, or chatbots should remain consistent and predictable on multiple pages. | Content Editor, Designer |
| 3.3.7 | Auto-populate or make selectable previously entered information within the same session unless re-entry is essential. | Developer |
| 3.3.8 | Ensure users can authenticate without solely relying on memory or cognitive tests, offering alternative methods or assistance. | Developer |
You can make learning WCAG even easier and faster by taking the on-demand course from Kris.
Kris’s WCAG checklists and guides are 100% free resources with no subscription required. If you find these documents helpful, we encourage you to share the link to this page (https://accessible.org/wcag) so more people can find out about these resources.
Thank you so much for sharing our accessibility resources.
WCAG stands for the Web Content Accessibility Guidelines. These guidelines are technical standards for web accessibility that bring about consistency and uniformity in how we make web content accessible. Developed by the W3C, WCAG helps ensure websites and online platforms are accessible by people with disabilities. Notably, WCAG conformance not only improves accessibility, but usability as well.
WCAG conformance improves access to people with one or more of the following disabilities.
Visual Impairments: Individuals who are blind, have low vision, or color blindness may use screen readers or other assistive technologies to access web content. Most WCAG success criteria are related to access for people with vision impairments. One key theme is that content that is available visually is also available programmatically.
Auditory Impairments: People who are deaf or hard of hearing may not be able to hear auditory cues (e.g., a chime indicator), audio (e.g., a podcast), or audio from a video so there are multiple WCAG success criteria that provide for alternatives to audio.
Motor Disabilities: Individuals with motor impairments may have difficulty using a mouse or keyboard. There are also multiple success criteria that address keyboard navigability and user control, ensuring that all functionality is accessible without requiring precise movements and that users can maintain control when navigating.
Cognitive Disabilities: People with cognitive disabilities may have difficulties with comprehension, focus, memory, and problem-solving. Several success criteria emphasize making content clear, understandable, intuitive and predictable.
Neurological Disabilities: Conditions like epilepsy may be triggered by certain types of visuals. There are two AA success criteria that specifically address blinking or flashing content that could potentially cause seizures.
Speech Impairments: Users with speech impairments may rely on alternative input methods or assistive technologies to interact with web content. WCAG provides for alternative input methods that do not rely solely on voice interactions.
The Web Content Accessibility Guidelines are guided by four principles, embodied by the acronym POUR. Let’s explain what each letter represents.
Perceivable: This principle focuses on ensuring that web content can be perceived by all users, regardless of their sensory abilities. Perceivable content means that information and user interface components must be presented in multiple ways in which users can perceive content.
Operable: The operable principle emphasizes that user interface components and navigation must be operable by all users, including those who rely on keyboards, touchscreens, screen readers, speech recognition software, or other input devices.
Understandable: This principle focuses on making web content understandable to all users, regardless of their cognitive abilities or familiarity with the content.
Robust: The robust principle means that web content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies. Moreover, robust implies that technologies follow best practices for coding and ensuring that content is future-proofed and remains accessible as technologies evolve.
There are multiple versions and conformance levels of WCAG. The versions are:
Think of 2.0 as the classic standard. It was released in 2008. 2.0 establishes a solid baseline for accessibility, providing foundational guidelines that address a wide range of disabilities. This version is key for ensuring that websites are usable and understandable by people with various impairments.
2.1 was released in 2018 and added additional considerations for the increase in mobile device usage. This update brought enhancements that improved accessibility on touch interfaces, small screens, and for users with low vision.
2.2 is now the current version and was only just released in October 2023. This latest edition continues to refine the guidelines, addressing emerging technologies and additional user needs to enhance digital accessibility further.
No matter which version, each is comprised of different success criteria or requirements for conformance that are categorized under different conformance levels.
The conformance levels are:
Level A criteria lay the essential foundation for accessible content. Level AA criteria are also extremely important and build upon the Level A foundation. Level AAA criteria adhere to the most rigorous standards, offering the highest level of accessibility.
WCAG is frequently cited around the world and while WCAG is never the law, it has been incorporated into several laws including Section 508 of the Rehabilitation Act, the Accessibility for Ontarians with Disabilities Act, and the European Accessibility Act.
WCAG is also commonly referenced in website accessibility litigation centered around the Americans with Disabilities Act (ADA).
Think of success criteria as things you can do to improve accessibility. Many people are familiar with accessibility considerations such as:
These considerations are a part of the fabric of the Web Content Accessibility Guidelines. Some are essentially success criteria themselves while others may be considered sufficient techniques for conformance or advisory techniques that enhance or optimize accessibility.
A key feature of the Web Content Accessibility Guidelines (WCAG) is that the versions and conformance levels are backwards compatible. This means that new versions of the guidelines build upon previous versions, rather than undoing them.
This also means that when a new version is released, such as going from WCAG 2.0 to WCAG 2.1, the core requirements remain intact, and only new criteria are added. For example, WCAG 2.1 AA includes all the success criteria from WCAG 2.0 (38) and introduces 12 additional success criteria to address accessibility considerations in newer technology, including considerations for mobile devices.
This backwards compatibility ensures that conformance efforts made for earlier versions are not undone and ensuring stability no matter what version is being used.
Further, the same backwards compatibility concept applies to conformance levels; each success conformance level includes the success criteria in the previous conformance level.
Although WCAG is specifically for web assets (they are literally the Web Content Accessibility Guidelines), the principles and concepts that comprise WCAG usually apply to other digital assets including mobile apps, software, virtual applications, platforms, and more.
While WCAG was written for the web, its core principles — perceivable, operable, understandable, and robust (POUR) — are just as relevant to non-web assets. For example:
However, applying WCAG to non-web assets requires adaptation and thus extra attention must be paid when making non-web assets WCAG conformant. We see this come up with VPATs / ACRs.
WCAG has been incorporated into many laws across the world and even where WCAG is not adopted, full WCAG 2.1 AA conformance is always a best practice for compliance.
Laws that have incorporated WCAG include:
In addition to our on demand WCAG Course, we also offer live workshops to help your digital team learn web accessibility.
We offer audit, remediation, and user testing services to help ensure your website is WCAG conformant, no matter what WCAG version you are working on.
We also offer consulting to help make accessibility as easy as possible.
Kris Rivenburgh is the founder and operator of Accessible.org. Kris is an attorney and the author of The ADA Book, the first book on ADA compliance for digital assets. With seven years of experience in digital accessibility and ADA Compliance, Kris advises clients ranging from small businesses to public entities and Fortune 500 companies.
