WordPress Accessibility: How to Make Your WordPress Site ADA Compliant

The disproportionate exposure isn't about WordPress being “bad” at accessibility. It's about three structural realities of how WordPress sites are built and maintained.

First, the plugin ecosystem. A typical WordPress business site runs 15–30 plugins. Each plugin injects HTML, CSS, and JavaScript into your pages. Every plugin is a potential source of missing alt text, poor color contrast, inaccessible forms, or keyboard-traps in modals. Most plugin authors are not accessibility specialists; many have never run their plugin through an automated WCAG checker. When you install one, you inherit its accessibility debt.

Second, themes are designed visually, not semantically. Popular themes are marketed on design and speed, not on semantic HTML, heading hierarchy, or ARIA. A theme that looks beautiful can still have skip-link issues, missing landmarks, broken focus indicators, or hero-slider components that violate WCAG 2.1.2 Pause, Stop, Hide.

Third, non-technical site owners. A solo business owner or small marketing team is unlikely to notice when the new cookie banner lacks a keyboard trap or when a page-builder widget renders buttons as <div>s. The WordPress surface that end users see is the output of dozens of little decisions from theme authors, plugin authors, and page-builder widgets — and those decisions change every time something updates.

The result: even a WordPress site that passed an audit in January can be non-compliant by June because a theme update, a new plugin, or a newly-published page introduced regressions. This is exactly the pattern driving the 2026 surge in ADA lawsuits.

A theme choice you make once ripples across every page of your site. Picking an accessibility-ready theme from day one costs nothing and eliminates a huge class of issues.

WordPress.org maintains an accessibility-ready tag that flags themes which have been manually reviewed against the WordPress accessibility theme review requirements. These themes commit to skip links, keyboard navigation, proper heading hierarchy, color contrast that meets WCAG AA, visible focus indicators, and semantic HTML5 landmarks.

Well-regarded options include the default Twenty Twenty-Four, Twenty Twenty-Three, and earlier WordPress defaults (all accessibility-ready by design), plus community favorites like GeneratePress, Astra, and Kadence which offer accessibility-ready configurations.

If you're married to a non-accessibility-ready theme (because of design investment, client preference, or page-builder lock-in), the minimum bar is to override the theme's decisions that fail accessibility: add a skip link, fix heading hierarchy, and set focus-visible styles in a child theme.

Page builders are where most WordPress accessibility problems originate in practice. They generate markup on your behalf, and the default output of every major page builder has well-documented accessibility limitations.

Elementoris the most widely used. Its default free templates often include carousels with auto-rotation, accordion widgets that don't respect keyboard focus order, and popup builders that trap focus incorrectly. Elementor Pro 3.x has made real accessibility progress — ARIA attributes are now more consistent, and newer widgets ship with keyboard handlers — but older pages built in 2.x-era templates need manual remediation.

Divi (Elegant Themes) renders visually rich layouts, but its tab, accordion, and slider modules have historically lacked proper ARIA roles and keyboard support. Recent Divi 4.x+ releases ship better defaults; sites on older Divi versions need a top-to-bottom audit.

Beaver Builderhas the strongest out-of-the-box accessibility posture among major builders — semantic HTML, ARIA landmarks, proper focus management. It's still not a free pass; custom modules from the marketplace vary wildly.

WPBakery (formerly Visual Composer) tends to produce the heaviest, least semantic output. Sites built primarily on WPBakery are frequently the ones we see in prospect scans with 40+ accessibility issues per page.

Practical advice regardless of builder:

• Avoid auto-rotating carousels entirely. WCAG 2.2.2 requires pause/stop/hide controls, and almost no page-builder carousel ships with compliant controls by default.
• Replace icon-only buttons with icon + visible text, or at minimum add an aria-label.
• Check that accordions and tabs are built with proper ARIA roles (role="tab", aria-expanded) and keyboard support.
• Run your site through a scanner after every major theme or builder update. Regressions from updates are the single most common cause of new lawsuits against WordPress sites.

Every plugin that renders HTML to your pages is an accessibility surface. Here are the categories where we see problems most often, based on thousands of WordPress scans:

Cookie / GDPR banners.Many popular banner plugins (Cookie Notice, CookieYes, GDPR Cookie Consent) fail to trap keyboard focus correctly, use insufficient color contrast on “Accept” buttons, and don't announce themselves to screen readers on page load.

Popups and modals. Popup Maker, OptinMonster, Thrive Leads — all three have shipped accessibility improvements in recent years but still default to behaviors that trap focus incorrectly or fail to return focus to the trigger element when closed.

Form plugins.Contact Form 7 in particular is notorious for generating inaccessible error messages (error text that isn't programmatically associated with its field). Gravity Forms and WPForms have better defaults but still require manual configuration to meet WCAG 3.3.1 Error Identification.

Sliders. Smart Slider, Slider Revolution, and MetaSlider all default to auto-play with no pause/stop/hide controls. This is a direct WCAG 2.2.2 violation that gets cited verbatim in lawsuit complaints.

Accessibility overlay plugins.A note specifically on plugins that claim to “make your site accessible instantly” (accessiBe, UserWay, AudioEye widgets). These do not make your site accessible. More than 800 accessibility advocates have signed the Overlay Fact Sheet stating that overlays do not ensure compliance, can conflict with users' existing assistive technology, and don't modify the actual source code. Courts have rejected overlay defenses. If you have one installed, don't rely on it — fix the underlying HTML.

E-commerce businesses are the most-sued category in ADA website litigation — approximately 35% of all federal ADA Title III digital lawsuits. WooCommerce runs roughly 28% of online stores, which puts WooCommerce site owners squarely in the crosshairs.

The WooCommerce-specific patterns that show up in lawsuit complaints:

• Product images without meaningful alt text (“IMG_4823.jpg” is not alt text).
• Checkout forms with missing or incorrectly associated labels. WooCommerce's default checkout is reasonably well-built; custom checkout plugins often break it.
• Product variation swatches (color pickers, size selectors) rendered as non-semantic clickable divs with no keyboard support.
• Price displays where the sale price has insufficient contrast against the background.
• “Add to cart” buttons that don't announce the addition to screen readers — so a blind user has no feedback that their action succeeded.

If you run a WooCommerce store, the single highest-value use of an hour per week is running a focused scan, triaging the critical issues, and fixing them before a plaintiff firm runs the same scan against you. Automated scanners catch about 30–40% of WCAG violations, which happens to be the exact 30–40% that gets cited in settlement demand letters.

Here is a practical sequence that works for any WordPress site, from a solo blog to a 10,000-product WooCommerce store:

1. Run an automated scan.Use CompliaScan or any WCAG 2.2 scanner to get a baseline. You'll typically see 20–60 issues on a first scan of a medium-sized WordPress site. This sets your starting point and catches the “easy” issues that get cited in lawsuits.
2. Triage by severity. Critical issues (missing alt text, color contrast failures, missing form labels) go first because they appear in every settlement demand letter. Moderate issues (heading hierarchy, ARIA misuse) go second. Minor issues (redundant links, decorative-image alt text choices) go last.
3. Fix the media library. Every image in every post should have meaningful alt text or be marked decorative. This is the single most-cited violation in ADA lawsuits. Plugins like Accessibility Checker, WP Accessibility, and Image SEO can help surface images without alt text in bulk.
4. Check your forms.Test every form (contact, checkout, newsletter, comment) with the keyboard only. Tab through it. If the focus disappears at any point, that's a WCAG 2.4.7 failure. If errors display after submission but aren't announced to screen readers, that's WCAG 3.3.1.
5. Test your navigation. Open your site, press Tab. You should see a visible skip link, then clear focus indicators as you move through the nav. Mega-menus that only open on hover fail keyboard users completely.
6. Screen reader spot-check.Turn on VoiceOver (Mac) or NVDA (Windows, free) and navigate your homepage with the screen reader. If page structure is unclear, heading levels jump incoherently, or interactive elements don't announce their state, those are fixable issues worth prioritizing.
7. Set up continuous monitoring. This is the part most WordPress site owners skip — and the part that matters most. WordPress sites change constantly. Plugin updates, theme updates, new content, new page builders, WooCommerce product additions. Without automated re-scans on a schedule, your site will drift back into non-compliance within weeks. See our continuous monitoring guide for why one-time audits fail.

A few plugins genuinely improve accessibility rather than papering over it with overlays:

WP Accessibility (Joseph C Dolson) — free, community-maintained, does small useful things: adds skip links, forces alt-text prompts on upload, fixes common theme issues. Good baseline plugin.

Accessibility Checker(Equalize Digital) — free tier scans posts and pages as you edit and shows issues inline in the WordPress admin. Paid tier adds site-wide scanning and audit history. Complements an external scanner; doesn't replace it.

One Click Accessibility — adds a simple toolbar for font-size, contrast, underline-links preferences. Useful as a user-facing convenience; does not substitute for fixing the underlying site.

What to avoid: any plugin that claims to make your site WCAG-compliant by installing a widget. Those are overlays. They do not work for compliance, and courts have said so.