WCAG 2.1 vs WCAG 2.2: What Changed and Does It Affect Your SaaS?

WCAG 2.2 was published as the official W3C recommendation in October 2023. If you have been working toward WCAG 2.1 Level AA compliance, as required by the European Accessibility Act (via EN 301 549) – you may be wondering whether WCAG 2.2 changes your obligations, what specifically is new, and whether you need to act now or wait. The short version: WCAG 2.2 is backwards-compatible with 2.1 (everything you have already done remains valid), adds nine new success criteria that address real gaps in mobile accessibility, authentication design, and cognitive accessibility, and will become the referenced standard in EN 301 549 when that standard updates – making today’s WCAG 2.2 work tomorrow’s legal baseline. This post explains exactly what changed between 2.1 and 2.2, what the new criteria require in practice, and what SaaS products need to prioritise.

WCAG Version History: The Context

WCAG is the Web Content Accessibility Guidelines, published by the W3C (World Wide Web Consortium). They define the technical standard for digital accessibility — the criteria that determine whether a website, web application, or digital service is accessible to people with disabilities.

WCAG 2.0 – published 2008. 61 success criteria covering the four POUR principles (Perceivable, Operable, Understandable, Robust). Designed primarily for the desktop web of the early 2000s.

WCAG 2.1 – published 2018. Added 17 new criteria addressing mobile accessibility, low vision, and cognitive disabilities. Total: 78 criteria. Currently referenced by EN 301 549 as the EAA compliance standard.

WCAG 2.2 – published October 2023. Added 9 new criteria, removed 1 obsolete one. Total: 86 criteria. Currently, the W3C recommends a standard. Not yet referenced by EN 301 549 (which drives EAA requirements), but expected to be when EN 301 549 updates.

WCAG 2.0, 2.1, and 2.2 are all valid existing standards. 2.2 does not supersede 2.1. W3C encourages using the latest version. Content meeting WCAG 2.2 automatically meets 2.1 and 2.0.

What WCAG 2.2 Removed: 4.1.1 Parsing

WCAG 2.1’s criterion 4.1.1 (Parsing) required HTML to be free of certain errors: duplicate IDs, unclosed tags, and similar markup issues — because older assistive technologies parsed HTML directly and were affected by these errors. Modern browsers and assistive technologies no longer have this vulnerability. The criterion was obsolete in practice and has been removed from WCAG 2.2.

If you are conforming to WCAG 2.2, you do not need to comply with 4.1.1. If you are still testing against WCAG 2.1 specifically, 4.1.1 still applies to that conformance claim.

The 9 New WCAG 2.2 Success Criteria

WCAG 2.2 introduces 9 new criteria. Three are Level A (minimum), five are Level AA (the compliance target for EAA and most legal frameworks), and one is Level AAA (enhanced, typically not required). The 6 new Level AA criteria are the ones that directly affect the EAA compliance strategy.

1. Focus Not Obscured (Minimum) – 2.4.11 (AA)

What it requires: When a keyboard-focusable element receives focus, at least part of it must remain visible; not entirely hidden behind a sticky header, cookie banner, floating chat widget, or other author-created content.

Why it matters for SaaS: SaaS products commonly use sticky navigation bars, persistent notifications, and floating support widgets. A user navigating by keyboard through a form can have the currently focused field disappear behind the navigation bar; they can see focus has moved, but cannot see where. This criterion requires that at least part of the focused element remains visible.

What to check: Tab through your product with keyboard navigation only. Do focused elements disappear behind any fixed or sticky-positioned elements?

2. Focus Not Obscured (Enhanced) – 2.4.12 (AAA)

The AAA version requires the entire focused element to be visible, not just part of it. Not required for AA compliance.

3. Focus Appearance – 2.4.13 (AA) (newly added at AA in 2.2)

What it requires: Keyboard focus indicators must meet minimum size and contrast requirements – the focus ring must be at least 2 CSS pixels wide and have a 3:1 contrast ratio against adjacent colours.

Why it matters for SaaS: The default browser focus indicator is often insufficient – thin, low-contrast, and invisible against many backgrounds. Many SaaS products suppress the default focus ring (via

) without providing an adequate replacement. This criterion sets a minimum bar for what a custom focus indicator must achieve.

What to check: Does your product have a visible, high-contrast focus indicator? Does it meet the size and contrast requirements?

4. Dragging Movements – 2.5.7 (AA)

What it requires: Any functionality that requires dragging must also be achievable by a single pointer action (a click or tap) without dragging.

Why it matters for SaaS: Drag-and-drop interfaces are common in SaaS products – Kanban boards, priority ordering, file organisation, widget placement. Users with motor disabilities, tremors, or limited fine motor control cannot reliably perform drag operations. This criterion requires that every drag-and-drop operation has a single-click alternative (e.g., a context menu with “move to” options, keyboard shortcuts, or similar).

What to check: Does your product have any drag-and-drop functionality? Does each dragging action have a single-pointer or keyboard alternative?

5. Target Size (Minimum) – 2.5.8 (AA)

What it requires: Interactive targets must be at least 24×24 CSS pixels, or must have sufficient spacing from adjacent targets such that a 24px circle centred on the target does not overlap another target.

Why it matters for SaaS: Dense interfaces with small interactive elements: icon buttons, close buttons, filter tags, action menus – are common in data-heavy SaaS products. Targets that are too small create barriers for users with motor impairments and for all users on touchscreens. WCAG 2.1 had a 44×44px AAA requirement that was too aggressive for many interfaces. The 2.2 AA requirement of 24px with spacing exceptions is more practical.

What to check: Inspect your smallest interactive elements. Do they meet 24×24px, or do they have adequate spacing from adjacent targets?

6. Consistent Help – 3.2.6 (AA)

What it requires: If a mechanism for getting human assistance (chat, email, phone, help link) is available across multiple pages, it must appear in the same location on each page.

Why it matters for SaaS: Help and support access should be predictable. If your product has a floating chat bubble or a “Help” link in the navigation, it should appear consistently, not disappear on some pages and appear differently on others.

What to check: Is your help mechanism consistently located across all product pages?

7. Redundant Entry – 3.3.7 (A)

What it requires: Information previously entered by the user and still required must either be auto-populated or available for the user to select — users should not have to re-enter the same information in the same session.

Why it matters for SaaS: Multi-step forms and onboarding flows that ask users to re-enter information they already provided (company name, email, billing address) create unnecessary barriers, particularly for users with cognitive disabilities. Auto-fill, data population from previous steps, or selection interfaces address this.

What to check: Do any forms in your product ask users to re-enter information they have already provided in the same session?

8. Accessible Authentication (Minimum) – 3.3.8 (AA)

What it requires: Authentication processes must not require a cognitive function test, such as solving a puzzle, reading distorted text (CAPTCHA), or memorising and transcribing a code from a separate source, unless an alternative is provided.

Why it matters for SaaS: This is one of the most impactful criteria for SaaS products. Two-factor authentication flows that require users to transcribe a one-time passcode from an authenticator app or SMS, without allowing copy-paste, create cognitive barriers. CAPTCHA that presents visual puzzles without audio alternatives fails. The criterion requires alternatives: allowing copy-paste for OTP codes, providing audio CAPTCHA alternatives, or using passkeys and biometric authentication.

What to check: Does your authentication flow allow copy-paste for OTP codes? If you use CAPTCHA, does it have an accessible alternative?

9. Accessible Authentication (Enhanced) – 3.3.9 (AAA)

The AAA version requires no cognitive function test at all, even with alternatives. Not required for AA compliance.

WCAG 2.1 vs WCAG 2.2: Side by Side

What SaaS Products Need to Do

If you are currently working toward WCAG 2.1 AA compliance: Continue – it remains the EAA legal baseline. Begin evaluating your product against the 6 new WCAG 2.2 AA criteria above, as they will become legally required when EN 301 549 updates. Prioritise: accessible authentication (3.3.8), drag-and-drop alternatives (2.5.7), and focus not obscured (2.4.11), these address the highest-frequency SaaS interface patterns.

If you are already WCAG 2.1 AA compliant: Audit against the 6 new AA criteria. Many products will find that focus not obscured, accessible authentication, and target size are the criteria that require the most work. Implementing these now positions you ahead of the EN 301 549 update.

If you are starting accessibility work: Target WCAG 2.2 AA from the beginning. You cannot be overcompliant. Building to 2.2 means meeting EAA requirements (2.1 AA) and being prepared for the standard update, without any additional rework.

At Inity, we design SaaS products with WCAG 2.2 AA as the standard from Discovery Week – every interactive component, every authentication flow, and every drag-and-drop interface is designed to meet the current criteria before a line of code is written.

Conclusion

WCAG 2.2 is not a departure from WCAG 2.1; it is an extension. The nine new criteria address real gaps: authentication flows that exclude users with cognitive disabilities, drag-and-drop interfaces that exclude users with motor impairments, and focus indicators that are invisible in modern interface designs with sticky navigation and floating elements. For SaaS products, most of the new criteria affect patterns that are extremely common, and most are straightforward to implement if built in from the beginning. The cost of retrofitting them onto a live product, however, is significantly higher. The EAA currently requires WCAG 2.1 AA. WCAG 2.2 is where the standard is heading. Building to 2.2 now means doing the work once.

→ Not sure where your product stands against WCAG 2.2? Inity conducts structured accessibility audits covering both WCAG 2.1 and 2.2 criteria. Book a call.