WCAG 2.2: The New Success Criteria in Detail

1. Why WCAG 2.2 arrived and how it relates to 2.1

WCAG 2.2 does not replace WCAG 2.1, it is an additive extension: every success criterion from 2.1 remains valid unchanged, WCAG 2.2 only adds new ones and drops a single existing criterion, 4.1.1 Parsing, because it had practically no remaining test relevance given modern browsers and robust HTML parsers. A store already conformant with 2.1 AA loses nothing by moving to 2.2, it simply gains nine additional criteria that largely grew out of practical experience with mobile use, authentication, and focus visibility.

The W3C deliberately chose the new criteria to close gaps that turned out to be especially consequential in the years since WCAG 2.1: tiny touch targets on mobile devices, drag and drop interactions with no keyboard alternative, security prompts that overload cognitive capacity, and focus indicators hidden behind cookie banners or sticky headers. Anyone who recognizes these patterns in their own store should treat WCAG 2.2 not as a bureaucratic footnote but as a direct response to observed barriers.

2. Focus Not Obscured: visible focus despite sticky elements

Criteria 2.4.11 Focus Not Obscured (Minimum) at level AA and 2.4.12 Focus Not Obscured (Enhanced) at level AAA require that a focused element during keyboard navigation is not entirely, or in the enhanced case not at all, hidden by other content. In practice this hits exactly the patterns that are everywhere in modern storefronts: a sticky header, a cookie consent banner pinned to the bottom of the screen, or a fixed cart icon that covers the focused button while tabbing through a long form.

For Hyvä themes built with Alpine.js, this means sticky positioned elements need sufficient scroll-margin or scroll-padding-top on the focusable target element, so the browser automatically scrolls far enough when focusing via keyboard that the element does not disappear beneath the sticky header. To test whether a store meets this criterion, simply tab consistently through a long page with a sticky header and check whether the blue focus ring stays at least partly visible at every step.

/* Prevents a sticky header from hiding the focus ring (WCAG 2.4.11) */
:root {
  --sticky-header-height: 4rem;
}

[tabindex], a, button, input, select, textarea {
  scroll-margin-top: calc(var(--sticky-header-height) + 0.5rem);
}

3. Dragging Movements: alternatives to drag and drop

Criterion 2.5.7 Dragging Movements at level AA requires that any function triggered by a dragging motion is also operable without dragging, unless dragging is essential to the function, for example drawing in graphics software. For online stores this mostly concerns swipe carousels for product images, quantity sliders for order amounts, or draggable range filters in category navigation, whenever they can only be operated through pointer drag.

The practical fix usually involves offering an equally functional click or keyboard alternative alongside the drag gesture: arrow buttons next to an image carousel, a text input field next to a quantity slider, or clickable individual steps on a range instead of a pure drag handle. It matters that this alternative be equally accessible, a tiny, barely visible arrow button tucked into the corner of a carousel formally satisfies the criterion but not its intent.

4. Target Size Minimum: minimum size for interactive controls

Criterion 2.5.8 Target Size (Minimum) at level AA requires clickable or tappable targets to be at least 24 by 24 CSS pixels, unless they are compensated by sufficient spacing to neighboring targets, are part of a sentence in running text, or an equally accessible, larger alternative exists elsewhere. This regularly catches small icon buttons in existing Magento themes, such as the wishlist heart icon, a modal close cross, or pagination arrows, which often sit well under 24 pixels.

In Tailwind based Hyvä themes, the criterion can usually be resolved by consistently enforcing a minimum size on interactive icon elements without fundamentally changing the visual design: the clickable area can be larger than the visible icon itself by using padding instead of forcibly enlarging the icon. This pattern preserves the compact visual impression while enlarging the actual hit area for mouse, touch, and assistive input devices alike.

<!-- Visible icon stays small, clickable area reaches 24x24px via padding -->
<button
  type="button"
  class="p-2.5 -m-2.5 inline-flex items-center justify-center rounded-full hover:bg-slate-100"
  aria-label="Add to wishlist"
>
  <svg class="w-4 h-4" aria-hidden="true"><!-- heart icon --></svg>
</button>

5. Consistent Help: help mechanisms at a consistent position

Criterion 3.2.6 Consistent Help at level A requires that help mechanisms such as a live chat, a contact phone number, or a link to frequently asked questions appear at a relatively consistent position within the page's sequence on every page where they occur. The criterion does not forbid the visual layout differing slightly between page types, but it does require that users who have learned where to find help find that same pattern on other pages.

For Magento stores, this frequently hits exactly the place where help is needed most urgently: checkout. If the live chat button appears bottom right on category pages but is suddenly missing or repositioned during checkout, that violates criterion 3.2.6 even if the chat itself functions perfectly well. The fix is usually organizational rather than technical: a single, globally anchored help element wired consistently into all relevant pages, including checkout, through layout XML.

6. Accessible Authentication: login without cognitive puzzles

Criteria 3.3.8 Accessible Authentication (Minimum) at level AA and 3.3.9 Accessible Authentication (Enhanced) at level AAA require that an authentication process does not rely on a cognitive function test, such as remembering a password, solving a puzzle captcha, or correctly rearranging characters, unless an alternative method exists that does not require this test, or a support mechanism such as copy and paste or a password manager is not blocked.

The most common violation in existing Magento checkouts is a login or registration form that blocks copy and paste in password fields via JavaScript, supposedly for security reasons, but in practice mainly obstructing password manager users and people with cognitive impairments without delivering any meaningful security benefit. Equally problematic are image captchas with no accessible alternative such as an audio captcha or an invisible, behavior based verification method.

7. Redundant Entry and further new criteria

Criterion 3.3.7 Redundant Entry at level A requires that information a user has already entered previously in the same process does not need to be manually re-entered, unless it is essential to the function, for example re-entering a password for confirmation on security grounds. For a multi step Magento checkout, this specifically means that when the billing and shipping addresses are identical, a checkbox must be able to replace re-typing the second address instead of forcing both forms to be filled independently.

The list is rounded out by 2.4.13 Focus Appearance at level AAA, which sets precise minimum requirements for the contrast and size of the focus indicator itself, going beyond the plain visibility required by 2.4.11. Even though AAA criteria are rarely mandated, it is worth a look, because a strong, clearly visible focus ring is already one of the simplest and most effective measures for keyboard users and usually takes just a few lines of CSS to implement.

8. Practical impact on existing Magento checkouts

Taken together, the new criteria hit the checkout process disproportionately hard, because small icon buttons, live chat widgets, login forms, and multi step address entry all converge there. A typical WCAG 2.2 review of an existing store therefore regularly finds Target Size violations on quantity steppers and remove icons in the cart, Accessible Authentication violations from blocked copy and paste in password fields, and Redundant Entry violations when guest checkout and registration are implemented separately and address data has to be entered twice.

Put positively: fixing these four or five concrete patterns already covers most of the practical impact of WCAG 2.2 on a typical Magento store, without requiring a full frontend overhaul. The remaining criteria, such as Consistent Help and Dragging Movements, usually concern individual, clearly scoped components like the help link in the footer or an image carousel on the product detail page.

9. Migration checklist for existing WCAG 2.1 stores

For a structured transition, it helps to work through a checklist covering exactly the nine new criteria one by one, rather than running a full new audit against every criterion, since the 2.1 baseline is already verified. Step one is tabbing consistently through every form, including checkout, to find Focus Not Obscured violations caused by sticky elements. Step two is a visual scan of every icon button using a browser overlay tool that highlights click areas under 24 pixels.

Step three checks login and registration forms for blocked copy and paste as well as captcha alternatives, step four checks the checkout flow for duplicate address entry, and step five looks for drag only interactions in image galleries and sliders. Finally, it is worth comparing the category page, product detail page, and checkout side by side to verify that help elements such as chat or an FAQ link actually appear at a consistent position, as Consistent Help requires.

10. Summary

11. FAQ: WCAG 2.2: Key Facts at a Glance