Since its release in October 2023, WCAG 2.2 has introduced a set of refinements aimed at closing persistent gaps in digital accessibility. The update builds on familiar territory, continuing the push toward more human-centred interaction design, especially on mobile, and especially for users with cognitive or physical limitations.
For digital teams already embedding accessibility into their processes, this isn’t about starting from scratch. It’s about adjusting emphasis, testing with greater intent, and staying attuned to how accessibility standards are evolving.
A Brief Note on WCAG 2.2
The Web Content Accessibility Guidelines (WCAG) are a global standard. Version 2.2 became an official W3C recommendation on 5 October 2023, expanding on the existing WCAG 2.1 framework with nine new success criteria. These updates apply primarily at Level A and AA, meaning they’re relevant for most compliance expectations across public, private, and enterprise sectors.
The four foundational principles of accessibility remain unchanged: content must be Perceivable, Operable, Understandable, and Robust. But the lens through which we interpret those principles continues to sharpen.
What’s Changed and Why it Matters
Many of the 2.2 additions address long-standing friction points for users, especially those navigating by touch or using assistive technologies. Highlights include:
- Minimum target size (2.5): When was the last time you mistapped on your phone? Touch targets must be at least 24 by 24 pixels, reducing the risk of mis-taps on mobile devices.
- Consistent help (3.2.6): Help mechanisms (like contact details or live chat) should appear in a predictable place across pages.
- Redundant input (3.3.7): Users shouldn’t be asked to re-enter previously provided information within the same session.
- Accessible authentication (3.3.8 & 3.3.9): Logins should be achievable without solving puzzles, remembering passwords, or passing cognitive tests.
These updates may appear incremental, but they carry real-world weight, especially when applied across platforms at scale. The emphasis isn’t only on code correctness, but on reducing cognitive strain and improving usability across devices and contexts.
Moving Beyond Compliance
The question isn’t just “Are we compliant?”
It’s “Do we know what good accessibility looks like in context?”
Some organisations treat accessibility like a checklist. Others treat it as a baseline expectation — a shared responsibility across product, design, content, and development. That difference comes down to maturity.
At MadeCurious, we ask slightly different questions:
- Are we making the experience intuitively usable, not just technically correct?
- Are we reducing the burden on the user — cognitively, physically, emotionally?
- Are we baking accessibility into our design critiques, dev tickets, and testing rituals?
These questions reveal far more than a pass/fail score ever could.
Where This Applies, and Who’s Affected
WCAG 2.2 compliance has legal implications in many jurisdictions (including the EU, US, Canada, Australia, and NZ), but even outside of mandates, it’s fast becoming a baseline for responsible digital practice.
Examples include:
- Government and public sector websites
- Health, education and finance platforms
- Large-scale ecommerce and SaaS applications
- Any product serving a diverse user base at scale
Accessibility isn’t about edge cases. It’s about designing for reality — where distractions, impairments (temporary or permanent), and device limitations are everyday concerns.
Preparing for WCAG 2.2 (Without Over-Engineering It)
If you’re already WCAG 2.1 compliant, you’ve done much of the groundwork. WCAG 2.2 simply asks you to raise the bar in a few focused areas.
For designers:
- Review mobile UI patterns: tap targets, spacing, and hierarchy
- Revisit login flows and help placement
- Reduce cognitive strain in forms
- Document any visual indicator changes clearly
For developers:
- Audit form logic, keyboard navigation, and input memory
- Keep semantic markup consistent as UI evolves
- Test with real assistive tech, not just simulators
For teams:
- Make accessibility part of sprint quality, not just post-launch QA
- Encourage shared literacy across disciplines
- Partner with specialists where needed
If you’re working within an ISO-compliant accessibility framework, most of this will already feel familiar. WCAG 2.2 just sharpens the lens.
Looking Ahead: What About WCAG 3.0?
WCAG 3.0 is on the (distant) horizon, but it's a longer-term shift, and still in draft form. It proposes a broader, more flexible model that could reshape how we test, score and validate accessibility across content types, including non-HTML formats. It aims to be understood more easily and cater for more needs (i.e. more needs of those with cognitive disabilities). See more on WCAG 3.0 here.
Until then, 2.2 remains the current standard and the most practical target for implementation.
Final Thought
For teams who already take accessibility seriously, WCAG 2.2 won’t be disruptive, but it is worth reflecting on. These updates represent more than technical adjustments. They reflect a growing expectation: that good digital experiences are inclusive by default.
Getting this right isn’t about ticking boxes.
It’s about craftsmanship.
