WCAG 2.2 for WordPress Sites
WCAG 2.2 became a W3C Recommendation in October 2023. It keeps every WCAG 2.1 requirement except 4.1.1 Parsing and adds six success criteria at Level A and AA, mostly about people with low vision, motor disabilities and cognitive disabilities. A WordPress site that meets WCAG 2.2 AA also meets 2.1 AA and 2.0 AA.
This checker runs the same free scan as the WordPress accessibility checker with the WCAG 2.2 AA preset, so the results include the 2.2 rules that automated testing can check.
On WordPress sites, WCAG 2.2 issues usually come from the theme and plugins rather than core: icon-only social links below 24 pixels, sticky headers that cover focused links, and login or comment forms that block password managers.
| Published | October 5, 2023 |
|---|---|
| Success criteria at Level A and AA | 55 |
| New at Level A and AA | 6 |
| Removed | 4.1.1 Parsing |
| Automated rules in this scan | 63 |
Who Should Run the WordPress WCAG 2.2 Checker
- WordPress site owners who want the most current, future-proof target.
- Teams redesigning a WordPress site, where adopting the latest version costs little extra.
- Organizations selling into the EU, where EN 301 549 V4.1.1 now uses WCAG 2.2.
- Anyone preparing for new rules, which tend to adopt the latest WCAG version.
The New WCAG 2.2 Criteria to Check on WordPress
-
2.4.11 Focus Not Obscured (Minimum)
Sticky headers, cookie banners and chat widgets must not completely hide the element that has keyboard focus.
-
2.5.7 Dragging Movements
Anything that works by dragging, such as sliders, carousels and sortable lists, needs a single-pointer alternative.
-
2.5.8 Target Size (Minimum)
Buttons and links need a target of at least 24 by 24 CSS pixels, or enough space around them. Icon buttons and pagination links often fail.
-
3.2.6 Consistent Help
Help such as a contact link or chat must appear in the same place on every page that has it.
-
3.3.7 Redundant Entry
Do not ask for the same information twice in one process, such as shipping and billing addresses, without offering to fill it in.
-
3.3.8 Accessible Authentication (Minimum)
Sign-in must not depend on a cognitive test, such as remembering a password without paste support or solving a puzzle.
Where WordPress Sites Usually Fail WCAG 2.2
These problems come up again and again on WordPress sites, and each one fails WCAG 2.2. The WordPress accessibility checker explains how to fix them in WordPress.
- Page builder markup. Elementor, Divi and WPBakery generate deeply nested, non-semantic divs and often style text to look like a heading without using a real heading tag, so screen readers cannot find the page structure.
- Contact form errors. Contact Form 7 and similar plugins frequently ship with missing field labels or error messages that are not announced to screen readers when a submission fails.
- WooCommerce galleries and carts. Product image galleries and cart interactions commonly trap keyboard focus, blocking anyone who cannot use a mouse from completing a purchase.
- Cookie banners. Consent banners are a common source of keyboard traps, especially when they load after the page and grab focus without a way to close them by keyboard.
- Decorative icons and sliders. Icon fonts and image sliders frequently expose decorative graphics to screen readers as unlabeled content, and carousels often ignore focus and pause controls.
Worried about ADA claims as well? The WordPress ADA compliance checker covers the WordPress risks behind most complaints.
What to Test by Hand on WordPress
Automated testing finds many, but not all, WCAG 2.2 failures. Check these yourself after the scan:
- Tab through each page and check the focused element is never fully covered by sticky content (2.4.11).
- Try every drag interaction with a single click or tap instead (2.5.7).
- Sign in with a password manager and check paste works (3.3.8).
- Rescan after each fix. Continuous monitoring rescans up to 500 URLs per domain daily and keeps a dated record in the Compliance Vault.
Related Guides
WordPress WCAG 2.2 Checker: Frequently Asked Questions
Does my WordPress site need to meet WCAG 2.2?
Few laws require WCAG 2.2 yet, but it is the current standard and meeting it also meets 2.1 and 2.0. EN 301 549 V4.1.1, written for the European Accessibility Act, now uses WCAG 2.2 AA.
What is new in WCAG 2.2 for WordPress sites?
Six Level A and AA criteria: focus not obscured, dragging movements, target size, consistent help, redundant entry and accessible authentication. Target size and focus visibility are the ones scans most often flag.
Can the scan check every WCAG 2.2 criterion on WordPress?
No automated tool can. The scan checks the criteria that can be tested automatically, such as target size, and lists the ones that need a person, such as accessible authentication.
Sources
- W3C: Web Content Accessibility Guidelines (WCAG) 2.2 (opens in a new tab)
- W3C WAI: What is new in WCAG 2.2 (opens in a new tab)
- GOV.UK: Accessibility requirements for public sector websites and apps (opens in a new tab)
This page explains general accessibility patterns for WordPress sites and is not legal advice. AccessBell is not affiliated with WordPress. WordPress and its logo are trademarks of their owners and are used only to identify the platform. See our disclaimer.
