What’s New in WCAG 2.2: Changes and Testing Tips

WCAG 2.2 adds nine success criteria to WCAG 2.1 and removes one: 4.1.1 Parsing. It is an extension, not a wholesale rewrite. The additions address keyboard focus visibility, pointer interactions and target size, consistent help, repeated form entry, and authentication. They have different conformance levels: A, AA, and AAA. A useful review combines automated checks where they apply with human evaluation of real tasks and states. W3C’s WCAG 2.2 overview records the nine additions and the Recommendation’s publication date, 5 October 2023.

This is standards guidance, not legal advice. The policy or obligation applicable to your organization may refer to a particular WCAG version. Confirm the version and conformance level that apply to your work, and use the normative WCAG 2.2 Recommendation for exact requirements and exceptions.

What changed from WCAG 2.1

WCAG 2.2 carries forward the WCAG 2.0 and 2.1 success criteria, with one exception: 4.1.1 Parsing is obsolete and removed in 2.2. It adds nine criteria intended to address barriers that include obscured keyboard focus, small pointer targets, dragging-only controls, inconsistent access to help, unnecessary re-entry, and cognitive tests during authentication. The new criteria were appended within their guidelines to preserve compatibility for implementers who rely on the earlier organization.

Success criterion	Level	What to review
2.4.11 Focus Not Obscured (Minimum)	AA	When an item receives keyboard focus, at least part of it remains visible.
2.4.12 Focus Not Obscured (Enhanced)	AAA	When an item receives keyboard focus, it is fully visible.
2.4.13 Focus Appearance	AAA	Check the visible focus indicator against the criterion’s area and contrast requirements and exceptions.
2.5.7 Dragging Movements	AA	Functionality operated by dragging also has a single-pointer way to operate it without dragging, unless an exception applies.
2.5.8 Target Size (Minimum)	AA	Pointer targets generally meet the 24 by 24 CSS-pixel baseline, subject to specified exceptions.
3.2.6 Consistent Help	A	Recurring help mechanisms are presented consistently, subject to the criterion’s conditions.
3.3.7 Redundant Entry	A	Information already supplied in a process is auto-populated or available for selection, unless an exception applies.
3.3.8 Accessible Authentication (Minimum)	AA	Review cognitive function tests in authentication and relevant considerations such as password-manager support and copy/paste.
3.3.9 Accessible Authentication (Enhanced)	AAA	Review the enhanced criterion, whose exceptions are narrower than those in the minimum criterion.

The table is a review aid, not a substitute for the normative text. In particular, “24 by 24” is not a universal target-size rule without qualifications. Each criterion has scope and exceptions; check the wording for the content and interaction being assessed.

How to review the new criteria

1. Test keyboard focus in real layouts (2.4.11 AA, 2.4.12 AAA, 2.4.13 AAA)

Use the keyboard to move focus through links, controls, menus, dialogs, and other interactive elements. Test the actual page layout, including sticky headers, fixed footers, open dialogs, banners, and other author-created content. Look for focused elements hidden behind an overlay or clipped by a scroll container.

For 2.4.11, verify that some part of a focused item remains visible.
For the AAA 2.4.12 check, verify that the focused item is fully visible.
For the separate AAA 2.4.13 check, assess the focus indicator’s area and contrast against the criterion, including applicable exceptions.
Repeat after opening and closing overlays, expanding navigation, changing viewport size, and triggering validation messages. Dynamic layout changes can create failures that are absent in the initial state.

Do not merge these into one generic “focus works” check: the two obscured-focus criteria have different levels and visibility thresholds, while focus appearance is a distinct AAA criterion.

2. Find dragging-only operations (2.5.7 AA)

Inventory author-controlled interactions that require dragging, such as rearranging list items or repositioning content. For each, try the operation with a single pointer using an action that does not require dragging, such as selecting an item and activating move-up or move-down buttons. Whether an exception applies depends on the criterion’s normative wording.

A slider illustrates the practical question: can a person change its value by clicking or tapping the track, as an alternative to dragging the thumb? W3C’s Dragging Movements guidance discusses this type of alternative. The criterion concerns pointer operation; also test keyboard access under the applicable keyboard criteria.

3. Measure pointer targets and check exceptions (2.5.8 AA)

Inspect controls that are difficult to activate accurately, particularly tightly packed icon buttons and inline actions. Measure target dimensions in CSS pixels and inspect spacing. The baseline is 24 by 24 CSS pixels, but the success criterion defines exceptions and conditions. Assess the actual target and context against the normative criterion and its explanatory guidance; do not infer failure from dimensions alone or silently treat the baseline as exception-free.

4. Walk through help and multi-step forms (3.2.6 A, 3.3.7 A)

Review recurring help mechanisms across the pages where they appear: for example, a contact route, support control, or instructions repeated through a flow. Check that their presentation is consistent where the criterion applies.

Then complete multi-step processes with realistic data. Note whether the user must enter the same information again after it has already been provided in that process. Check whether the interface carries the information forward or makes it available for selection. Evaluate exceptions against the criterion instead of assuming every repeated field is automatically a failure.

Review the complete authentication experience, including sign-in, account creation where relevant, multi-factor steps, password reset, and recovery. Identify any cognitive function test the user must complete. Check whether the flow supports password managers and allows copy/paste where relevant to the criterion. Evaluate 3.3.8 and 3.3.9 separately: both concern accessible authentication, but the enhanced criterion has narrower exceptions.

A practical WCAG 2.2 review workflow

Set the scope. Record the pages, states, user journeys, WCAG version, and conformance level being evaluated. Confirm the applicable policy separately.
Map the nine additions to product features. Include interactive components, shared navigation and help, multi-step processes, and authentication. Record where a criterion may not apply and why.
Run automated checks where useful. Use automation to identify issues it can detect, such as some measurable properties or code patterns. Treat results as leads for review, not as a conformance verdict.
Evaluate interactions manually. Use keyboard and pointer input, including single-pointer alternatives for dragging. Observe focus, overlays, responsive layouts, form state, and authentication flows.
Record evidence and exceptions. For each finding, note the page and state, steps to reproduce, expected behavior, observed behavior, relevant criterion, and any exception considered. Keep screenshots as supporting visual evidence when they clarify a state; a screenshot cannot show whether an interaction works.
Retest fixes and related states. Check the specific failure and nearby states that may have changed. A focus fix in one dialog, for example, does not establish that sticky navigation or another dialog behaves correctly.

WCAG success criteria are testable, but W3C says evaluation involves a combination of automated testing and human evaluation. Functional testing checks whether content satisfies criteria. Usability testing is additional evidence about how well people can use the content for its intended purpose; when conducting usability testing, W3C recommends including people with disabilities. See Understanding Conformance and the WCAG 2.2 guidance.

Normative criteria, techniques, and conformance

The success criteria in the WCAG Recommendation are the requirements. W3C techniques are informative examples, not mandatory implementation recipes. W3C puts it plainly: “Techniques are informative — that means they are not required.” There may be other ways to meet a criterion, provided the outcome satisfies the criterion and the conformance requirements. Read Understanding Techniques when using examples to guide implementation.

Likewise, an automated score is not a conformance claim. A tool can help find certain issues, but it cannot fully judge task behavior, exceptions, or the experience of navigating changing states. Keep automated results, human functional evaluation, and usability findings distinct in reports.

Capture visual evidence for a review

A screenshot can help a developer see a focus indicator hidden by a sticky header, a dense group of pointer targets, or a form state that needs discussion. Capture the relevant page state and add the keyboard or pointer steps separately: a static image does not demonstrate keyboard operability, target behavior, or conformance. If consent overlays or other widgets obscure the page during evidence capture, record whether the image reflects the state being evaluated.

DIY browser capture

For a one-off screenshot, open the page in your browser, reproduce the relevant state, and use the browser’s screenshot or developer-tools capture feature. For repeatable capture in a test workflow, a browser automation library can navigate to the page and save an image, but setup and state handling depend on your browser stack. Keep the capture separate from the actual accessibility evaluation.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. One GET request can return a PNG, JPEG, WebP, or PDF. For a quick evidence image, request a screenshot of the page under review and save the response:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

See the ScreenshotNeo API documentation for request options. Cookie banners, popups, and chat widgets are removed before the shot; each step can be turned off. Bot checks, blank pages, and failed loads are never billed, and response headers report the page verdict and billing status. Its MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.

Performance, reliability, and cost considerations

Performance: Automated checks can cover many pages quickly, while manual evaluation takes time because it follows real interactions and states. Prioritize shared components and critical journeys, then test variations that change focus, overlays, forms, and authentication.
Reliability: A passing scan only supports the checks it actually performs. Document the tested pages, states, inputs, tools, and limitations so the evaluation can be repeated. Retest after changes to shared UI or flow logic.
Cost: WCAG itself is a standard, but evaluation effort depends on the breadth of content and interaction states. Avoid treating a tool score as a replacement for human evaluation. For screenshot evidence, ScreenshotNeo offers 1,000 monthly shots free, then paid plans at published tiers: $5 for 3,000, $15 for 15,000, $39 for 60,000, $99 for 250,000, and $249 for 1,000,000; yearly billing gives two months free. Every feature is on every plan. These are screenshot service prices, not accessibility audit costs.

Common testing mistakes and fixes

Problem	Why it happens	What to do
Assuming all nine additions are AA	The new criteria have A, AA, and AAA levels.	Keep the level beside each criterion in the review plan and findings.
Treating every target below 24 by 24 CSS pixels as an automatic failure	The criterion includes specified exceptions and conditions.	Measure in CSS pixels, then assess the complete normative text and applicable exceptions.
Testing only the initial page view	Sticky elements, dialogs, validation messages, and responsive states can change visibility.	Repeat checks after interactions and at relevant viewport sizes.
Passing a drag control because it works with a mouse	That test may still require dragging.	Try the operation with a single-pointer alternative that does not require dragging, and assess criterion exceptions.
Requiring one specific W3C technique	Techniques are informative, and other conforming solutions may exist.	Judge whether the implementation meets the success criterion, not whether it copies an example.
Calling an automated scan a WCAG audit	Automation cannot evaluate every behavior, exception, or intended-use question.	Combine automated checks with human functional evaluation; add usability testing when appropriate.
Using a screenshot as proof that a control is accessible	An image captures appearance, not keyboard or pointer behavior.	Attach the screenshot to reproducible interaction steps and observed results.

FAQ

Does WCAG 2.2 replace WCAG 2.1?

It extends the WCAG 2.x criteria with nine additions and removes 4.1.1 Parsing. Which version you need to use depends on the policy or obligation applicable to your organization.

Are all nine new criteria required for every conformance target?

The criteria have different levels. A conformance target determines which levels apply, so do not treat the nine additions as a single-level package.

Do W3C techniques have to be followed?

No. They are informative guidance. The success criteria and conformance requirements determine whether content conforms.

Can an accessibility checker establish WCAG 2.2 conformance?

Automation can assist with some checks, but evaluation also requires human evaluation. A scan result alone is not a conformance determination.

Does a screenshot prove focus or drag accessibility?

No. A screenshot can preserve a visual state, but focus movement and pointer operation must be evaluated through interaction.