WCAG 2.0 vs 2.1: What?s Changed?

Quick answer: WCAG 2.0 vs WCAG 2.1

WCAG 2.1 builds on WCAG 2.0 without removing anything. It was published in 2018 and adds 17 new success criteria that focus on mobile, low vision and cognitive accessibility. If you already meet WCAG 2.1, you meet WCAG 2.0; the reverse is not true.

What WCAG 2.0 set out to do

WCAG 2.0, published in 2008, created a stable, technology-neutral set of success criteria grouped under perceivable, operable, understandable and robust. It became the common baseline for accessible web content and emphasised keyboard access, text alternatives, contrast, predictable navigation and semantic markup.

What WCAG 2.1 added and why

WCAG 2.1 did not replace 2.0. Instead it extended 2.0 by adding criteria that address gaps identified as the web evolved. The additions focus on three main areas:

Mobile and device input

Touchscreens and small viewports introduced new interaction challenges. 2.1 adds criteria to make touch targets, gestures and device-based interactions more accessible.

Low vision users

People with low vision need content that works at larger text sizes, higher zoom and with limited contrast. 2.1 adds checks for reflow, text spacing and non-text contrast to improve readability and meaning when users enlarge content.

Cognitive and learning disabilities

Some new criteria aim to reduce accidental activation and make interfaces simpler to use. These changes cover things such as content that appears on hover, requirements for motion-based actions and clearer relationships between labels and controls.

Key success criteria added (examples)

Below are representative examples of new success criteria introduced in WCAG 2.1. They are listed with their published identifier so you can cross-check the official specification.

Success criterion	What it targets
1.3.4 Orientation	Prevents loss of content or functionality when device orientation changes.
1.4.10 Reflow	Ensures content is usable when text is enlarged or viewport is narrow.
1.4.11 Non-text Contrast	Requires contrast for graphical objects and control components, not only text.
1.4.12 Text Spacing	Allows spacing adjustments for letter, word and line spacing without loss of content.
1.4.13 Content on Hover or Focus	Controls how additional content appears and can be dismissed when hovered or focused.
2.5.1 Pointer Gestures	Makes multi-point or path-based gestures optional or provides an alternative.
2.5.2 Pointer Cancellation	Helps users avoid unintended activation of controls on touch devices.
2.5.3 Label in Name	Ensures the programmatic name of a control contains its visible label for voice input.
2.5.4 Motion Actuation	Prevents actions that trigger based only on motion without an alternative.
2.5.5 Target Size	Helps ensure interactive targets are large enough to be reliably activated on touch screens.

Backward compatibility and legal practicalities

WCAG 2.1 is backward compatible with WCAG 2.0. That means sites conforming to WCAG 2.1 satisfy 2.0. Which version a regulator or contract cites varies by jurisdiction and document. Always check the exact standard named in a law, policy or procurement document before assuming compliance requirements.

Common gaps teams miss

• Relying only on automated tools. Many 2.1 checks require manual testing or keyboard and touch testing.
• Testing only on desktop. Mobile-specific criteria need testing on real devices and with small viewports.
• Ignoring non-text contrast. Controls, icons and focus indicators often fail contrast tests while body text passes.
• Not testing with real users. Low-vision and cognitive accessibility assumptions often miss practical barriers.

Practical upgrade checklist (prioritised)

Use this list to plan an upgrade from WCAG 2.0 to 2.1. Work iteratively and test after each change.

1. Audit — Run an inventory of interactive patterns, forms, menus and custom controls. Include mobile views.
2. Automated scan — Run automated tools to find obvious failures, but mark findings for manual review.
3. Mobile interaction fixes — Check touch targets, gestures, pointer cancellation and motion actuation alternatives.
4. Low-vision checks — Verify reflow, text spacing and non-text contrast. Test at larger text sizes and narrow widths.
5. Hover and focus — Ensure content revealed on hover is dismissible and reachable via keyboard and touch.
6. Labeling for voice — Ensure visible labels are included in programmatic names for voice input tools.
7. User testing — Run short sessions with keyboard users, screen reader users and people with low vision.

Mapping common UI patterns to WCAG 2.1 checks

Here are practical mappings you can use during development and QA.

• Custom buttons and icons: test non-text contrast, target size and keyboard focus visibility.
• Dropdown menus and tooltips: ensure content on hover works with focus and is dismissible.
• Forms on phones: test orientation, identify input purpose and pointer cancellation.
• Animated banners: provide pause/stop controls and avoid motion actuation triggers.

Testing tips and quick checks

• Test keyboard only and touch only for every interactive component.
• Increase text size and narrow the browser or emulator to mimic reflow conditions.
• Check focus styles and the contrast of icons, borders and controls, not only text.
• Use voice activation tools to verify label-in-name behaviour for common controls.
• Include at least 5 users with relevant impairments in short usability tests for the highest value feedback.

Next steps

Start with an audit that includes mobile views. Prioritise fixes that will help many users, such as non-text contrast and reflow. Add manual tests to your CI process so 2.1 regressions are caught early. Finally, involve real users for validation rather than relying on automated checks alone.

Where this guide helps and where to check the spec

This article explains the practical differences between WCAG 2.0 and 2.1 and gives a hands-on upgrade path. For authoritative wording and the complete list of all new success criteria, consult the official WCAG specification from the W3C.