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

In June 2025, the digital landscape changed forever. The European Accessibility Act (EAA) came into full enforcement, making web accessibility a legal requirement for almost all digital businesses operating in the EU.

It’s no longer just “nice to have.” It’s akin to GDPR. Non-compliance risks significant fines and lawsuits.

For WordPress developers and site owners, the standard is WCAG 2.2 Level AA. This guide (2000+ words) breaks down exactly what changed in 2026 and how to ensure your theme isn’t breaking the law.

1. The eaa: Why 2025 was the turning point

Previously, accessibility laws mostly applied to the Public Sector (Government/Uni). The EAA expanded this to E-commerce, Banking, Transport, and eBooks.

• Scope: If you sell a t-shirt to a customer in France, your checkout flow must be accessible.
• The Penalty: Fines vary by country, but they can be severe, coupled with the reputational damage of excluding 15% of the global population.

2. WCAG 2.2: The new criteria explained

WCAG 2.2 built upon 2.1, adding 9 new criteria. The most critical for WordPress themes are:

2.4.11 focus not obscured (minimum) (aa)

• The Problem: You tab down a page. An item gets focus, but your “Sticky Header” or “Cookie Banner” covers it up. The user knows they are somewhere, but can’t see where.
• The Fix: Use CSS scroll-padding-top on the html element to ensure focused items scroll into the visible area below your sticky header.

2.5.8 target size (minimum) (aa)

• The Rule: Interactive targets (buttons) must be at least 24x24 CSS pixels.
• The Reality: Those tiny “X” close buttons on your popups? They are illegal. Make them bigger. Finger taps are imprecise.

3.3.8 accessible authentication (aa)

• The Rule: Don’t force users to solve puzzles (CAPTCHAs) or memorize passwords without help.
• The WordPress Impact: Support password managers (don’t block pasting into password fields) and use “Magic Links” or WebAuthn (Biometrics) where possible.

3. Semantic HTML: The foundation

90% of accessibility issues are solved by writing correct HTML.

• Landmarks: Use <main>, <nav>, <aside>, <footer>. Screen reader users jump between these regions. Don’t drown everything in <div> soup.
• Headings: h1 through h6 is a hierarchy, not a style choice. Do not skip from h2 to h4 just because you want a smaller font. Use CSS for sizing.
• Buttons vs. Links:
  • Goes to a new URL? Use <a>.
  • Changes something on the current page (opens a menu)? Use <button>.
  • Never use <div onClick="...">. It is invisible to keyboards.

4. The “overlay” trap

You’ve seen them. The little “man in circle” icon in the corner that opens a menu to change contrast or font size. Avoid them.

• False Security: They claim to make you compliant instantly with one line of JS. They don’t. They can’t fix semantic HTML errors.
• User Friction: Blind users already have screen readers. They don’t need your overlay interfering with their tools.
• Legal Risk: In the US, companies using overlays have been sued more often because it proves they knew they had a problem but chose a “band-aid” solution.

5. Testing: Automated vs. Manual

You cannot automate accessibility 100%.

The testing workflow

1. Automated (30%): Use axe-core or the Lighthouse “Accessibility” audit. This catches missing alt text and low contrast.
2. Manual Keyboard (50%): Unplug your mouse. Can you navigate the entire menu, open the submenus, and fill out the contact form using only the Tab, Enter, and Space keys? If not, you fail.
3. Screen Reader (20%): Turn on VoiceOver (Mac) or NVDA (Windows). Close your eyes. Can you understand what’s happening?

6. Accessible forms IN WordPress

Contact Form 7 and Gravity Forms are popular, but often misconfigured.

• Labels: Every input needs a <label>. Placeholders are NOT labels (they disappear when you type).
• Error Messages: “Error found” is useless. “Email address is missing the @ symbol” is accessible.
• Focus Management: When a user submits a form and there is an error, programmatically move the keyboard focus to the first error field so they can fix it immediately.

7. Conclusion

Accessibility is often framed as a constraint. In reality, it’s a quality indicator. Accessible code is cleaner, more robust, and better for SEO. In 2026, building an inclusive web isn’t just the law—it’s the only professional way to work.

Need an Accessibility Audit? WPPoland provides WCAG 2.2 remediation services for enterprise.