WordPress ADA Compliance Checker

WordPress runs 43% of the web, and a lot of the lawsuits

WordPress powers roughly 43% of all websites globally. That market share means WordPress sites make up a disproportionate share of ADA demand letter targets. The challenge with WordPress specifically is that accessibility lives in four places: the core CMS, the theme, the plugins, and the content. A failure in any one layer causes an ADA exposure, and the layers are owned by different people who rarely coordinate.

This page covers what actually matters for WordPress ADA compliance: how to evaluate your current site, which themes and plugins create risk, how to handle page builders, and what WooCommerce requires specifically. Start with the scan above, then work through the remediation guide below.

The four layers of WordPress accessibility

Layer 1: WordPress core

WordPress core (the CMS itself) has invested heavily in accessibility over the past few years. The block editor (Gutenberg) passes most accessibility baseline tests. The admin interface is largely accessible. Core is rarely the source of compliance problems anymore.

Layer 2: Theme

Your theme is where the biggest accessibility decisions live. A good theme handles skip navigation, heading hierarchy, focus indicators, color contrast, and keyboard navigation correctly. A bad theme breaks all of them. Theme choice is the single highest-leverage accessibility decision for most WordPress sites.

Layer 3: Plugins and page builders

Every plugin can introduce violations. Contact form plugins often ship with unlabeled inputs. Slider plugins often fail keyboard navigation. Page builders (Elementor, Divi, Beaver Builder) generate HTML with structural problems that are hard to fix after the fact.

Layer 4: Content

This is the layer site owners control directly. Images uploaded without alt text. Links with "click here" as the visible text. Videos embedded without captions. Headings skipped (h1 to h4 with no h2 or h3). These violations accumulate with every post, page, and media upload.

The most common WordPress ADA violations

Images without alt text

WordPress makes it easy to skip alt text during upload. Over time, media libraries accumulate hundreds of images with no alternative text. Every one of them is a WCAG 1.1.1 failure and a classic demand-letter citation.

Fix: In the media library, click each image and fill in the alt text field. Bulk remediation plugins like Alt Text AI or ShortPixel can auto-generate for large libraries, but review for quality before accepting. Going forward, make alt text a required step in your upload workflow.

Skipped heading levels

WordPress themes often set the site title as h1 and the page title as h1 simultaneously, or they skip from h1 directly to h3 because h2 is used for sidebar widgets. Screen reader users navigate by headings, and broken hierarchy makes content hard to scan.

Fix: Audit your theme's template files for heading use. Most themes have the worst heading issues in the header, sidebar, and footer templates. Tools like WP Accessibility plugin can flag heading issues automatically.

Contact form plugin inputs without labels

Contact Form 7, Gravity Forms, WPForms, and Ninja Forms all have accessibility gaps in default configurations. Placeholder text is often used instead of visible labels. Required fields may not be announced. Error messages may not be tied to specific fields.

Fix: In your form builder, always enable visible labels (not placeholder-only). Verify required fields use aria-required or have visible required indicators. Test form submission with a screen reader to confirm errors are announced.

Insufficient color contrast

WordPress themes often prioritize design aesthetics over contrast. Light gray body text on white, pale button colors, and low-contrast links fail WCAG 1.4.3. The block editor's default color palette includes several combinations that fail at normal body text size.

Fix: Use the theme customizer to set color choices that meet 4.5:1 contrast for body text and 3:1 for large text and UI elements. For block editor content, configure a custom color palette that only includes accessible combinations.

Accessibility overlay plugins

If you have AccessiBe, UserWay, or similar overlay plugins installed, remove them. They do not provide compliance, and over 1,000 ADA lawsuits in 2024 targeted sites with overlays installed. Some plaintiff firms specifically target sites with overlays because it shows the owner knew about accessibility but chose a shortcut.

Page builders and ADA compliance

Elementor, Divi, Beaver Builder, and Oxygen each have their own accessibility profile. All of them are capable of producing accessible output. Most default builds do not.

Elementor

Elementor has improved accessibility significantly in recent versions but still ships with problems. Default accordions do not announce state to screen readers. Slider widgets often fail keyboard navigation. The "Pro" dynamic content features can generate heading-hierarchy issues. Elementor sites can be made compliant, but you need to audit every widget and often replace some with custom accessible alternatives.

Divi

Divi has structural accessibility issues in its default modules. The accordion, tab, and toggle modules have historical problems with keyboard operation and screen reader announcement. The image slider module often lacks proper controls. Divi is one of the most challenging page builders to make fully accessible.

Beaver Builder

Beaver Builder is slightly better out of the box than Divi or Elementor, partly because it generates cleaner HTML. Still requires manual review of interactive modules, and custom modules often ship with accessibility gaps.

Gutenberg (the block editor)

The native WordPress block editor has the strongest accessibility baseline. Core blocks (Paragraph, Heading, Image, List, Group, Cover) generate clean, accessible HTML. Third-party block libraries (Kadence Blocks, GenerateBlocks, Stackable) are generally accessible. The WPBakery-style bloated page builders are worse than native blocks. If you're starting a new WordPress site, use Gutenberg.

WooCommerce and ADA compliance

WooCommerce powers a large share of WordPress e-commerce. Fashion, beauty, and furniture sites together accounted for more than 41% of the 3,948 ADA web accessibility lawsuits filed in federal court in 2025, and WordPress specifically was named in 808 cases that year. So WooCommerce stores face elevated legal risk. The specific issues that show up repeatedly:

• Product gallery keyboard navigation. Default WooCommerce galleries often trap focus or skip images when navigated by keyboard.
• Variation selectors. Color and size variation dropdowns often lack proper labels or use custom controls that screen readers cannot operate.
• Quantity inputs. The +/- quantity buttons often have no accessible names and cannot be operated with keyboard.
• Cart table. The cart page uses a table layout that is sometimes marked up incorrectly, making row headers unreadable for screen readers.
• Checkout form labels. Many themes override default WooCommerce checkout templates and strip proper labels.

Fix these by auditing your specific theme's WooCommerce template overrides, using accessibility-first themes like Storefront or Blocksy for e-commerce, and avoiding one-page checkout plugins that restructure the form.

WordPress ADA remediation, step by step

Week 1: Scan, audit, and triage

• Run the automated scan above on your homepage, top 3 landing pages, and checkout.
• Install the Accessibility Checker plugin for ongoing content-level scanning.
• Remove any accessibility overlay plugins (AccessiBe, UserWay, etc.).
• Document findings in a spreadsheet with severity and remediation owner.

Week 1: Content fixes (editor level)

• Add alt text to every media library image in use. Bulk tools help.
• Review heading hierarchy on all published pages.
• Replace "click here" links with descriptive anchor text.
• Add captions or transcripts to embedded videos.

Week 2: Theme and plugin fixes

• Evaluate your theme's accessibility. If it's deeply problematic, consider switching to an accessibility-ready alternative.
• Review color palette in theme customizer; ensure contrast meets WCAG 2.1 AA.
• Audit each form plugin's output. Enable visible labels, proper required indicators.
• For page builder sites, audit each reusable template; focus on accordions, tabs, sliders, modals.

Ongoing: Monitoring

• Set up automated monitoring across your full site. Alerts on new violations after any deploy.
• Before updating plugins or themes on production, scan the update on a staging site first.
• Maintain an accessibility statement page with a contact method.
• Quarterly manual keyboard + screen reader test on top traffic pages.

Frequently asked questions

Related: Shopify ADA compliance · E-commerce · Small business · ADA compliance checker · ADA compliance audit · WCAG compliance checker