WCAG 2.2 AA Compliance: What Changed and How to Test It
A vendor RFP asks for “WCAG 2.2 AA conformance.” Legal’s last memo cited 2.1. The design system was audited eighteen months ago, and nobody on the team can say with confidence whether the current contract, regulation, or internal accessibility policy requires 2.1 or 2.2. That gap between the applicable requirement and the current technical standard is where enterprise accessibility programs quietly fall behind.
eight25 is a certified Contentstack implementation partner and a Contentful solution partner. Our delivery approach combines automated checks with manual testing across components, page templates, and complete user flows because no automated tool alone can establish WCAG conformance. WCAG 2.2 added nine success criteria in October 2023, and six of them apply to a Level AA claim. The DOJ Title II rule still specifies WCAG 2.1 AA, while the European Accessibility Act does not directly name WCAG 2.2. Building to 2.2 is therefore often the stronger technical decision, but the applicable regulation, contract, and procurement language still need to be checked.
Why WCAG 2.2 Matters When Many Requirements Still Cite Earlier Standards
The DOJ’s ADA Title II final rule requires state and local government web content and mobile apps to meet WCAG 2.1 Level AA, subject to specified exceptions. Public entities with populations of 50,000 or more had to begin complying by April 24, 2026; entities with populations below 50,000 and special district governments had until April 26, 2027. In the EU, the European Accessibility Act has applied to covered products and services since June 28, 2025, but the directive does not itself name WCAG 2.1 or WCAG 2.2 as its universal technical standard. EN 301 549 v3.2.1 is harmonized in support of the Web Accessibility Directive, while standards work to support the EAA remains a developing area. The correct baseline therefore depends on the organization, product or service, jurisdiction, and contractual requirements.
Procurement teams often confuse the current technical target with the standard that must be reported for a particular contract. W3C recommends WCAG 2.2 as the new conformance target even when formal obligations reference an earlier version, but the Accessibility Conformance Report should address the standards named in the solicitation or contract. The CMS does not make the resulting website conformant on its own: Contentstack explicitly states that it does not enforce front-end accessibility requirements, and a platform’s own accessibility statement does not guarantee the accessibility of every site built with it. This is where implementation matters. eight25 can translate the applicable criteria into reusable components, authoring controls, manual test cases, and release checks rather than leaving accessibility as a final automated scan.
What Actually Changed Between 2.1 and 2.2
WCAG 2.1 contains 78 success criteria. WCAG 2.2 added nine and removed 4.1.1 Parsing from the conformance requirements, leaving 86 active criteria. W3C removed Parsing because assistive technologies no longer need to parse HTML directly and the relevant interoperability problems are either obsolete or addressed by other criteria. That does not make malformed markup or duplicate IDs harmless; they can still create failures under criteria such as Name, Role, Value when they affect how components are exposed to assistive technology.
The nine additions split across three conformance levels:
| Level | Count | Success Criteria |
|---|---|---|
| A | 2 | 3.2.6 Consistent Help, 3.3.7 Redundant Entry |
| AA | 4 | 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.3.8 Accessible Authentication (Minimum) |
| AAA | 3 | 2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance, 3.3.9 Accessible Authentication (Enhanced) |
Because Level AA conformance requires meeting every Level A and Level AA criterion, a site claiming “WCAG 2.2 AA” must address six new checks, not only the four labeled AA. The two Level A additions, Consistent Help and Redundant Entry, belong in the same delta review.
The Six New Criteria a WCAG 2.2 AA Claim Actually Covers
Three of the six show up constantly in real interfaces and are worth knowing cold:
2.5.8 Target Size (Minimum). Pointer targets generally need to measure at least 24 by 24 CSS pixels. An undersized target may still pass when a 24-pixel-diameter circle centered on its bounding box does not intersect another target or the equivalent circle around another undersized target. Other exceptions include an equivalent conforming control on the same page, inline links, user-agent-controlled targets, and presentations whose size is essential. Icon buttons, modal close controls, and dense filter chips are practical places to begin testing.
2.5.7 Dragging Movements. When site-authored functionality uses dragging, the same function must also be achievable with a single pointer without dragging. A reorderable list might provide move-up and move-down controls, while a slider might accept a click or tap at the desired value. The requirement does not apply when dragging is essential to the function or when the interaction is controlled by the user agent rather than the site. This check is easy to miss when the interaction has only been tested with a mouse by users with fine motor control.
2.4.11 Focus Not Obscured (Minimum). When a user interface component receives keyboard focus, it must not be entirely hidden by author-created content. Sticky headers, cookie banners, modal layers, and chat widgets are common sources of failures. The Level AA requirement is partial visibility; WCAG 2.4.12 at Level AAA requires the component to remain fully visible. eight25 treats sticky and overlapping elements as both component-level and page-template test cases because their behavior often changes with viewport size and scroll position.
The other three matter but are less visually obvious:
3.3.8 Accessible Authentication (Minimum) prevents an authentication step from relying solely on a cognitive function test, such as remembering a password or solving a puzzle, unless the flow provides an alternative method, a mechanism that assists the user, an object-recognition test, or a test based on personal content supplied by the user. Support for password managers and copy and paste can satisfy the assistance requirement in relevant cases. 3.2.6 Consistent Help applies when qualifying help mechanisms are repeated across pages in the same set: they must appear in the same order relative to other page content, but the criterion does not require every page to contain help. 3.3.7 Redundant Entry requires previously supplied information to be auto-populated or available for selection when requested again in the same process, unless re-entry is essential, required for security, or the previous information is no longer valid.
How to Test For Each One
None of these six criteria should be treated as fully machine-testable in every implementation. Automated tools can identify likely problems, but W3C is explicit that no tool alone can determine whether a site conforms. Target Size can be screened programmatically using rendered dimensions and spacing, including axe-core’s target-size rule, but exceptions, equivalent controls, responsive behavior, and real interaction states still need human verification. The remaining criteria require manual testing across components, page templates, and complete user processes.
| Success Criterion | Fastest test method | What to look for |
|---|---|---|
| 2.5.8 Target Size | Automated screening followed by manual verification at relevant responsive breakpoints | Targets below 24 by 24 CSS pixels; circle-based spacing; overlapping targets; equivalent controls; inline, user-agent, and essential-presentation exceptions |
| 2.5.7 Dragging Movements | Manually complete every site-authored drag function with a single pointer but without dragging | Sliders, reorderable lists, maps, carousels, or custom pickers without a click, tap, or button-based alternative; document any essential-dragging exception |
| 2.4.11 Focus Not Obscured | Navigate by keyboard with sticky and overlapping content active at relevant viewport sizes | A focused component becoming entirely hidden behind an author-created header, banner, modal, footer, or widget |
| 3.3.8 Accessible Authentication | Walk through login, MFA, account recovery, and password-reset flows with password-manager and copy-paste support enabled | Cognitive tests with no allowed alternative or assistance; blocked password managers; disabled paste; exceptions involving object recognition or personal content |
| 3.2.6 Consistent Help | Compare the serialized relative order of repeated help mechanisms across pages in the same set and page variation | A repeated human contact, self-help, or automated contact mechanism moving to a different relative order without a user-initiated change |
| 3.3.7 Redundant Entry | Complete every relevant multi-step process from beginning to end | Previously supplied information being requested again without auto-population or selection; verify essential, security, and no-longer-valid exceptions |
Shared components are the highest-leverage place to start, but they are not the whole audit. Fixing a defective modal or target-size pattern once can remove the same problem from every page that uses it. Consistent Help, however, must be compared across pages, while Redundant Entry and Accessible Authentication often require complete process testing. A defensible eight25 review therefore begins with the component inventory, then validates representative full pages, responsive states, and every in-scope multi-step process.
Building a 2.2 Delta Audit Into an Existing 2.1 Program
A full re-audit may be unnecessary when the existing WCAG 2.1 baseline is recent, its scope is documented, the relevant pages and components have not materially changed, and regression controls have been maintained. WCAG 2.2 was designed to be backward compatible with 2.1, so a focused delta review can begin with the six new Level A and AA criteria. A 2.2 conformance claim still requires the current site to satisfy every applicable Level A and AA criterion, however. If the earlier audit is stale, incomplete, or followed by significant design and development changes, the existing criteria should be revalidated as well.
Scope the review to actual exposure without confusing a sampled review with a site-wide conformance claim. A twelve-page marketing site with no authentication, multi-step forms, or drag interactions presents a different testing surface from a customer portal with account creation, MFA, and a reorderable dashboard. The portal needs every in-scope process and responsive state tested; the smaller site may justify a narrower component and template review. Public-sector sites, regulated services, and organizations facing active legal claims should have counsel confirm the required scope. eight25 can then translate that scope into a proportionate test plan rather than applying the same audit package to every property.
A CMS rebuild is the right moment to fix the mechanism rather than individual instances. Authoring controls can constrain heading structure, require useful asset descriptions, and reduce avoidable publishing errors, but they cannot guarantee the accessibility of the rendered front end or its user flows. The six new criteria span shared components, page-level patterns, and complete processes. During NetApp’s Tridion-to-Contentstack migration, eight25 found that editors had been required to select H1, H2, and H3 tags manually. Instead of reproducing that error-prone workflow, eight25 assigned heading tags automatically for relevant components. That is the more durable role of an implementation partner: put accessible defaults into the system so every release depends less on individual editors remembering technical rules.
Document What You Don’t Fix
Record every unresolved finding with the affected pages or components, the relevant success criterion, user impact, remediation owner, and target date. If an in-scope Level A or AA criterion still fails, do not describe that scope as WCAG 2.2 AA conformant. An organization may make an internal risk and scheduling decision about remediation, but documenting that decision does not turn a failure into conformity or remove an applicable legal obligation. Counsel should advise on launch decisions where regulatory or litigation exposure exists.
Frequently Asked Questions
Do I need to comply with WCAG 2.2, or is 2.1 still enough?
It depends on the requirement that applies to the specific organization and digital property. The DOJ’s ADA Title II rule specifies WCAG 2.1 AA for covered state and local government content. The European Accessibility Act establishes accessibility requirements for covered products and services but does not simply mandate WCAG 2.1 or 2.2 for every website. Contracts, procurement documents, national laws, and organizational policies may impose additional requirements. For new work, W3C recommends WCAG 2.2 as the conformance target. Any Accessibility Conformance Report should identify the precise standards and version against which the product or site was evaluated.
What is the WCAG 2.2 target size requirement?
Success criterion 2.5.8 generally requires pointer targets to be at least 24 by 24 CSS pixels. An undersized target may pass when a 24-pixel-diameter circle centered on its bounding box does not intersect another target or the equivalent circle around another undersized target. Exceptions also exist for an equivalent conforming control, inline targets, user-agent-controlled sizing, and presentations whose size is essential.
What counts as a “dragging movement” under WCAG 2.5.7?
A dragging movement is an interaction in which the pointer engages with an element, moves while remaining engaged, and releases at a different position. Examples include moving a slider thumb or reordering a list. If site-authored functionality uses dragging, the same function must also be achievable with a single pointer without dragging, unless dragging is essential or the functionality is controlled by the user agent.
How do I test for Focus Not Obscured (2.4.11)?
Navigate through the page by keyboard while every relevant sticky or overlapping element is active, including headers, cookie banners, modal layers, and chat widgets. Test the page at its relevant responsive breakpoints and confirm that no focused component becomes entirely hidden by author-created content. Partial visibility satisfies 2.4.11; full visibility belongs to the enhanced Level AAA criterion, 2.4.12.
Can an accessibility overlay get a site to WCAG 2.2 AA?
An overlay cannot, by itself, substantiate a site-wide WCAG 2.2 AA conformance claim. Client-side tools may alter some rendered behavior, but conformance still has to be established against the complete pages and processes users actually experience. In 2025, the FTC finalized an order requiring accessiBe to pay $1 million and prohibited unsupported claims that its automated product could make any website WCAG-compliant or ensure continued compliance. Treat overlays as neither evidence of conformance nor a substitute for correcting and testing the underlying implementation.
How do I find a partner who can audit against WCAG 2.2, not just 2.1?
Ask prospective partners which checks are automated, which are manual, how they test complete user processes, and how findings are carried into future releases. An automated scan report alone cannot establish conformance. The stronger model combines reusable-component testing with representative full-page, responsive, keyboard, and process-level evaluation. eight25’s advantage is that this work can be connected to the component system, content model, and ongoing delivery process instead of ending as a standalone report that begins aging on the day it is delivered.
Getting the 2.2 Delta Right Without Re-Auditing Everything
If an RFP named WCAG 2.2, or your design system has not been evaluated against the current standard since before October 2023, the first step is establishing what evidence can still be relied on. eight25 reviews the existing audit, component inventory, representative page templates, and complete user flows to determine whether a focused 2.2 delta review is sufficient or broader validation is needed. That gives enterprise teams a defensible scope before they commit a budget to unnecessary testing. Start a conversation with our team