Accessibility for WordPress sites.
WordPress powers ~40% of the web and faces a disproportionate share of ADA lawsuits — most from theme/plugin combinations that look fine but fail WCAG. The patterns, audit workflow, and what to avoid.
What goes wrong in WordPress projects.
Theme color schemes that fail WCAG 1.4.3
Most off-the-shelf WordPress themes ship with light gray text on white in widgets, footers, and meta info. Run an audit on a fresh install before customizing.
Page builders generating div soup
Elementor, Divi, WPBakery, and Beaver Builder can output deeply nested divs with role="button" or role="link" on non-semantic elements. Audit the rendered HTML, not the page builder UI.
Sliders/carousels without keyboard controls
WordPress slider plugins (Slider Revolution, Smart Slider, MetaSlider) often ship without keyboard pause/navigation controls. Many are not WCAG-compliant out of the box.
Accessibility overlay plugins
Plugins like accessiBe, UserWay, AudioEye are heavily marketed for WordPress. They do not make a site ADA-compliant — courts and DOJ guidance say so. They can also introduce new accessibility bugs.
Comment forms with placeholder-as-label
Many themes hide the comment-form labels visually and rely on placeholder text — fails WCAG 3.3.2. Always render the label, hide visually if needed (use `screen-reader-text` class).
Gutenberg block accessibility regressions
Custom blocks (especially from third-party plugins) can drop accessibility features that core blocks have. Audit any third-party block in the editor and on the published page.
The WordPress accessibility stack we recommend.
WP Accessibility plugin
Free plugin that adds skip links, removes inaccessible attributes, helps with form labels. Sticking-plaster for theme issues, not a fix for everything.
Accessibility-ready theme tag
WordPress.org's "accessibility-ready" tag (search themes by it). Themes with this tag have been reviewed for accessibility baseline. Twenty Twenty-One, Twenty Twenty-Two, and other default themes qualify.
Equalize Digital Accessibility Checker
Free WordPress plugin that scans posts and pages on save. Surfaces issues in the editor before publish. Good for ongoing content workflows.
axe DevTools browser extension
Run on key WordPress pages during audit. Free; the paid version (axe DevTools Pro) adds IDE integration.
AccessProof (continuous external audit)
Scan your WordPress site from outside. Catches what plugin-level scans miss (post-CDN, post-cache, real visitor view). Better legal evidence than per-post in-editor scans.
Step-by-step for a WordPress accessibility audit.
- 1
Audit the theme baseline
Install a clean copy of your theme. Run AccessProof or axe-core against a sample post, page, archive, and front page. Document baseline issues to file.
- 2
Audit plugins on the homepage
Each active plugin can inject HTML/CSS/JS. Disable plugins one at a time on a staging site and re-scan to identify each plugin's accessibility contribution.
- 3
Audit page builders specifically
For Elementor/Divi/WPBakery sites: audit a representative page built with the builder, not just the default theme. The builder's output is what visitors see.
- 4
Remove accessibility overlays if present
If accessiBe/UserWay/AudioEye is installed, removing them is usually the right call. They do not provide legal defense and can introduce new bugs.
- 5
Schedule continuous scans
Content updates frequently in WordPress (post-launch typing). Schedule weekly or daily scans (AccessProof Starter $29/mo for 5 sites including weekly schedule).
Run a WCAG audit on your WordPress site in 42 seconds.
External scan — no JS injected into your app
WCAG 2.2 + Section 508 + EN 301 549 in one pass
Court-ready PDF with element selectors
CI/CD gate — block deploys on regression
Works with WordPress on any hosting (Vercel, Netlify, Fly, self-hosted)
Free plan — 1 site, monthly scan
WordPress-specific questions.
Will an accessibility plugin make my WordPress site ADA-compliant?
No, and the major overlay plugins (accessiBe, UserWay, AudioEye) face active US lawsuits and explicit DOJ guidance that they are not sufficient. WP Accessibility and Equalize Digital are legitimate tools that help — but they do not replace fixing the underlying theme/plugin issues.
Which WordPress themes are accessible?
The "accessibility-ready" tag on WordPress.org is a reasonable starting filter. Twenty Twenty-One, Twenty Twenty-Two, Twenty Twenty-Three, and Twenty Twenty-Four ship with strong baselines. Astra and GeneratePress have accessibility-focused configurations available. Page builder themes (Avada, Bridge, etc.) typically require more remediation work.
How do I make Elementor/Divi sites accessible?
Audit the rendered HTML, not the builder UI. Common issues: skip default heading hierarchy in favor of custom styling (fix the headings), button widgets that render `<a>` without `href` (use proper buttons), animated sections without prefers-reduced-motion (add a CSS override). Some agencies pair the builder with custom CSS to fix systemic issues; others migrate accessibility-critical pages to block themes.
Do I need to make my admin dashboard accessible?
For most public-facing sites, ADA Title III applies to the visitor-facing content. Admin accessibility matters if you have content editors with disabilities or you serve admin-area features to logged-in users. WordPress core admin has strong baseline accessibility; many plugins' admin UIs do not.