guide
EAA on WordPress: complete compliance checklist
Implementing EAA compliance on WordPress means addressing the platform's specific failure modes (inaccessible third-party themes, page builders (elementor, divi) injecting non-semantic markup) while applying European Accessibility Act success criteria across content, code, and editorial workflow.
EAA in 60 seconds
The European Accessibility Act (Directive (EU) 2019/882) is the EU's prescriptive accessibility law that takes effect 28 June 2025, requiring covered products and services — banking, e-commerce, transport, audiovisual media, ebooks and computer hardware — to meet harmonised accessibility requirements derived from EN 301 549 and WCAG 2.1 AA.
WordPress accessibility — what you are starting with
WordPress core has reasonable accessibility, but the WordPress ecosystem (themes, page builders, plugins) is where most failures originate. Elementor, Divi, and many ThemeForest themes regularly introduce inaccessible widgets.
EAA setup checklist for WordPress
1. Choose an accessibility-ready theme: Filter the WordPress.org theme repository by "accessibility-ready". Avoid most ThemeForest themes without explicit accessibility documentation.
2. Audit your active plugins: Disable plugins one by one; re-test. Common offenders: cookie banners, social-share widgets, popup builders, "page speed" plugins that re-inject markup.
3. Editorial discipline on content: Train editors on heading hierarchy, alt text, link text, table headers. The most common WCAG failures originate in editorial workflow, not code.
4. Integrate continuous scanning: Wire axe-core into a CI scan on every deploy. Pair with quarterly manual audit.
Common EAA failures on WordPress
• Inaccessible third-party themes
• Page builders (Elementor, Divi) injecting non-semantic markup
• Plugins adding inaccessible widgets
• Image lazy-loading without alt fallback
• Inaccessible Gutenberg blocks from third parties
Putting it together
Combine EAA's Level AA requirements with WordPress's native tooling. Bake accessibility into your component library and editorial workflow; instrument axe-core in CI for regression.
FAQ
Frequently asked questions
Cited answers. Sourced. Updated as standards and case law change.
Is WordPress EAA-compliant out of the box?
WordPress core admin and the default themes (Twenty Twenty-Four etc) meet WCAG 2.1 AA. The accessibility coding standards require new core code to be accessible. The risk is in third-party themes and plugins, not core.
What is the easiest path to EAA compliance on WordPress?
Start with the platform's most-accessible default theme (where applicable), audit each installed plugin/extension/module, train content authors on alt text and heading hierarchy, and instrument axe-core in your CI pipeline.
Is WordPress core accessible?
WordPress core admin and the default themes (Twenty Twenty-Four etc) meet WCAG 2.1 AA. The accessibility coding standards require new core code to be accessible. The risk is in third-party themes and plugins, not core.
Are page builders like Elementor and Divi accessible?
They can produce accessible output but commonly do not by default. Elementor has invested in accessibility improvements since 2022; Divi remains the more problematic option. Both require manual auditing of the rendered output.
Does using a WordPress accessibility plugin guarantee compliance?
No. Most "accessibility plugins" are overlay widgets that do not remediate source code. They do not produce WCAG conformance and have been cited in ADA lawsuits as evidence of bad-faith remediation.
Stop guessing. Get the audit a Fortune 500 a11y team would have written.
Free audit on your live URL. No sign-up. IAAP-format report. Ready in hours.
founders@accessivepath.com · +977 9851094056