guide
WAD on WordPress: complete compliance checklist
Implementing WAD 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 EU Web Accessibility Directive success criteria across content, code, and editorial workflow.
WAD in 60 seconds
The EU Web Accessibility Directive (Directive (EU) 2016/2102) requires public-sector bodies in all EU member states to make their websites and mobile apps accessible per EN 301 549, with mandatory accessibility statements and a complaints mechanism — operative since September 2018 for new sites and September 2020 for all sites.
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.
WAD 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 WAD 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 WAD'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 WAD-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 WAD 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