EAA compliance for WordPress: WCAG 2.1 AA checklist & fixes

What the EAA actually requires from a WordPress site

On WordPress the EAA scope splits between the core platform (which has invested heavily in accessibility and largely passes WCAG 2.1 AA in the block editor and default themes) and the third-party theme plus plugin layer, where coverage varies wildly. EN 301 549 conformance therefore usually comes down to auditing the active theme first, then every plugin that emits front-end markup, since page builders like Elementor and Divi can generate deeply nested div soup with missing landmarks and headings. The requirement is that the rendered public pages, not just core, meet AA with your real theme and plugin stack.

WordPress powers a huge cross-section of EU sites, from one-person blogs that may fall under exemptions to large publishers and retailers exposed to the most serious national penalties. The relevant fine depends entirely on who runs the site: a small local business faces a fixed per-breach fine, while a large media group or retailer on WordPress can be exposed to France's up-to-4%-of-turnover regime. The common thread is that a premium theme or aggressive page builder is usually the source of the failure, so risk tracks the plugin choices more than the platform.

WordPress remediation is done by the site's developer or agency, ideally through a child theme and a must-use plugin so fixes survive updates, rather than editing theme files that get overwritten. Starting from an accessibility-ready theme (Twenty Twenty-Four, Astra, GeneratePress) cuts audit time dramatically; from there you reinforce the lang attribute, add skip links and focus styles, and disable any unused plugin. Expect a few days of work, and always re-audit after activating cookie-consent, chat, or popup plugins since those are the usual regressors.

Top WCAG failures we see on WordPress sites

Across hundreds of WordPress scans, the same handful of issues show up over and over. None of them require ripping the theme apart — most are fixable in a few hours by someone comfortable in the platform's editor or template files.

• Third-party themes overriding focus and color tokens

  Premium themes often ship with brand-aggressive colors and custom CSS that removes default focus outlines.

  1.4.3, 2.4.7 — Level AA
• Page builders generating <div> soup

  Elementor, Divi, and similar builders can produce nested <div>s without semantic roles. Headings and landmarks go missing.

  1.3.1 — Level A
• Cookie consent banners blocking primary content

  Many EU-required CMP banners trap focus or render above the skip link, breaking keyboard navigation.

  2.1.2, 2.4.1 — Level A

Concrete code fixes for WordPress

Below are copy-paste fixes for the most common WordPress issues. They assume you have access to your theme code or the platform's custom-code injection panel. If you cannot edit code directly, share these snippets with whoever maintains the site — every one of them is a ten-minute change.

// Appearance → Themes → search "accessibility-ready"
// Default safe choices: Twenty Twenty-Four, Astra, GeneratePress

add_filter('language_attributes', function ($attrs) {
    return $attrs . ' lang="' . esc_attr(get_locale()) . '"';
});

Tools and plugins worth installing first

• Accessibility Checker plugin — runs on save and flags page-level issues
• WP Accessibility — adds skip links, removes title attributes, fixes labels
• Disable any plugin you do not use; each adds JS that can break interaction patterns

How to scan a WordPress site without missing anything

Automated scanners catch about 30–40% of WCAG issues; the rest need manual review. The good news is that the 30–40% includes the most expensive issues to remediate after the fact, so an automated scan is the cheapest way to get unstuck. Run one before you change a line of theme code.

• Audit before AND after activating cookie consent / chat / popup plugins.
• Crawl /, /blog, a single post, /contact, and the WooCommerce flow if applicable.