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 marked as obsolete. The new criteria are distributed across three conformance levels: one at Level A, six at Level AA and two at Level AAA. Since the BFSG and the European Accessibility Act define Level AA as the minimum requirement, seven of the nine new criteria are directly compliance-relevant.

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.4.11 Focus Not Obscured (Minimum) at Level AA requires that the keyboard focus is not completely hidden by other page elements. In practice, this means: when a user navigates through the page using the Tab key and an element receives focus, that element must not disappear behind a sticky header, a cookie banner, a chat widget or another overlaying element.

This criterion addresses a common problem on modern websites. Sticky headers with a height of 60 to 80 pixels regularly obscure focused elements at the top of the page. Cookie banners at the bottom of the screen overlay footer links. Chat widgets in the lower right corner cover form fields. For keyboard users who cannot visually track the focus, these elements become invisible and thus unusable.

Technical implementation requires careful coordination of z-index values, scroll-padding rules and focus management. Sticky headers need appropriate scroll-padding-top on the HTML element so that focused elements scroll below the header. Cookie banners should be minimized after interaction and not permanently block the lower area. The stricter AAA variant (2.4.12) requires the focused element to be fully visible, not just partially.

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 3.3.7 Redundant Entry at Level A is one of the most practically relevant new criteria. It requires that information the user has already entered in a process is not requested again, unless re-entry is essential to the function. The classic example: when a user enters their billing address in checkout, the shipping address field should be able to automatically adopt this data.

This criterion primarily targets people with cognitive disabilities for whom repeated data entry represents a significant burden. But the principle also makes sense for all other users: fewer inputs mean fewer errors, faster processes and higher conversion rates. According to Baymard Institute (2024), 12% (project experience) of all checkout abandonments are due to forms that are too long or complicated.

Implementation requires a well-thought-out form architecture. Multi-step forms must enable data carry-over between steps. Checkout processes need an option to adopt the billing address as the shipping address. Registration forms should carry over data from the ordering process. Autocomplete attributes per the HTML standard facilitate automatic population by the browser. All these measures are part of accessible shop development.

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.3.8 Accessible Authentication (Minimum) at Level AA requires that authentication processes do not require cognitive function tests unless an alternative is available. Specifically: if a login process contains a CAPTCHA requiring letter recognition, image matching or math problems, an alternative method must be offered.

Acceptable alternatives include password manager support through correct autocomplete attributes, copy-and-paste capability for verification codes, biometric authentication such as fingerprint or facial recognition, and object-based CAPTCHAs that do not require cognitive effort. The goal is that people with cognitive disabilities are not locked out by the authentication process.

For e-commerce websites, this criterion has direct implications for login, registration and checkout processes. Contact forms with CAPTCHAs need alternative spam protection mechanisms such as honeypot fields or server-side time checks. Implementing accessible authentication simultaneously improves conversion rates, as CAPTCHAs are a known abandonment factor.

Criterion 3.2.6 Consistent Help at Level A requires that help mechanisms appear at the same relative position across all pages of a website. If a chat icon appears in the lower right corner on the homepage, it must be there on all other pages too. If the phone number appears in the header, it must be found in the header 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.

Criterion 2.4.13 Focus Appearance at Level AAA defines strict requirements for the visibility of focus indicators. The focus ring must have a minimum contrast of 3:1 against the surrounding background and a minimum area of two CSS pixels outline thickness. Although this criterion is at AAA level and thus not directly BFSG-mandated, we recommend implementation as visible focus indicators are fundamental for keyboard navigation.

Many websites use outline: none in their CSS, removing the browser's default focus indicator. This looks visually cleaner but makes the site unusable for keyboard users. The better solution: implement a custom focus indicator matching the design with sufficient contrast. The CSS property :focus-visible enables showing the focus ring only during keyboard navigation, not on mouse clicks.

A well-designed focus indicator uses a combination of outline and offset to ensure the ring is not obscured by the element itself. Color-wise, it should clearly stand out from the background. On dark backgrounds, a light focus ring is recommended; on light backgrounds, a dark one. A consistent focus strategy across the entire website strengthens predictability and improves the user experience for all keyboard users.

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 2.2 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.