WCAG 2.2 AA What Changed and What Your Team Needs to Know

At Doghouse, we design and build with WCAG 2.2 AA in mind because accessibility is not a separate stream. It is how you avoid rework, reduce support burden, and create services that more people can actually use.

What changed in WCAG 2.2

WCAG 2.2 keeps the familiar structure of Level A, AA, and AAA, but adds success criteria that focus on everyday friction points. The most relevant changes for most teams are:

• **Focus not obscured**: keyboard focus must remain visible and not be covered by sticky elements or popovers
• **Focus appearance**: focus indicators need to be clear enough to see
• **Dragging movements**: if something can be dragged, there should be another way to operate it
• **Target size**: interactive controls need a large enough hit area
• **Consistent help**: help mechanisms should appear in a consistent place
• **Accessible authentication**: login flows should not depend on memory puzzles or interaction traps

These are not theoretical changes. They affect forms, navigation, modals, accordions, carousels, calendars, and custom components.

Why this matters for government

Government services are used by everyone, including people on older devices, people in a hurry, people with temporary injuries, and people navigating under stress. If a system is hard to use, the impact is real: dropped applications, higher call centre demand, more incomplete transactions, and less trust.

WCAG 2.2 AA is especially relevant for:

• service portals
• application forms
• content-heavy information sites
• authenticated dashboards
• case management tools

The key point is this: accessibility issues often show up first in complex journeys, not on the homepage.

What your team needs to update

If you are building or maintaining a digital service, start with these areas:

1. Design system components

Review button sizes, focus states, contrast, error messaging, and modal behaviour. If the design system is wrong, every product team inherits the problem.

2. Forms and validation

Make sure labels are clear, errors are specific, and focus moves logically after submission. Avoid relying on placeholder text as the only instruction.

3. Keyboard and assistive tech testing

Automated tools will not catch everything. You still need real keyboard testing and screen reader checks. If a flow is technically compliant but frustrating to use, it is not done.

4. Mobile interaction

Target size requirements matter more on touch screens than many teams realise. Tiny controls create avoidable errors, especially for users with motor impairments.

5. Authentication

WCAG 2.2 pays closer attention to login and verification flows. If your service uses MFA, image selection, drag gestures, or time-based challenges, test them properly.

Accessibility is a delivery discipline

The best teams do not treat accessibility as a final audit. They build it into planning, design reviews, code reviews, and QA. That is how you stop accessibility debt from piling up release after release.

Doghouse has done this across large government and enterprise programs, including content platforms, engagement tools, and service portals. The pattern is always the same: the earlier accessibility is considered, the cheaper and faster it is to get right.

What to do next

If your organisation has not reviewed WCAG 2.2 AA yet, start with an audit of your highest-traffic journeys. Look at forms, sign-in, navigation, and any custom UI. Then update your component library so the fix sticks.

Accessibility is not a nice-to-have. It is part of delivering a service that works for the public. WCAG 2.2 AA just makes that expectation more explicit. Teams that take it seriously will ship better products and spend less time firefighting later.