guide
WCAG 2.1 on WordPress: complete compliance checklist
Implementing WCAG 2.1 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 Web Content Accessibility Guidelines 2.1 success criteria across content, code, and editorial workflow.
WCAG 2.1 in 60 seconds
WCAG 2.1 is the World Wide Web Consortium's accessibility standard published June 2018, adding 17 success criteria to WCAG 2.0 — primarily addressing mobile, low vision, and cognitive disabilities — and currently referenced as the conformance baseline by the European Accessibility Act and most procurement frameworks.
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.
WCAG 2.1 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 WCAG 2.1 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 WCAG 2.1's 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 WCAG-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 WCAG 2.1 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