Understanding WCAG 2.2: A Comprehensive Guide to Web Accessibility Compliance
The Web Content Accessibility Guidelines (WCAG) are the international standard for digital accessibility, published by the World Wide Web Consortium (W3C) through its Web Accessibility Initiative (WAI). Since their first publication as WCAG 1.0 in 1999, the guidelines have evolved through WCAG 2.0 (2008), WCAG 2.1 (2018), and the current WCAG 2.2 (October 2023). They define how to make web content perceivable, operable, understandable, and robust — the four POUR principles — for people with a broad spectrum of disabilities including vision, hearing, motor, cognitive, and neurological disabilities.
WCAG 2.2 and Legal Compliance Globally
What began as a technical recommendation has become a legal imperative in most jurisdictions. In the United States, the ADA (Americans with Disabilities Act) has been applied to websites through DOJ guidance and a large body of case law since the Robles v. Domino's Pizza ruling (2019). In March 2024, the DOJ issued a final rule under Title II of the ADA formally requiring state and local government websites to meet WCAG 2.1 Level AA by specific deadlines (April 2026 for large entities, April 2027 for smaller ones). Title III ADA compliance for private businesses — covering retail, hospitality, restaurants, and any business open to the public — is enforced primarily through litigation, with over 4,600 web accessibility lawsuits filed in federal court in 2023 alone according to UsableNet data.
The European Accessibility Act (EAA, EU Directive 2019/882) brought the most sweeping private-sector mandate. Since 28 June 2025, most digital products and services sold to EU consumers — e-commerce, banking, e-books, transport services, communication services — must comply with EN 301 549 v3.2.1, which references WCAG 2.1 AA as its core web content standard. Australia's Disability Discrimination Act (DDA) and the Australian Human Rights Commission's Web Accessibility National Transition Strategy have long pointed to WCAG as the standard of care. India's Rights of Persons with Disabilities Act 2016 mandates accessible ICT, referencing WCAG 2.0 AA in government guidelines, with increasing pressure on private sector compliance.
The Four POUR Principles Explained
Perceivable means that users can perceive all information and UI components — it cannot be invisible to all their senses. Key requirements include text alternatives for non-text content (1.1.1), captions for audio and video (1.2.x), adaptable content structure (1.3.x), distinguishable colour contrast and audio (1.4.x). Operable requires that all functionality is available from a keyboard and that users have enough time to interact. This covers keyboard navigation (2.1.x), timing (2.2.x), seizures (2.3.x), navigation and wayfinding (2.4.x), and input modalities (2.5.x). Understandable ensures that content and operations are comprehensible — readable language (3.1.x), predictable behavior (3.2.x), and input assistance (3.3.x). Robust means content can be reliably interpreted by assistive technologies including screen readers and braille displays, primarily through valid, semantic HTML and ARIA (4.1.x).
New in WCAG 2.2
WCAG 2.2 introduced nine new success criteria and removed one (4.1.1 Parsing). The Level A and AA additions relevant to most organisations are: 2.4.11 Focus Appearance (AA) — the keyboard focus indicator must have a minimum perimeter and contrast ratio, addressing the widespread problem of invisible focus rings; 3.2.6 Consistent Help (A) — help mechanisms (chat, phone number, FAQ link) must appear in the same relative location on every page where they appear; 3.3.7 Redundant Entry (A) — information already entered by the user earlier in a session should not be requested again unless the re-entry is essential; 3.3.8 Accessible Authentication (AA) — authentication steps must not require a cognitive function test (like a CAPTCHA or transcribing text) unless an alternative is provided. The 2.5.3 Label in Name criterion (A), originally advisory in 2.1, is now normative in 2.2.
Automated Testing vs Manual Testing
A persistent industry misconception is that accessibility can be achieved through automated scanning alone. Research from Deque Systems, WebAIM, and the UK Government Digital Service consistently shows that automated tools detect only 25–40% of WCAG failures. Tools like axe-core, WAVE, Lighthouse, and IBM Equal Access Checker are excellent for catching structural issues — missing alt text, invalid ARIA roles, colour contrast violations, duplicate IDs, and missing form labels — but they cannot evaluate the quality of alt text descriptions, keyboard operability of custom components, screen reader announcement order, cognitive load, or focus management in single-page applications. A complete accessibility audit requires automated scanning plus manual keyboard testing, screen reader testing (NVDA, JAWS, VoiceOver, TalkBack), cognitive walkthrough, and ideally, testing with actual disabled users.
Building an Accessibility Programme
Achieving and maintaining WCAG compliance is an ongoing programme, not a one-time project. The most effective approach integrates accessibility into every phase of product development: Discovery — include users with disabilities in research; Design — check colour contrast and focus order in mockups, use inclusive design patterns; Development — use semantic HTML, integrate axe-core into CI/CD pipelines, run automated tests on every PR; QA — include keyboard and screen reader testing in QA checklists; Production — run periodic automated scans, monitor for regressions, handle user feedback about accessibility. Publishing an accessibility statement with your current conformance status, known issues, and contact details for reporting problems is a legal requirement under the EAA and UK regulations and best practice everywhere.