WCAG 2.2 was published as a W3C Recommendation in October 2023, adding 9 new success criteria to the 2.1 standard. While the DOJ's Title II rule references WCAG 2.1, forward-thinking agencies are already targeting 2.2 — and for good reason.
The new criteria address real barriers that 2.1 missed: authentication challenges, repetitive interactions, and small touch targets that frustrate users with motor disabilities. If you're building toward compliance anyway, hitting 2.2 now means you won't need to remediate again when standards inevitably update.
What Changed from 2.1 to 2.2
WCAG 2.2 adds 9 new success criteria (6 at Level A or AA, 3 at Level AAA) and removes one existing criterion (4.1.1 Parsing, which modern browsers handle natively). Here's what matters for your government site:
New Level A Criteria
3.2.6 Consistent Help
If your site provides help mechanisms — contact information, chatbots, FAQ links — they must appear in the same relative location on every page. Users shouldn't have to hunt for the help link because it moves depending on which section they're in.
Government example: Your "Contact Us" link should be in the same position in the header or footer on your parks page, your utilities page, and your permits page.
How to comply: Pick a consistent location for help mechanisms and enforce it across all templates and page layouts.
3.3.7 Redundant Entry
When users need to re-enter information they've already provided in the same process, the system must either auto-populate it or offer a way to select it. Don't make someone type their address three times in a permit application.
Government example: If a resident provides their address on step 1 of a building permit application, step 3 shouldn't ask for it again without pre-filling it.
How to comply: Store form data within multi-step flows and pre-populate fields. Offer "same as above" checkboxes for repeated address or contact fields.
New Level AA Criteria
2.4.11 Focus Not Obscured (Minimum)
When a UI component receives keyboard focus, it can't be entirely hidden behind other content like sticky headers, cookie banners, or fixed footers. At least part of the focused element must be visible.
Government example: Your sticky navigation header can't completely cover the focused link below it. If a user tabs to a menu item, some portion of it must remain visible even with the sticky header present.
How to comply: Use scroll-padding-top in CSS to account for sticky elements. Test keyboard navigation thoroughly with your actual page layout.
2.4.12 Focus Not Obscured (Enhanced) — Level AAA
The entire focused component must be visible, not just part of it. This is the stricter version of 2.4.11.
2.4.13 Focus Appearance — Level AAA
The focus indicator must meet minimum size and contrast requirements. Specifically, the focus indicator area must be at least as large as a 2px perimeter around the component, with at least 3:1 contrast against adjacent colors.
2.5.7 Dragging Movements
Any action that requires dragging must also have a non-dragging alternative. Users with motor disabilities can't always perform drag operations.
Government example: If your GIS mapping tool requires dragging to draw a property boundary, you must also provide click-based alternatives (e.g., clicking to add points).
How to comply: For every drag interaction, provide an equivalent tap/click workflow. This usually means offering coordinate input or sequential click placement.
2.5.8 Target Size (Minimum)
Interactive targets (buttons, links, form controls) must be at least 24×24 CSS pixels, unless an alternative meets the size requirement, the target is in a sentence of text, the size is user-agent controlled, or the size is essential.
Government example: Your mobile navigation hamburger menu, action buttons, and form submit buttons all need to be at least 24px in both width and height.
How to comply: Set minimum dimensions on interactive elements. This often means increasing padding on links within navigation and ensuring icon buttons have adequate touch area.
3.3.8 Accessible Authentication (Minimum)
Authentication flows can't require cognitive function tests (like remembering a password or solving a puzzle) unless an alternative is provided. This means offering options like:
- Password managers (don't block paste)
- WebAuthn / biometric login
- One-time codes sent via email or SMS
- OAuth through an existing identity provider
Government example: Your resident portal login can't rely solely on CAPTCHA. You must offer alternatives that don't require pattern recognition or memorization beyond what a password manager handles.
How to comply: Never block paste in password fields. Offer passwordless alternatives. If you use CAPTCHA, provide an audio or email-based alternative.
3.3.9 Accessible Authentication (Enhanced) — Level AAA
No cognitive test at all for authentication, including object recognition or personal content identification.
Practical Implications for Government Sites
Forms Are the Biggest Risk Area
Government websites are form-heavy: permit applications, utility registrations, public records requests, meeting sign-ups. The redundant entry, authentication, and target size criteria all hit forms directly. Audit every multi-step form for repeated fields, tiny submit buttons, and login flows.
Mobile Must Meet Target Size
The 24px minimum target size finally puts teeth behind "mobile-friendly." Government mobile sites with cramped navigation links and tiny form fields will need layout adjustments.
Sticky Elements Need Testing
Fixed headers and banners are common on government sites (emergency notifications, language selectors). The focus obscured criteria mean you must keyboard-test every page with these elements in place.
How to Test for WCAG 2.2
Automated scanning tools can catch many 2.2 issues — particularly target size violations, missing help consistency, and paste-blocking. However, some criteria (like dragging alternatives and redundant entry) require manual review of user flows.
A solid testing approach combines:
- Automated scanning (HelloCivic Scanner covers the majority of machine-testable criteria)
- Manual keyboard testing (focus visibility, dragging alternatives)
- Form flow review (redundant entry, authentication paths)
- Mobile device testing (target sizes at actual viewport widths)
Future-Proofing Your Compliance
WCAG 3.0 is in development, but it's years from finalization. WCAG 2.2 AA is the standard you should target today. If you're already meeting 2.1 AA for Title II compliance, adding the 2.2 criteria is incremental — mostly target size adjustments, form improvements, and authentication alternatives.
The investment pays forward. These aren't arbitrary rules; they're real barriers that real residents encounter. Meeting 2.2 now means fewer support calls, fewer complaints, and a better experience for everyone who interacts with your digital services.
