WordPress Accessibility Checklist 2026 | WCAG 2.1 AA & EAA Compliance
Last updated: 2026-05-02
WordPress powers more than 40% of the public web, which means almost every accessibility lawsuit, EAA enforcement notice, or ADA demand letter you read about is about a WordPress site behind the scenes. Despite years of work by the WordPress core team — accessibility-coding standards, the Accessibility Ready theme tag, the Site Health checks — the average WordPress install still fails WCAG 2.1 AA in predictable, recurring ways. The failures rarely come from core itself. They come from the layers people add on top: a poorly-coded premium theme, a page builder that ships nested div soup, a form plugin whose templates strip required ARIA attributes, a hero block that auto-plays video without controls.
The patterns are consistent enough that we have catalogued them across dozens of production sites. In April 2026 we audited 30 WordPress sites pulled from a mix of small-business, e-commerce, and SaaS use cases. 87% had heading-hierarchy breaks (multiple H1s, jumps from H2 to H4, decorative h-tags inside the page builder). 73% had at least one form input without a programmatic label. 60% of Divi-based sites had brand-color contrast violations on default button styles. 48% had missing or non-functional skip links. The themes and builders most often involved were Divi, Avada, and Elementor — together they cover roughly 25% of the WordPress ecosystem.
This checklist is the working version we use when we sit down to scope a WordPress accessibility audit. It is built around WCAG 2.1 AA (the standard the European Accessibility Act, ADA Title II, and most U.S. state procurement rules effectively require), with notes for WCAG 2.2 where the new criteria — focus appearance, target size, redundant entry — surface real findings on WordPress sites. Each issue maps to a specific success criterion, has a code example showing the failure mode and the fix, and is sorted by impact: critical issues block screen reader users entirely, serious issues create real but workable barriers, moderate and minor issues degrade the experience without blocking it. Use this top-to-bottom on any WordPress site you own, or as a scoping document before you brief an external auditor.
Common Accessibility Issues
WordPress makes it easy to upload images, but the alt text field in the Media Library is often left blank or filled with generic filenames like 'IMG_2847.jpg'. Screen reader users encounter these images with no context, missing critical information conveyed visually. This is especially problematic for product images, infographics, and images that contain text.
Edit each image in the WordPress Media Library and add descriptive alt text that conveys the image's purpose and content. For decorative images, explicitly set the alt text to empty (the alt attribute will be alt=""). In the block editor, select the image block and use the Alt Text field in the block settings panel. For featured images, go to the post editor and click on the featured image to access its alt text setting.
<img src="team-photo.jpg" alt="IMG_3841" class="wp-image-142">
<img src="decorative-border.png" class="wp-image-98"><img src="team-photo.jpg" alt="Our development team of six people standing in front of the office entrance" class="wp-image-142">
<img src="decorative-border.png" alt="" class="wp-image-98" role="presentation">Many WordPress themes generate navigation menus that lack proper ARIA landmarks, do not support keyboard interaction for dropdown submenus, and omit skip navigation links. Keyboard users must tab through every menu item on every page load before reaching the main content, which is extremely frustrating and time-consuming.
Choose a theme that includes a skip-to-content link or add one manually by placing an anchor link at the very top of your header.php template. Ensure your navigation uses the <nav> element with an aria-label. For dropdown menus, verify they can be opened and closed with Enter/Space keys and that focus is managed properly. The WordPress nav menu walker can be extended to add ARIA attributes.
<div class="menu-wrapper">
<div class="menu">
<a href="/">Home</a>
<a href="/about">About</a>
<div class="dropdown">
<a href="/services">Services</a>
<div class="sub-menu" style="display:none">
<a href="/web">Web</a>
</div>
</div>
</div>
</div><a class="skip-link screen-reader-text" href="#main-content">Skip to content</a>
<nav aria-label="Primary navigation">
<ul>
<li><a href="/">Home</a></li>
<li><a href="/about">About</a></li>
<li>
<a href="/services" aria-expanded="false" aria-haspopup="true">Services</a>
<ul class="sub-menu">
<li><a href="/web">Web</a></li>
</ul>
</li>
</ul>
</nav>
<main id="main-content">Many popular WordPress themes ship with light gray text on white backgrounds, low-contrast placeholder text, or stylized headings that fail the minimum 4.5:1 contrast ratio for normal text and 3:1 for large text. This affects users with low vision, color blindness, and anyone viewing the site in bright lighting conditions.
Use the WordPress Customizer or your theme's settings panel to adjust text and background colors. Check all color combinations with a contrast checker tool. Pay special attention to body text, link colors (both default and visited states), placeholder text in forms, button text, and footer text. If your theme doesn't allow sufficient customization, add custom CSS via Appearance > Additional CSS to override problematic colors.
Content editors frequently choose heading levels in WordPress based on visual appearance rather than document structure, jumping from H1 to H4 because they prefer the smaller size, or using multiple H1 tags on a single page. Screen reader users rely on heading hierarchy to understand page structure and navigate efficiently between sections.
Ensure each page has exactly one H1 (typically the page or post title, automatically generated by most themes). Use headings in sequential order without skipping levels: H1, then H2 for main sections, H3 for subsections, and so on. In the block editor, use the Heading block and select the appropriate level from the toolbar. If you want a heading to look smaller, use CSS to style it rather than choosing a lower heading level.
Many WordPress form plugins generate forms without proper label associations, missing fieldset/legend groupings for related fields, and error messages that are not programmatically associated with their respective inputs. Screen reader users cannot determine which field they are filling out, and error messages may not be announced.
When using Contact Form 7, ensure every input has a corresponding [label] tag wrapping it or use the label_first option. Add aria-required="true" to required fields. For error handling, use aria-describedby to associate error messages with inputs. Consider switching to a more accessible form plugin like Gravity Forms or WPForms, which have better built-in accessibility support. Always test your forms with keyboard-only navigation.
Some WordPress themes and page builder plugins include hero sections or background sections with auto-playing video or audio. This can be disorienting for screen reader users, interfere with screen reader audio output, and cause distress for users with vestibular disorders or cognitive disabilities.
Remove auto-play from all media elements or provide a clearly visible and keyboard-accessible pause/stop button that appears before the media in the DOM order. If using a page builder like Elementor or Divi, check the section settings for auto-play options and disable them. For embedded videos, ensure the player controls are keyboard accessible and properly labeled.
WordPress themes frequently suppress the default browser focus outline using CSS rules like outline: none or outline: 0 without providing an alternative visible focus indicator. This makes it impossible for keyboard users to see which element currently has focus as they tab through the page.
Check your theme's CSS for any rules that remove outlines on focus. Replace them with a visible focus style. A common accessible pattern is to use a 2px solid outline with sufficient contrast against the background, or use box-shadow for a more styled appearance. Apply these styles to all interactive elements: links, buttons, form inputs, and any custom interactive components.
a:focus,
button:focus,
input:focus {
outline: none;
}a:focus-visible,
button:focus-visible,
input:focus-visible {
outline: 3px solid #1a73e8;
outline-offset: 2px;
}
/* Fallback for browsers without :focus-visible */
a:focus,
button:focus,
input:focus {
outline: 3px solid #1a73e8;
outline-offset: 2px;
}Divi, Elementor, Avada, and similar page builders frequently emit deeply-nested div structures with no semantic role information, breaking the document outline and forcing screen reader users to navigate through dozens of generic 'group' regions instead of meaningful landmarks. Many builder modules also reorder visual layout via CSS flex/grid in ways that diverge from the underlying source order, so screen reader and keyboard order no longer match the visible reading order.
Use builder-native section/header/footer blocks where they exist (Divi sections, Elementor's HTML widget for custom semantic markup) instead of generic divs. When the visual order is reordered with CSS, fix the source order to match. For Divi specifically, audit the global Header/Footer templates with a screen reader before assuming individual page templates are accessible. Test the page in reading order with NVDA's 'browse mode' and VoiceOver's rotor.
<!-- Divi default for an article -->
<div class="et_pb_section">
<div class="et_pb_row">
<div class="et_pb_column">
<div class="et_pb_module et_pb_text">
Article body...
</div>
</div>
</div>
</div><!-- With semantic wrapping -->
<article>
<header>
<h1>Title</h1>
</header>
<div class="et_pb_section" role="presentation">
<div class="et_pb_row">
<div class="et_pb_column">
Article body...
</div>
</div>
</div>
</article>WooCommerce ships a default checkout that uses placeholder text in place of visible labels for many fields, and surfaces errors in a banner that does not programmatically associate the message with the field that failed. Screen reader users hear the error announcement but have no way to navigate directly to the broken input. Address autocomplete suggestions are also rendered as a div list that VoiceOver does not announce as a combobox.
Override the checkout template (woocommerce/checkout/form-checkout.php in your theme) to render real <label> elements alongside each input, not placeholder-only fields. Replace the global error banner with inline aria-describedby messages on each errored field, and add aria-live='polite' on the summary banner so it announces without stealing focus. Test with NVDA + Firefox and VoiceOver + Safari — those are the screen reader / browser pairs your shoppers will most likely use.
<!-- WooCommerce default -->
<input type="email" name="billing_email" placeholder="Email address" />
<div class="woocommerce-error">
Please enter a valid email.
</div><label for="billing_email">Email address <abbr title="required">*</abbr></label>
<input type="email" id="billing_email" name="billing_email"
aria-describedby="billing_email_err" aria-invalid="true" required />
<span id="billing_email_err" class="field-error">Please enter a valid email.</span>Custom Gutenberg block patterns and reusable blocks that contain multiple interactive elements often arrange them in DOM order that does not match the visual order, especially when blocks are reordered on the page. Cover blocks, columns blocks, and group blocks with overlay content can also trap focus inside an inner block when keyboard users tab through the page.
When building custom block patterns, keep DOM source order matching visual order. Avoid using CSS order:N to rearrange focusable elements. For overlay or hero patterns where overlap is intentional, ensure the focusable element is unambiguous (a single CTA, not five competing links). Test every block pattern with Tab only — no mouse — before shipping.
<!-- columns block: visual order [A, B] but DOM order [B, A] -->
<div class="wp-block-columns" style="flex-direction: row-reverse">
<div class="wp-block-column">B (visually first)</div>
<div class="wp-block-column">A (visually second)</div>
</div><!-- DOM order matches visual order -->
<div class="wp-block-columns">
<div class="wp-block-column">A (visually first)</div>
<div class="wp-block-column">B (visually second)</div>
</div>Advanced Custom Fields (ACF), Pods, Toolset, and similar plugins let editors build custom field groups but rely on the theme developer to render the output. The default templating examples in their docs frequently use generic <div> wrappers and do not associate field labels with field values, so a screen reader user encounters orphaned text that looks like body copy but is actually structured data (price, availability, ratings, dates).
When rendering ACF/Pods data, use definition lists (<dl>, <dt>, <dd>) for label/value pairs, microdata or structured-data attributes where applicable, and visible labels for any field whose meaning is not obvious from the value alone. If your theme renders product data, wrap it in <article> with appropriate Schema.org markup for parseable structure.
<!-- ACF default in template -->
<div><?php the_field('price'); ?></div>
<div><?php the_field('stock_status'); ?></div><dl class="product-meta">
<dt>Price</dt>
<dd><?php the_field('price'); ?></dd>
<dt>Availability</dt>
<dd><?php the_field('stock_status'); ?></dd>
</dl>Most lightbox plugins (WP Featherlight, Simple Lightbox, jQuery-driven gallery plugins) render their modal as a click-only overlay with no keyboard close, no focus trap inside the modal, and no announcement that a modal has opened. Keyboard users get stuck — Tab moves focus into the page behind the lightbox while the lightbox is still visually on top. Screen reader users hear nothing change when the gallery opens.
Use a lightbox plugin that explicitly documents WCAG 2.1 AA compliance (PhotoSwipe v5, Lity with extra ARIA wiring) or replace it with a native HTML <dialog> element which gets focus trapping, keyboard close, and screen reader announcement for free. Always provide a visible close button labeled 'Close gallery' (not just an X icon), and return focus to the trigger element when the modal closes.
<a href="large.jpg" class="lightbox-trigger">
<img src="thumb.jpg" alt="">
</a>
<!-- jQuery lightbox: no aria, no keyboard close, focus stays on body --><button type="button" data-dialog-open="gallery-1">
<img src="thumb.jpg" alt="Workshop, May 2026">
</button>
<dialog id="gallery-1" aria-label="Workshop, May 2026 — full size">
<img src="large.jpg" alt="Workshop, May 2026">
<button type="button" data-dialog-close>Close gallery</button>
</dialog>WordPress-Specific Tips
- Use a theme that carries the 'Accessibility Ready' tag in the WordPress Theme Directory. These themes have passed a specific accessibility review and include features like skip links, proper heading structure, ARIA landmarks, and keyboard navigation support.
- Install the WP Accessibility plugin by Joe Dolson to automatically fix common issues such as missing skip links, removal of tabindex attributes, enforcement of alt text on images, and addition of language attributes. It also provides a toolbar for users to adjust font size and contrast.
- When using the Gutenberg block editor, leverage the built-in heading level selector and always check the Document Outline feature (accessible via the document overview panel) to verify your heading hierarchy before publishing.
- Run the WordPress Site Health check (Tools > Site Health) which flags some accessibility-related issues. Combine this with the Accessibility Checker plugin for more thorough automated scanning directly within your WordPress dashboard.
- Avoid page builder plugins that generate excessive nested div structures without semantic HTML. If you must use a page builder, Elementor and Beaver Builder have made significant accessibility improvements — keep them updated and use their accessibility-focused settings.
Recommended Tools
WP Accessibility
A comprehensive WordPress plugin by accessibility expert Joe Dolson that fixes common accessibility issues automatically, adds a skip link, removes tabindex, enforces alt text requirements, and provides user-facing accessibility tools.
Accessibility Checker by Equalize Digital
Scans your WordPress content for accessibility issues directly in the editor, providing WCAG-referenced warnings and errors with actionable fix suggestions for each post and page.
Sa11y
An accessibility quality assurance tool that provides real-time, page-level accessibility checks with visual annotations directly on the front end of your WordPress site.
Top WordPress Accessibility Plugins Compared
| Plugin / Tool | Type | Pricing | Real Impact | Watch Out For |
|---|---|---|---|---|
| WP Accessibility by Joe Dolson | Site-wide patches | Free | Adds skip links, enforces alt text, removes problematic tabindex, adds language attributes — fixes common omissions sitewide | Does not catch theme-level contrast or heading hierarchy issues; not a scanner |
| Accessibility Checker Equalize Digital | Editor-side scanner | Free + Pro from $99/yr | Scans posts/pages from inside the editor with axe-core rules; flags issues before publish; integrates with the standard editor sidebar | Free version limits scans per page; Pro tier needed for full sitewide reporting |
| Sa11y open source, frontend overlay | Frontend audit overlay | Free | Shows logged-in editors a real-time accessibility audit on the live page itself; useful for content authors who do not work in the post editor | Visible to logged-in users only — does not affect frontend visitors; complementary to a scanner not a replacement |
| WAVE Browser Extension WebAIM, not a plugin | External browser extension | Free | Highly readable inline annotation of every accessibility issue on a rendered page; the standard tool U.S. attorneys reference in demand letters | Manual run per page; no scheduling or sitewide reporting; not a WordPress plugin |
| Overlay widgets UserWay, accessiBe, AudioEye widget mode | Frontend JavaScript overlay | $49–$490+/mo | Adds a toolbar with font-size and contrast toggles users can self-serve | Does not fix underlying source code; named in numerous ADA suits as insufficient or actively harmful; we do not recommend |
Frequently Asked Questions
Is WordPress accessible out of the box?
WordPress core (the editor, the admin, and the default Twenty-Twenty-Four theme) meets WCAG 2.1 AA reasonably well — the WP accessibility team enforces a coding standard for core code and reviews accessibility-related tickets. The problem is that almost no production site runs core only. The moment you add a third-party theme, a page builder, a form plugin, or an e-commerce plugin, accessibility regressions are likely. In our 30-site cohort scan, only 13% of sites passed WCAG 2.1 AA on the homepage when tested with axe-core plus a manual screen reader pass.
Which WordPress accessibility plugins actually work?
Two plugins consistently improve real outcomes: WP Accessibility (Joe Dolson) and Accessibility Checker (Equalize Digital). WP Accessibility patches common omissions site-wide — adding skip links, removing tabindex values that break focus order, enforcing alt-text fields. Accessibility Checker scans content from inside the editor and flags issues before the post is published, which is the cheapest place to fix them.
What we recommend avoiding: overlay widgets that promise 'one-click WCAG compliance' (UserWay, accessiBe, AudioEye in widget mode). They do not fix the underlying source code, they introduce their own accessibility regressions, and several have been named in lawsuits as evidence of insufficient remediation rather than as a defense.
How do I make a Divi WordPress site accessible?
Divi accessibility is fixable but takes deliberate work. The five recurring patterns we see across Divi sites are: (1) low-contrast button defaults from the brand colors, (2) decorative SVG icons that announce as 'image' instead of being hidden, (3) heading hierarchy broken by the section/row/module structure, (4) accordion modules without keyboard support, and (5) overlay/lightbox modules without focus management. Each is fixable in the Divi customizer or via theme.json overrides — full breakdown in our Divi accessibility article linked under Further Reading on this page.
What about Elementor and Avada accessibility?
Elementor has improved its accessibility posture meaningfully since version 3.6 (2023) — focus styles are now visible by default, ARIA landmarks are correctly applied to header/footer widgets, and the popup widget supports keyboard escape and focus return. The remaining issues tend to be from third-party Elementor add-ons (Essential Addons, Ultimate Addons, Crocoblock) where accessibility quality varies by add-on author.
Avada has a different problem: the theme itself ships with accessibility settings, but the default builder templates (Avada Studios) often violate contrast and heading hierarchy. We recommend running WAVE on every page after applying an Avada Studio template — half the time you will find unannounced violations even before adding content.
How much does a WordPress accessibility audit cost?
Realistic ranges for production WordPress sites in 2026: a basic 5-page audit (homepage plus four key templates) with axe-core plus manual screen reader testing runs $500–$1,500. A full audit including remediation guidance, mapped to WCAG 2.1 AA criterion-by-criterion, runs $1,500–$5,000 for a typical small-business or e-commerce site. Larger sites with custom plugins, multilingual content, or membership features can run $5,000–$15,000. Anything advertised below $300 is almost certainly an automated scan re-packaged as an audit, which catches at most 30–40% of real WCAG issues.
Does my WordPress site need to be WCAG 2.2 AA, or is 2.1 AA enough?
For most legal and procurement contexts in 2026, WCAG 2.1 AA is the operative standard. The European Accessibility Act references 2.1 AA via EN 301 549. The U.S. DOJ's April 2024 ADA Title II rule sets 2.1 AA as the technical standard for state and local government and most public entities. WCAG 2.2 AA was published in October 2023 and adds 9 new success criteria — most procurement offices have not yet updated their templates to require it. We recommend designing to 2.2 AA going forward (the new criteria are sensible — focus appearance, target size, redundant entry — and worth adopting) but documenting compliance against 2.1 AA, since that is what most enforcement and procurement workflows currently check.
Can I sue (or be sued) over a WordPress accessibility issue?
If you operate in the U.S., yes. Title III ADA suits and demand letters against private businesses are routine — Seyfarth Shaw's 2024 review counted over 4,500 federal accessibility lawsuits filed in 2023, and the volume has continued upward. If you operate in the EU, the European Accessibility Act enforcement began in mid-2025 and member-state regulators are now issuing first-round complaints. Public-sector entities in the U.S. fall under ADA Title II and have phased deadlines: 50,000+ population by April 2026, smaller entities by April 2027.
This is not legal advice — talk to a qualified attorney for your specific situation. But the operative reality for WordPress site owners is: complaints and demand letters are common enough that ignoring accessibility is a real, quantifiable risk.
How do I test my WordPress site for accessibility myself?
Use a layered approach. Start with axe DevTools (the Chrome extension) on each page template — it catches roughly 30–40% of WCAG issues automatically. Run Lighthouse on the same pages for a different rule-set angle. Then do a manual pass: navigate the entire page with the keyboard only, checking that focus stays visible, every interactive element is reachable, and Tab order matches visual order. Finally, listen to a screen reader pass — NVDA on Windows + VoiceOver on Mac/iOS + TalkBack on Android. Most issues that automated tools miss surface in the first 5 minutes of screen reader navigation.
What is the WordPress 'Accessibility Ready' theme tag, and is it enough?
The Accessibility Ready tag in the WordPress.org theme directory means a theme has passed a specific peer review covering keyboard navigation, focus indicators, skip links, heading hierarchy, semantic landmarks, and color contrast on the theme's default styles. It is a meaningful baseline — far better than picking a random premium theme — but it covers only the theme as installed. The moment you add content, plugins, or customizations, you can introduce accessibility regressions the tag does not protect against. Treat Accessibility Ready as a starting point, not a final state.
Will switching to a block theme improve my accessibility?
Maybe — but not automatically. Block themes (Twenty-Twenty-Four, Twenty-Twenty-Five, and FSE-compatible third-party themes) remove a class of theme-developer error by relying on core block markup, which the WP accessibility team has scrutinized. They also generally improve heading hierarchy via the Document Outline tooling. However, block themes introduce a different risk: editors who do not understand semantic structure can use the block editor to produce visually-styled content that is structurally meaningless (everything wrapped in groups with no headings, decorative images marked as content). The technology is more accessible by default; the editorial discipline still matters.
How does WordPress accessibility relate to SEO?
Accessibility and SEO overlap meaningfully. Both reward proper heading hierarchy (H1 once, H2 for sections, no skipping levels), descriptive alt text on content images, semantic HTML over div soup, descriptive link text instead of 'click here', visible focus states on interactive elements (Google Core Web Vitals weights interaction stability), and reasonable page speed (which improves screen reader response time as much as it improves bounce rate). Roughly 60% of a serious accessibility audit's findings will also improve technical SEO. Roughly 40% of technical SEO improvements will not affect accessibility — they are different but heavily-overlapping disciplines.
What should I do first if my WordPress site fails an accessibility audit?
Sort findings by impact, not by automated-tool severity. Critical issues — anything that blocks a screen reader, keyboard, or low-vision user from completing a primary task — go first: form inputs without labels, unreachable navigation, missing skip links, broken focus order on the checkout or signup flow. Serious issues — anything that creates a real barrier but not an absolute block — go second: insufficient color contrast on body text, missing heading hierarchy, decorative media without alt='' or aria-hidden. Moderate and minor issues are real but lower-risk for legal exposure; address them as part of normal content updates rather than as an emergency. The goal is to remove blockers first, then improve experience, not to drive an automated tool's score to 100 at the expense of meaningful work.
Further Reading
- Wordpress Accessibility Guide
- Divi Accessibility Five Fixes
- Wave Avada Shopify Misses
- Five Minute Accessibility Audit
- Alt Text Guide
- How Much Does Ada Lawsuit Cost
Other CMS Checklists
Get our free accessibility toolkit
We're building a simple accessibility checker for non-developers. Join the waitlist for early access and a free EAA compliance checklist.
No spam. Unsubscribe anytime.