WCAG 2.2 Guidelines Explained in Plain Language

The Web Content Accessibility Guidelines (WCAG) 2.2 became a W3C Recommendation on October 5, 2023. It is the current standard for web accessibility, referenced by laws and policies worldwide. The document itself runs to thousands of words of technical specification. This article translates it into language any designer, developer, or product manager can act on.

The Structure: Principles, Guidelines, Success Criteria

WCAG organizes everything under four principles, remembered by the acronym POUR:

1. Perceivable — Users can sense the content (see it, hear it, feel it).
2. Operable — Users can interact with all controls and navigation.
3. Understandable — Users can comprehend the content and interface behavior.
4. Robust — Content works with current and future technologies, including assistive tools.

Under these four principles sit 13 guidelines, and under those sit individual success criteria — the testable requirements. Each success criterion is rated Level A (minimum), AA (standard target for most laws), or AAA (enhanced).

What Changed from WCAG 2.1 to 2.2

WCAG 2.2 adds nine new success criteria and removes one (4.1.1 Parsing, now obsolete because browsers handle malformed HTML gracefully).

New at Level A

3.2.6 Consistent Help — If your site offers help features (chat, phone number, FAQ link), they must appear in the same relative location on every page. Users who need help should not have to hunt for it each time they navigate.

3.3.7 Redundant Entry — Do not force users to re-enter information they already provided in the same session. If a user typed their address on step 1 of checkout, step 3 should auto-populate it or let them select it from prior entries.

New at Level AA

2.4.11 Focus Not Obscured (Minimum) — When a keyboard user tabs to an element, the focused component must not be entirely hidden by other page content such as sticky headers, cookie banners, or fixed footers. Partially obscured is allowed at AA; fully visible is required at AAA (2.4.12).

2.4.13 Focus Appearance — The focus indicator must have sufficient size and contrast. Specifically, the focus indicator area must be at least as large as a 2px perimeter around the component, and the contrast between focused and unfocused states must be at least 3:1.

2.5.7 Dragging Movements — Any function that uses dragging must also have a single-pointer alternative. A slider must have increment/decrement buttons or a text input. A drag-to-reorder list must also support move-up/move-down buttons. See our accessible drag and drop guide for implementation patterns.

2.5.8 Target Size (Minimum) — Interactive targets must be at least 24x24 CSS pixels, or have sufficient spacing so that a 24px-diameter circle centered on each target does not overlap another target. Inline links within text are exempt. For mobile-specific guidance, see touch target sizes.

3.3.8 Accessible Authentication (Minimum) — Login flows must not require cognitive function tests (memorizing a password, solving a CAPTCHA, recognizing images) unless an alternative is provided. Password managers, passkeys, email magic links, and biometrics all satisfy this criterion.

New at Level AAA

2.4.12 Focus Not Obscured (Enhanced) — The focused element must be fully visible, not just partially visible.

3.3.9 Accessible Authentication (Enhanced) — Tighter than 3.3.8: no cognitive tests at all, including object recognition and personal content identification.

The Success Criteria That Matter Most (AA Compliance)

Most legal frameworks and organizational policies target Level AA. Here are the criteria that cause the most failures, grouped by principle.

Perceivable

• 1.1.1 Non-text Content (A): Every image, icon, and graphic needs a text alternative. Decorative images get alt="".
• 1.3.1 Info and Relationships (A): Use semantic HTML. Headings must be <h1> through <h6>, not styled <div> tags. Lists must use <ul>/<ol>. Tables need <th> headers.
• 1.4.3 Contrast Minimum (AA): 4.5:1 for normal text, 3:1 for large text. Use the color contrast tools guide to verify.
• 1.4.11 Non-text Contrast (AA): UI components and graphical objects need 3:1 contrast against adjacent colors.

Operable

• 2.1.1 Keyboard (A): All functionality must be available from a keyboard. No mouse-only interactions. See keyboard navigation essentials.
• 2.4.7 Focus Visible (AA): A visible focus indicator must appear on the currently focused element.
• 2.5.8 Target Size Minimum (AA): 24x24 CSS pixels or equivalent spacing.

Understandable

• 3.1.1 Language of Page (A): Set the lang attribute on the <html> element.
• 3.3.1 Error Identification (A): When a form error occurs, identify the field and describe the error in text. See error handling in UX.
• 3.3.2 Labels or Instructions (A): Every form input needs a visible label.

Robust

• 4.1.2 Name, Role, Value (A): All UI components must expose their name, role, and state to assistive technology. Use native HTML elements first; add ARIA roles only when native semantics are insufficient.

How to Start a WCAG 2.2 Audit

1. Automated scan: Run axe DevTools, WAVE, or Lighthouse on every unique page template. This catches roughly 30-40% of issues.
2. Keyboard walkthrough: Tab through every page. Can you reach, operate, and leave every interactive element?
3. Screen reader test: Navigate with VoiceOver (macOS/iOS) or NVDA (Windows). Does the announced content match what sighted users see?
4. Manual review: Check heading hierarchy, alt text quality, color contrast, focus order, and form labels.
5. User testing: Recruit participants who use assistive technology daily.

For detailed tool recommendations, see our accessibility testing tools comparison.

Key Takeaways

• WCAG 2.2 adds nine new success criteria focused on focus visibility, target sizing, authentication, dragging alternatives, and consistent help placement.
• Level AA is the standard compliance target for most legal frameworks.
• Automated tools catch only 30-40% of issues — manual testing and user research are essential.
• The removal of 4.1.1 Parsing reflects that modern browsers handle HTML errors gracefully.

Next Steps

• Read the full universal design guide for the philosophy behind these requirements.
• Explore specific criteria in depth: color contrast, keyboard navigation, form design.

Sources

• WCAG 2.2 W3C Recommendation — The full specification this article summarizes.
• Understanding WCAG 2.2 — W3C supplementary guidance explaining each success criterion.
• WebAIM WCAG 2 Checklist — Practical checklist for WCAG conformance.
• Deque University WCAG Reference — axe rules mapped to WCAG success criteria.

Based on the W3C Web Content Accessibility Guidelines (WCAG) 2.2, published October 5, 2023. This article is an educational summary — refer to the official W3C specification for normative requirements.