WCAG compliance means meeting the Web Content Accessibility Guidelines published by the W3C, the global standard for making web content usable by people with disabilities. WCAG 2.2 is the current version, organized into four principles, three conformance levels (A, AA, AAA), and dozens of success criteria. Compliance is both an ethical baseline — the web should work for everyone — and a legal requirement in most jurisdictions through laws like the ADA, Section 508, EAA, and AODA. This guide walks through what WCAG covers, what each level demands, and how to bring any website into compliance.
What WCAG Actually Is
The Web Content Accessibility Guidelines are a consensus standard developed by the Web Accessibility Initiative at the W3C. The standard defines testable criteria for accessibility, organized so that designers, developers, content authors, and quality testers can verify compliance.
WCAG is not a law. It is a technical specification that laws reference. When the Americans with Disabilities Act (ADA), Section 508 of the U.S. Rehabilitation Act, the European Accessibility Act (EAA), or the Accessibility for Ontarians with Disabilities Act (AODA) require accessible websites, they point at WCAG as the standard to meet.
WCAG Versions
- WCAG 2.0 (2008) — the original standard, still widely referenced in older laws.
- WCAG 2.1 (2018) — added 17 success criteria covering mobile, low vision, and cognitive disabilities.
- WCAG 2.2 (2023) — added 9 success criteria, the current standard in 2026.
- WCAG 3.0 — in draft, no fixed release date. Not yet applicable for compliance.
If you are starting compliance work today, target WCAG 2.2 AA. That is the level most laws now require.
The Four POUR Principles
WCAG is organized around four foundational principles, remembered with the acronym POUR.
Perceivable
Users must be able to perceive the information presented. This means text alternatives for non-text content, captions for video, sufficient color contrast, and content that adapts to different sensory needs.
Example criteria: alt text for images, captions for videos, contrast ratios of at least 4.5:1 for normal text, content that does not rely solely on color to convey meaning.
Operable
Users must be able to operate the interface. This means keyboard accessibility, sufficient time to complete tasks, no content that triggers seizures, and clear navigation.
Example criteria: every interactive element reachable by keyboard, no keyboard traps, focus visible at all times, target sizes large enough to tap accurately on mobile.
Understandable
Information and operation must be understandable. This means readable text, predictable behavior, and help when users make mistakes.
Example criteria: page language declared, consistent navigation across pages, form errors identified clearly, instructions provided when input is required.
Robust
Content must be robust enough to work with current and future assistive technologies. This means valid markup, proper semantic structure, and ARIA used correctly when standard HTML is insufficient.
Example criteria: clean HTML, correct ARIA roles, name/role/value exposed for every interactive component, status messages announced to screen readers.
The Three Conformance Levels
WCAG defines three conformance levels: A (minimum), AA (acceptable), and AAA (best practice). Each higher level includes everything from the levels below.
Level A
The absolute floor. Failing Level A makes content unusable for entire groups of users. Includes essentials like keyboard accessibility, alt text for images, captions for prerecorded video, and pages that do not flash dangerously. No site should claim accessibility without meeting Level A in full.
Level AA
The legal standard in most jurisdictions. AA adds contrast requirements, resize support up to 200 percent without loss of content, consistent navigation, error identification and suggestions, and labels on all form inputs. Most ADA settlements require WCAG 2.1 AA at minimum, and WCAG 2.2 AA is becoming the new baseline.
Level AAA
The strictest level, often impractical to meet for entire sites. AAA adds sign language interpretation for video, 7:1 contrast ratios, extended audio descriptions, and prohibits any content that requires more than three actions to navigate. Many sites pursue AAA on individual pages where the audience requires it but few sites achieve AAA site-wide.
WCAG 2.2 Success Criteria Categories
The success criteria break down into thirteen broad categories. Here is the practical breakdown of what each covers.
1. Text Alternatives
Every non-text element — images, icons, decorative graphics, complex visualizations — needs a text equivalent. Decorative images use empty alt attributes; informative images get descriptive alt text. Our image handling guide covers the practical patterns.
2. Time-Based Media
Audio and video need captions, transcripts, and (at AAA) audio descriptions. Prerecorded video at AA requires captions; live video at AA requires captions; AAA adds extended audio descriptions and sign language interpretation.
3. Adaptable Content
Content must be presentable in different ways without losing information. This means proper heading structure, logical reading order in the DOM, and identifying input purpose so assistive technology can autofill.
4. Distinguishable Content
Make it easy to see and hear content. Text contrast of at least 4.5:1 at AA, 7:1 at AAA. Resize text to 200 percent without breaking layout. Audio control for any media that plays automatically. Color cannot be the only way to convey information.
5. Keyboard Accessibility
Every function must be available from a keyboard. No keyboard traps. Character key shortcuts must have a way to disable them. New in WCAG 2.2: dragging movements must have an alternative single-point gesture.
6. Enough Time
Users must have enough time to read and use content. Timeouts must be adjustable or disabled. Auto-updating content must be pausable. Movement must be stoppable.
7. Seizures and Physical Reactions
No content that flashes more than three times per second. This protects users with photosensitive epilepsy.
8. Navigable
Users must find content and know where they are. Skip links to bypass repeated navigation. Descriptive page titles. Focus order that makes sense. Visible focus indicators on all interactive elements.
9. Input Modalities
Beyond keyboard, support touch and pointer. Target sizes at least 24×24 CSS pixels (new in WCAG 2.2). Pointer cancellation so users can abort an action before releasing. Label in name — visible labels must match accessible names.
10. Readable Content
Language of the page must be declared. Language of individual passages in another language must be marked. Unusual words, abbreviations, and reading level (at AAA) must be explained.
11. Predictable
Components that look the same should behave the same. Navigation must be consistent across pages. Changes of context must not happen without user action. Consistent help (new in WCAG 2.2) — help mechanisms should appear in the same place across pages.
12. Input Assistance
Help users avoid and correct mistakes. Errors must be identified and described in text. Labels and instructions must be provided. Critical actions (financial, legal, data deletion) must be reversible, checkable, or confirmable.
13. Compatible
Markup must be valid. Name, role, and value must be exposed for every UI component. Status messages must be announced to assistive technology without taking focus.
A Step-by-Step Path to Compliance
Achieving WCAG 2.2 AA is a process, not a one-time fix. Here is the order of operations that works.
Step 1: Audit the Current State
Run an automated scan first — axe DevTools, WAVE, Lighthouse, or a paid platform like Siteimprove or Level Access. Automated tools catch about 30 to 40 percent of issues but miss the harder ones. Follow with a manual audit using keyboard-only navigation and a screen reader (NVDA, JAWS, or VoiceOver). Our website audit guide covers the full process.
Step 2: Prioritize Findings
Group issues by severity and reach. Critical issues that block users from completing essential tasks come first — broken forms, inaccessible navigation, missing alt text on key images. Cosmetic contrast issues come later. Fix critical issues across the whole site before moving down the list.
Step 3: Fix Systemic Issues at the Template Level
Most accessibility issues are systemic. A missing skip link is missing on every page. A poorly labeled form field appears in every form. Fix the template or component once and the fix propagates everywhere. Use a real design system so future pages inherit accessibility.
Step 4: Train Content Authors
Designers and developers fix templates; content authors break them. Train anyone creating content on alt text, heading hierarchy, link text, and color usage. Without this step, regressions appear within weeks.
Step 5: Test with Real Users
Automated tools and manual checks catch most issues. Testing with users who rely on assistive technology catches the rest. Recruit screen reader users, keyboard-only users, and users with cognitive disabilities. Their feedback reveals issues no checklist surfaces.
Step 6: Build Accessibility into Every New Feature
Add accessibility acceptance criteria to every ticket. Include accessibility checks in pull request reviews. Run automated scans in continuous integration. Compliance is not a project that ends; it is a quality bar that stays in place forever.
Step 7: Publish an Accessibility Statement
Document your compliance status, the standards you target, and a contact channel for accessibility issues. This both informs users and demonstrates good faith in any legal challenge. The European Accessibility Act explicitly requires one.
Common WCAG Violations
WebAIM’s annual analysis of the top one million homepages finds the same handful of violations every year.
- Low contrast text — fixable with a design system that bakes in compliant color combinations.
- Missing alt text — fixable with editorial discipline and platform validation.
- Empty links and buttons — links with no visible or accessible text.
- Missing form labels — every input must have a programmatically associated label.
- Missing document language — the
<html lang="en">attribute is missing.
Fixing these five issues alone moves most sites a long way toward AA compliance.
WCAG and Legal Risk
ADA accessibility lawsuits in the U.S. grew to over 4,000 per year in 2024. The plaintiff’s bar has industrialized accessibility litigation, and most settlements require WCAG 2.1 AA compliance plus remediation and ongoing monitoring. The European Accessibility Act takes effect for private sector digital services in 2025, expanding the scope dramatically. Public sector sites in the EU have already been required to comply for years.
The defensive move is straightforward: meet WCAG 2.2 AA, publish an accessibility statement, and respond to accessibility complaints quickly. Sites that have done this work are rarely targeted by serial filers.
FAQ
Do small business websites have to comply with WCAG?
In the United States, the ADA’s application to small business websites is still litigated court by court, but most courts now say yes. The European Accessibility Act explicitly covers private sector digital services from 2025. Beyond legal requirements, an inaccessible site loses customers — about 1 in 4 U.S. adults has some form of disability. The right answer regardless of legal nuance is to comply with WCAG 2.2 AA.
Can an accessibility overlay or widget bring my site into compliance?
No. Overlay widgets — like accessiBe, UserWay, and similar tools — have been heavily criticized by accessibility experts and have themselves been the subject of lawsuits. They paper over accessibility issues rather than fixing them, often break screen readers, and do not satisfy WCAG. Real compliance requires fixing the underlying code, structure, and content.
How long does it take to make a site WCAG 2.2 AA compliant?
Depends on the starting point and site size. A small marketing site built on a modern platform with reasonable defaults can reach AA in two to four weeks of focused work. Large legacy sites with thousands of pages can take six to twelve months. Either way, plan it as an ongoing program, not a one-time project.
Want a site built accessible from day one — WCAG 2.2 AA compliance baked into the templates, components, and CMS rules? See our pricing or get in touch.