WCAG 2.2 Explained: A Beginner's Guide to Web Accessibility Standards

What Is WCAG?

WCAG stands for the Web Content Accessibility Guidelines — a set of internationally recognized standards for making web content accessible to people with disabilities. Published by the World Wide Web Consortium (W3C), WCAG is the global benchmark that governments, regulators, and organizations use to define what "accessible" actually means.

Think of WCAG as the building code for the web. Just as physical buildings must meet safety and accessibility standards (ramps, elevators, braille signs), websites must meet WCAG standards to be usable by everyone — including people who are blind, deaf, have motor disabilities, or experience cognitive challenges.

WCAG 2.2 is the latest version, released in October 2023. It's the standard referenced by the European Accessibility Act (EAA) through EN 301 549, making it legally relevant for any business serving EU consumers.

Why WCAG Matters (Beyond Legal Compliance)

Yes, WCAG compliance is increasingly a legal requirement — especially under the European Accessibility Act. But the benefits go far beyond avoiding fines:

• 1.3 billion people worldwide live with some form of disability
• 16% of the global population could be excluded from your website if it's inaccessible
• Accessibility improvements benefit all users — better contrast helps in bright sunlight, captions help in noisy environments, keyboard navigation helps power users
• Accessible sites tend to have better SEO, lower bounce rates, and higher conversion rates

Learn more about the overlap between accessibility and good user experience in our article on why accessibility is UX.

The Four Principles: POUR

WCAG is organized around four foundational principles, known by the acronym POUR. Every guideline and success criterion falls under one of these:

1. Perceivable

Users must be able to perceive the information on your site — meaning it can't be invisible to all of their senses.

In practice, this means:

• Images have descriptive alt text so screen readers can announce them
• Videos have captions for deaf and hard-of-hearing users
• Audio content has transcripts available
• Text and backgrounds have sufficient color contrast (at least 4.5:1 for normal text)
• Information is not conveyed by color alone — icons, text labels, or patterns supplement color

Example: A form that marks required fields only with a red asterisk fails this principle. Adding the text "(required)" alongside the asterisk fixes it.

2. Operable

Users must be able to operate the interface — navigate, interact, and complete tasks regardless of how they interact with the page.

In practice, this means:

• Every function works with a keyboard (Tab, Enter, Escape, arrow keys)
• Users are never trapped in a component (they can always navigate away)
• There are no time limits that can't be adjusted or extended
• Content doesn't flash more than three times per second (to prevent seizures)
• Users can find pages through multiple methods (navigation menu, search, sitemap)
• Focus indicators are clearly visible so keyboard users know where they are

Example: A dropdown menu that only opens on mouse hover is inaccessible. It should also open with keyboard focus and Enter/Space key activation.

3. Understandable

Users must be able to understand both the content and how the interface works.

In practice, this means:

• Text is readable and written at an appropriate level for the audience
• The page language is declared in the HTML (so screen readers use the correct pronunciation)
• Navigation is consistent across pages
• Error messages clearly explain what went wrong and how to fix it
• No unexpected actions happen (like a form submitting when you change a dropdown selection)

Example: A form that says "Error: invalid input" without explaining which field has the error or what format is expected fails this principle.

4. Robust

Content must be robust enough to work reliably with current and future technologies, including assistive technologies like screen readers.

In practice, this means:

• HTML is valid and well-structured (proper opening/closing tags, no duplicate IDs)
• Custom components use correct ARIA roles, states, and properties
• Status messages are programmatically communicated to assistive technologies without requiring focus

Example: A custom toggle switch built with <div> elements won't be recognized by screen readers unless it has role="switch", aria-checked, and keyboard event handlers.

Conformance Levels: A, AA, and AAA

Each WCAG success criterion is assigned a conformance level based on its impact:

Level A — Minimum Accessibility

These are the bare-minimum requirements. Failing Level A criteria means your site has fundamental barriers that block users entirely.

Examples:

• All images must have alt text (or alt="" for decorative images)
• Page must have a language attribute
• No keyboard traps

Level AA — Standard Accessibility (The Target)

Level AA is the standard that laws and regulations reference, including the EAA. It builds on Level A and addresses the most common accessibility barriers encountered by users.

Examples:

• Color contrast ratio of at least 4.5:1 for normal text
• Text can be resized up to 200% without loss of functionality
• Multiple ways to find pages (navigation + search)
• Visible focus indicators

Level AAA — Enhanced Accessibility

Level AAA represents the highest level of accessibility. While it's excellent to strive for, it's not typically required by law and may not be achievable for all types of content.

Examples:

• Enhanced contrast ratio of 7:1
• Sign language interpretation for video content
• Text written at a lower secondary education reading level

Our recommendation: Target Level AA for your entire site. Implement Level AAA criteria where feasible, especially for critical user flows.

What's New in WCAG 2.2?

WCAG 2.2, released in October 2023, added 9 new success criteria (and removed one from 2.1). Here are the most impactful ones you need to know:

Focus Not Obscured (Minimum) — 2.4.11 (Level AA)

When a user tabs to an element, it must not be entirely hidden behind other content. This commonly happens with:

• Sticky headers or navigation bars
• Cookie consent banners
• Chat widgets

Fix: Ensure that when elements receive focus, at least part of the focused element remains visible. Better yet, scroll the focused element into clear view.

Focus Not Obscured (Enhanced) — 2.4.12 (Level AAA)

Same as above, but the focused element must be fully visible — not just partially.

Focus Appearance — 2.4.13 (Level AAA)

Focus indicators must meet specific size and contrast requirements. While this is AAA, implementing strong focus indicators is a best practice for all sites.

Dragging Movements — 2.5.7 (Level AA)

Any functionality that requires dragging (drag-and-drop interfaces, sliders, sortable lists) must have an alternative that doesn't require dragging.

Fix: Add up/down buttons for sortable lists, input fields for sliders, or click-to-place alternatives for drag-and-drop interfaces.

Target Size (Minimum) — 2.5.8 (Level AA)

Interactive elements (buttons, links, form controls) must have a target area of at least 24×24 CSS pixels, unless:

• The target is in a sentence of text (inline links)
• The user agent controls the sizing (default checkboxes)
• There's sufficient spacing between targets

Fix: Make buttons and interactive elements generously sized. When in doubt, go bigger — it improves usability for everyone, not just accessibility.

Consistent Help — 3.2.6 (Level A)

If your site provides help mechanisms (contact info, FAQ links, chat support), they must appear in a consistent location across pages.

Fix: Keep your help/contact options in the same position in your header, footer, or sidebar on every page.

Redundant Entry — 3.3.7 (Level A)

Users shouldn't have to re-enter information they've already provided in a multi-step process, unless re-entry is essential for security.

Fix: Auto-populate fields with previously entered data. If a user enters their shipping address, don't make them type it again for billing — offer a "same as shipping" option.

Accessible Authentication (Minimum) — 3.3.8 (Level AA)

Authentication processes must not require cognitive function tests (like solving puzzles or remembering passwords) unless an alternative is available.

Fix: Support password managers, biometric login, or copy-paste functionality for authentication codes.

WCAG 2.2 vs. WCAG 2.1: What Changed?

| Aspect | WCAG 2.1 | WCAG 2.2 | |--------|----------|----------| | Release date | June 2018 | October 2023 | | Success criteria | 78 total | 86 total (9 new, 1 removed) | | Mobile focus | First to address mobile/touch | Expanded with dragging and target size | | Cognitive accessibility | Limited | Significantly expanded (authentication, redundant entry) | | Legal reference | Previous EN 301 549 versions | Current EN 301 549 / EAA reference |

Key takeaway: If you were already meeting WCAG 2.1 AA, you're most of the way there. WCAG 2.2 adds targeted improvements — focus appearance, target sizing, cognitive accessibility — that you'll need to address.

How to Check Your WCAG Compliance

Automated Testing

Start with automated tools that scan your site against WCAG criteria. These are fast, consistent, and great for catching low-hanging fruit.

Try our free WCAG 2.2 scanner → It checks your pages against all testable WCAG 2.2 AA criteria and delivers a detailed report with specific fix recommendations.

Manual Testing Checklist

After your automated scan, walk through these manual checks:

1. Keyboard navigation — Can you reach and operate every element with only a keyboard?
2. Screen reader — Does every element have an appropriate accessible name?
3. Zoom to 200% — Does the layout adapt? Is anything cut off or overlapping?
4. Zoom to 400% — Does content reflow to a single column?
5. Disable images — Does all important information have text alternatives?
6. Check forms — Are labels associated? Are errors descriptive? Can you complete the form by keyboard?
7. Check media — Do videos have captions? Is there a transcript for audio?

Ongoing Monitoring

WCAG compliance isn't a one-time achievement. Every content update, feature addition, or design change can introduce new issues. Set up regular automated scans and periodic manual reviews to maintain compliance.

For a complete walkthrough of the compliance process, see our EAA compliance checklist.

Common WCAG Misconceptions

"WCAG only applies to government websites." Not anymore. The EAA extends accessibility requirements to private sector businesses across the EU. If you sell products or services to EU consumers, WCAG 2.2 AA is your target.

"Accessibility means my site will look ugly." Absolutely not. Accessible design is good design. Sufficient contrast, clear typography, logical layouts, and intuitive navigation make sites more attractive and usable for everyone.

"We'll just add an overlay widget." Accessibility overlays (toolbar widgets that claim to "fix" accessibility) do not make your site WCAG-compliant. They can introduce new issues, conflict with real assistive technologies, and may not satisfy regulatory requirements. There are no shortcuts — genuine compliance requires fixing the underlying code and content.

"Once we're compliant, we're done." Websites evolve. New content, third-party integrations, and feature updates can break accessibility. Compliance requires ongoing monitoring and maintenance.

Your Next Steps

1. Scan your site now — Get a free WCAG 2.2 compliance report in 60 seconds
2. Review the results — Understand which criteria you pass and which need work
3. Follow our 15-step checklist — A structured approach to achieving compliance
4. Understand the stakes — Read about EAA fines and penalties if you need extra motivation

WCAG 2.2 might seem complex at first, but it boils down to one question: can everyone use your website? Start answering that question today.