Wooden Scrabble tiles spelling out 'COMPLIANCE' on a rustic wood surface, surrounded by scattered letter tiles
Suyog Goraksh - WordPress Developer

Meet the Author:

Suyog is a seasoned Webmaster with over 15 years of experience in web design and development. As the founder of WebAdroit, Suyog is committed to delivering top-notch quality and perfection in every project undertaken. With expertise in WordPress customization, e-commerce integration, DotNetNuke, and more, Suyog brings a comprehensive skill set to enhance clients' online presence. Passionate about creating exceptional client experiences, Suyog strives to exceed expectations and deliver outstanding results.

More than 5,000 digital accessibility lawsuits were filed in 2025 alone, and a lot of the businesses on the receiving end had no idea their website was a target until the demand letter showed up. So here’s the question worth asking honestly: is yours one of them waiting to happen? I’ve started getting this question from clients too — not because they got sued, but because someone forwarded them a scary headline and asked, “Wait, is my site okay?”

The honest answer, for most WordPress sites I audit, is: not really. Not because anyone did anything wrong on purpose — accessibility just isn’t something themes and page builders handle for you by default, no matter what the marketing copy says.

This Isn’t Just an Amazon-Sized-Company Problem

The numbers get thrown around like this only hits huge retailers, but that’s not what the data shows. Only about 36% of companies sued over web accessibility in 2025 had revenue over $25 million — meaning the majority didn’t. E-commerce sites account for roughly 70% of filings, food service another 21%, and once a company has been sued once, the risk of a repeat claim jumps sharply: 45% of federal accessibility lawsuits in 2025 targeted businesses that had already faced a claim before.

New York and California together account for close to 2,000 of these cases, but Florida, Pennsylvania, Minnesota, and Missouri have all seen rising filing activity too. This isn’t a two-state problem anymore, and it isn’t a “we’re too small to notice” problem either.

What “Accessible” Actually Means on a WordPress Site

This is the part that surprises people: it’s rarely one big glaring issue. It’s usually a handful of small, fixable things that add up.

Alt text that actually describes the image

Not “image123.jpg,” and not keyword-stuffed SEO text either — a real, concise description of what’s in the image, written for someone using a screen reader. I run this check on every image I add to a client site now, including the featured images on blog posts.

Color contrast between text and background

WCAG AA requires a contrast ratio of at least 4.5:1 for normal text (3:1 for large text). This is the one I see fail most often on designed pages — light gray text on white backgrounds, or text laid over photos without a proper overlay. It’s a quick fix once you know to check for it, and tools like WebAIM’s contrast checker make it a five-second lookup.

Keyboard-only navigation

Try tabbing through your own site without touching the mouse. If you lose track of where the focus is, or can’t reach the menu or a form, so will anyone using assistive tech. Skip links and visible focus states fix most of this.

Forms with actual labels

This is a common one with Contact Form 7 and similar plugins — placeholder text is not a label. A screen reader needs a real <label> tied to each field, not just gray placeholder copy that disappears the moment someone starts typing.

Real heading structure

One H1 per page, headings nested in order (H2s under the H1, H3s under relevant H2s), and no using a paragraph block styled to “look like” a heading. Page builders like Elementor make it easy to skip this because everything is visual — but screen readers and search engines both read the actual heading hierarchy, not the font size.

The “Accessibility Ready” Theme Tag Doesn’t Mean What You Think

WordPress.org has an “Accessibility Ready” tag for themes, and it’s a reasonable starting signal — but it isn’t a guarantee. I’ve audited “accessibility ready” themes that still failed on contrast or keyboard navigation once real content and custom CSS got added. The tag tells you the theme’s default setup passed a review. It says nothing about what happens after you and your page builder get involved.

Fixing It After a Demand Letter Costs More Than Building It Right

Here’s the part that doesn’t get said enough: accessibility work is almost always cheaper before a lawsuit than after one. Once a demand letter lands, you’re not just paying a developer to fix the site anymore — you’re paying for legal review, often a settlement negotiation, and sometimes an outside audit just to document that you’ve actually fixed things. That’s on top of the development work you’d have needed to do anyway. I’ve seen the same pattern play out with security: the cost of prevention is never close to the cost of cleanup after something’s already gone wrong.

Where I’d Start, If I Were You

You don’t need to fix everything this week. Here’s the order I actually work through on client sites:

1. Run a free automated scan first. WAVE (from WebAIM) catches the obvious stuff — missing alt text, contrast failures, empty links — in under a minute.

2. Fix contrast and alt text sitewide. These are usually the highest-volume, lowest-effort fixes, and they’re exactly what shows up first in most legal complaints.

3. Tab through your own site. No mouse. If you get stuck, so will a keyboard-only visitor.

4. Check every form. Labels, error messages, and required-field indicators all need to be readable by a screen reader, not just visible on screen.

5. Re-test after every theme or plugin update. Accessibility isn’t a one-time fix — an update to your page builder or a new plugin can quietly undo work you already did. I covered a related version of this “set it and forget it” trap in my plugin security checklist post — the same discipline of routine checks applies here.

You can review the full standard yourself at the W3C’s official WCAG 2.1 quick reference if you want to go deeper than a checklist.

The Takeaway

Nobody builds an inaccessible website on purpose. It happens by default, one unlabeled form field and one low-contrast heading at a time, because most themes and builders don’t stop you from doing it. The fix isn’t dramatic, and it overlaps with a lot of the same site hygiene I’ve written about before — it’s just that this piece carries real legal exposure if it’s ignored long enough, on top of quietly shutting out real visitors who can’t use your site the way it’s currently built.

If you want a second set of eyes on where your WordPress site actually stands on accessibility, get in touch and I’ll run through it with you.

Photo by Markus Winkler on Unsplash

Share This Story!

Leave A Comment

Leave A Comment

About Author: Suyog is a seasoned Webmaster with over 15 years of experience in web design and development. As the founder of WebAdroit, Suyog is committed to delivering top-notch quality and perfection in every project undertaken. With expertise in WordPress customization, e-commerce integration, DotNetNuke, and more, Suyog brings a comprehensive skill set to enhance clients' online presence. Passionate about creating exceptional client experiences, Suyog strives to exceed expectations and deliver outstanding results.