Executive Summary: A Two-Track Strategy

This report looks at the move towards a new standard for web accessibility.

1. WCAG 2.2 (The Mandate): The current, legally-cited standard. Organisations must audit and remediate against these new criteria immediately to ensure accessibility.
2. WCAG 3.0 (The Strategy): A completely new, philosophical replacement for the 2.x series. It introduces graded scoring and context-aware contrast. It should be treated as a roadmap for future-proofing design systems and testing protocols.

Part 1: The Immediate Mandate - WCAG 2.2 Actionable Updates

WCAG 2.2 is an "add-on" standard, fully backwards-compatible with 2.1. It adds nine new criteria and removes one.

1.1 The Single Removal: 4.1.1 Parsing

Criterion 4.1.1 Parsing has been removed. Modern browsers are now robust enough to handle imperfect code without crashing assistive technologies. For HTML/XML content, this criterion "should be considered as always satisfied," shifting the burden from developer syntax perfection to browser robustness.

1.2 The 4 Critical New Level AA Success Criteria

These are the most impactful updates for design and development teams.

2.4.11 Focus Not Obscured (Minimum) (AA):

• The Rule: When a user tabs to an element, it must not be entirely hidden by other content (like sticky headers, footers, or cookie banners).
• Context: This directly addresses modern layouts where "sticky" elements frequently block keyboard users from seeing where they are.
• Action: Test tab navigation. If a focused item disappears behind a sticky header, use CSS scroll-padding or redesign the overlay.

2.5.7 Dragging Movements (AA):

• The Rule: Any action that involves dragging (e.g., reordering a list, a map slider) must have a "single-pointer" alternative (e.g., a simple click or tap).
• Users with motor impairments may lack the fine dexterity needed to hold down a mouse button while moving the cursor.
• Action: Ensure all drag-and-drop interfaces have "Move Up/Down" buttons or similar click-based alternatives.

2.5.8 Target Size (Minimum) (AA):

• The Rule: Interactive targets must be at least 24 by 24 CSS pixels. This includes the padding/spacing around the object.
• Context: This helps users with tremors or those using touch devices avoid "fat finger" errors. It is a relaxed version of the stricter AAA (44x44) requirement.
• Exceptions: Links within a sentence of text are exempt.

3.3.8 Accessible Authentication (Minimum) (AA):

• The Rule: Authentication flows (logging in) must not rely solely on a "cognitive function test" like memorising a password, solving a puzzle, or transcribing a CAPTCHA.
• Context: Users with cognitive disabilities often cannot complete these memory-based tests.

Action: You must provide an alternative, such as:

• Allowing password managers (copy/paste).
• "Magic link" emails or 2FA codes (which rely on recognition, not recall).
• Object recognition tests (e.g., "click the boat") rather than transcription.

Part 2: The Future - Deconstructing WCAG 3.0

WCAG 3.0 (Project "Silver") is a fundamental rebuild. It is not backwards compatible with WCAG 2.x and utilises a completely different conformance model. It is currently a Working Draft and will not be a finalised recommendation for several years.

2.1 The New Conformance Model: Bronze, Silver, Gold

The rigid "A / AA / AAA" levels are replaced to incentivise actual usability over technical compliance.

• Bronze (The Baseline): Comparable to WCAG 2.2 Level AA It can be met through "atomic" (technical) testing, such as automated linters and code checks.
• Silver & Gold (The Holistic Standard): To achieve these higher levels, organisations must perform "holistic testing."

Context: Holistic testing is explicitly defined as usability testing with people with disabilities and using assistive technologies. This codifies user research into the standard itself. You cannot achieve Gold status with perfect code alone; you must prove the experience actually works for humans.

2.2 Scoring: Graded Outcomes and Functional Categories

WCAG 3.0 replaces "Pass/Fail" with a graded score (0-4).

• Averaging: A site might score 3.5/4 on an outcome, allowing for minor failures (e.g., one missing label in a massive application) without failing the entire audit.
• Critical Errors: To prevent abuse, "Critical Errors" (e.g., a video with no captions) automatically drop the score for that outcome to 0, regardless of other successes.
• Functional Categories: A site must achieve a passing average within every functional category (e.g., Vision, Hearing, Cognitive, Motor).
• Why this matters: This prevents "imbalanced accessibility." You cannot pass by scoring 100% on visual fixes while ignoring cognitive barriers. A low score in the "Cognitive" category will fail the entire product, forcing teams to address all disability types equally.

2.3 Assertions: Measuring Process, Not Just Code

WCAG 3.0 introduces "Assertions" formal claims that an organisation has followed a specific process.

• Context: Some aspects of accessibility (like plain language or inclusive design) cannot be tested in code.
• Action: Organisations will attest to procedures such as "staff training," "usability testing cycles," or "executive sign-off." This moves accessibility from a QA checklist to an organisational maturity metric.

Part 3: Technical Innovations The Contrast Shift (APCA)

The most disruptive technical change in WCAG 3.0 is the replacement of the 4.5:1 contrast ratio with the Advanced Perceptual Contrast Algorithm (APCA)

3.1 Why the Change?

The current 4.5:1 math is flawed; it does not account for human perception of lightness. It incorrectly fails readable white text on dark buttons while passing unreadable grey text on white backgrounds.

3.2 How APCA Works

APCA calculates a Lightness Contrast (Lc) value based on font weight, size, and context. It is context-aware:

• Dark Mode Benefit: APCA is more flexible with light text on dark backgrounds, unlocking many colours that currently "fail" WCAG 2.x despite being readable.
• Light Mode Strictness: It is stricter with dark text on light backgrounds. Many light-grey text styles currently in use will likely fail.

3.3 New Thresholds for Designers

Instead of "4.5:1," designers will target Lc scores. (Note: values are approximate for the Bronze level):

• Lc 90: Preferred for body text.
• Lc 75: Minimum for body text (approx. 18px font).
• Lc 60: Minimum for "medium" text (approx. 24px) or bold text (16px bold).
• Lc 45: Minimum for large headlines (36px) or non-text UI components.

Part 4: Strategic Roadmap for Product Leaders

4.1 Immediate Actions (0-6 Months)

• Audit for WCAG 2.2 AA: Specifically check your "sticky" UI elements (Focus Not Obscured) and login flows (Accessible Authentication).
• Design System Update: Mandate a minimum click target size of 24px in your component library (Success Criterion 2.5.8).

4.2 Long-Term Strategy (1-3 Years)

• Shift Left on Testing: Begin building the capability for "Holistic Testing." Start recruiting users with disabilities for user research now. This will be a requirement for WCAG 3.0 Silver/Gold
• Pilot APCA: Have your design team audit your colour palette using an APCA calculator. Identify where your "light mode" greys might fail future standards and where "dark mode" might gain new flexibility.
• Contract Language: In vendor contracts, require WCAG 2.2 AA compliance, but add a clause stating the vendor must "demonstrate alignment with the principles of WCAG 3.0," specifically regarding inclusive user testing processes.

Conclusion

WCAG 2.2 is the final polish on the old "checklist" era of accessibility. WCAG 3.0 is the beginning of the "usability" era. By complying with 2.2 today, you avoid legal risk. By adopting the 3.0 processes (Holistic Testing and Assertions) today, you build a product that is not just compliant but genuinely usable for everyone.