Accessibility (WCAG 2.2) in 2026: Is your WordPress site legal?

WCAG 2.2 Level AA is the practical bar most WordPress teams aim for when they need a shared checklist for keyboard use, focus visibility, and form usability. In the EU, the European Accessibility Act (EAA) also raised the stakes for many consumer-facing digital products and services. This piece is a developer walkthrough of the WCAG 2.2 criteria that break WordPress themes most often, how Gutenberg and block themes help or hurt, and how to test without treating the article as legal advice.

Official references: the WCAG 2.2 Recommendation and the WordPress accessibility handbook.

#EAA context for WordPress teams (not legal advice)

The EAA is EU product legislation. Member states implement and enforce it. It covers defined categories of products and services (for example many e-commerce and banking digital interfaces), not “every website on the internet” by slogan.

What that means for a WordPress project in practice:

• Treat WCAG 2.1 or 2.2 Level AA as the technical language procurement and auditors usually speak.
• Map your offering (store, booking, media, SaaS marketing site with login) against your counsel’s EAA scope analysis for the markets you sell into.
• Document what you tested (templates, assistive tech, date). Audits age; lastVerified on this article is 2026-09-20 for editorial freshness, not a certificate of compliance.

Do not use this guide as a substitute for jurisdiction-specific legal review. Obligations, exemptions, and penalties vary by country and product type.

#WCAG 2.2: what changed for themes and blocks

WCAG 2.2 builds on 2.1. Several new or tightened criteria hit sticky headers, icon buttons, login flows, and dense admin-like UIs that WordPress themes often ship.

#Focus not obscured (minimum) - 2.4.11 (AA)

When a user tabs, the focused control must not be hidden under sticky headers, footers, or cookie banners. A focus ring that exists but sits under chrome still fails.

Typical WordPress failure: a fixed header at z-index above content, or a consent bar that covers the first focused link after skip-to-content.

Practical fixes:

• Prefer scroll-padding-top (and bottom when needed) on html equal to sticky chrome height so focused elements scroll into the clear area.
• Keep cookie UIs in the tab order with a visible dismiss control; do not trap focus without an Escape path.
• Avoid overflow: hidden on ancestors that clip the focused outline.

#Focus appearance (minimum) - 2.4.13 (AAA in 2.2, still worth shipping)

Many teams still strip outline for aesthetics and never replace it. Even when 2.4.13 is AAA, Focus Visible (2.4.7) remains AA. Ship a high-contrast :focus-visible style that is not the same colour as the background and has enough area to notice.

In block themes, put focus styles in theme.json or a small stylesheet that survives editor and front-end. Do not rely on browser default alone if your CSS resets it.

#Target size (minimum) - 2.5.8 (AA)

Pointer targets need at least 24 by 24 CSS pixels, with documented exceptions (for example inline links in a sentence, or targets with enough spacing). Tiny “X” icons on modals, pagination chevrons, and social icon rows often fail.

Fix with padding, min-width / min-height, or wrapping the icon in a larger hit area without changing the visual size of the glyph if design requires it.

#Accessible authentication (minimum) - 3.3.8 (AA)

Do not force cognitive function tests (puzzles, obscure CAPTCHAs) as the only path. Allow paste into password fields so password managers work. Prefer email magic links, WebAuthn / passkeys, or copy-paste of one-time codes where the product allows.

On WordPress logins and membership plugins, audit any “disable paste” scripts and third-party bot walls. If you must use a challenge, offer an accessible alternative path.

#Dragging movements - 2.5.7 (AA)

Anything that requires drag (sortable menus, slider handles, Kanban-style builders) needs a single-pointer alternative such as buttons or form controls. Gutenberg itself exposes alternatives for many interactions; custom blocks that only listen to drag events need the same treatment on the front end.

#Semantic HTML remains the foundation

Most durable fixes are boring HTML:

• Landmarks: one main, clear nav, header, footer. Screen reader users jump by region.
• Heading levels follow outline, not font size. Style with CSS; do not skip from h2 to h4 for looks.
• Links go somewhere; buttons change state on the page. Never use a div with a click handler as the only control.
• Images that convey meaning get alt; decorative images get empty alt.

ARIA is a supplement when native HTML cannot express the pattern. Prefer a real <button> over role="button" on a span.

#Gutenberg and the block editor

Core blocks and the block editor have improved keyboard support and structure over several releases. That does not make every published page accessible.

Patterns that still fail in the wild:

• Group and Cover blocks with low-contrast text over busy media. Check contrast after theme colour palettes apply.
• Navigation block with mega-menus that open on hover only. Provide click / Enter activation and Escape to close.
• Custom blocks that render interactive widgets without focusable elements or with incorrect aria-expanded on toggles.
• Patterns from marketplaces that nest headings incorrectly or duplicate h1.

Editor checklist for authors:

1. Use the List View to verify heading order before publish.
2. Prefer native Image / Gallery blocks so alt fields remain editable.
3. Avoid stacking multiple sticky template parts that compete for vertical space.

For theme developers: register block styles that preserve focus outlines; document any required wrapper markup in block.json supports. Test both the Site Editor canvas and the front-end output - they are not always identical.

#Themes: classic, hybrid, and block themes

Classic PHP themes fail when templates hard-code inaccessible menus or remove focus styles in style.css. Hybrid setups (classic theme plus block template parts) need the same sticky and focus checks on both PHP and HTML templates.

Block themes (theme.json, template parts) centralise colour and typography, which helps contrast if the palette is designed with AA ratios. They also make it easy to ship a global sticky header that violates Focus Not Obscured on every page - fix once in the header template part.

WooCommerce and form plugins sit on top of the theme. Checkout, account, and contact templates deserve their own keyboard pass: label association, error text that names the field, and focus moved to the first error after failed submit.

#Skip the overlay widget

Accessibility overlays and “one-line fix” widgets do not rewrite your DOM into semantic HTML. They often conflict with real assistive technology. Courts and advocates have repeatedly treated overlays as insufficient when the underlying markup stays broken. Remediate theme and content instead.

#Testing workflow that fits WordPress releases

Automated tools (axe, WAVE, Lighthouse accessibility category) are the first pass, not the last. They miss most keyboard traps and many focus-obscured cases.

Suggested order on each major template:

1. Automated scan on home, archive, single post, search, form, and checkout if present.
2. Keyboard only: Tab through the header, open every submenu, submit a form with an intentional error, dismiss modals with Escape.
3. Screen reader spot-check with NVDA (Windows) or VoiceOver (macOS / iOS) on the same critical path.

Re-test after theme updates, plugin updates that change markup, and Site Editor template edits. Accessibility regressions often arrive with a “harmless” CSS commit that sets outline: none.

#Accessible forms on WordPress

Contact Form 7, Gravity Forms, Fluent Forms, and custom wp_mail UIs share the same rules:

• Visible <label> (or correctly associated aria-labelledby), not placeholder-as-label alone.
• Error messages that say what failed and how to fix it.
• After submit with errors, move focus to the first invalid field or to a summary that links to fields.
• Do not disable paste on password or OTP fields.

#Putting it together

Ship focus styles, respect 24px targets, keep focused controls out from under sticky UI, and keep authentication paste-friendly. Use Gutenberg’s native blocks where they already expose accessible patterns, and treat custom blocks as first-class UI that needs keyboard and screen reader tests.

If you need a WordPress developer to remediate theme templates, block markup, or a WooCommerce checkout path against WCAG 2.2 AA, start from a documented audit of the templates you actually ship - not from an overlay install.