Skip to main content
ADA Fail

Is WordPress ADA Compliant? The Truth About Themes and Plugins

Is WordPress ADA compliant? No platform is compliant on its own. Here is how themes, plugins, and your own content decide whether your site is accessible.

← Back to Blog
6 min read · by ADA Fail Team
Is WordPress ADA Compliant? The Truth About Themes and Plugins

No. WordPress does not make your site ADA compliant, and no website platform can. WordPress is a content-management tool: accessibility depends on the theme you choose, the plugins you install, and the content you publish on top of it. You can build a fully accessible site on WordPress, and you can just as easily build one that draws a demand letter next month. The platform is neutral; the choices are yours.

That answer matters because "is WordPress ADA compliant" is one of the most common questions business owners ask, usually right after a competitor gets sued. The honest version is that WordPress powers a huge share of the web, including plenty of accessible sites and plenty of inaccessible ones. What follows is where the real risk lives and what to do about it.

Why can't any platform be "ADA compliant" out of the box?

Accessibility is measured against WCAG — the Web Content Accessibility Guidelines — and the benchmark courts and settlements reference is WCAG 2.2 Level AA. Those success criteria apply to the actual pages a visitor experiences: the color contrast of your text, whether your images have alt text, whether your forms have labels, whether someone can navigate with only a keyboard.

A platform ships none of that pre-filled. WordPress gives you an empty framework. The moment you pick a theme, add a page builder, embed a video, or paste in copy, you are the one determining whether the result meets Level AA. That is why "our platform is compliant" is a meaningless claim from any vendor — the compliance is decided by what gets rendered, not by the engine underneath.

The scale of the problem is documented. WebAIM's 2025 analysis of the top one million homepages found detectable WCAG failures on 94.8% of them, with the same culprits over and over: low-contrast text, missing image alt text, missing form labels, and empty links or buttons. Every one of those is something a WordPress site owner controls directly.

Where do WordPress themes create accessibility problems?

The theme is the single biggest lever. It defines your color palette, your typography, your heading structure, your buttons, and your focus styles — the visual and structural skeleton every page inherits.

Contrast and color come from the theme's design

Many popular themes ship with light-gray body text or pale button colors that look modern and fail contrast requirements. WCAG asks for a 4.5:1 contrast ratio for normal text and 3:1 for large text. A theme's default palette can put you below that line on every page at once. Our guide to color contrast requirements covers how to check yours.

Look for themes that advertise accessibility-readiness

The WordPress theme directory tags some themes "accessibility-ready," meaning they have passed a baseline review for things like keyboard navigation and heading order. That tag is a helpful starting filter, not a guarantee — it does not account for the content you add or the plugins you layer on. Treat it as a lower floor, not a finished ceiling.

Do plugins and page builders make WordPress less accessible?

They can, and page builders are the usual offenders. Drag-and-drop builders like Elementor, Divi, and WPBakery generate a lot of markup to achieve their visual flexibility, and that markup frequently includes broken heading order, unlabeled interactive elements, sliders that trap keyboard focus, and accordions that screen readers cannot operate.

None of that makes page builders forbidden — accessible sites use them every day. It means the output needs testing, because the convenience of dragging a widget into place hides whether that widget is operable without a mouse. The more plugins render interactive content — carousels, pop-ups, booking forms, mega-menus — the more surface area you have to check.

Forms deserve special attention. Contact and booking forms are a top source of violations because fields ship without proper labels, and error messages are not announced to assistive technology. If you run any lead form, read our breakdown of common accessible-form mistakes before you assume it passes.

What about accessibility plugins and overlays?

Here is where WordPress site owners get sold a false shortcut. A whole category of plugins promises to make your site "ADA compliant" automatically with a single script — the overlay. It does not work, and installing one can raise your risk rather than lower it.

In January 2025 the FTC announced a $1 million action against accessiBe (final order approved April 2025) over deceptive claims that its widget could make any website WCAG-compliant. The National Federation of the Blind formally opposes these products as "not only ineffective but harmful." WebAIM found sites running overlays averaged roughly as many detectable errors as sites without them, and UsableNet repeatedly finds that hundreds of companies sued each year already had a widget installed when the lawsuit landed.

Draw a clear line here. A preference widget — a small button that lets visitors adjust contrast or text size on a site that is already accessible in its code, making no compliance claim — is fine. ADA Fail runs one. A compliance overlay — a third-party script sold as making a broken site compliant — is the thing regulators are fining. We explain the difference in detail in widget versus overlay. The overlay does not remediate your code; it papers over it.

How do you actually make a WordPress site accessible?

Fix the source, not the surface. That means real changes to the theme, the templates, and the content.

  • Audit against WCAG 2.2 AA. Automated scanners catch only about a third of the success criteria — the rest, including keyboard traps and screen-reader behavior, require human testing. A scan is a starting point, not a verdict.
  • Pick or fix the theme first. Correct contrast, focus styles, and heading order at the template level so every page inherits the fix.
  • Test the interactive plugins. Run each form, menu, slider, and pop-up with the keyboard alone and with a screen reader.
  • Repair your content. Add alt text to images, caption your videos, and keep a logical heading structure in every post.

If you want to know where you actually stand today, start with a free accessibility audit — it shows the specific violations on your live theme and content, not a generic checklist. From there, remediation is code-level work, and our compliance checklist walks through the priorities in order.

The stakes are not hypothetical. More than 5,000 digital-accessibility lawsuits were filed in 2025, up roughly 20% over the prior year, and most cases settle for between $10,000 and $75,000 plus a commitment to fix the site. Building accessibly on WordPress from the start is far cheaper than either outcome.

Frequently asked questions

Is a WordPress.com site more accessible than a self-hosted WordPress.org site?

Not inherently. Both run the same core software, and both leave accessibility to the theme, plugins, and content you choose. WordPress.com managed plans limit some plugin flexibility, which can reduce the number of risky third-party scripts, but neither version delivers accessibility automatically. The determining factor is the same in both: what actually renders on the page.

Will switching WordPress themes fix my accessibility problems?

A better theme fixes theme-level issues — contrast, focus styles, and heading structure that every page inherits — so it is often the highest-leverage single change. It will not fix content-level problems like missing alt text, uncaptioned video, or a booking plugin that traps keyboard focus. Think of a good theme as clearing the biggest, most repeatable failures, after which content and plugin testing still has to happen.

Does WordPress being open-source affect my legal liability?

No. Under ADA Title III, the business that owns and operates the website is responsible for its accessibility, regardless of the software it runs on. There is no formal federal regulation naming a web standard, but the DOJ's position and most courts treat business websites as covered, and WCAG is the de facto benchmark. The platform being free and open-source does not shift that responsibility to anyone else — the liability follows the business.

Want to know exactly which theme, plugin, and content issues put your WordPress site at risk? Request a free accessibility audit and get a specific, plain-English list of what is failing on your live site and what it takes to fix it.

Share this article
Next Step

Find out where your site stands
ADA Fail

Get a free WCAG 2.2 audit — no widgets, no snake oil, just a real report you can hand to any developer.

Disclaimer

The information on this site is provided for general educational purposes and does not constitute legal advice. WCAG and ADA conformance depend on your specific website, content, and jurisdiction, and no audit or service can guarantee immunity from litigation. Reading this site does not create an attorney–client or consultant relationship. For advice about your legal obligations, consult a qualified attorney. Request a free audit.