Loading…
Loading…
Additional success criteria in WCAG 2.2 addressing focus, dragging, and consistent help.
stellae.design
WCAG 2.2, published as a W3C Recommendation in October 2023, adds 9 new success criteria to WCAG 2.1, addressing gaps in cognitive accessibility, mobile usability, and user assistance. Notable additions include SC 2.4.11 Focus Not Obscured (Minimum, AA) — ensuring focused elements aren't hidden behind sticky headers; SC 2.5.7 Dragging Movements (AA) — requiring single-pointer alternatives to drag; SC 2.5.8 Target Size (Minimum, AA) — setting 24×24px as the minimum target size; SC 3.3.7 Redundant Entry (A) — preventing users from re-entering previously provided data; and SC 3.3.8 Accessible Authentication (Minimum, AA) — prohibiting cognitive function tests for login. One criterion (4.1.1 Parsing) was removed as obsolete.
WCAG 2.2, published as a W3C Recommendation in October 2023, introduces nine new success criteria that address accessibility gaps left by previous versions — particularly for users with cognitive and learning disabilities, users with low vision, and users who rely on alternative input methods like switches, voice control, or eye tracking. These new criteria reflect the accessibility community's growing recognition that earlier WCAG versions focused heavily on screen reader and keyboard access while underserving the much larger population of users with cognitive, motor, and visual impairments that fall outside the traditional assistive technology model. Organizations that proactively adopt WCAG 2.2 gain both legal protection as regulatory frameworks update to reference the latest standard and a genuine competitive advantage, because the new criteria target usability problems — like tiny touch targets, redundant authentication steps, and dragging-dependent interactions — that frustrate all users, not just those with disabilities.
An online retailer replaces its login flow that required users to type a remembered password and solve a visual CAPTCHA with a modernized system supporting passkeys, biometric authentication on mobile devices, email magic links, and a traditional password option backed by browser autofill support — eliminating the cognitive function test requirement while actually improving security. The CAPTCHA is replaced with invisible bot detection that does not require user interaction, satisfying the accessible authentication criterion without introducing new friction. Conversion rate on the login page increases because the barriers that excluded users with cognitive disabilities were also frustrating the broader user base.
A multi-step government benefits application auto-populates the applicant's name, address, and date of birth across all form steps after initial entry, and provides a persistent help link in the same header position on every page that connects to both a phone support line and a live chat — satisfying both the 3.3.7 Redundant Entry and 3.2.6 Consistent Help criteria simultaneously. The form also stores progress server-side so users can return to their application without re-entering completed steps, which particularly benefits users with cognitive disabilities who may need to complete the form across multiple sessions. These improvements reduce form abandonment across all user demographics, demonstrating that WCAG 2.2 criteria target genuine usability problems rather than edge-case compliance requirements.
A task management app implements its entire workflow around drag-and-drop — users must drag cards between columns to change status, drag to reorder priorities, and drag items to the trash to delete them — with no tap, long-press, or menu-based alternatives for any of these actions, failing the 2.5.7 Dragging Movements criterion and rendering the app unusable for anyone using switch access, voice control, or mouth-stick input. When the team attempts to add alternatives retroactively, they discover that the entire state management architecture was built around drag events, requiring a significant rewrite rather than the simple addition of alternative interaction handlers. This illustrates why WCAG 2.2 criteria should inform initial design and architecture decisions rather than being treated as a compliance checklist applied after development is complete.
• The most common mistake is treating WCAG 2.2 as an incremental update that only requires checking the nine new criteria, when in practice the new criteria often reveal systemic issues — a target size audit frequently uncovers hundreds of undersized elements that require design system changes rather than individual fixes. Teams also frequently misinterpret the target size criterion as requiring all targets to be 24x24 pixels, missing the spacing exception that allows smaller targets if they have sufficient surrounding inactive space; this misunderstanding leads to unnecessary design compromises when proper spacing would have achieved compliance with less visual disruption. Another pervasive error is implementing accessible authentication alternatives as secondary options hidden behind a "more options" link rather than as primary, equally prominent login methods, which technically satisfies the criterion's letter but defeats its purpose of making authentication genuinely accessible without requiring users to seek out the accessible pathway.
Was this article helpful?