ADA Compliance for WordPress: A Complete Guide

WordPress powers over 40% of all websites. That's an incredible number, and it means millions of WordPress sites are used every day by people with disabilities. If your site isn't accessible, you're locking out roughly 15% of the global population, and you could be exposing yourself to an ADA lawsuit.

I've scanned thousands of WordPress sites with our free accessibility scanner, and the same problems come up again and again. Bad themes, form plugins with no labels, missing alt text, page builders that spit out inaccessible HTML. The good news? Most of these issues are fixable without touching code.

This guide walks you through everything: why accessibility matters for WordPress, what goes wrong most often, how to pick the right theme and plugins, and a quick-wins checklist you can work through this afternoon.

Why WordPress Sites Need Accessibility

Let's start with the numbers. About 1.3 billion people worldwide have a significant disability. That's 16% of the global population. Many of them use assistive technologies like screen readers, switch devices, or voice control to browse the web. When your WordPress site has accessibility barriers, these users can't read your content, buy your products, or fill out your contact form.

Then there's the legal side. ADA website lawsuits have been climbing steadily since 2018, and WordPress sites are frequent targets. Courts have consistently ruled that websites qualify as "places of public accommodation" under the ADA. Small businesses, e-commerce stores, restaurants, professional services: nobody is exempt.

But accessibility isn't just about avoiding lawsuits. It's also good for SEO. Google's ranking algorithms favor sites with proper heading structure, descriptive alt text, good color contrast, and semantic HTML. The things that make a site accessible are largely the same things that help search engines understand your content. If you want to learn more about the standard itself, check out our guide on what WCAG is and how it works.

And there's a practical business case too. Accessible sites tend to have lower bounce rates, longer session times, and higher conversion rates. Curb-cut effect: making your site easier for people with disabilities makes it easier for everyone.

Common WordPress Accessibility Issues

Here's what I see most often when scanning WordPress sites. These are the issues that show up in nearly every report.

Themes with Poor Color Contrast

This is the number one issue. Many popular WordPress themes use light gray text on white backgrounds, or put text over busy hero images without enough contrast. WCAG 2.2 AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. A surprising number of premium themes fail this test right out of the box.

The worst part is that theme demos often look fine to sighted users, so you don't realize there's a problem until a screen reader user or a lawsuit notification tells you.

Missing Alt Text on Media

WordPress makes it easy to upload images. It does not make it easy to remember alt text. The media library has an alt text field, but it's optional, and most users skip it. Every image that conveys information needs descriptive alt text. Decorative images need an empty alt="" attribute so screen readers skip them. For a detailed guide on writing good alt text, see our alt text writing guide.

Form Plugins Without Labels

Contact forms are one of the most common accessibility failures. Many form plugins use placeholder text instead of proper <label> elements. Placeholders disappear when you start typing, leaving users (especially those with cognitive disabilities) with no indication of what the field is for. Screen readers may not announce placeholder text at all.

Page Builders Generating Inaccessible HTML

Page builders like Elementor, Divi, and WPBakery can produce messy HTML with deeply nested <div> elements, missing heading hierarchy, and interactive elements that aren't keyboard accessible. A section that looks like a button might actually be a styled <div> with a click handler, which means keyboard users and screen reader users can't interact with it.

For a broader look at the issues that come up repeatedly across all types of sites, read our common accessibility mistakes guide.

Choosing an Accessible Theme

Your theme is the foundation. If it's inaccessible, you'll be fighting an uphill battle with every page you build. Here's what to look for when choosing a theme.

Semantic HTML

The theme should use proper HTML5 elements: <header>, <nav>, <main>, <footer>, <article>, <section>. These give screen readers a structural map of the page. If you inspect the theme's demo and it's all <div> elements, walk away.

Keyboard Navigation

Tab through the theme's demo without using a mouse. Can you reach every link, button, and form field? Can you see where the focus is (a visible outline or highlight)? Can you open and close the mobile menu with the keyboard? If any of these fail, the theme isn't accessible.

Skip Links

An accessible theme includes a "Skip to content" link that appears when you press Tab on page load. This lets keyboard users jump past the navigation and go straight to the content. It should be visually hidden until focused.

ARIA Landmarks

The theme should use ARIA landmarks or native HTML5 sectioning elements so screen readers can announce the page structure. You should see role="navigation" or <nav>, role="main" or <main>, and so on.

WordPress "Accessibility-Ready" Tag

WordPress.org has an "accessibility-ready" tag for themes that meet a set of accessibility guidelines. You can filter themes by this tag in the theme directory. It's not a guarantee of perfection, but it means the theme has passed a review process.

Some solid choices: GeneratePress is lightweight, fast, and has excellent semantic HTML output. The default WordPress themes (Twenty Twenty-Four, Twenty Twenty-Three) are built with accessibility in mind by the core team. Search the WordPress.org theme directory and filter by the "accessibility-ready" tag to find more options.

But don't trust the tag blindly. Always test with a keyboard and run an accessibility scan on the demo before committing to any theme.

Best WordPress Accessibility Plugins

Plugins can help, but they can't fix everything. No plugin will magically make an inaccessible theme accessible. Think of these as tools that patch gaps and catch oversights.

WP Accessibility by Joe Dolson

This is the most respected accessibility plugin in the WordPress ecosystem. It's free, lightweight, and maintained by an accessibility expert who sits on the WordPress core accessibility team. Here's what it does:

• Adds a skip link to themes that don't have one
• Removes the target="_blank" attribute from links (which can confuse screen reader users)
• Adds language attributes and ARIA landmarks
• Fixes common toolbar accessibility issues
• Provides a color contrast testing tool in the admin

What it doesn't do: fix your content. It can't add alt text to your images, label your form fields, or restructure your headings. That's on you.

Equalize Digital Accessibility Checker

This plugin scans your content as you edit it and flags accessibility issues right in the WordPress editor. It runs over 40 automated checks based on WCAG 2.2, catching missing alt text, empty links, skipped heading levels, and missing form labels. Think of it like a spellchecker for accessibility.

The free version covers the basics. The pro version adds more checks, site-wide scanning, and detailed reporting.

What Plugins Can't Fix

I want to be blunt about this. Overlay plugins that promise "one-click ADA compliance" don't work. Products like AccessiBe, UserWay, and similar tools add a toolbar widget to your site that lets users adjust font sizes, contrast, and spacing. These overlays don't actually fix the underlying HTML issues. They don't add proper alt text, fix heading structure, or make forms accessible. Many accessibility advocates actively campaign against them, and some have even been the subject of lawsuits themselves.

Real accessibility means fixing the actual code, not layering a widget on top of broken markup.

Fixing Gutenberg Block Accessibility

The WordPress block editor (Gutenberg) is reasonably accessible itself, but the content you create with it might not be. Here are the most common block-level issues and how to fix them.

Image Blocks Need Alt Text

When you add an image block, Gutenberg shows an "Alt text (alternative text)" field in the block settings sidebar. Don't leave it empty. Write a concise description of what the image shows. If the image is purely decorative (a divider, a background texture), you can leave it empty, but you should also mark it as decorative in the block settings if that option is available.

<!-- What Gutenberg generates with alt text -->
<figure class="wp-block-image">
  <img src="team-photo.jpg" alt="Our team at the 2025 accessibility summit">
</figure>

<!-- What Gutenberg generates without alt text (bad) -->
<figure class="wp-block-image">
  <img src="team-photo.jpg" alt="">
</figure>

Button Blocks Need Meaningful Text

Button blocks should have clear, descriptive text. "Click here" and "Learn more" are bad button labels because they don't tell screen reader users what they'll get. "Download our pricing guide" or "Sign up for the newsletter" tells the user exactly what to expect.

<!-- Bad: vague button text -->
<div class="wp-block-button">
  <a class="wp-block-button__link">Click Here</a>
</div>

<!-- Good: descriptive button text -->
<div class="wp-block-button">
  <a class="wp-block-button__link">Download the 2026 Pricing Guide</a>
</div>

Heading Hierarchy

This is one of the easiest things to get wrong. Headings should follow a logical order: H1, then H2, then H3, and so on. Don't skip from H2 to H4 because you like how H4 looks. Screen reader users navigate by headings, and skipped levels break that navigation pattern.

Gutenberg lets you pick any heading level for a heading block. Just because you can jump to H4 doesn't mean you should. If you want smaller text, use CSS, not a lower heading level.

A good page structure looks like this:

H1: Page Title (only one per page)
  H2: First Section
    H3: Subsection
    H3: Subsection
  H2: Second Section
    H3: Subsection
      H4: Sub-subsection

Making WordPress Forms Accessible

Forms are where accessibility failures hit the hardest. If someone can't fill out your contact form, request a quote, or complete a purchase, you've lost a customer. For a deep dive on form accessibility, read our accessible forms guide.

Here's how the major WordPress form plugins stack up.

Contact Form 7

Contact Form 7 is the most popular form plugin with over 5 million active installs. It generates reasonably accessible HTML by default, using <label> elements for each field. The main issue is that error messages aren't always linked to their fields with aria-describedby, so screen reader users may not know which field has the error.

To improve CF7 accessibility:

• Always use the [label] tag to wrap your form fields
• Add aria-required="true" to required fields
• Make sure error messages are visible and near the field that triggered them

Gravity Forms

Gravity Forms has made significant accessibility improvements in recent versions. It generates proper label associations, supports aria-describedby for field descriptions and error messages, and includes an "Enable accessibility enhancements" option in form settings. Turn that on. It adds proper ARIA attributes and improves keyboard navigation.

One thing to watch: conditional logic (showing/hiding fields based on other fields) can confuse screen readers if the hidden fields aren't properly removed from the tab order. Test your conditional forms with a keyboard.

WPForms

WPForms generates clean HTML with label elements, but the lite (free) version has some gaps. Field descriptions aren't always linked via aria-describedby, and the multi-page form navigation can be tricky for keyboard users. The pro version has better accessibility features.

General Form Tips

Regardless of which plugin you use:

• Never rely on placeholder text as the only label. Always use a visible <label> element.
• Group related fields with <fieldset> and <legend> (for radio buttons, checkboxes, address sections).
• Make sure error messages are specific ("Please enter a valid email address" instead of "Invalid input") and linked to the field.
• Test the entire form with keyboard-only navigation. Can you tab to every field, select options, and submit?

<!-- Accessible form field pattern -->
<label for="user-email">Email Address</label>
<input type="email" id="user-email" name="email"
       aria-required="true"
       aria-describedby="email-help">
<p id="email-help">We'll never share your email with anyone.</p>

<!-- Inaccessible form field (no label, placeholder only) -->
<input type="email" placeholder="Email Address">

Testing Your WordPress Site

You've picked an accessible theme, installed the right plugins, and fixed your content. Now you need to verify it actually works.

Step 1: Run an Automated Scan

Start with our free accessibility scanner. Enter your URL and you'll get a detailed report showing every accessibility issue, organized by severity. The report includes specific code snippets and fix recommendations for each issue. Automated scanning catches about 30-40% of accessibility issues, which covers the most common and impactful problems.

Step 2: Keyboard Testing

Unplug your mouse (or just don't touch it) and try to use your site with only the keyboard. Press Tab to move forward, Shift+Tab to move backward, Enter to activate links and buttons, Space to toggle checkboxes, and arrow keys for radio buttons and select menus.

Check for these things:

• Can you see where the focus is at all times? (There should be a visible outline or highlight.)
• Can you reach every interactive element?
• Can you open and close the mobile navigation menu?
• Can you complete a form submission?
• Does focus get trapped anywhere? (It shouldn't, unless you're in a modal dialog.)

Step 3: Screen Reader Testing

If you're on a Mac, turn on VoiceOver with Cmd+F5 and navigate through your pages. Listen to how elements are announced. Are images described? Are form fields labeled? Do headings make sense out of context? On Windows, download NVDA (it's free) and do the same thing.

You don't need to become a screen reader expert. Even 10 minutes of testing will reveal issues that automated tools miss.

Step 4: Check Color Contrast

Use a contrast checker tool to verify that all text meets the 4.5:1 minimum ratio. Pay special attention to text over images, light gray text, and link colors that might blend with surrounding text.

Quick Wins Checklist

Here's a prioritized list of things you can fix right now. Start at the top and work your way down.

1. Run an accessibility scan to get a baseline of your current issues.
2. Add alt text to all images. Go to Media Library, filter by "unattached" or just scroll through, and add descriptive alt text to every image that conveys information.
3. Fix your heading structure. Make sure every page has exactly one H1 (your page title), and that headings follow a logical order (H1 > H2 > H3, no skipping).
4. Check your forms. Every input field needs a visible label. Replace placeholder-only fields with proper labels.
5. Install WP Accessibility. It takes 30 seconds and fixes several common issues automatically (skip link, landmark roles, target="_blank" removal).
6. Test keyboard navigation. Tab through your homepage and one interior page. Fix any place where focus disappears or you get stuck.
7. Check color contrast. Run your site through a contrast checker and fix any text that falls below 4.5:1.
8. Add descriptive link text. Replace every "click here" and "read more" with text that makes sense out of context ("Read our pricing guide" instead of "Click here").
9. Make sure videos have captions. If you embed YouTube videos, enable captions. If you host your own videos, add WebVTT subtitle files.
10. Set the language attribute. Make sure your site's HTML has lang="en" (or whatever your language is) in the <html> tag. WordPress usually handles this, but some themes override it.

Platform-Specific Guides

Running a Shopify store instead? See our Shopify accessibility guide. We also have guides for Wix and Squarespace sites.