WCAG 2.2 Changes: What's New and What It Means for WordPress

WCAG 2.2 added nine new success criteria and removed one old one. The changes focus on keyboard users who need to see where focus is, people with limited hand movement, and people with cognitive or memory disabilities. For most WordPress sites, the new rules hit sticky headers, cookie banners, small icon buttons, multi-step forms and login pages.

This article is general information, not legal advice.

WCAG 2.2 at a glance

The Web Content Accessibility Guidelines (WCAG) are published by the World Wide Web Consortium (W3C). WCAG 2.2 became a W3C Recommendation on October 5, 2023. An updated edition with small corrections followed on December 12, 2024. The full list is on the W3C’s What’s New in WCAG 2.2 page.

Most organizations aim for Level AA, which includes every Level A criterion. That means six of the nine new criteria apply to a typical compliance target: 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 and 3.3.8.

WCAG 2.2 is backward compatible. The W3C states in the WCAG 2.2 specification that content conforming to 2.2 also conforms to 2.1 and 2.0. So if a contract or regulation names WCAG 2.1 Level AA, as the U.S. Department of Justice rule for state and local governments does, meeting 2.2 covers it. We explain the legal side in our ADA compliance guide for WordPress.

The new Level A and AA criteria, applied to WordPress

2.4.11 Focus Not Obscured (Minimum)

When an element gets keyboard focus, it must not be completely hidden by other content you added to the page.

Where WordPress sites fail: sticky headers, sticky “Book now” bars, cookie consent banners and chat widgets. A keyboard user presses Tab, focus moves to a link that sits under the sticky header, and they can no longer see where they are.

How to fix it:

• Add scroll-padding-top to the page so the browser scrolls focused items clear of a sticky header.
• Make cookie banners non-blocking, or move focus into them until they are dismissed.
• Make sure chat bubbles do not sit on top of footer links.

html {
  /* Match the height of your sticky header */
  scroll-padding-top: 6rem;
}

2.5.7 Dragging Movements

Anything that requires dragging must also work with a single click or tap, unless dragging is essential.

Where WordPress sites fail: before-and-after image sliders, range sliders in product filters, drag-to-reorder lists in front-end forms, and custom map interfaces.

How to fix it: add buttons or inputs as an alternative. A price filter can have two number fields next to the slider. A sortable list can have “move up” and “move down” buttons. A drag-and-drop file upload area should also have a regular “choose file” button, which most good upload fields already include.

2.5.8 Target Size (Minimum)

Clickable targets must be at least 24 by 24 CSS pixels. There are exceptions. The most useful ones are:

• Spacing: a smaller target passes if a 24-pixel circle centered on it does not overlap another target or its circle.
• Inline: links inside a sentence or paragraph are exempt.
• Equivalent: another control on the same page does the same thing and meets the size.
• Essential or browser default controls are exempt.

Where WordPress sites fail: social media icons in the footer, carousel dots, pagination numbers, close buttons on popups, and “remove item” icons in WooCommerce carts.

How to fix it: increase the padding on the clickable element, not just the icon. The icon can stay visually small while the link area grows.

.social-links a {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-width: 24px;
  min-height: 24px;
}

For touch screens, we usually go larger than the minimum. Twenty-four pixels is the floor, not a goal.

3.2.6 Consistent Help

If you offer help, such as a phone number, contact link, chat widget or FAQ link, and it appears on several pages, it must appear in the same relative order on each of those pages.

Where WordPress sites fail: landing pages built with a page builder that drop the normal header, or sites where the contact link moves between the header, the footer and a floating button depending on the template.

How to fix it: put help options in a shared header or footer template part and use it everywhere. This criterion does not force you to add help. It only asks you to be consistent when you do.

3.3.7 Redundant Entry

In a single process, users should not have to type the same information twice. Information they already entered must be filled in for them or offered for selection. Exceptions include re-entering a password for security, or cases where re-entry is essential.

Where WordPress sites fail: multi-step forms that ask for an email on page one and again on page three, and checkouts with no “shipping address same as billing” option.

How to fix it: most form plugins, including Gravity Forms, can pre-fill a later field from an earlier one. A “same as billing” checkbox handles the checkout case. If you need help with complex multi-step forms, our article on Gravity Forms custom development covers when custom work makes sense.

3.3.8 Accessible Authentication (Minimum)

Logging in must not depend on a cognitive function test, such as remembering a password with no help, solving a puzzle, or transcribing distorted characters, unless there is an alternative or a helping mechanism.

The good news: a normal username and password field passes, as long as people can use a password manager or paste their password. Recognizing objects (such as “select all the images with a bus”) is allowed at Level AA, but not at Level AAA.

Where WordPress sites fail:

• Math CAPTCHA plugins on wp-login.php (“What is 7 + 4?”).
• Text CAPTCHAs with distorted letters.
• Custom login forms that block pasting into the password field.
• Login forms with autocomplete="off", which can stop password managers from filling them in.

How to fix it: remove puzzle CAPTCHAs from login and use less intrusive spam and brute-force protection, such as rate limiting on the server. Let browsers fill and paste passwords. Offer passkeys, magic links or single sign-on if your audience needs them. This overlaps with security work; our WordPress security hardening checklist covers login protection that does not hurt usability.

The Level AAA additions

These three are not part of a typical Level AA target, but they are useful design goals:

• 2.4.12 Focus Not Obscured (Enhanced): no part of the focused element may be hidden.
• 2.4.13 Focus Appearance: the focus indicator must be at least 2 CSS pixels thick around the element and have at least 3:1 contrast between focused and unfocused states.
• 3.3.9 Accessible Authentication (Enhanced): no object recognition or personal content checks at login.

Even if you do not aim for AAA, 2.4.13 is a good rule of thumb for focus styles. A visible, thick, high-contrast outline helps everyone who uses a keyboard.

What was removed: 4.1.1 Parsing

WCAG 2.2 removed 4.1.1 Parsing. It required valid, well-formed HTML markup, mostly so older assistive technology would not break. Modern browsers and screen readers handle markup errors in a consistent way, so the W3C marked it obsolete.

This does not mean broken HTML is fine. Duplicate IDs can still break form labels and ARIA references, and those failures are still caught by other criteria, such as 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value.

What WCAG 2.2 means for your WordPress site in practice

For most WordPress sites we review, the WCAG 2.2 work comes down to a short list:

1. Fix sticky elements that cover focused links.
2. Enlarge small icon buttons and carousel controls.
3. Add click alternatives to sliders and drag interfaces.
4. Keep help links in a consistent place across templates.
5. Pre-fill repeated form fields.
6. Remove puzzle CAPTCHAs from login and allow password managers.

WordPress itself has adopted the new version. The WordPress accessibility coding standards expect code in core, WordPress.org sites and official plugins to conform to WCAG 2.2 Level AA. Your theme and plugins are where the gaps usually are.

What about WCAG 3?

The W3C is working on WCAG 3, but it is still a working draft. The W3C says in its WCAG 3 introduction that it is not expected to be finished for a few more years. WCAG 2.2 is the version to build and test against today.

Check your site against WCAG 2.2

Automated scanners catch some of these issues, such as small targets, but not all of them. Focus being hidden, consistent help and redundant entry usually need a person to test. Our guide on how to audit WordPress accessibility explains the manual checks.

If you want a clear list of what WCAG 2.2 changes mean for your own site, our accessibility audit tests your key templates and forms against WCAG 2.2 Level AA and ranks each issue by impact. Contact us and we will tell you what we would test first.