AccessGuardby VASTROX

WCAG 2.2 Checker: Scan for the New 2.2 Success Criteria

WCAG 2.2 became a W3C Recommendation in October 2023, adding nine new success criteria and retiring the old Parsing requirement. AccessGuard checks your site against these updated rules, flags WCAG issues, and gives your developers clear fix guidance.

What WCAG 2.2 adds and what it removed

WCAG 2.2 builds directly on 2.1. Every success criterion from 2.0 and 2.1 still applies, and 2.2 layers nine additional criteria on top. Six of these matter most for typical websites because they land at Level A and AA, the levels that most organizations and regulators reference. The Level AAA additions are valuable but rarely required for baseline conformance.

The headline change most teams miss is a removal. Success Criterion 4.1.1 Parsing is now obsolete in WCAG 2.2. It previously required valid, well-formed markup, but modern browsers and assistive technologies handle parsing reliably, so it no longer contributes to conformance. If an older audit tool still flags 4.1.1 Parsing failures, that tool is scanning against 2.1 rather than 2.2.

AccessGuard scans against the current 2.2 rule set, so you see the criteria that actually apply today. This is an accessibility scanner and WCAG issue detection tool, not legal advice, and passing a scan does not guarantee legal compliance. It gives you a defensible, evidence-based starting point for accessibility improvements.

  • Level A additions: Consistent Help (3.2.6), Redundant Entry (3.3.7)
  • Level AA additions: Focus Not Obscured Minimum (2.4.11), Dragging Movements (2.5.7), Target Size Minimum (2.5.8), Accessible Authentication Minimum (3.3.8)
  • Level AAA additions: Focus Not Obscured Enhanced (2.4.12), Focus Appearance (2.4.13), Accessible Authentication Enhanced (3.3.9)
  • Removed: 4.1.1 Parsing is obsolete in WCAG 2.2

The six new criteria that matter most (A and AA)

Focus Not Obscured, Minimum (2.4.11, AA) requires that when a component receives keyboard focus, it is not entirely hidden by author-created content such as sticky headers, cookie banners, or floating chat widgets. A keyboard user must be able to see at least part of the element they have tabbed to. Sticky elements with high z-index are the most common cause of failures here.

Target Size, Minimum (2.5.8, AA) sets a floor of 24 by 24 CSS pixels for pointer targets, unless an equivalent larger target exists, the target is inline in a sentence, or spacing between targets is sufficient. Dense icon toolbars, tightly packed pagination, and small close buttons are frequent offenders. Dragging Movements (2.5.7, AA) requires that any action driven by dragging also has a simple pointer alternative, so sliders, drag-to-reorder lists, and map panning need a click or tap based equivalent.

Consistent Help (3.2.6, A) requires help mechanisms such as contact links, chat, or a help page to appear in the same relative order across pages. Redundant Entry (3.3.7, A) says you must not force users to re-enter information they already provided in the same process, so multi-step checkouts and forms should auto-populate or offer a select-to-reuse option. Accessible Authentication, Minimum (3.3.8, AA) prohibits cognitive function tests like remembering a password or solving a puzzle unless an alternative exists, which is why support for password managers, copy and paste, and passkeys matters.

WCAG 2.1 vs 2.2: what actually changed for your team

If you already conform to WCAG 2.1 AA, you are close, but you are not automatically at 2.2 AA. The four new AA criteria and two new A criteria are net-new work that a 2.1 audit never checked. The practical gap for most sites concentrates in three areas: touch target sizing on mobile, focus visibility around sticky and overlay UI, and authentication and form flows that assume users can retype or memorize data.

The upside is that none of the new criteria require a redesign. They are targeted, testable fixes: increase small tap targets to at least 24 pixels or add spacing, adjust z-index and scroll padding so focused elements stay visible, add pointer alternatives to drag interactions, keep help links consistent, prefill known data, and let password managers and passkeys work. Each maps to a concrete code change.

WCAG 2.2 is also the reference standard behind the harmonized EN 301 549 requirements that inform European Accessibility Act readiness. AccessGuard surfaces EAA readiness signals based on your scan results so you understand where you stand. These are signals to guide accessibility improvements, not a legal determination, and they do not replace advice from a qualified accessibility or legal professional.

How to test for WCAG 2.2 (automated plus manual)

No scanner catches everything, and WCAG 2.2 makes that especially clear because several new criteria depend on context and intent. Automated testing is excellent at measuring target dimensions, detecting overlapping focused elements, checking contrast, and finding missing labels. It is a fast, repeatable first pass that flags the majority of mechanical issues across every page at once.

Manual testing then confirms the human-judgment criteria. Tab through your interface with a keyboard to verify focus stays visible past sticky headers and modals. Test drag interactions with a single click or tap to confirm an alternative exists. Walk a multi-step form to check that data is not requested twice. Try logging in using only a password manager and a passkey, without typing anything from memory, to validate Accessible Authentication.

AccessGuard runs the automated layer for you: scan a URL, get a prioritized list of WCAG 2.2 issues mapped to the exact success criterion, and hand your developers specific fix guidance for each finding. Install the WordPress plugin for continuous scanning, export a PDF report for stakeholders, and track progress in the dashboard. When you want the fixes done, VASTROX web development, WordPress maintenance, and accessibility repair teams can implement them.

  • Automate first: target size, focus visibility, contrast, labels, and structure
  • Keyboard test: tab through sticky headers, banners, and modals to confirm focus is not obscured
  • Pointer test: confirm every drag action has a click or tap alternative
  • Flow test: check forms for redundant entry and log in using only a password manager or passkey
  • Report and fix: export a PDF, track in the dashboard, then remediate with developer fix guidance

Frequently asked questions

Is a WCAG 2.2 checker enough to prove legal compliance?

No. AccessGuard is an accessibility scanner that detects WCAG issues and provides EAA readiness signals and fix guidance. It is not legal advice and does not guarantee legal compliance. Automated tools cannot evaluate every context-dependent criterion, so combine scanning with manual testing and, where needed, guidance from a qualified accessibility or legal professional.

What is the difference between WCAG 2.1 and WCAG 2.2?

WCAG 2.2 keeps all 2.1 criteria and adds nine new ones, including Target Size Minimum, Focus Not Obscured, Dragging Movements, Consistent Help, Redundant Entry, and Accessible Authentication. It also removes the old 4.1.1 Parsing criterion, which is now obsolete. If you meet 2.1 AA, you still need to address the six new A and AA criteria to reach 2.2 AA.

Which new WCAG 2.2 criteria are Level AA?

Four new criteria are Level AA: Focus Not Obscured Minimum (2.4.11), Dragging Movements (2.5.7), Target Size Minimum (2.5.8), and Accessible Authentication Minimum (3.3.8). Two more, Consistent Help (3.2.6) and Redundant Entry (3.3.7), are Level A. Together these six form the practical gap most sites need to close for 2.2 AA.

Do I have to re-test if my markup was flagged for 4.1.1 Parsing?

Not for that criterion. 4.1.1 Parsing is obsolete in WCAG 2.2, so parsing-only failures no longer count against conformance. If a tool still reports them, it is checking against WCAG 2.1. AccessGuard scans against the current 2.2 rule set so your results reflect the criteria that apply today.

Can AccessGuard help fix the issues it finds, not just report them?

Yes. Every finding is mapped to the exact WCAG 2.2 success criterion with developer fix guidance. You can scan for free, install the WordPress plugin for continuous monitoring, export PDF reports, and track progress in the dashboard. For hands-on remediation, VASTROX offers web development, WordPress maintenance, and accessibility repair services.

Important: AccessGuard performs automated accessibility checks and provides technical guidance based on common WCAG-related issues. Automated testing cannot detect every accessibility barrier and does not replace manual testing, user testing, or legal review. AccessGuard does not guarantee legal compliance.

More accessibility checkers

Scan your site now

Free, in a real browser, with a clear fix plan.

Scan my website