WCAG Compliance Guide — Understanding WCAG 2.2, 2.2 & 3.0

What is WCAG and how has it evolved since 1999?

WCAG is the web accessibility standard developed through the World Wide Web Consortium (W3C) and its Web Accessibility Initiative (WAI). The first version, WCAG 1.0, was published as a W3C Recommendation on May 5, 1999. WCAG 2.0 followed on December 11, 2008, then WCAG 2.2 on June 5, 2018, and WCAG 2.2 on October 5, 2023. These milestones reflect a long-running effort to keep accessibility requirements technically testable while adapting to modern interfaces, mobile-first patterns, and changing assistive technology behavior.

WCAG is not just a checklist for designers or developers. It is a shared interoperability layer for legal, policy, engineering, QA, procurement, and audit teams. Governments and large enterprises use WCAG to write contract requirements, assess supplier risk, set acceptance criteria, and evaluate public-facing systems. This is why WCAG terminology appears across legal settlements, VPAT/ACR documents, procurement RFPs, and compliance reporting workflows.

One important point in 2026 is that WCAG versions are intentionally backward compatible at a practical level: content that conforms to WCAG 2.2 is designed to align with the earlier 2.x framework as well. W3C guidance continues to encourage teams to use the latest WCAG 2 version while recognizing that many legal references still cite WCAG 2.2 AA and some legacy programs still cite WCAG 2.0 AA.

What are the POUR principles in WCAG?

POUR is the foundation of WCAG. Every guideline and success criterion ultimately supports one of four principles that describe what accessible digital content must enable for real users in real contexts.

POUR Principle	What It Means	Practical Website Impact
Perceivable	Users must be able to perceive information through at least one available sense.	Provide alt text, captions, transcripts, adaptable layouts, and sufficient color contrast.
Operable	Users must be able to operate controls and navigate interface components.	Support keyboard navigation, visible focus, predictable interactions, and time-limit controls.
Understandable	Content and interaction behavior must be understandable and predictable.	Use clear labels, consistent navigation/help, usable forms, and clear error handling.
Robust	Content must be compatible with user agents and assistive technologies over time.	Use valid semantics, programmatic names/roles/states, and resilient markup patterns.

What are WCAG conformance levels and what does each one mean?

WCAG conformance levels describe accessibility depth and legal maturity. They are cumulative: higher levels build on lower levels. In practice, this means Level AA assumes all relevant Level A criteria are already met, and Level AAA builds beyond both.

Conformance Level	Role in Practice	How Organizations Use It
Level A	Minimum baseline to remove severe blocking barriers.	Used to establish first-stage remediation priorities and eliminate immediate exclusion risks.
Level AA	Mainstream compliance target across laws, policies, and enterprise governance.	Used as default requirement in audits, procurement, legal settlements, and accessibility programs.
Level AAA	Enhanced accessibility where feasible, often beyond minimum legal obligation.	Used selectively for high-impact journeys, public services, and mature design systems.

When organizations ask, “What level should we target?” the practical answer for most public-facing websites is WCAG 2.2 AA or WCAG 2.2 AA depending on legal scope and program maturity. Level AAA remains valuable but is not generally required across all content types and workflows.

How many WCAG success criteria are there in WCAG 2.2 and 2.2?

This is one of the most common points of confusion in accessibility discussions. WCAG 2.2 has 78 success criteria in total. WCAG 2.2 adds 9 new criteria and marks 4.1.1 Parsing obsolete, leaving 86 active criteria in WCAG 2.2.

Version	Total Criteria	Level Breakdown	Notes
WCAG 2.2	78	30 A, 20 AA, 28 AAA	Published June 5, 2018.
WCAG 2.2	86 active	31 A, 24 AA, 31 AAA	Published October 5, 2023; adds 9 criteria, with 4.1.1 Parsing obsolete.

If you have seen summaries that claim “three criteria removed” from WCAG 2.2, verify the source carefully. W3C’s WCAG 2.2 documentation identifies one obsolete criterion in this transition: 4.1.1 Parsing. From a program perspective, the key operational change is not subtraction. It is the addition of practical usability-focused criteria that reduce common failures in keyboard focus, target interaction, forms, and authentication.

What changed in WCAG 2.2 compared to WCAG 2.2?

WCAG 2.2 introduces nine new success criteria and keeps WCAG’s overall structure intact, making adoption straightforward for teams already working under WCAG 2.2. The nine additions concentrate on frequent user pain points that were underrepresented in older criteria, especially for cognitive accessibility, low dexterity interactions, and modern component patterns.

New in WCAG 2.2	Level	Why It Matters
2.4.11 Focus Not Obscured (Minimum)	AA	Focused elements cannot be fully hidden by sticky headers/footers or overlays.
2.4.12 Focus Not Obscured (Enhanced)	AAA	Extends minimum visibility to full visibility expectations.
2.4.13 Focus Appearance	AAA	Requires stronger focus indicator size and contrast for keyboard users.
2.5.7 Dragging Movements	AA	Requires non-drag alternatives for functionality that uses dragging gestures.
2.5.8 Target Size (Minimum)	AA	Adds minimum target size/spacing protections for touch and pointer accuracy.
3.2.6 Consistent Help	A	Keeps help mechanisms in consistent order and placement across related pages.
3.3.7 Redundant Entry	A	Avoids re-entering the same information in multi-step processes.
3.3.8 Accessible Authentication (Minimum)	AA	Prevents cognitive-function tests from becoming mandatory access barriers.
3.3.9 Accessible Authentication (Enhanced)	AAA	Strengthens accessibility of login and account recovery workflows.

WCAG 2.2 also explicitly treats 4.1.1 Parsing as obsolete. This reflects the modern HTML parsing ecosystem and shifts focus toward criteria that create clearer user impact. For engineering teams, this means modernization priorities should emphasize interaction quality, perceivable focus states, and inclusive form/auth flows over legacy parser-centric checklists.

What is the current status of WCAG 3.0 and should organizations wait for it?

As of March 2026, WCAG 3.0 remains a W3C Working Draft, with a draft conformance direction using Bronze, Silver, and Gold tiers. It is explicitly a work in progress and not yet a finalized recommendation that regulators generally require for conformance claims. W3C’s own status language emphasizes that WCAG 3 still has years of work remaining and may change substantially before standardization.

A better strategy is dual-track planning. Continue implementing WCAG 2.2/2.2 AA rigorously for present-day compliance while monitoring WCAG 3 developments for future design-system evolution. This allows you to remain compliant today and ready for future model shifts without freezing delivery.

Which laws and standards reference WCAG today?

WCAG is referenced globally, but legal implementation details vary by jurisdiction and sector. Some laws cite WCAG directly in regulation text; others use harmonized standards or policy guidance that map back to WCAG. The summary below reflects widely used public frameworks in 2026.

Law / Standard	Common WCAG Reference	Scope Snapshot
ADA (U.S., Title II rule)	WCAG 2.2 Level AA	State and local government web content and mobile apps under DOJ final rule.
Section 508 (U.S. federal)	WCAG 2.0 Level A/AA (current binding baseline)	Federal ICT, including web and non-web electronic content, with ongoing modernization efforts.
EAA and EN 301 549 (EU ecosystem)	Widely operationalized through WCAG 2.2 alignment in EN 301 549 v3.2.1	Applies across covered products/services; legal implementation depends on EU/member-state instruments.
AODA (Ontario)	WCAG 2.0 Level AA (with listed exceptions)	Public websites for designated public sector and large organizations under IASR schedule rules.
Other regional and national frameworks	Often WCAG 2.2 AA (or WCAG-derivative standards)	Coverage and enforcement vary by jurisdiction and sector.

For multinational teams, the safest policy baseline remains implementing WCAG 2.2 or 2.2 at Level AA across the full product lifecycle. This reduces fragmentation, simplifies procurement language, and lowers cross-jurisdiction compliance drift. Legal counsel should still validate jurisdiction-specific obligations, but shared technical execution based on WCAG AA is usually the most practical governance default.

How should teams operationalize WCAG compliance beyond one-time audits?

Sustainable WCAG conformance requires process integration, not a one-off accessibility sprint. Start by defining a compliance baseline per product line, then map each release stage to accessibility controls: design review, component standards, automated checks, manual assistive-technology testing, and defect triage. Mature programs treat accessibility issues as product quality defects with severity, owners, SLAs, and retest evidence.

Teams should also distinguish between scan-detectable issues and user-journey barriers that require manual testing. Automated tooling can find many failures (missing alt text, form-label mismatches, contrast alerts), but it cannot fully judge clarity, interaction predictability, authentication burden, or contextual assistive-tech behavior. Pairing automation with structured manual testing is essential for legal-grade confidence.

Finally, document everything: findings, remediation decisions, release notes, exceptions, and retest outcomes. In regulated environments and legal disputes, your evidence trail matters almost as much as your point-in-time score. Accessibility maturity is demonstrated by repeatable control, not by isolated pass/fail snapshots.

How does LEWCA help with WCAG compliance?

LEWCA helps organizations run ongoing WCAG-oriented accessibility monitoring instead of relying on one-time checks. It scans across issues mapped to all four POUR principles, helping teams identify barriers tied to perceivability, operability, understandability, and robustness in a practical remediation workflow. This shortens the time from detection to fix, especially for WordPress teams managing frequent content and plugin updates.

LEWCA also supports reporting by conformance level so teams can prioritize remediation against Level A, AA, and AAA expectations. For common recurring patterns, automated fixes can reduce repetitive engineering effort and lower regression risk between releases. To explore capabilities, visit /features/ and start with /pricing/.