WCAG 2.2 Compliance Guide for Web Teams

What Is WCAG and Why It Matters

The Web Content Accessibility Guidelines (WCAG) are a set of technical standards published by the World Wide Web Consortium (W3C) that define how to make web content accessible to people with disabilities. WCAG is maintained by the W3C's Web Accessibility Initiative (WAI) and is the globally recognized benchmark for web accessibility.

WCAG matters for three reasons:

• Legal compliance: WCAG is referenced by accessibility laws in dozens of countries. In the United States, courts have consistently interpreted the Americans with Disabilities Act (ADA) as requiring web accessibility, and WCAG 2.1 Level AA is the de facto standard. The European Accessibility Act (EAA), which became enforceable in June 2025, explicitly references EN 301 549, which incorporates WCAG. Failure to comply exposes organizations to lawsuits, fines, and regulatory action.
• Audience reach: Approximately 16% of the global population experiences some form of disability (World Health Organization, 2023). Beyond permanent disabilities, accessibility benefits people with temporary impairments (a broken arm), situational limitations (using a phone in bright sunlight), and age-related changes (declining vision and motor control). Accessible websites serve more people.
• Better products: Accessible design produces better products for everyone. Keyboard navigation benefits power users. Clear heading structure benefits SEO. Sufficient color contrast benefits users on cheap monitors or in outdoor settings. Captions benefit users in noisy environments. Accessibility is not a separate concern — it is a quality indicator.

WCAG 2.2 was published as a W3C Recommendation on October 5, 2023, and is the current version. It builds on WCAG 2.1 (published 2018) and WCAG 2.0 (published 2008). Each version is backward-compatible — if you meet WCAG 2.2, you also meet 2.1 and 2.0.

The Four Principles: POUR

WCAG is organized around four foundational principles, commonly abbreviated as POUR. Every accessibility criterion falls under one of these principles. Understanding POUR gives your team a mental model for thinking about accessibility even when you are not looking at a specific checklist item.

1. Perceivable

Information and user interface components must be presentable to users in ways they can perceive. If content relies on a single sense (sight, hearing), users who lack that sense are excluded.

• Provide text alternatives for non-text content (images, icons, charts)
• Provide captions and transcripts for audio and video
• Ensure content can be presented in different ways without losing meaning (e.g., linearized for screen readers)
• Make content distinguishable — sufficient color contrast, resizable text, no information conveyed by color alone

2. Operable

User interface components and navigation must be operable. If a user cannot interact with your interface using their input method (keyboard, switch device, voice control), the feature is inaccessible to them.

• All functionality must be available via keyboard
• Users must have enough time to read and use content
• Content must not cause seizures or physical reactions (no flashing content above 3 flashes per second)
• Navigation must be consistent and predictable
• Input methods beyond keyboard must be supported (pointer, touch, voice)

3. Understandable

Information and the operation of the user interface must be understandable. If a user can perceive and operate your content but cannot understand it, the content is still inaccessible.

• Text is readable and understandable (language is declared, jargon is minimized)
• Web pages appear and operate in predictable ways
• Users are helped to avoid and correct mistakes (clear error messages, input assistance)

4. Robust

Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies. This means using valid, semantic HTML and following established patterns.

• Maximize compatibility with current and future user agents
• Use valid HTML/ARIA markup
• Ensure status messages are programmatically determinable without receiving focus

Conformance Levels: A, AA, and AAA

WCAG defines three conformance levels, each building on the previous:

Level A (Minimum)

The bare minimum for accessibility. If your site fails Level A criteria, it has barriers that make it impossible for some users to access content at all. Examples of Level A criteria:

• 1.1.1 Non-text Content: All images have alt text
• 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation are programmatically determinable (proper heading hierarchy, form labels, table structure)
• 2.1.1 Keyboard: All functionality is operable via keyboard
• 4.1.2 Name, Role, Value: UI components have accessible names and roles

Level AA (Standard)

The level most laws and policies reference. Level AA is considered the practical target for most websites. It addresses the most common barriers without requiring heroic effort. Examples of Level AA criteria:

• 1.4.3 Contrast (Minimum): Text has a contrast ratio of at least 4.5:1 (3:1 for large text)
• 1.4.4 Resize Text: Text can be resized up to 200% without loss of content or functionality
• 1.4.5 Images of Text: Text is used instead of images of text wherever possible
• 2.4.7 Focus Visible: Keyboard focus indicator is visible
• 1.4.11 Non-text Contrast: UI components and graphical objects have a contrast ratio of at least 3:1

Level AAA (Enhanced)

The highest level of accessibility. Level AAA is not typically required by law and is not recommended as a blanket target for entire sites, because some criteria are not achievable for all types of content. However, meeting AAA criteria where feasible improves accessibility further. Examples:

• 1.4.6 Contrast (Enhanced): Text has a contrast ratio of at least 7:1 (4.5:1 for large text)
• 2.4.9 Link Purpose (Link Only): The purpose of each link can be determined from the link text alone
• 3.1.5 Reading Level: Content is written at a lower secondary education reading level, or a simpler version is available

Practical recommendation: Target WCAG 2.2 Level AA for your entire site. Address Level AAA criteria on a case-by-case basis where feasible and beneficial. This is the approach recommended by the W3C and adopted by most legal frameworks.

What Is New in WCAG 2.2

WCAG 2.2 added nine new success criteria compared to WCAG 2.1 and removed one (4.1.1 Parsing, which was made obsolete by modern browser parsing behavior). Here are the new criteria your team needs to know:

Level A:

• 3.3.7 Redundant Entry: Information previously entered by or provided to the user that is required to be entered again in the same process must be either auto-populated or available for the user to select. Example: if a user enters their shipping address in step 2, do not make them re-type it as a billing address in step 3 — auto-fill it or provide a "same as shipping" checkbox.

Level AA:

• 2.4.11 Focus Not Obscured (Minimum): When a user interface component receives keyboard focus, the component is not entirely hidden by author-created content. Sticky headers, cookie banners, and chat widgets often violate this by covering the focused element.
• 2.4.13 Focus Appearance: Focus indicators must meet specific size and contrast requirements. The focus indicator area must be at least as large as a 2px perimeter around the component, and must have a contrast ratio of at least 3:1 between the focused and unfocused states.
• 2.5.7 Dragging Movements: Functionality that uses dragging (drag-and-drop) must have a single-pointer alternative. Users with motor impairments may not be able to perform dragging gestures. Provide click/tap alternatives for reordering, moving, and resizing.
• 2.5.8 Target Size (Minimum): Interactive targets must be at least 24x24 CSS pixels, with specific exceptions for inline text links, targets where the size is determined by the user agent, and targets where a larger alternative is available on the same page.
• 3.2.6 Consistent Help: If a help mechanism (contact information, human contact, self-help option, or automated contact mechanism) is provided across multiple web pages within a set of pages, it must be located in the same relative order on each page. This ensures users can reliably find help.
• 3.3.8 Accessible Authentication (Minimum): Cognitive function tests (such as remembering a password, solving a puzzle, or recognizing images) are not required for any step in authentication, unless the test provides at least one of: an alternative method, an assistive mechanism (copy-paste support for passwords), or object recognition of the user's own content. This means password managers must work (do not block paste on password fields) and CAPTCHAs must have accessible alternatives.

Level AAA:

• 2.4.12 Focus Not Obscured (Enhanced): No part of the focused component is hidden (stricter than 2.4.11, which only requires the component to not be entirely hidden)
• 3.3.9 Accessible Authentication (Enhanced): Stricter than 3.3.8 — excludes object recognition and personal content recognition as acceptable alternatives

Removed criterion:

• 4.1.1 Parsing: This criterion required valid HTML parsing. It has been removed because modern browsers and assistive technologies are now robust enough to handle minor parsing errors. This does not mean you should write invalid HTML — it simply means WCAG no longer tests for it as a separate criterion.

Accessibility Testing Tools

Automated tools can detect approximately 30-40% of WCAG criteria programmatically. The remaining 60-70% require human judgment. A good testing strategy uses both.

Automated testing tools:

• axe DevTools (by Deque Systems): The most widely used accessibility testing engine. Available as a browser extension (Chrome, Firefox, Edge), a JavaScript library (axe-core) for integration into CI/CD pipelines, and integrations with testing frameworks like Cypress, Playwright, and Selenium. axe follows a zero-false-positive philosophy — issues it flags are real. It tests against WCAG 2.1 and 2.2 criteria.
• WAVE (by WebAIM): A browser extension and online tool that provides a visual overlay of accessibility issues directly on the page. Particularly useful for non-technical team members because it shows issues in context rather than in a list. Color contrast analysis, heading structure visualization, and ARIA attribute checking are especially well implemented.
• Google Lighthouse: Built into Chrome DevTools, Lighthouse includes an accessibility audit powered by axe-core. It is convenient but less thorough than axe DevTools run directly, because Lighthouse samples a subset of axe rules for faster execution. Good for a quick check; not sufficient as your only automated tool.
• Pa11y: An open-source command-line accessibility testing tool. Pa11y is particularly useful for CI/CD integration and batch testing of multiple pages. It uses HTML_CodeSniffer under the hood and supports testing against WCAG 2.1 AA. pa11y-ci can test entire sitemaps in your deployment pipeline.
• Accessibility Insights (by Microsoft): Available for web (Chrome extension), Windows, and Android. The "FastPass" mode runs automated checks, while the "Assessment" mode provides a guided manual testing process — useful for teams new to accessibility testing.

Manual testing essentials:

• Keyboard testing: Tab through every page using only the keyboard. Verify that every interactive element is reachable, that focus order is logical, that focus is visible, and that no keyboard traps exist (a state where you cannot tab away from an element). Test all custom components: modals, dropdown menus, accordions, carousels, date pickers.
• Screen reader testing: Test with at least one screen reader. VoiceOver on macOS (Cmd+F5) is free and built in. NVDA on Windows is free and open source. Test key flows: navigation, forms, dynamic content, error handling. Listen for missing labels, nonsensical reading order, and missing announcements for dynamic updates.
• Zoom and reflow testing: Zoom to 200% and verify no content is lost. Zoom to 400% and verify content reflows into a single column without horizontal scrolling (WCAG 1.4.10 Reflow).
• Color and contrast: Use a contrast checker (built into axe, or standalone tools like Colour Contrast Analyser by TPGi) to verify contrast ratios. Check that no information is conveyed by color alone — verify this by viewing the page in grayscale.

The 10 Most Common WCAG Violations

The WebAIM Million study (an annual analysis of the top 1,000,000 home pages) consistently finds the same violations year after year. Here are the most common, with specific WCAG criteria references and fixes:

1. Low contrast text (WCAG 1.4.3)

Found on 81% of home pages in the 2024 study. Light gray text on white backgrounds is the most frequent offender.

Fix: Ensure body text has at least 4.5:1 contrast ratio. Large text (18px bold or 24px regular) needs 3:1 minimum. Use your design system's color tokens and verify contrast during design review, not just during QA.

2. Missing alternative text for images (WCAG 1.1.1)

Found on 54% of home pages. Images without alt attributes force screen readers to announce the image filename or URL, which is useless.

Fix: Add descriptive alt text to informative images. Use empty alt="" for purely decorative images. Never use alt="image" or alt="photo" — describe what the image conveys.

3. Missing form input labels (WCAG 1.3.1, 4.1.2)

Found on 45% of home pages. Placeholder text is not a label — it disappears when the user starts typing and is not reliably announced by screen readers.

Fix: Every form input needs a <label> element with a for attribute matching the input's id. If a visible label is not possible, use aria-label or aria-labelledby.

4. Empty links (WCAG 2.4.4, 4.1.2)

Found on 49% of home pages. Links that contain only an icon or image but no text are announced as "link" with no indication of where they go.

Fix: Add aria-label to icon-only links, or include visually hidden text inside the link. Example: <a href="/cart" aria-label="Shopping cart (3 items)"><svg ...></a>

5. Empty buttons (WCAG 4.1.2)

Found on 27% of home pages. Same issue as empty links — buttons containing only icons have no accessible name.

Fix: Same approach — use aria-label or visually hidden text.

6. Missing document language (WCAG 3.1.1)

Found on 17% of home pages. Without <html lang="en">, screen readers may use the wrong language pronunciation rules.

Fix: Always set the lang attribute on the <html> element. For multilingual pages, use lang attributes on specific elements containing content in a different language.

7. No skip navigation link (WCAG 2.4.1)

Keyboard users are forced to tab through the entire navigation on every page load.

Fix: Add a "Skip to main content" link as the first focusable element on the page. It can be visually hidden until focused.

8. Inaccessible custom components (multiple criteria)

Custom dropdown menus, modals, tabs, accordions, and carousels that are built without ARIA roles, states, and keyboard interaction patterns.

Fix: Follow the ARIA Authoring Practices Guide (APG) for interaction patterns. Better yet, use a component library with built-in accessibility (Radix UI, Headless UI, Adobe React Aria).

9. Focus management failures (WCAG 2.4.3, 2.4.7)

Focus is not moved to modals when they open, not returned when they close, or is invisible because outline: none was applied without a replacement.

Fix: Manage focus programmatically for dynamic content. Never remove focus outlines without providing an alternative indicator. Use :focus-visible to show focus styles only for keyboard navigation.

10. Auto-playing media (WCAG 1.4.2)

Audio that plays automatically with no way to pause or stop it.

Fix: Do not auto-play audio. If you must auto-play video, start it muted with controls visible.

Remediation Strategies

If an accessibility audit reveals dozens or hundreds of issues, the prospect of fixing them all can be paralyzing. A structured remediation approach prevents overwhelm and delivers incremental value.

Step 1: Prioritize by impact and frequency

Not all accessibility issues are equal. Prioritize fixes based on:

• Impact: Does the issue completely block a user from accessing content or completing a task? (high) Or does it create friction but allow workarounds? (medium) Or is it technically non-compliant but unlikely to affect real users? (low)
• Frequency: Does the issue appear on every page (global navigation, header, footer) or on a single page? Fix global issues first — one fix improves every page.
• Effort: Some fixes take minutes (adding alt text, adding lang attribute). Others require component redesign (rebuilding a custom dropdown with ARIA). Quick wins first build momentum and demonstrate progress.

Step 2: Fix the systemic issues first

Address issues at the component and template level, not page by page. If your button component lacks focus styles, fix the component once rather than adding inline styles on 200 pages. Common systemic fixes:

• Update the design system's color tokens to meet contrast requirements
• Add focus styles to the base interactive component classes
• Add lang attribute to the HTML template
• Add skip navigation to the global layout
• Ensure form components always render associated labels

Step 3: Integrate accessibility into the development process

Remediation is a losing strategy if new inaccessible code is produced faster than old code is fixed. Shift accessibility left:

• Design phase: Designers check color contrast during design, annotate heading levels, and specify focus states for interactive components
• Development phase: Developers use semantic HTML, run axe-core during development, and test keyboard navigation before marking a story as done
• Code review: Include accessibility criteria in your code review checklist — check for alt text, labels, ARIA usage, and keyboard operability
• CI/CD: Run axe-core or Pa11y as part of your automated test suite. Fail the build on new Level A and AA violations.
• QA: Include accessibility checkpoints in your QA process (see our Website QA Checklist)

Step 4: Test with real users

Automated tools and expert review are necessary but not sufficient. Test with people who actually use assistive technologies. Organizations like Knowbility and Level Access can connect you with testers who use screen readers, switch devices, and other assistive technologies daily. Their feedback reveals usability issues that no automated tool can detect.

Building an Accessibility Culture

Compliance is the floor, not the ceiling. Organizations that treat accessibility as a checkbox exercise — audit once, fix the list, move on — find themselves in the same position a year later with a new list of issues. Sustainable accessibility requires cultural change.

Education: Most accessibility issues stem from lack of awareness, not lack of caring. Train your entire team — designers, developers, QA, content authors, product managers — on the basics of how people with disabilities use the web. Even a 2-hour introductory session changes how people think about their work.

Recommended learning resources:

• W3C Introduction to Web Accessibility
• web.dev Learn Accessibility — free, comprehensive, and practical
• W3Cx Introduction to Web Accessibility on edX (free audit option)

Accountability: Assign accessibility ownership. An "accessibility champion" on each team — someone with deeper knowledge who reviews designs and code — prevents issues from reaching QA. Some organizations hire a dedicated accessibility lead or partner with an accessibility consultancy for ongoing guidance.

Measurement: Track accessibility metrics over time. Run automated scans regularly and track the number of issues by severity and page. Set improvement targets: "reduce Level A violations by 50% this quarter." What gets measured gets managed.

Procurement: When evaluating third-party tools, components, or platforms, ask vendors for their VPAT (Voluntary Product Accessibility Template) or accessibility conformance report. If you build on inaccessible foundations, your product inherits those accessibility gaps.

Feedback loop: Make it easy for users to report accessibility issues. A simple "Report an accessibility issue" link in your footer — routed to someone who will actually act on it — demonstrates commitment and surfaces real-world issues that testing may miss.

Frequently Asked Questions

Resources and Further Reading

• WCAG 2.2 Specification The official W3C Web Content Accessibility Guidelines 2.2 specification
• Understanding WCAG 2.2 W3C supplementary guide explaining each WCAG 2.2 criterion with examples and techniques
• ARIA Authoring Practices Guide (APG) Patterns and examples for building accessible custom widgets with ARIA
• axe-core (Deque Systems) Open-source accessibility testing engine, the industry standard for automated a11y testing
• WebAIM Million Annual Report Annual accessibility analysis of the top 1,000,000 home pages — essential data on common violations
• web.dev Learn Accessibility Free comprehensive accessibility course from Google covering all WCAG principles

Latest News on This Topic

Related Guides