WCAG 2.2: 9 New Criteria Engineering Teams Must Test

WCAG 2.2 is the current W3C Recommendation that extends WCAG 2.0 and 2.1 with nine new success criteria covering focus visibility, dragging, target size, and authentication. For teams, that means updating test scripts, component libraries, and CI checks to cover the new rules, while retiring older checklist items like 4.1.1 Parsing that no longer apply.

TL;DR:

• WCAG 2.2 adds nine criteria and removes 4.1.1 Parsing, so teams should retire that obsolete violation from their audit checklists.
• Interactive targets must measure at least 24 by 24 CSS pixels, except where WCAG 2.2 permits smaller targets, such as sufficiently spaced controls.
• Focus indicators need at least a 3:1 contrast ratio against adjacent colors, and keyboard testing can reveal when fixed content hides them.
• A login cannot rely only on a cognitive test unless an alternative exists; enhanced AAA also bars object recognition as the sole authentication option.
• Automated scanners catch around a third of page issues, so test critical flows manually with a keyboard and screen reader; block new violations in CI.

Table of Contents

• What changed in WCAG 2.2
• WCAG's four principles and conformance levels
• How to test each new success criterion
• Build a testing strategy that mixes automation and humans
• Design patterns that prevent regressions
• Make accessibility part of the development lifecycle
• Why accessibility can't be a one-time fix
• How we help teams put WCAG 2.2 into practice
• FAQ
• Sources

What changed in WCAG 2.2

WCAG 2.2 did not rewrite the guidelines; it added to them. The update introduces nine new or changed success criteria, each mapped to one of the four existing guidelines, and it removes one criterion that had become more trouble than it was worth.

The new criteria address three groups of people who were underserved by WCAG 2.1: keyboard users whose focus indicator gets hidden by sticky headers or modals, people with limited fine motor control who struggle with drag gestures or small tap targets, and people with cognitive disabilities who get tripped up by inconsistent help links or forms that make them retype information.

• 2.4.11 Focus Not Obscured (Minimum): a focused element must not be entirely hidden by other content like sticky banners or cookie notices.
• 2.4.12 Focus Not Obscured (Enhanced): a stricter AAA version requiring no part of the focus indicator to be hidden.
• 2.4.13 Focus Appearance: the focus indicator must meet minimum size and contrast thresholds so it is actually visible.
• 2.5.7 Dragging Movements: any function performed by dragging must also be available through a simple pointer action, like a tap or click.
• 2.5.8 Target Size (Minimum): interactive targets need at least 24 by 24 CSS pixels, unless an exception applies.
• 3.2.6 Consistent Help: if a help mechanism (chat, contact link, FAQ) appears on multiple pages, it must stay in the same relative order.
• 3.3.7 Redundant Entry: information already supplied in a process must not be requested again from the same user, unless it's essential.
• 3.3.8 Accessible Authentication (Minimum): login cannot rely solely on a cognitive function test, such as memorizing a password, unless an alternative exists.
• 3.3.9 Accessible Authentication (Enhanced): a stricter AAA version that also rules out object recognition as the only alternative.

Alongside these additions, 4.1.1 Parsing was made obsolete and removed. That criterion used to require valid HTML markup, but modern browsers parse malformed markup consistently enough that the rule stopped catching real accessibility failures. If your audit checklist still flags parsing errors as a WCAG violation, it's testing against a criterion that no longer exists in the current recommendation.

WCAG's four principles and conformance levels

Every WCAG success criterion, old or new, sits under one of four principles: Perceivable, Operable, Understandable, and Robust, often shortened to POUR. Perceivable covers whether content can be seen or heard in some form (alt text, captions, contrast). Operable covers whether people can navigate and interact using a keyboard, switch device, or screen reader. Understandable covers whether content and interface behavior are predictable and comprehensible. Robust covers whether content works reliably across browsers and assistive technologies.

Conformance comes in three levels, and they're cumulative:

• Level A: the baseline; missing these criteria creates serious barriers for some users.
• Level AA: a conformance level that includes every Level A criterion plus the AA set.
• Level AAA: the strictest level, rarely required site-wide because some AAA criteria conflict with certain types of content.

When you reference WCAG 2.2 in a policy, contract, or RFP, cite the specific version and level, for example "WCAG 2.2 Level AA," rather than a vague phrase like "WCAG compliant." Because 2.2 was built for backward compatibility, content that conforms to 2.2 automatically satisfies 2.0 and 2.1, which makes it the safer citation for new contracts and policy updates going forward.

How to test each new success criterion

Each new criterion needs its own test approach. Automated scanners catch some of these reliably; others need a human with a keyboard and a mouse.

Focus Not Obscured (2.4.11 and 2.4.12). The failure pattern is familiar: a user tabs to a form field, and a sticky header or cookie banner sits on top of it, hiding the focused element entirely. To test, tab through every interactive element on a page while watching for anything that disappears behind fixed-position content. Automated tools can flag elements with position: fixed or position: sticky that overlap the tab order, but confirming an actual obscured state usually takes a manual pass. The fix is often a scroll-margin-top or scroll-padding-top value matched to the height of your sticky header, so the browser scrolls focused elements clear of it.

Focus Appearance (2.4.13). This one asks for a focus indicator with enough size and contrast to actually be seen, not just technically present. Many teams rely on the browser default outline, then strip it with outline: none for cosmetic reasons and never replace it, which is the single most common focus-related failure. Use :focus-visible instead of :focus so the indicator shows for keyboard users without appearing on every mouse click, and make sure the indicator has at least a 3:1 contrast ratio against adjacent colors.

Dragging Movements (2.5.7). Think of a slider, a reorderable list, or a map that only responds to click-and-drag. Anyone using a switch device, voice control, or a tremor-affected pointer can't perform that gesture reliably. The test is simple: try to complete the same action without dragging. Can you click the slider track to jump to a value? Is there an "up" and "down" button next to the reorderable item? If not, add one.

Target Size (2.5.8). Measure your smallest clickable icons and buttons. Targets should be large enough to use comfortably, with exceptions for some inline targets, targets spaced sufficiently from neighbors, or targets whose small size is essential to the function. Browser dev tools can measure this directly, and a quick visual check against a 24px grid overlay catches most offenders fast, especially icon-only buttons in toolbars and mobile navigation bars.

Consistent Help (3.2.6). If your site has a "Contact Support" link, chat widget, or help page linked from multiple screens, its position in the navigation or footer needs to stay consistent across pages. This is a straightforward manual check: visit a sample of pages and compare where the help mechanism appears relative to other repeated elements.

Redundant Entry (3.3.7). Multi-step checkouts and applications are the usual offenders, asking for a shipping address on step two and then the same address again on step four. Fixes include auto-populating fields from earlier steps, offering a "same as above" checkbox, or presenting previously entered data as a selectable option rather than a blank field to retype.

Accessible Authentication (3.3.8 and 3.3.9). A login that only works if the user remembers a password, solves a text-distorted CAPTCHA, or transcribes a code from an image fails this criterion unless another path exists. Acceptable alternatives include password managers (don't block paste on password fields), email magic links, or biometric login. The enhanced AAA version also excludes object recognition puzzles as the sole alternative.

Pro Tip: Run a full keyboard-only pass on your three highest-traffic pages before touching a scanner; it surfaces focus and dragging issues that automated tools routinely miss.

Automated accessibility scanners typically catch around a third of WCAG issues on a page, which is why manual testing stays part of any serious audit process.

A WCAG 2.2 developer checklist can help teams turn these criteria into concrete sprint tickets rather than abstract compliance language.

Build a testing strategy that mixes automation and humans

Automated scanners are fast and consistent, but they only catch a portion of real accessibility problems. A tool can tell you an image has no alt attribute; it can't tell you whether the alt text is meaningful, whether a drag interaction has a keyboard equivalent, or whether a focus indicator is visually distinguishable from its background in every theme.

Build a toolchain that layers automation, manual review, and assistive technology testing:

1. Run axe-core or Pa11y in CI against every pull request that touches markup or styles.
2. Run Lighthouse accessibility audits as part of your performance budget checks, since both tend to live in the same CI stage.
3. Spot-check flagged pages with WAVE in the browser to visualize issues in context rather than reading a raw report.
4. Test critical flows (checkout, account creation, forms) manually with a keyboard only, no mouse.
5. Test the same flows with a screen reader matrix: NVDA on Windows with Chrome or Firefox, VoiceOver on macOS and iOS, and TalkBack on Android.
6. Track violations per page, severity level, and time-to-fix as ongoing metrics, not one-off audit scores.

For CI integration, treat new accessibility violations in changed files as a blocking check on the pull request, while existing violations in untouched code feed a prioritized backlog instead of blocking unrelated work. Start remediation with your highest-traffic pages and the flows that generate revenue or support requests, since that's where fixes reach the most people fastest and where failures cost the most in abandoned transactions and support tickets.

Design patterns that prevent regressions

Fixing a violation once and fixing it everywhere are different problems. The second one needs a design system that bakes accessibility into shared components instead of leaving each team to rebuild focus handling, form validation, and target sizing from scratch.

• Build buttons, form fields, modals, and navigation components in a central library, and test each one with axe-storybook-testing so violations surface before the component ships anywhere.
• Document the expected ARIA role, keyboard behavior, and focus management for every interactive component directly in its spec, not in a separate wiki page nobody opens.
• Give every focusable element a :focus-visible style with adequate size and contrast, defined once at the design-token level so it's consistent across the whole product.
• Build form fields that accept autofill and pre-populate known values across multi-step flows, satisfying Redundant Entry by default rather than per-form.
• Offer at least one non-biometric, non-puzzle authentication path (password manager support, magic link) in the shared login component.
• Set a default tap target size large enough for people to use comfortably for every icon button and control in the component library, not just the ones someone remembers to check.

Common integration mistakes tend to repeat across teams: overriding the browser's default focus outline without supplying a replacement, using overflow: hidden or z-index in a way that visually buries a focused element, and relying on color alone to indicate an error or active state. A UI/UX audit checklist is a fast way to catch these patterns during design review, before they reach a component library and multiply across every screen that uses it.

Pro Tip: Add an automated check in your design tokens pipeline that fails the build if a focus style's contrast ratio drops below 3:1 against its background.

Make accessibility part of the development lifecycle

Accessibility that only shows up during a pre-launch audit tends to stay expensive and reactive. Integrating accessibility checks into design and development from the start costs less and catches more than retrofitting it after a feature ships, because fixes get made while the context and the original developer are still available.

A few structural changes make that shift realistic:

• Add an accessibility checklist to design review and story acceptance criteria, so a ticket isn't "done" until keyboard and screen reader behavior have been considered.
• Name accessibility champions on each product team who review pull requests for new violations and keep the rest of the team current on WCAG 2.2 changes.
• Add eslint-plugin-jsx-a11y to your linting pipeline to catch common markup issues, like missing labels or invalid ARIA attributes, before code review even starts.
• Set a CI threshold that blocks merges introducing new critical or serious violations, while routing existing issues into a tracked backlog with owners and target dates.
• Schedule a recurring re-scan, since content and components drift out of compliance even when nobody intended to break anything. Pairing this with your performance budget checks in CI keeps both concerns visible in the same pipeline instead of competing for separate attention.

Why accessibility can't be a one-time fix

The biggest misconception about WCAG 2.2 is that it's a checklist you complete once and then forget. Treating it that way guarantees you'll be back to square one within a year, because each new feature, redesigned component, or third-party widget added to a page is a fresh opportunity to break something that used to work.

What gets underestimated is how much of the failure in practice isn't a knowledge gap, it's a process gap. Teams know what alt text is; they don't have a step in their pull request template that asks for it. Teams know focus indicators matter; nobody owns catching a regression when a new CSS framework quietly resets outline styles. The new criteria in WCAG 2.2 are specific and testable, which is exactly why they expose weak processes faster than vaguer principles did.

The conventional wisdom treats compliance as a legal risk to manage. The more useful framing treats it as a product quality signal: a site with clean keyboard navigation, visible focus states, and forms that don't make you retype your address is a better product for everyone, not just the subset of users who rely on assistive technology to get through it.

— YS

How we help teams put WCAG 2.2 into practice

Meeting WCAG 2.2 consistently takes more than a one-time scan; it takes component-level design decisions, development discipline, and a process that catches regressions before they reach production. We work across all three layers: UX/UI design for accessible component patterns, website development for implementation and remediation, and IT consulting for embedding accessibility checks into your CI pipeline and governance process.

Our typical engagement starts with an audit of your highest-traffic flows, moves into a prioritized remediation plan, and continues through implementation sprints that fix issues directly in your components rather than page by page.

• Accessibility audit covering automated scans, manual keyboard testing, and screen reader checks on priority flows.
• A prioritized remediation plan ranked by user impact and effort.
• Implementation sprints that fix issues at the component level so the same bug doesn't reappear elsewhere.
• CI automation and linting setup so new violations get caught before merge, not after launch.

If your team is weighing where to start, review our portfolio of past projects or reach out through our website development services page to scope an audit for your highest-priority pages.

FAQ

What Are WCAG 2.2 Standards?

WCAG 2.2 standards are a set of success criteria published by the W3C that define how to make web content accessible to people with disabilities. They build on WCAG 2.0 and 2.1 and add nine new criteria covering focus visibility, dragging, target size, and authentication.

Is WCAG 2.2 Mandatory?

Whether WCAG 2.2 is legally required depends on your jurisdiction and sector; many laws and procurement standards reference WCAG at the AA level, but the specific version required varies by country and regulation. Check the primary accessibility law or standard that applies to your organization, or consult legal counsel, rather than assuming one global rule applies.

What Does WCAG Stand For?

WCAG stands for Web Content Accessibility Guidelines, the technical standard published by the W3C for making websites and apps usable by people with disabilities. It covers visual, auditory, motor, and cognitive accessibility needs across four principles: perceivable, operable, understandable, and robust.

Is WCAG 2.2 Finalized?

Yes, WCAG 2.2 is a finalized W3C Recommendation, meaning it has completed the W3C's standards process and represents the current official version of the guidelines. It was built for backward compatibility, so content conforming to WCAG 2.2 also satisfies WCAG 2.0 and 2.1.

How Do I Start Testing for WCAG 2.2 Compliance?

Start by running an automated scanner like axe-core or Lighthouse across your highest-traffic pages, then follow up with manual keyboard navigation and screen reader testing on critical flows like checkout or sign-up. A WCAG 2 AA checklist can help map each success criterion to a concrete test step.

Sources

• Web Content Accessibility Guidelines (WCAG) 2.2
• Web Content Accessibility Guidelines (WCAG) 2.2
• Usability

Recommended

• 10 UI/UX Design Tips for 2026 That Actually Move Metrics
• Cut Rework in Sprints: 9 Item Design to Development Handoff Checklist