WCAG 2.0 vs. 2.1: What’s the Difference?

Back to blog

WCAG 2.0 vs. 2.1: What’s the Difference?

Posted November 20, 2024

AudioEye

Posted November 20, 2024

Text box reading 'WCAG 2.0 vs WCAG 2.1' sitting above various icons denoting accessibility. The accessibility icon is on top of the text box.
Text box reading 'WCAG 2.0 vs WCAG 2.1' sitting above various icons denoting accessibility. The accessibility icon is on top of the text box.

Ready to see AudioEye in action?

Watch Demo

With future updates coming to the Web Content Accessibility Guidelines in the near future, let’s look at the key differences between WCAG 2.0 vs. 2.1 and which standards you need to meet for ongoing compliance.

The Web Content Accessibility Guidelines (WCAG) are considered the standard for web accessibility. The guidelines are designed to enhance accessibility and usability for individuals with disabilities, including visual, auditory, cognitive, and physical disabilities, ensuring everyone has equal access to digital spaces. 

As digital technologies evolve, the World Wide Web Consortium (W3C), the authors of WCAG, frequently review and update the guidelines to ensure ongoing accessibility for individuals with disabilities. Each new version of WCAG addresses new technology and provides guidance on how organizations can ensure ongoing accessibility for individuals with disabilities. 

Two of the more recent versions of WCAG are 2.0 and 2.1. Below, we’ll explore the difference between each version and explain which version you must follow. We’ll also explain which version of WCAG you need to meet to comply with accessibility laws such as the Americans with Disabilities Act (ADA), the European Accessibility Act (EAA), and the Accessibility for Ontarians with Disabilities Act (AODA).

Before diving into that, here is a quick refresh on WCAG.

What is WCAG?

As mentioned above, WCAG was created by the W3C to ensure websites, mobile apps, online documents, and other digital tools are easy to use and navigate. The guidelines are built around four main principles: perceivable, operable, understandable, and robust (POUR), and include three levels of conformance — A, AA, and AAA. Level AA is considered the standard for compliance with most accessibility laws, including the ADA and Section 508.

A Brief History of WCAG

The first version of WCAG — WCAG 1.0 — was published in 1999 and laid the foundation for digital accessibility. Some of the first WCAG success criteria included providing alt text for images, sufficient color contrast, and compatibility with assistive technologies like screen readers. WCAG 1.0 was a solid start, though limited by the evolving complexity of the internet. 


To keep up with technological advances, the W3C released WCAG 2.0 in 2008, which introduced the four core principles and shifted to a technology-agnostic approach. WCAG 2.0 quickly became a global standard and is still referenced in laws like the ADA and Section 508. WCAG 2.1 was introduced in 2018, with WCAG 2.2 (which is still in draft mode) following in 2023; WCAG 3.0 is also in draft mode and is expected to include even bigger advancements.

Stylized web browser with various icons surrounding it.

The Differences Between WCAG 2.0 vs. 2.1

WCAG 2.1 builds on the foundation of WCAG 2.0 by addressing accessibility gaps in areas like mobile usage, low vision, and cognitive disabilities. While WCAG 2.0 established the core principles of accessibility, it didn’t account for the rise in smartphones and tablets and the accessibility issues faced by some users. WCAG 2.1 introduced 17 new success criteria to ensure digital content works well across modern devices and is more inclusive for a broader range of users. 

We’ll explain each of those 17 new success criteria in more detail below; we’ve grouped each into three categories: low vision, cognitive disabilities, and mobile accessibility improvements.

Low Vision Improvements

1.4.10: Reflow

Content must adjust to fit smaller screens or larger zoom levels (up to 400%) without forcing users to scroll horizontally. This helps users with low vision or those who use screen magnifiers, ensuring they can easily read content without losing context.

1.4.11: Non-text Contrast

Requires sufficient color contrast for non-text elements, including buttons, icons, form inputs, and other non-text elements. WCAG guidelines require a minimum color contrast ratio of 3:1 against adjacent colors to help users with low vision to distinguish between various web elements and their backgrounds.

1.4.12: Text Spacing

Users should be able to adjust the spacing between lines, letters, and paragraphs without breaking the design of the web page. People with dyslexia or who have processing disorders often need more space to improve readability.

1.4.13: Content on Hover or Focus

Ensures that pop-ups or tooltips triggered by hover or focus are accessible — they should be dismissible, hoverable, and visible long enough to read. This prevents frustration for users with vision impairments or motor challenges who may struggle to keep this type of content in view.

2.5.5: Target Size

Touch targets (including buttons) should be large enough to reduce errors or frustration for users with low vision or motor impairments. WCAG guidelines recommend a minimum size of 44x44 pixels, as anything smaller can be difficult to interact with, especially on mobile devices.

Cognitive Disabilities Improvements

1.3.5: Identify Input Purpose

Input fields must be programmatically associated with their purposes, such as marking a field as “email” or “date.” This allows assistive technologies to provide guidance, such as autofill suggestions, making forms easier for users with cognitive disabilities.

1.3.6: Identify Purpose

This criterion expands on 1.3.5 and requires elements like headings, regions, links, or titles to be labeled appropriately so assistive technologies can customize how content is presented to users with cognitive disabilities. For example, a navigation region can be identified as a menu to simplify interpretation.

1.4.12: Text Spacing

Improves readability for users with cognitive impairments by allowing them to customize how text is presented. For example, they can adjust text spacing to reduce visual crowding and make text less overwhelming.

2.2.6: Timeouts

Requires users to be informed about time limits and, where possible, be given the option to extend or disable them. Timeouts can impact users with cognitive or motor disabilities who may need extra time to complete actions.

2.3.3 Animation from Interactions

Ensures users can disable animations triggered by actions like clicking or scrolling. These animations can be distracting to users or even cause disorientation, motion sickness, or seizures.

4.1.3: Status Messages

Status updates, such as form validation messages or system alerts, should be conveyed to assistive technologies without requiring focus changes. This makes feedback easier for users with cognitive disabilities to understand.

Mobile Accessibility Improvements

2.5.1: Pointer Gestures

Requires that complex gestures (like swiping, pinching, or two-finger scrolling) have simpler alternatives, such as a single tap. This helps users with motor impairments who may struggle to perform multi-touch gestures.

2.5.2: Pointer Cancellations

Ensures accidental taps or swipes (e.g., dragging a finger across the screen) can be undone or don’t trigger unintended actions, which reduces frustration for users with limited fine motor control.

2.5.4: Motion Actuation

Provides alternative controls for features activated by motion, like shaking or tilting a device. This benefits users with limited mobility or those who cannot perform specific motions.

2.1.4: Character Key Shortcuts

Single-character keyboard shortcuts (like “S” for the search” must be adjustable or disabled to prevent accidental reactivation, especially for users relying on voice input or switch controls.

2.5.6: Concurrent Input Mechanisms

Ensures users can switch between input methods, such as touchscreen, keyboard, or mouse, without losing functionality. This flexibility is essential for users needing alternative inputs based on context or cognitive impairments.

2.5.3: Label in Name

Requires that visible labels match their programmatic names to improve compatibility with voice controls. For example, if a button says ‘submit’, users should be able to activate it by saying “submit.”

Accessibility symbol surrounded by text boxes with various WCAG success criteria.

Which Version of WCAG Should You Follow?

To be compliant with accessibility laws like the ADA, EAA, AODA, and others, you’ll need to meet all the Level AA requirements in WCAG 2.1. 

One thing that’s important to understand about the different versions of WCAG is that each one includes all the success criteria from the previous version. For example, WCAG 2.1 includes all success criteria from WCAG 2.0. By implementing all Level AA success criteria in WCAG 2.1, you’re also meeting success criteria in WCAG 2.0. 

Though WCAG 2.2 is still in draft mode, it’s recommended you include the nine additional success criteria contained in the version now. Doing so can help you stay on top of changing accessibility laws and further enhance the accessibility of your digital content. 


The best way to determine which WCAG success criterion you’re meeting (or not meeting) is to test your digital content using an accessibility checker like AudioEye’s. By testing your digital content, you’ll have a better idea of how accessible your existing content is, where improvements need to be made, and streamline your path to compliance. You can also use a WCAG checklist to help you keep track of your progress.

Meet Accessibility Standards with Confidence

WCAG 2.1 builds on the foundation of WCAG 2.0, filling in gaps for mobile accessibility, low vision support, and cognitive disabilities to make digital content more accessible and usable by individuals with disabilities. 

However, accessibility isn’t just a check box — it requires regular testing against WCAG guidelines and adjustments to stay ahead of evolving accessibility requirements like WCAG 2.1 and the upcoming WCAG 2.2. That’s where AudioEye can help. 

AudioEye’s three-pronged approach to accessibility combines AI-driven automation technology, Expert Audits from the disability community, and testing throughout the development process to achieve industry-leading compliance with accessibility standards. We start with a free accessibility scan that tests your content for 30 WCAG success criteria (more than any other tool on the market), giving you a clear starting point for enhancing the accessibility of your content.


Don’t navigate WCAG or accessibility compliance on your own. Get a free scan of your site using our Web Accessibility Scanner below, or schedule a demo to see AudioEye in action.

Ready to see AudioEye in action?

Watch Demo

Ready to test your website for accessibility?

Scan your website now.

Share post

Topics:

Keep Reading