WCAG 2.2 for WordPress: Full Implementation Guide

In this article: A practical guide to implementing WCAG 2.2 compliance on WordPress sites. It’s for developers and site owners who need to understand what changed in WCAG 2.2, which criteria are hardest to meet, and exactly how to fix each one. By the end, you’ll have a working checklist you can run through on any WordPress build.

What WCAG 2.2 means for your WordPress site

If you run or build WordPress sites, WCAG 2.2 is the accessibility standard you need to meet in 2026. It became a W3C Recommendation in October 2023 and has since been referenced in legislation across the UK, EU, US, and Australia. The EU Accessibility Act, which came into force for most private-sector businesses in June 2025, explicitly points to WCAG 2.2 Level AA as the benchmark for digital compliance.

WCAG 2.2 builds on the previous 2.1 standard. Most of what you already know still applies. The update adds nine new success criteria, removes one (4.1.1 Parsing, which is now obsolete), and tightens the focus on three groups of users who were underserved by earlier guidelines: people with cognitive and learning disabilities, people with low vision, and people using mobile devices or switch controls.

WordPress powers over 40% of the web, which means a significant share of the accessibility gaps in the digital landscape sit inside WordPress themes, plugins, and custom builds. This guide covers every new WCAG 2.2 criterion, explains what it means in plain English, and shows you how to address it on a WordPress site.

---

What changed: the nine new WCAG 2.2 criteria

Before jumping into fixes, it helps to understand what WCAG 2.2 actually added. The nine new success criteria span three conformance levels: A, AA, and AAA.

For most organisations, Level AA is the legal and practical target. That means you need to meet all Level A and Level AA criteria. The three new Level AAA criteria are listed below for completeness, but they are not typically required.

New Level A criteria

2.4.11 Focus not obscured (minimum): When a keyboard-focusable component receives focus, it must not be entirely hidden by author-created content. Sticky headers, fixed cookie banners, and chat widgets are the most common culprits on WordPress sites.

3.2.6 Consistent help: If a site offers a help mechanism (phone number, email link, live chat, self-service portal), that mechanism must appear in the same location across pages. This is most relevant to sites with multiple page templates.

3.3.7 Redundant entry: Users should not have to re-enter information they have already provided within the same session or process. This matters for multi-step forms in WooCommerce checkouts, membership sign-ups, and contact forms.

New Level AA criteria

2.4.12 Focus not obscured (enhanced): A stricter version of 2.4.11. No part of the focused component can be hidden by author-created content. Level AA requires the focused element to be at least partially visible; the Level AA version of this criterion (2.4.12) is slightly stronger than the Level A version.

2.4.13 Focus appearance: The focus indicator must meet minimum size and contrast requirements. Specifically, the focus indicator area must be at least as large as a 2 CSS pixel perimeter around the component, and the colour change between focused and unfocused states must have a contrast ratio of at least 3:1.

2.5.7 Dragging movements: Any functionality that uses a dragging movement (sliders, drag-and-drop reordering, map panning) must also be operable with a single pointer without dragging. This is a significant criterion for WooCommerce product galleries, page builders, and custom UI components.

2.5.8 Target size (minimum): Interactive targets must be at least 24 by 24 CSS pixels, or have sufficient spacing around them so that a 24-pixel circle centred on the target does not intersect another target or its spacing. Inline text links are exempt. Small icon buttons, social share links, and close buttons on modals are the most common failures.

3.3.8 Accessible authentication (minimum): Authentication processes must not rely solely on a cognitive function test unless an alternative is provided. CAPTCHA that requires solving a puzzle or identifying images without an accessible alternative fails this criterion. Most WordPress login and WooCommerce checkout flows need a review.

New Level AAA criteria

For reference only (not required for AA conformance):

• 2.4.14 Focus appearance (enhanced) — stricter version of 2.4.13
• 3.3.9 Accessible authentication (enhanced) — removes exemptions allowed in 3.3.8
• 3.2.7 Visible controls — UI controls must be visible without requiring hover or focus

---

The WCAG 2.2 checklist for WordPress

The following checklist maps each new criterion to a concrete action you can take inside WordPress. Work through it top to bottom. For each item, test with a keyboard only, then retest with a screen reader and a mobile device.

Focus visibility and keyboard access

Check your sticky header offset. If your theme uses a sticky or fixed header, keyboard focus can land behind it when users tab through the page. Fix this with a CSS scroll-margin-top value on focusable elements equal to the height of your header, or by using a JavaScript focus management approach.

:focus {
  scroll-margin-top: 80px; /* match your sticky header height */
}

Audit your focus indicator styles. Most WordPress themes reset or hide the browser default outline. Search your theme’s CSS for outline: none or outline: 0 and remove or replace those rules. The replacement focus style must meet the 2.4.13 size and contrast requirements. A solid 2px offset outline in a colour with at least 3:1 contrast against its adjacent background is a safe baseline.

:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 3px;
}

Test every draggable component. If your theme or a plugin adds a slider, carousel, or drag-to-reorder feature, confirm that every action can also be completed by clicking or tapping without dragging. Contact the plugin author if not — this is their responsibility to fix.

Target size

Audit small buttons and icons. Use browser DevTools to measure the rendered size of icon buttons, close buttons on modals and banners, and social sharing links. Any target below 24x24 CSS pixels that sits within 24 pixels of another target needs to be enlarged or given additional spacing via padding.

/* Minimum safe approach for icon buttons */
.icon-btn {
  min-width: 44px;  /* 44px is the WCAG 2.5.5 AAA recommendation — exceeds the AA minimum */
  min-height: 44px;
  display: inline-flex;
  align-items: center;
  justify-content: center;
}

Check your WooCommerce product grids. Add-to-cart and wishlist icon buttons in product cards are a common failure point. Override the theme’s default sizing for these elements if they fall below the threshold.

Forms and authentication

Review your CAPTCHA implementation. If you use a CAPTCHA on your login page, contact form, or WooCommerce checkout, confirm it offers an accessible alternative. reCAPTCHA v3 (which is invisible) generally passes because it does not ask the user to perform a cognitive task. Image-selection and text-distortion CAPTCHAs fail unless an audio or logical alternative is provided.

Audit multi-step forms for redundant entry. If your checkout or sign-up process spans multiple steps and asks for the same information twice (for example, billing email and then account email), pre-populate the second field from the first, or remove the duplication.

Add a consistent help mechanism. If your site includes any form of contact or support (a phone number in the footer, a live chat widget, a help email), check that it appears in the same location on every page type: homepage, inner pages, checkout, account pages. A persistent footer placement usually satisfies this requirement.

---

Testing your WordPress site for WCAG 2.2 compliance

No automated tool can catch every WCAG 2.2 failure. Automated scanners typically identify around 30–40% of accessibility issues. For full coverage, combine automated testing with manual keyboard testing and assistive technology testing.

Automated testing tools

Run your pages through at least two automated tools, since each catches different issues:

• WAVE by WebAIM — good for contrast, missing labels, and heading structure
• axe DevTools — deeper ARIA and focus order analysis, available as a browser extension
• Lighthouse in Chrome DevTools — built-in accessibility audit score with actionable recommendations

Manual testing checklist

Run through this sequence on every unique page template in your WordPress site:

1. Tab through the page from top to bottom. Confirm every interactive element receives visible focus in order.
2. Check focus is never fully hidden behind sticky headers, modals, or overlapping elements.
3. Complete every form using keyboard only. Confirm you can submit without a mouse.
4. Test all draggable components without dragging.
5. Measure small touch targets using DevTools.
6. Attempt login or checkout and confirm no CAPTCHA blocks keyboard or screen reader users.

Screen reader testing

Test with at least one screen reader. On Windows, NVDA is free and widely used. On macOS, VoiceOver is built in (activate with Command+F5). On mobile, use TalkBack on Android or VoiceOver on iOS. Navigate using the screen reader’s heading shortcuts, form mode, and link list to check that structure and labels make sense without visual context.

---

Using AccessYes to support WCAG 2.2 compliance

AccessYes is a free WordPress accessibility plugin that helps address a range of WCAG 2.2 requirements directly from the WordPress dashboard. It adds a customisable accessibility widget to your site that lets users adjust focus indicator visibility, text spacing, contrast, and more — addressing several cognitive accessibility and focus-related criteria without requiring custom code.

AccessYes is a practical layer on top of a properly built site, not a replacement for fixing underlying code issues. The most reliable path to WCAG 2.2 compliance is to fix structural issues at the theme and plugin level, then use a tool like AccessYes to extend the accessibility options available to your users.

You can learn more about what AccessYes covers in the AccessYes feature overview, or see how specific WCAG criteria map to plugin settings in our WCAG criteria reference guide.

---

Key takeaways

WCAG 2.2 compliance for WordPress comes down to three practical priorities:

1. Fix focus. Every keyboard-visible element needs a high-contrast, appropriately sized focus indicator that is never hidden behind fixed or sticky UI elements. This addresses 2.4.11, 2.4.12, and 2.4.13.

2. Audit interactive components. Check target sizes, draggable interactions, and multi-step forms. Small icon buttons and drag-and-drop widgets are the most common sources of failure. This addresses 2.5.7 and 2.5.8.

3. Review authentication and forms. Replace or supplement CAPTCHA with an accessible alternative, and remove redundant data entry from multi-step flows. This addresses 3.3.7 and 3.3.8.

No single plugin makes a WordPress site fully accessible. Compliance requires code-level fixes, ongoing testing, and a commitment to including accessibility in your build process from the start. The checklist and criteria in this guide give you a concrete place to begin.

Ready to get started? Install AccessYes for free and run through the checklist above on your next WordPress project.