Guide

WordPress accessibility: check & fix

Last updated: 30 June 2026

WordPress powers a huge share of the web, so "is my WordPress site accessible?" is one of the most common compliance questions — especially with the EU Accessibility Act now in force and ADA lawsuits ongoing. WordPress itself can be made accessible, but whether your site is depends almost entirely on your theme, plugins, page builder, and content. Here's where the problems come from and how to find them. (General information, not legal advice.)

Where WordPress accessibility issues come from

  • Your theme. The biggest factor. Themes vary wildly; look for ones tagged accessibility-ready in the WordPress theme directory — but note even those can be broken by customization.
  • Plugins. Sliders, pop-ups, cookie banners, social feeds, and booking widgets inject markup you didn't write — a frequent source of contrast, keyboard, and focus problems.
  • Page builders. Elementor, Divi, WPBakery etc. make it easy to ship <div> soup, skipped heading levels, and tiny/low-contrast text.
  • Your content. Images without alt text, "click here" links, colour-only buttons, and uploaded PDFs are all owner-controlled.

The common problems to look for

  • Missing alt text — add it in the Media Library / block settings for every meaningful image (see alt text best practices).
  • Colour contrast on buttons, links, and muted text (see contrast requirements).
  • Heading structure — one h1 per page, no skipped levels; the block editor makes it easy to misuse heading sizes for styling.
  • Keyboard & focus — menus, sliders, and pop-ups that can't be operated or dismissed with a keyboard (see keyboard testing).
  • Forms — contact/checkout form plugins often miss labels and clear errors (see accessible forms).

Why an "accessibility plugin" won't fix it

Plugins and widgets that promise "one-click accessibility" or an overlay toolbar do not make a WordPress site compliant — they layer controls on top without fixing the underlying markup, and the accessibility community (and many lawsuits) treat them as insufficient. Fix the real issues in your theme, blocks, and content instead. See overlays vs real compliance.

How to audit your WordPress site

You don't need to check every post — check every template: home, a standard page, a blog post, an archive/category page, and (if you use WooCommerce) product, cart, and checkout. Scan your site free with WCAGwise on one page of each to find the WCAG 2.2 AA issues and exactly where they are, fix them in the theme/blocks/content, then do the manual keyboard and screen-reader pass — automated checks catch a meaningful share but not everything. With Pro you can roll those template scans into one client-ready report. WCAGwise is an audit aid, not a legal guarantee.

Related guides