WCAG 2.2 (Web Content Accessibility Guidelines 2.2) is the current version of the W3C's web accessibility standard, published as a Recommendation in October 2023. It added 9 new success criteria to WCAG 2.1 and removed one (4.1.1 Parsing). WCAG 2.2 is backwards compatible - all WCAG 2.1 criteria still apply.

What is WCAG 2.2 Level AA?

WCAG 2.2 Level AA is the conformance level required by most accessibility regulations including the European Accessibility Act and UK public sector bodies regulations. It includes all Level A criteria plus additional Level AA requirements. Most professional accessibility audits target AA compliance.

What is new in WCAG 2.2?

WCAG 2.2 added 9 new success criteria: Focus Not Obscured (2.4.11), Focus Not Obscured Enhanced (2.4.12), Focus Appearance (2.4.13), Dragging Movements (2.5.7), Target Size Minimum (2.5.8), Consistent Help (3.2.6), Redundant Entry (3.3.7), Accessible Authentication Minimum (3.3.8), and Accessible Authentication Enhanced (3.3.9). It also removed 4.1.1 Parsing.

Accessibility Reference

WCAG 2.2 Checklist

The complete WCAG 2.2 Level AA checklist - all 9 new criteria explained in plain English, plus the most important existing requirements, with practical testing guidance for each.

Run a free WCAG scan Book an audit

What changed in WCAG 2.2?

WCAG 2.2, published October 2023, is backwards compatible with WCAG 2.1. All existing criteria remain. These are the additions and removals.

New criteria added

Criterion removed (4.1.1)

Total criteria (A + AA + AAA)

New in WCAG 2.2

The 9 new success criteria

These are the additions you need to address if you were previously targeting WCAG 2.1 AA.

2.4.11

Focus Not Obscured (Minimum)

Level AA

Requirement: When a user interface component receives keyboard focus, it must not be entirely hidden by author-created content.

How to test: Tab through every interactive element on the page. Check that sticky headers, cookie banners, and fixed footers do not completely cover the focused element.

Common failure: Sticky nav bar covers the focused element. The bottom of the focused element is obscured by a chat widget.

2.4.12

Focus Not Obscured (Enhanced)

Level AAA

Requirement: The focused component must be fully visible - no part of it is hidden by author-created content.

How to test: Same test as 2.4.11 but the standard is stricter: the focused element must be fully visible, not just partially visible.

Common failure: Any overlap between focused element and fixed UI is a failure at AAA level.

2.4.13

Focus Appearance

Level AA

Requirement: Focus indicators must have a minimum area and a contrast ratio of at least 3:1 against adjacent colours.

How to test: Measure the focus indicator: it must have an area at least as large as the perimeter of the unfocused component times 2 CSS pixels, or enclose the component. Verify the contrast of the indicator against surrounding unfocused colours.

Common failure: 1px dotted outline that barely meets the area requirement. Browser default focus styles that are removed by CSS resets.

2.5.7

Dragging Movements

Level AA

Requirement: Any functionality using a dragging movement must be achievable with a single pointer action (e.g., a click or tap).

How to test: Find all drag-and-drop interactions. Verify there is an alternative: click to select then click to drop, or buttons to move items.

Common failure: Kanban board cards that can only be dragged between columns with no keyboard or click-based alternative.

2.5.8

Target Size (Minimum)

Level AA

Requirement: The size of interactive targets must be at least 24x24 CSS pixels, or there must be sufficient spacing around smaller targets.

How to test: Measure interactive elements in browser DevTools. Any target smaller than 24x24 CSS pixels must have sufficient offset space to make the effective tap area adequate.

Common failure: Social media icons at 16x16px with no spacing. Close buttons on modals at 20x20px.

3.2.6

Consistent Help

Level A

Requirement: If a help mechanism (live chat, contact email, FAQ link, help phone number) appears on multiple pages, it must appear in the same location on each page.

How to test: Check that any help links or contact information appear in a consistent position across all pages. Navigation or footer placement both qualify if consistent.

Common failure: Help link in header on most pages but in the main content on one page. Chat widget absent on mobile.

3.3.7

Redundant Entry

Level A

Requirement: Information previously provided by the user in the same multi-step process must not need to be entered again unless re-entry is essential or required for security.

How to test: Walk multi-step forms. If billing address was entered in a previous step, the delivery address step should allow auto-fill from it. Previously entered data should be auto-populated or selectable.

Common failure: Asking for the user's name again in step 3 after they entered it in step 1. Multi-page checkout asking for email a second time.

3.3.8

Accessible Authentication (Minimum)

Level AA

Requirement: Authentication processes must not require cognitive function tests (solving puzzles, identifying objects in images, transcribing text) unless an alternative is provided.

How to test: Test the login and sign-up flows. CAPTCHA that requires identifying images or solving visual puzzles fails this criterion unless there is an audio CAPTCHA alternative or the CAPTCHA can be bypassed by other means.

Common failure: Image-based CAPTCHA with no audio alternative. Visual puzzle CAPTCHAs.

3.3.9

Accessible Authentication (Enhanced)

Level AAA

Requirement: All cognitive function tests are prohibited in authentication - there are no exceptions for alternatives.

How to test: This is the stricter version: no cognitive tests of any kind in authentication, period.

Common failure: Any CAPTCHA without exception at AAA level.

Removed in WCAG 2.2: 4.1.1 Parsing

Removed

4.1.1 required that HTML be well-formed. It was removed because modern browsers handle invalid markup gracefully and the criterion no longer improves accessibility meaningfully. If you were testing for this, you can stop including it in WCAG 2.2 audits.

Key existing Level AA criteria

These inherited from WCAG 2.1 but are among the most frequently failed and highest impact.

1.1.1

Non-text Content

Level A

Requirement: All non-text content (images, icons, charts) has a text alternative.

How to test: Check every image has a meaningful alt attribute, or alt="" for decorative images. Icon buttons have aria-label.

Common failure: Images with file names as alt text ('hero-image-final2.jpg'). Icon-only buttons with no accessible name.

1.3.1

Info and Relationships

Level A

Requirement: Structure and relationships conveyed visually are also conveyed programmatically.

How to test: Check headings use H1-H6 elements, not styled divs. Tables use th for headers. Lists use ul/ol/li.

Common failure: Headings created with bold paragraph text. Table data with no th headers.

1.4.3

Contrast (Minimum)

Level AA

Requirement: Text must have a contrast ratio of at least 4.5:1 (normal text) or 3:1 (large text of 18px+ or 14px+ bold).

How to test: Use the browser's DevTools accessibility panel or a contrast checker. Check all body text, link text, placeholder text.

Common failure: Light grey text on white backgrounds. Placeholder text at insufficient contrast.

1.4.4

Resize Text

Level AA

Requirement: Text can be resized up to 200% without loss of content or functionality.

How to test: Set browser text size to 200% and verify all content remains accessible and no text is cut off.

Common failure: Fixed-height containers that clip text when resized.

2.1.1

Keyboard

Level A

Requirement: All functionality is operable by keyboard.

How to test: Tab through every interactive element. Verify all buttons, links, forms, and custom widgets can be operated with keyboard alone.

Common failure: Custom dropdown or date picker only operable with mouse. Drag-and-drop with no keyboard alternative.

2.4.1

Bypass Blocks

Level A

Requirement: A mechanism exists to skip repeated blocks of content (e.g., 'Skip to main content' link).

How to test: Tab once from the top of the page and verify a skip navigation link appears.

Common failure: No skip nav link. Skip link exists but is hidden and never focusable.

2.4.6

Headings and Labels

Level AA

Requirement: Headings and labels describe topic or purpose.

How to test: Read every heading and form label. Verify they are descriptive and make sense without visual context.

Common failure: Form fields labelled 'Field 1', 'Field 2'. Section headings like 'More information'.

3.1.1

Language of Page

Level A

Requirement: The default human language of a page is programmatically determined.

How to test: Check that the HTML element has a valid lang attribute (e.g., lang="en").

Common failure: Missing lang attribute on the HTML element.

4.1.2

Name, Role, Value

Level A

Requirement: All UI components have accessible names, roles, and states that can be determined programmatically.

How to test: Inspect custom interactive components (tabs, accordions, modals). Verify they have appropriate ARIA roles and states (aria-expanded, aria-selected, etc.).

Common failure: Custom accordion with no aria-expanded. Modal without role=dialog or aria-label.

How to audit your site for WCAG 2.2

Run an automated scan

Automated tools catch roughly 30-40% of accessibility failures. Use the RedQA Accessibility Scanner, axe DevTools, or Lighthouse to identify issues quickly.

Run a free scan

Manual keyboard testing

Tab through every page and feature using only your keyboard. Verify all interactive elements are reachable, operable, and have visible focus indicators.

Screen reader testing

Test with NVDA + Chrome on Windows, VoiceOver + Safari on Mac, and TalkBack on Android. Listen for missing alt text, unlabelled fields, and confusing announcements.

Colour contrast checks

Check all text elements with a contrast analyser. Pay particular attention to placeholder text, disabled states, and text on coloured backgrounds.

Document findings and remediate

Document each issue with its WCAG success criterion, severity, and specific element. Prioritise Level A failures first, then Level AA.

Ready to Ship with Confidence?

Let's discuss how RedQA can help you deliver better software, faster. Get a free consultation and quote tailored to your project.

Get a Free Quote Book a 30-min call