Web accessibility: build WCAG 2.2 in from the design stage

Version 2.2 of the Web Content Accessibility Guidelines has been a W3C Recommendation since October 2023. It does not overturn the earlier versions: it stays backward compatible and simply adds nine success criteria aimed mainly at keyboard navigation, touch interactions and authentication. Handling accessibility at the design stage, rather than as an end-of-project fix, changes the cost of compliance dramatically. A project that anticipates it absorbs these criteria with no visible overhead; a project that discovers them at acceptance pays full price for every correction.

#What WCAG 2.2 adds

The nine new criteria spread across the three conformance levels. Most fall under level AA, the one regulatory frameworks target.

Two criteria deserve immediate attention. Target Size (Minimum) (2.5.8) requires clickable areas of at least 24 by 24 CSS pixels, with some exceptions: a dense navigation menu or cramped icons become non-compliant. Accessible Authentication (3.3.8) forbids requiring a cognitive test, such as remembering a password or solving a puzzle, without an alternative: a field compatible with the password manager is enough to satisfy it.

The other criteria target concrete irritants. Dragging Movements (2.5.7) require any drag-and-drop action to offer a single-pointer alternative, helping people with tremors as much as touchscreen users. Consistent Help (3.2.6) asks that help mechanisms, a contact form or a link to support, appear in the same place from one page to the next. Redundant Entry (3.3.7) forbids asking again for information already provided within the same journey, barring genuine need: a shipping address should not be retyped at the billing step.

#Three levels, one realistic target

The criteria fall into three cumulative levels. Aiming for AAA across a whole site is neither required nor always possible; level AA is the reference target.

#Turning criteria into code

Most criteria are met with correct HTML and a few CSS rules, no library required. An accessible form field pairs an explicit label, a suitable type and help linked by aria-describedby.

<label for="email">Adresse e-mail</label>
<input id="email" name="email" type="email"
       autocomplete="email" required
       aria-describedby="email-aide">
<p id="email-aide">Format attendu : [email protected]</p>

The autocomplete attribute directly satisfies accessible authentication: it lets the browser and the password manager fill the field, with no cognitive effort. On the presentation side, target size and focus visibility are set in a few lines, drawing on the theme’s variables.

/* 2.5.8 Taille de cible (minimum) : 24 x 24 px */
.btn-icone {
  min-block-size: 24px;
  min-inline-size: 24px;
}

/* 2.4.11 Focus non masqué : un focus toujours visible */
:focus-visible {
  outline: 3px solid var(--focus, #1a9694);
  outline-offset: 2px;
}

Centralising the focus colour in a variable avoids reintroducing it on every component and keeps a consistent rendering in light and dark themes, in the spirit of design tokens. The same approach applies to spacing targets: setting a minimum line height on navigation lists fixes the compliance of dozens of links at once.

Redundant entry is handled as much on the server as in the markup. A multi-step form benefits from keeping already-entered values and pre-filling them, rather than showing empty fields. Here too, a well-chosen autocomplete attribute and preserved state between steps are enough, with no bespoke component.

#The European legal framework

Accessibility is no longer merely good practice. The European Accessibility Act has applied since 28 June 2025 to many digital services sold to consumers in the Union: online retail, banking, ticketing, content platforms. In practice, the reference technical standard, EN 301 549, points to the AA-level WCAG criteria. In France, the RGAA transposes the same requirement for the actors concerned, with a now well-established principle: the absence of a conformance statement and an action plan is itself a shortcoming, regardless of the site’s actual quality.

The scope is broad and often underestimated. A marketplace, a booking application or a bank’s customer area fall within it, while a strictly brochure site may remain exempt in some cases. Checking your exposure ahead of a redesign avoids discovering the obligation once the budget is committed, and a non-compliant site now faces legal risk, not just an ergonomics critique.

A criterion fixed on the mockup costs a few minutes; the same one, retrofitted in production, ties up a whole team.

#Building accessibility into the workflow

Automation catches part of the defects without replacing human review. An audit with an engine like axe or the browser’s Lighthouse tab flags insufficient contrast, missing labels and targets that are too small. These checks are better run throughout development than at delivery, exactly as site monitoring is set up continuously rather than at the finish line. Wired into the continuous integration pipeline, they block a regression before it reaches production, just like a failing unit test.

The semantic markup that underpins accessibility also serves search: a correctly structured heading helps the screen reader and the search engine alike, and a clear heading hierarchy aids both. Investing in a clean semantic base therefore serves two goals in one move, which makes the budget trade-off far easier to defend to a client.

#The bottom line

WCAG 2.2 overturns nothing but tightens the requirements where users struggle most: touch targets, keyboard focus, authentication. Level AA is the concrete target, now backed by a legal obligation in Europe. The right approach is to build these criteria in from the design stage, to lean on semantic HTML and theme variables, and to complement automated audits with human testing. It is less a one-off project than a habit to install in the workflow.

Further reading: the reference specification, Web Content Accessibility Guidelines (WCAG) 2.2 (W3C).