The key takeaway: WCAG 2.2 AA is the technical standard most EU accessibility law points to, and it comes down to four principles — perceivable, operable, understandable, robust — but in practice, most WordPress sites fail on a small, repeatable set of issues: color contrast, missing alt text, keyboard navigation gaps, and broken heading hierarchy.
Why This Matters Now, Not Eventually
The European Accessibility Act (Directive (EU) 2019/882) has applied since June 28, 2025, requiring specific categories of products and services sold to EU consumers — e-commerce, banking, e-books, transport services, and telecommunications among them — to meet accessibility requirements. It isn't a future deadline anymore; it's already active law in EU member states.
The Act references WCAG 2.2 at the AA conformance level as the practical technical standard most organizations use to demonstrate compliance, even where the EAA itself is written in broader legal language. That makes WCAG 2.2 AA the concrete target worth building toward, regardless of whether a specific site falls under the EAA's exact scope.
What WCAG 2.2 AA Actually Requires
WCAG organizes its requirements around four principles, commonly abbreviated POUR:
- Perceivable — content must be presentable in ways users can perceive, covering things like alt text for images and sufficient color contrast for text.
- Operable — interface components must be usable via keyboard alone, not just a mouse, and users need enough time to read and interact with content.
- Understandable — content and interface behavior need to be predictable and readable, including clear form labels and consistent navigation.
- Robust — content must work reliably across assistive technologies like screen readers, which depends heavily on clean, semantic HTML and correct ARIA usage.
WCAG 2.2 added nine new success criteria on top of 2.1, several targeting mobile and cognitive accessibility specifically — a minimum target size for clickable elements, consistent placement of help mechanisms across pages, and clearer visible focus indicators for keyboard users.
The Most Common WordPress Accessibility Failures
We ran a full axe-core plus Playwright accessibility audit across this site — 14 pages in both dark and light mode — and it's a useful real-world sample of exactly where WordPress sites tend to fail, since the issues found were entirely typical rather than site-specific.
- Color contrast on decorative elements. Category tags and colored badges used raw brand hex colors directly as text color on tinted backgrounds, clearing only about 3.3-4.0:1 — under the 4.5:1 minimum for normal text at AA. The fix was defining separate, purpose-built "text-safe" color tokens rather than reusing brand colors directly as text.
- Heading hierarchy skips. A listing page jumped from an H1 directly to H3 sections with no H2 in between, which is invisible visually but breaks the logical document outline screen reader users rely on to navigate.
- Links distinguished by color alone. Inline links in longer text blocks were colored differently from surrounding text but not underlined, failing the requirement that link-vs-text distinction not depend on color perception alone.
- Missing ARIA attributes on custom interactive components. A custom FAQ accordion had no aria-expanded, aria-controls, or role="region" — functional for a mouse user, but ambiguous for a screen reader user with no signal about the accordion's state.
None of these were caught by simply glancing at the page — they surfaced through combined automated scanning and manual review, which is the pattern worth replicating on any WordPress site.
A Practical Audit Process
| Step | Tool/Method | Catches |
|---|---|---|
| Automated scan | axe-core or WAVE browser extension | Missing alt text, contrast failures, missing form labels |
| Keyboard-only pass | Tab through the entire page without a mouse | Broken focus order, unreachable interactive elements |
| Screen reader spot-check | VoiceOver (Mac) or NVDA (Windows) | Ambiguous ARIA, confusing heading structure |
| Manual contrast check | Browser dev tools or a contrast checker | Contrast issues in states automated tools miss (hover, focus) |
| Both color modes | Repeat all of the above in dark and light mode | Contrast regressions that only appear in one theme |
Common WordPress-Specific Trouble Spots
- Theme and page builder defaults often ship with contrast or heading structure issues baked into templates, which then repeat across every page using that template.
- Plugin-added widgets (sliders, accordions, tabs) frequently lack proper ARIA attributes, since not every plugin author tests with assistive technology.
- Uploaded images without alt text are one of the single most common and easiest-to-fix violations — bulk-checking a media library for missing alt text catches years of accumulated gaps at once. Erdo Image Optimizer includes a built-in audit that flags images missing alt text across an entire media library, alongside the file-size optimization we cover in our image SEO guide.
- Cookie consent banners and modals are commonly missed in keyboard-focus testing, since they're added after the main page loads and easily fall outside a site's regular tab order.
Accessibility Is Maintenance, Not a One-Time Project
A WCAG audit fixes what exists at the moment it's run; every new blog post, every new plugin, and every template change is a fresh opportunity to reintroduce an issue that audit already closed. Treating accessibility checks as part of the regular publishing and development workflow — not a project that gets marked done once — is what keeps a site compliant six months later instead of only on launch day.
Common Mistakes
- Relying on an automated scanner alone, missing the manual keyboard and screen reader issues no scanner can judge.
- Fixing contrast in light mode only, when a site with a dark mode toggle needs both checked independently.
- Assuming a popular theme or page builder is accessible by default, when template-level contrast and heading issues repeat across every page built from it.
- Treating an accessibility audit as a one-time task rather than an ongoing check applied to new content and features as they ship.
- Skipping alt text on new image uploads even after a bulk audit fixed the existing backlog, letting the gap quietly reaccumulate.
Wrapping Up
In short, WCAG 2.2 AA compliance for a WordPress site comes down to a short, repeatable list of real-world failure points — color contrast, missing alt text, keyboard navigation, heading structure, and ARIA usage on custom components — caught reliably only through a combination of automated scanning and manual testing, and maintained through ongoing habit rather than a single audit. With the EU Accessibility Act now in force rather than pending, treating this as routine maintenance rather than a future to-do is the difference between a compliant site and a liability.