Designing for WCAG 2.2 after ISO approval changes how teams plan accessibility work. With ISO/IEC 40500:2025 published in Sep/Oct 2025 and the W3C press release of 21 Oct 2025, WCAG 2.2 now has an internationally harmonized record that drives procurement, national adoption, and clearer conformance references.
This article explains practical design changes, new success criteria, testing updates, and procurement implications you should act on now. It draws on the W3C and ISO publications, recent public sector guidance, and the authoritative how-to resources you should bookmark.
What ISO adoption means for designers and product teams
The ISO/IEC 40500:2025 entry maps the October 2023 WCAG 2.2 Recommendation into an international standard, identified as Edition 2 and published in 2025. That ISO record makes WCAG 2.2 more likely to be cited in national standards, procurement rules, and contract language worldwide, so product teams must anticipate stronger external expectations.
W3C leaders highlighted the global coordination in the Oct 21, 2025 press release, noting ISO/IEC JTC 1 provided the updated accessibility standard. Practitioners should treat this change as a shift from a primarily web community standard to one with formal international recognition, which accelerates legal and procurement adoption.
For designers, the practical consequence is simple: update conformance targets, accessibility statements, and procurement templates to reference ISO/IEC 40500:2025 when your organisation intends to meet WCAG 2.2. That step reduces downstream friction in contracts and public tenders, and it aligns public messaging with the international record.
What is new in WCAG 2.2 and what to prioritise
WCAG 2.2 adds nine new success criteria overall, bringing notable additions across Levels A, AA, and AAA. The new criteria break down to 2 at Level A, 4 at Level AA, and 3 at Level AAA. Teams must review the specifics because some changes affect common UI patterns designers use every day.
The nine new success criteria are: 2.4.11 Focus Not Obscured (AA); 2.4.12 Focus Not Obscured Enhanced (AAA); 2.4.13 Focus Appearance (AAA); 2.5.7 Dragging Movements (AA); 2.5.8 Target Size Minimum (AA); 3.2.6 Consistent Help (A); 3.3.7 Redundant Entry (A); 3.3.8 Accessible Authentication Minimum (AA); and 3.3.9 Accessible Authentication Enhanced (AAA). Also note success criterion 4.1.1 Parsing was removed and is no longer part of WCAG 2.2.
W3C recommends organisations adopt WCAG 2.2 as the target to future-proof work, even where regulation currently cites an older version. Prioritise the AA-level additions for broad compliance expectations, especially 2.5.8 Target Size and 2.4.11 Focus Not Obscured, which affect core interaction affordances.
Design system and component updates to meet WCAG 2.2
Update your design system tokens, components, and documentation to bake in the new requirements. Make visible, large focus indicators a default, guarantee minimum target sizes or spacing, and document consistent placement for help UI. These changes reduce one-off fixes and keep engineers from drifting back to noncompliant styles.
For focus appearance, implement the W3C rule that the focus indicator area must be at least the area of a 2 CSS-pixel perimeter around the unfocused control and that the focused state has at least a 3:1 contrast change compared to unfocused state. The W3C Understanding page provides formulas and pass/fail examples you can automate or run in design review.
For target sizing, enforce the 24×24 CSS pixel minimum or apply the spacing exceptions from the spec. Where you allow smaller visual targets, ensure non-overlapping 24px diameter circles around the control, or otherwise apply the documented exceptions. Include code samples and visual test cases in your component library so teams reuse proven solutions.
Interactions: dragging, touch targets, and focus management
Interaction patterns are central to WCAG 2.2. 2.5.7 requires that functionality using dragging is also operable with a single-pointer non-drag alternative unless dragging is essential. Designers must provide alternative activation models, for example tap-to-select plus move controls or accessible handles that can be keyboard-operated.
Target size rules in 2.5.8 introduce numerical thresholds designers must meet. Use the W3C understanding pages to implement and test the 24×24 CSS px rule and the spacing exceptions. These metrics are testable in automated suites and are concrete enough to include in acceptance criteria for components and features.
Focus not obscured and focus appearance rules mean components that show overlays, menus, or tooltips must not hide the focus indicator or should move the indicator so keyboard users always know where focus is. Review patterns like modals, drawers, and inline widgets against 2.4.11 and 2.4.13 during design reviews.
Authentication, cognitive load, and reducing redundant entry
WCAG 2.2 adds important requirements for authentication and cognitive load. The new authentication SCs (3.3.8 and 3.3.9) require alternatives to cognitive function tests and support for password managers, copy/paste, and other mechanisms. Remove object-recognition puzzles as primary authentication methods and add accessible fallback flows.
3.3.7 Redundant Entry encourages auto-population and optional re-entry to reduce cognitive load for users. Practical implementations include retaining previously entered personal data between steps when appropriate, offering review screens rather than forcing re-entry, and clearly marking optional fields.
Consistent help (3.2.6) means help mechanisms should appear in predictable places and follow consistent designs. Add help copy, inline guidance, and global help patterns to your design system so designers reuse consistent layouts and users learn where to look when they need assistance.
Testing, automation, and the evolving ACT Rules ecosystem
Testing for WCAG 2.2 should be a mix of automated checks, ACT rules where available, manual keyboard and screen-reader testing, and user testing with people with disabilities. W3C maintains a tools list; many popular tools like axe and Lighthouse have updated to include WCAG 2.2 checks, but coverage varies and manual validation remains essential.
W3C’s ACT Rules Format moved to a Candidate Recommendation snapshot, and ACT rules coverage for WCAG 2.2 is expected to grow. Add ACT-based checks to your CI pipeline as rules become available, and keep manual test cases for nuanced SCs like focus appearance, authentication alternatives, and consistent help placement.
Use the W3C How to Meet WCAG 2.2 quick reference, Understanding documents, and Techniques for each new SC. Those resources contain code examples, measurement formulas, and pass/fail examples that are invaluable when creating automated tests, QA scripts, and acceptance criteria for design tokens and components.
Procurement, legal context and rollout planning
The ISO publication shifts how procurement and legal teams reference accessibility. Expect national standards and procurement language to increasingly cite ISO/IEC 40500:2025. Update accessibility statements and procurement templates to refer explicitly to the ISO entry when your organisation intends to meet WCAG 2.2; this helps avoid ambiguity in bids and contracts.
In Europe, EN 301 549 historically referenced WCAG 2.1; work is ongoing to align EN 301 549 and the European Accessibility Act with WCAG 2.2. Monitor harmonisation timelines because legal presumption of conformity may lag the ISO publication. In the U.S., DOJ and other agencies still reference WCAG 2.1 in regulations, so plan adoption paths that bridge current regulatory dates and expected updates.
Recommended rollout steps are: 1) inventory pages and components, 2) update design system tokens and components for focus and targets, 3) update test suites/CI with ACT and automation plus manual suites, 4) update accessibility statements and procurement language to reference ISO/IEC 40500:2025, and 5) run user testing with people with disabilities. Those steps collate guidance from W3C, GDS, NHS and other authorities.
WCAG 2.2 as ISO/IEC 40500:2025 is a practical upgrade rather than an abstract change; it gives designers clearer numeric tests and stronger international grounding. Use the W3C resources, the How to Meet quick reference, and the Understanding pages for each new SC when implementing updates.
Keep a short watchlist: EN 301 549 harmonisation timing, national adoptions of ISO/IEC 40500:2025, expansion of ACT rules coverage for WCAG 2.2, and any future WCAG text processed through ISO. Practically, update your design system, test suites, procurement language, and run real user testing to ensure compliant and usable outcomes.