WCAG 2.2: Implementing the New Success Criteria

WCAG 2.2 builds on the foundation of WCAG 2.1 and adds nine new success criteria, while one existing criterion (4.1.1 Parsing) has been removed as obsolete. The new criteria are distributed across three conformance levels: two at Level A, four at Level AA and three at Level AAA. Six of the nine new criteria therefore count towards WCAG 2.2 AA conformance. EN 301 549, to which the BFSG refers via harmonised standards, adopts exactly these six in version V4.1.1; version V3.2.1 is still based on WCAG 2.1.

The content focus of the new criteria lies in three areas: focus management (Focus Not Obscured, Focus Appearance), motor accessibility (Dragging Movements, Target Size) and cognitive accessibility (Redundant Entry, Consistent Help, Accessible Authentication). These priorities reflect the recognition that previous WCAG versions primarily addressed visual and auditory barriers while cognitive and motor impairments were underrepresented.

For companies already WCAG 2.1 AA-compliant, the effort for migration to WCAG 2.2 is manageable. The new criteria affect specific interaction patterns that can be efficiently tested in a targeted WCAG audit. Those who still do not meet fundamental 2.1 requirements should address these first.

Criterion 2.5.7 Dragging Movements at Level AA requires that any function requiring drag-and-drop can also be performed via a single-pointer alternative. This means: every interaction requiring a dragging motion must also be achievable through simple tapping or clicking. This criterion is particularly relevant for users with motor impairments who cannot perform precise dragging movements.

In practice, this criterion affects numerous common UI patterns: sliders and range inputs operated by dragging, drag-and-drop sorting in lists and kanban boards, file uploads via drag-and-drop, carousels with swipe gestures and map applications with panning interaction. For each of these patterns, an alternative operating method must exist.

For sliders, a numeric input or plus/minus buttons serve as alternatives. Sortable lists can receive additional up/down buttons. File uploads need a classic file selection button alongside the drop area. Carousels need forward/backward controls. These alternatives improve not only accessibility but often also general usability, as not all users find drag interactions intuitive. Accessible web development considers these patterns from the start.

Criterion 2.5.8 Target Size (Minimum) at Level AA defines that interactive elements must be at least 24x24 CSS pixels in size. Alternatively, an element may be smaller if the distance to neighboring interactive elements is large enough to prevent accidental activation. This criterion particularly affects mobile interfaces, where small touch targets are a common problem.

In practice, many websites violate this criterion without knowing it. Icons in navigation bars measuring only 16x16 pixels, social media links at 20x20 pixels, tightly spaced checkbox groups and small close buttons in modals regularly fall below the minimum size. The AAA variant (criterion 2.5.5 from WCAG 2.1) even recommends 44x44 CSS pixels as target size.

Implementation is technically straightforward: CSS rules ensure all interactive elements meet the minimum size. For icons that should appear visually smaller, the clickable area can be enlarged via padding without changing the visual design. Verification can be automated, for example through tools that measure the bounding box of all interactive elements and check against the threshold.

Criterion 3.2.6 Consistent Help at Level A requires that help mechanisms repeated on multiple pages of a website appear at the same relative position on each of them. If a chat icon appears on several pages, it sits in the same place on every one of them. If the phone number appears in the header on several pages, it must be in the same place there each time. The criterion does not require help to be offered on every page.

This criterion addresses the needs of people with cognitive disabilities who rely on predictable layouts. Searching for and rediscovering help elements in different positions represents a significant cognitive burden for this user group. The solution is simple: help elements are implemented as part of the global layout, not as page-specific components.

Affected help mechanisms include live chat widgets, phone numbers and email addresses in the context area, FAQ links or help buttons, contact form links and self-service portals. All these elements should be anchored in a consistent header or footer structure that does not change across the entire website. Accessible web development implements this consistency as an architectural principle.

Implementation of WCAG 2.2 criteria should proceed systematically. As a first step, a comprehensive audit is recommended that checks the current state against all WCAG 2.2 AA criteria. Results are summarized in a prioritized action plan that addresses the most critical issues first.

For technical implementation, we recommend a component-based approach: each UI component is individually checked against the relevant criteria and adjusted as needed. Buttons and links are checked for Target Size. Forms are tested for Redundant Entry and Accessible Authentication. Navigation is validated for Consistent Help and Focus Not Obscured. This modular approach enables stepwise migration without interrupting ongoing operations.

Particularly important is integrating WCAG requirements into the development process. New features should be developed against WCAG 2.2 from the start. Code reviews should include accessibility as a fixed review criterion. Automated tests catch a portion of problems but do not replace manual testing by trained testers. Our training programs provide developers and designers with the necessary competencies for accessible development in daily practice.