Over 4,000 ADA lawsuits were filed against websites in 2024 alone, and small and mid-size businesses made up a large share of them, not just big brands. If your WordPress site has never had an accessibility review, this is worth 15 minutes now rather than a settlement letter later. Settlements for these cases commonly run $10,000-25,000 once legal fees and remediation are included — far more than fixing the underlying issues would have cost.
What “ADA compliant” actually means for a WordPress site
The ADA itself doesn’t mention websites — it was written in 1990, before the web existed as we know it. But the U.S. Department of Justice has been clear that websites count as “places of public accommodation” under Title III, and courts have consistently pointed to the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA as the practical standard for what “accessible” means. There’s no official government certification — compliance means your site genuinely meets WCAG 2.1 AA, not that you’ve installed a badge or a widget that claims it does.
Why this matters more in 2026, not less
Two things changed the landscape recently. First, ADA website litigation has kept climbing year over year, and plaintiffs’ firms increasingly target small business sites specifically, since they’re least likely to have already fixed the obvious issues. Second, if you sell to or serve customers in the EU, the European Accessibility Act (EAA) took effect on June 28, 2025 and is now being enforced across member states — accessibility stopped being optional for any site with European customers. If your WordPress store serves European or UK customers, this now sits alongside GDPR as a compliance requirement, not a nice-to-have.
The plugin myth, and why it keeps costing people money
Search “WordPress ADA compliance” and most of what you’ll find is a plugin promising to make your site compliant automatically — usually an overlay widget that adds a floating accessibility icon. Be honest with yourself about what these actually do: they layer a UI on top of your site’s existing code without fixing what’s broken underneath. Several well-known overlay vendors have themselves been named in ADA lawsuits, and courts have not treated an installed overlay as evidence of compliance. If a plugin is doing the real work — rewriting broken heading structure, adding real form labels, fixing color contrast in your theme’s CSS — it’s not a one-click widget, it’s a genuine code fix. There’s no shortcut around that, no matter what the sales page says.
The real WordPress ADA/WCAG compliance checklist
1. Color contrast
Body text needs a contrast ratio of at least 4.5:1 against its background; large text (18pt+, or 14pt+ bold) needs 3:1. This is the single most common failure on WordPress sites, usually from a theme’s light-gray body text or low-contrast button styling. Check every text/background combination your theme uses, not just the homepage.
2. Alt text on every image
Every meaningful image needs descriptive alt text — not the filename, not “image123.jpg”, and not keyword-stuffed marketing copy. Purely decorative images (a background flourish with no informational content) should have empty alt text (alt="") so screen readers skip them instead of reading out noise.
3. Keyboard navigation and visible focus states
Tab through your entire site using only the keyboard — no mouse. Every link, button, and form field needs to be reachable in a logical order, and the current focused element needs a visible outline. Many modern themes strip the default focus outline for aesthetics without replacing it with anything, which fails WCAG 2.4.7 outright.
4. Semantic HTML and heading hierarchy
One H1 per page, then H2s and H3s in actual nested order — never skip from an H2 straight to an H4 just because it looks right visually. Screen reader users navigate by heading structure the way sighted users scan a page visually; a broken hierarchy makes that navigation useless.
5. Accessible forms
Every form field needs a real <label> element associated with it, not just placeholder text that disappears when the user starts typing. Error messages need to be announced to screen readers and describe what’s actually wrong, not just turn the field red.
6. An accessible theme — tested, not assumed
“Accessibility-ready” is a self-applied WordPress.org tag, not an audit result. Test your actual theme with a keyboard and a free screen reader (NVDA on Windows, VoiceOver on Mac) before trusting the label. See our guide on building a custom WordPress theme from scratch if your current theme’s accessibility problems turn out to be structural rather than fixable with CSS.
7. A skip-to-content link
Keyboard and screen reader users shouldn’t have to tab through your entire navigation menu on every single page just to reach the main content. A skip link, hidden until focused, fixes this in a few lines of code.
How to actually test your WordPress site
Automated scanners catch roughly 25-30% of WCAG issues — useful as a starting point, not a finish line. Run your site through WAVE or the axe DevTools browser extension for the automated pass, then do the manual checks a scanner can’t: tab through the site with your mouse unplugged, and try navigating with a screen reader for at least your homepage, a blog post, and your contact form.
When to bring in a developer instead of DIY
Contrast and alt text fixes are genuinely doable yourself in an afternoon. Structural issues — broken heading hierarchy baked into your theme’s templates, a checkout flow that’s not keyboard-navigable, forms built by a page builder that don’t expose proper labels — usually need someone who can edit the theme’s actual code, not just content. This is exactly the kind of work covered under bug fixes & site rescue: if you’ve already had a demand letter or you’d rather fix this before one arrives, that’s where to start.
