WordPress Accessibility: Themes, Plugins and What to Check

Updated September 29, 2026 · 7 min read

WordPress powers a large share of small-business websites, which means many accessibility problems on those sites share the same causes: a theme choice, a page builder, a handful of plugins, and content added without accessibility in mind. This guide walks through where to look first, in the order that usually matters most.

This is general information, not legal advice. For questions about legal exposure, talk to an attorney.

What WordPress core does and does not handle

WordPress core has an accessibility team and a published coding standard, and its default themes and admin screens are built with accessibility in mind. That gives you a decent starting point. It does not give you a finished, conformant site.

Core generally does not decide:

• Whether your images have meaningful alt text
• Whether your headings follow a logical order
• Whether your color choices meet contrast requirements
• Whether videos have captions
• Whether links say where they go
• What your theme, page builder or plugins output on the front end

In practice, most front-end accessibility issues come from things you add on top of core, not from core itself. Treat "it's WordPress" as neutral: it neither protects you nor dooms you.

Choosing an accessibility-ready theme

The WordPress.org theme directory has an "Accessibility Ready" feature tag. Themes carrying it have been reviewed against a set of accessibility requirements by the WordPress themes team. That is a useful filter, but it has limits:

• The tag reflects a review at a point in time, and it covers the theme's own templates, not your content or your plugins.
• Customization can undo it. Changing colors, fonts or layouts can introduce new contrast or focus problems.
• Commercial themes sold outside the directory may claim accessibility without the same review. Ask for specifics rather than accepting a badge.

What to test in any theme

Before committing to a theme, test a demo page or your own staging site:

• Keyboard use. Press Tab through the whole page. Can you reach every link, menu item and button, and see where focus is? See WCAG 2.1.1 Keyboard and WCAG 2.4.7 Focus Visible.
• Skip link. Is there a "skip to content" link that appears on focus? See WCAG 2.4.1 Bypass Blocks.
• Menus. Do dropdowns open with the keyboard, and can you close them with Escape?
• Zoom. Zoom the page to 200 percent. Does text stay readable without content being cut off? See WCAG 1.4.4 Resize Text.
• Contrast. Check body text, buttons, links and placeholder text against their backgrounds. See WCAG 1.4.3 Contrast (Minimum).
• Page language and titles. Confirm the page declares its language and has a descriptive title. See WCAG 3.1.1 Language of Page and WCAG 2.4.2 Page Titled.

Page builders and "div soup"

Visual page builders make layout easy, but some generate deeply nested, generic <div> elements where meaningful HTML should be. This is often called "div soup." The concern is that assistive technology relies on real structure: headings, lists, landmarks, buttons and links.

Common patterns to look for:

• Headings chosen for looks. A builder lets you pick "H4" because it is small, not because it fits the outline. Headings should follow document structure, not styling.
• Clickable divs. A <div> with a click handler is not a button. It is not focusable or operable by keyboard unless someone adds that behavior.
• Fake lists and tables. Rows of divs styled to look like a list or table lose their structure. See WCAG 1.3.1 Info and Relationships.
• Custom widgets. Tabs, accordions, sliders and modals need correct roles, states and keyboard behavior. See WCAG 4.1.2 Name, Role, Value.

Here is the difference in markup:

<!-- Not operable by keyboard or announced as a button -->
<div class="btn" onclick="openMenu()">Menu</div>

<!-- Focusable, keyboard-operable, announced correctly -->
<button type="button" aria-expanded="false" aria-controls="site-menu">Menu</button>

Page builders vary a great deal, and versions change. Rather than trusting a general reputation, inspect the actual output of the builder on your own pages using your browser's developer tools, and test the widgets you use with a keyboard. The block editor (Gutenberg) tends to output simpler markup, but blocks and third-party block libraries are not automatically accessible either.

Auditing your plugins

Every plugin that adds something visible to the front end is part of your accessibility surface. Common offenders include sliders, popups, cookie banners, form builders, tabs and accordions, sticky headers, and chat widgets.

A practical plugin review

List every active plugin, then sort them into two groups:

• No front-end output (backups, security, caching). These rarely affect accessibility directly.
• Front-end output. Test each one individually.

For each plugin with front-end output, check:

• Can you operate it entirely with a keyboard?
• Does focus move sensibly, especially for popups and modals? Can you close a modal with the keyboard and return to where you were?
• Do form fields have real, visible labels? See WCAG 3.3.2 Labels or Instructions.
• Do auto-advancing sliders or carousels have a way to pause?
• Is the plugin still maintained? Check when it was last updated and whether the developer publishes accessibility information.

If a plugin fails and cannot be configured or replaced, consider whether the feature is worth keeping. Removing a broken popup is often easier than fixing it.

About accessibility overlay plugins

Some plugins promise to fix accessibility automatically with a widget or script. Their effectiveness is widely disputed, and they have been named in legal actions. Read our overview of overlays and lawsuits before relying on one. Fixing the underlying theme, plugin and content problems is more dependable than layering a tool on top.

Alt text in the media library

Alt text is one of the most common WordPress problems because the workflow invites skipping it. When you upload an image, the media library has an "Alternative Text" field. If it is empty, WordPress does not invent a description for you.

Guidelines for good alt text under WCAG 1.1.1 Non-text Content:

• Informative images: describe what the image communicates in context, not every visual detail.
• Decorative images: leave the alt attribute empty (alt="") so screen readers skip them. In the block editor, this can be done by leaving the alt field blank, though behavior with theme-generated images varies, so verify in the page source.
• Images that are links: the alt text should describe where the link goes.
• Images of text: avoid them where possible, or repeat the text in the alt.
• Filenames are not alt text. "IMG_4032.jpg" tells a user nothing.

Note that the media library stores alt text with the image file, but the block editor lets you override it per placement. Check the rendered page, not just the library.

<img src="team.jpg" alt="Three staff members at the front counter of our Denver shop">
<img src="divider.png" alt="">

Also review video and audio. Embedded videos need captions; see WCAG 1.2.2 Captions (Prerecorded).

A quick summary table

Putting it together

A workable order of operations:

1. Check your theme with a keyboard and at 200 percent zoom.
2. Review front-end plugins one at a time.
3. Inspect page builder output for real headings, buttons and lists.
4. Audit media library alt text and video captions.
5. Run an automated scan, then manual checks for what tools cannot catch. Our WCAG 2.1 AA checklist is a good reference.
6. Keep a dated record of what you tested and fixed. See dated accessibility audit records.

Automated tools catch only some issues, so manual keyboard and screen reader checks still matter. If you have received a demand letter, read what to do when you get an ADA website demand letter and speak with an attorney.

To see where your site stands, run a free scan at proofofaccess.com.

Frequently asked questions

Is an "Accessibility Ready" WordPress theme enough to make my site accessible?

No. The tag indicates the theme's templates passed a review against certain requirements, but it does not cover your content, page builder output or plugins. Customizations can also introduce new issues, so you still need to test the finished site.

Do page builders make WordPress sites inaccessible?

Not automatically, but some generate generic nested markup and custom widgets that lack proper structure or keyboard support. The result varies by builder, version and how you use it. Inspect the actual output and test interactive elements with a keyboard.

Does WordPress add alt text to my images for me?

No. WordPress provides an Alternative Text field in the media library, but leaves it blank unless you fill it in. You should write alt text that fits how each image is used, and leave it empty for purely decorative images.

Should I install an accessibility plugin to fix everything?

Be cautious. Tools that promise automatic fixes have limits, their effectiveness is disputed, and they cannot repair every issue in your theme, plugins or content. Fixing the underlying problems is generally more reliable.

How often should I re-check my WordPress site?

Re-check after theme, builder or plugin updates, and whenever you add new page types or features. Content changes matter too, since new images, videos and headings can introduce fresh issues. Keeping dated records of each check helps you show what was reviewed and when.

Related

• WCAG 2.1 AA checklist for business websites
• Got an ADA website demand letter? What to do in the first two weeks
• WCAG 1.1.1 Non-text Content
• Do accessibility overlay widgets prevent ADA lawsuits?

Proof of Access provides technical accessibility assessments. We are not a law firm and nothing on this page is legal advice. If you have received a demand letter or a lawsuit, talk to an attorney.