WCAG 2.2 has been the W3C recommendation since October 2023. EN 301 549 v3.2.1 remains the harmonised ICT accessibility standard referenced for current EU web accessibility alignment, while the next EN 301 549 revision is expected to bring WCAG 2.2 support for European Accessibility Act work. Teams that built their accessibility practice against WCAG 2.1 have work to do: four new Level AA success criteria in WCAG 2.2 and the removal of one criterion that was often misapplied.
WCAG 2.2 adds nine new success criteria across Levels A, AA, and AAA, and removes SC 4.1.1 Parsing, which was made obsolete by modern browser handling of HTML errors. For teams working to Level AA, the new criteria to implement are Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum), and Accessible Authentication (Minimum). Focus Appearance is important design-system work, but it is a Level AAA criterion in WCAG 2.2, not a Level AA requirement.
SC_2_4_11_FOCUS_NOT_OBSCURED_MINIMUM
This criterion requires that when a component receives keyboard focus, the component is not entirely hidden by author-created content. The failure case is a sticky header, cookie banner, or chat widget that sits on top of focused elements and obscures the focus indicator. The criterion is at minimum level — the focused component should not be entirely hidden, though it may be partially obscured. SC 2.4.12 Focus Not Obscured (Enhanced, AAA) requires that the focused component is not obscured at all.
The implementation fix for most products is ensuring that the scroll margin or scroll padding values on focusable elements account for the height of any sticky positioned content. CSS scroll-margin-top can compensate for a sticky header. For cookie banners and chat widgets that appear unpredictably, the fix requires either ensuring the focusable elements in the banner are in the DOM order before the affected page content, or using z-index management that keeps focused page elements visible above the overlay content.
- Identify all sticky-positioned and fixed-positioned elements in your layout that could obscure focused page content.
- Navigate every page with keyboard-only and verify that no focused element is entirely hidden by a sticky header, footer, banner, or overlay.
- Apply
scroll-margin-topvalues matching your sticky header heights to interactive elements that appear in scrollable containers. - Test with the cookie consent banner visible, since that is the common failure case on first page load.
SC_3_3_8_ACCESSIBLE_AUTHENTICATION_MINIMUM
This criterion requires that authentication flows do not depend on a cognitive function test unless the site also provides an accessible alternative, a mechanism that helps the user complete the step, or an object-recognition or personal-content exception applies. The common failure case is a login or account recovery flow that requires memorising and transcribing a one-time code, solving a puzzle, or retyping a password without allowing password managers or copy-paste.
In practice, the fix is usually operational rather than decorative: support password managers, allow paste into verification fields, avoid blocking copy from a password manager, provide magic-link or passkey options where appropriate, and make CAPTCHA alternatives genuinely usable. Authentication is often owned by a platform team, but the failure appears in product journeys such as checkout, account recovery, support access, and subscription management.
Focus Appearance remains worth implementing as a design-system quality bar even though it is Level AAA. Strong focus indicators reduce errors for keyboard users and make the Level AA Focus Not Obscured requirement easier to test, but the checklist should not label it as one of the four new Level AA criteria.
- Audit login, account recovery, checkout, and administrative sign-in flows for memory, transcription, puzzle, and re-entry requirements.
- Allow password managers, passkeys, and paste into verification fields unless there is a specific, documented security reason not to.
- Provide an accessible alternative for CAPTCHA or challenge flows, and test that the alternative is available before the user is blocked.
- Include authentication flows in release QA, not just component-level accessibility testing. Authentication failures often sit outside the main design system.
SC_2_5_7_DRAGGING_MOVEMENTS
This criterion requires that any functionality using dragging can be achieved with a single pointer without a dragging movement, unless dragging is essential or the dragging motion is determined by the user agent and not modified by the author. The practically significant cases are drag-and-drop sorting in lists and tables, resizable panels split by drag handles, and slider controls where dragging is the primary input method.
The requirement is not to remove dragging — it is to provide an alternative that does not require path-based gesture. For a drag-sortable list, the alternative is typically a move button or a keyboard shortcut that repositions items. For a resizable panel, the alternative is a numeric input field or increment/decrement buttons that adjust the split position. For a range slider, the alternative is already provided by the native <input type="range"> element's keyboard handling — products that replace this with custom slider components need to implement equivalent keyboard interaction.
- Inventory all drag interactions in your product: list sorting, panel resizing, canvas interactions, map panning, slider controls.
- For each drag interaction, document the single-pointer alternative and verify it is implemented and discoverable.
- Test alternative interactions with keyboard-only and with a switch access device simulation. The alternative should not require more steps than the drag interaction it replaces.
- For new component development, design the non-drag alternative at the same time as the drag interaction, not as an afterthought once the drag implementation is complete.
SC_2_5_8_TARGET_SIZE_MINIMUM
This criterion requires interactive targets to be at least 24 by 24 CSS pixels, with exceptions for inline text links (where changing the size would reflow text), targets where sufficient spacing exists around them (spacing to adjacent targets of at least the difference between the 24px minimum and the actual target size), and targets that are determined by the user agent and not resized by the author.
The spacing exception makes this criterion considerably more practical than a strict minimum size requirement. A 16x16 icon button can meet the criterion if it has at least 4px of clear space on each side with no other interactive target within that space. This means redesigning every small icon button is not necessarily required — adjusting spacing and ensuring no other targets are adjacent may be sufficient. The important thing is to verify, not assume.
The failure cases that cannot be resolved with spacing are icon buttons in dense UI contexts where multiple small targets are adjacent to each other — icon toolbars, table row actions, and tag cloud components. In those cases, the targets need to be enlarged, combined into a menu, or the layout redesigned to provide the required spacing. The choice between these options is a product decision, but the choice needs to be made consciously, not deferred until a complaint investigation forces it.
- Identify all icon-only buttons and controls under 24px in your product and measure their actual rendered size in the browser, not the design source size.
- For targets below 24x24 CSS pixels, assess whether the spacing exception applies: measure the distance to adjacent interactive targets and calculate whether the gap meets the spacing requirement.
- Prioritize target size fixes in high-frequency flows: navigation, checkout, form submission, account management. These are the flows most likely to appear in complaint investigations.
- Add target size to your design system acceptance criteria so new components are assessed before they enter production.
EMBEDDING_WCAG_2_2_IN_DELIVERY
Treating WCAG 2.2 compliance as an audit outcome rather than a delivery input produces a cycle of remediation that never closes. Audits find issues, issues are fixed, new features introduce new issues, the audit finds them at the next cycle. The cycle breaks when accessibility criteria become release conditions: a component cannot be promoted to the design system without documented accessibility testing, a feature cannot be merged without keyboard navigation testing, a page cannot be released without automated scan results reviewed and addressed.
The enforcement pressure from the EAA makes the business case for embedding accessibility clearer than it was under the previous voluntary compliance environment. Evidence that accessibility was built into the delivery process is what matters in enforcement proceedings — not an accessibility statement asserting conformance, but testing records that demonstrate the process was operating before the complaint was filed. The process creates the evidence as a side effect, at no additional documentation cost, provided the testing happens at the right point in the delivery cycle.
The minimum embedding that produces defensible evidence is: automated accessibility testing in CI (axe-core or equivalent) with failures blocking merge; keyboard navigation testing as a defined step in QA for every new and modified component; screen reader testing for interactive components on the highest-traffic user journeys; and a visible accessibility testing summary in each release or sprint review. That is achievable without specialist staffing for teams that have already built baseline accessibility competence in the engineering team.