WCAG 2.2 AA adds six additional success criteria for full conformance. On Accessible.org’s side, this means there are more issues we need to audit for and, on the client’s end, there are more potential issues to work through for full conformance.
Most clients elect to use the WCAG 2.1 AA standard for their audit and others opt for WCAG 2.2 AA. We estimate it’s an 85/15 split.
| Aspect | WCAG 2.1 AA | WCAG 2.2 AA |
|---|---|---|
| Success Criteria | Standard criteria set | 6 additional criteria added for full conformance |
| Client Preference | 85% of clients choose this standard | 15% of clients opt for enhanced coverage |
| Audit Cost | Standard Accessible.org pricing | 10% higher cost for additional testing requirements |
| Project Timeline | Standard project duration | Increased time due to more criteria and complexity |
| Accessibility Coverage | Comprehensive accessibility standards | More thorough accessibility with enhanced user support |
| Conformance Difficulty | Standard complexity level | More difficult to achieve full conformance |
| ADA Title II | Explicitly required for compliance | Exceeds requirements |
| ADA Title III | Best practice (no explicit rule) | Exceeds best practice recommendations |
| European Accessibility Act | Best practice for EAA compliance | Exceeds EAA best practices |
| Section 508 | Exceeds requirements (2.0 required) | Significantly exceeds requirements |
| Future-Proofing | Meets all current legal requirements | Protected against future regulations requiring “current” or “most recent” standards |
Practical Differences
Here are the primary practical differences between WCAG 2.1 AA and 2.2 AA audits:
- Full WCAG 2.2 AA conformance is more difficult, increases project time
- Cost of an Accessible.org audit is 10% more for WCAG 2.2 AA
- WCAG 2.2 AA provides for more thorough accessibility
Legal Difference
In terms of compliance, the major laws and regulations either require WCAG 2.1 AA or it’s a best practice.
- The new ADA Title II web rule explicitly requires WCAG 2.1 AA conformance.
- There isn’t a rule for ADA Title III (the law the majority of website owners are being sued under in the U.S.), but WCAG 2.1 AA conformance is a best practice for preventing litigation.
- The European Accessibility Act (EAA) doesn’t explicitly name WCAG in the directive, but WCAG 2.1 AA is a best practice for EAA compliance.
- Section 508 of the Rehabilitation Act actually still ties to WCAG 2.0, the classic version of the Web Content Accessibility Guidelines published in 2008.
However, WCAG 2.2 AA conformance would exceed this threshold and future proofs against any digital accessibility law that requires WCAG 2.2 AA or conformance with the “current” or most “recent” standard.
So what are the actual technical differences between the two standards?
The 6 New Success Criteria in WCAG 2.2 AA
WCAG 2.2 AA introduces six additional success criteria beyond what’s included in WCAG 2.1 AA, bringing the total from 50 to 55 success criteria (with 2.1 success criterion 4.1.1 Parsing marked as obsolete in 2.2). These new requirements focus primarily on improving accessibility for users with cognitive disabilities and enhancing the mobile experience.
2.4.11 Focus Not Obscured (Minimum)
This success criterion ensures that when a user interface component receives keyboard focus, it’s at least partially visible. The focused element cannot be entirely hidden by other content like sticky headers, pop-ups, or overlays. This is crucial for keyboard users who need to see where they are on the page.
2.5.7 Dragging Movements
Functionality that uses dragging movements must have an alternative that can be achieved with a single pointer without dragging. For instance, if you have a slider that requires dragging to adjust values, you need to provide buttons or another mechanism that doesn’t require the dragging motion. This helps users with motor impairments who may struggle with precise dragging gestures.
2.5.8 Target Size (Minimum)
Interactive targets must be at least 24 by 24 CSS pixels, with some exceptions for inline targets, essential presentations, and user-agent controlled elements. This is actually less stringent than the 44 by 44 pixel requirement in WCAG 2.1’s 2.5.5 Target Size (Enhanced), which remains at Level AAA.
3.2.6 Consistent Help
If help mechanisms like contact information, chat features, or self-help options are provided on multiple pages, they must appear in the same relative order across those pages. This consistency helps users with cognitive disabilities locate help when they need it.
3.3.7 Redundant Entry
Information previously entered by the user in the same process should be either auto-populated or available for the user to select. Users shouldn’t have to re-enter the same information multiple times within a single process, which particularly benefits users with cognitive disabilities and those using assistive technologies.
3.3.8 Accessible Authentication (Minimum)
Authentication processes cannot rely solely on cognitive function tests like remembering passwords or solving puzzles. Alternatives must be available, such as support for password managers, email authentication links, or biometric options. This ensures users with cognitive disabilities can still access authenticated services.
These six success criteria represent WCAG 2.2’s emphasis on reducing cognitive load and improving the experience for users with motor impairments, making digital experiences more accessible for an even broader range of users.
The Difficulty
The last success criterion, 3.3.8 can be a particularly difficult one if you don’t use email verification as a login.
This success criterion frequently causes nonconformance, particularly for organizations with established authentication methods. The prohibition against cognitive function tests extends beyond just passwords to include CAPTCHAs, security questions, and puzzle-solving. While password managers offer one solution, many enterprise systems block paste functionality for security reasons, creating direct conflict with this requirement. Organizations must implement alternative authentication methods like email magic links, biometric authentication, or OAuth providers – all of which require substantial infrastructure changes.
Note that just because you use email verification doesn’t necessarily mean you’re home free — you still have to meet other requirements for conformance:
- If users must transcribe or remember their email address without support for auto-fill, paste functionality, or browser password managers, you may still fail this criterion. Always ensure the email field accepts pasted content and works with browser auto-complete features.
- Some email authentication systems add CAPTCHAs before sending the magic link, which would then be nonconformant with 3.3.8. Similarly, requiring users to enter a code from the email (rather than clicking a link) reintroduces a cognitive function test.
Summary
It’s client’s choice on this one and we can understand the rationale for going in either direction.
One approach that can work favorably if you’re open an initial audit and a secondary audit later is to start with a WCAG 2.1 AA audit, complete remediation, and then after 4-8 months have passed, make your second audit a WCAG 2.2 AA audit.
For the second audit, there should be significantly less issues which mean your team can put more focus into working on 2.2 issues.
If you’re ready to start with an audit, we’d love to help.
Send us a message below or contact us and we’ll be right with you.
