WordPress WCAG: What Plugins and Themes Can Actually Do

No. No plugin can read your whole site, understand what each element is meant to do, and rewrite it correctly. The plugins worth installing do narrower jobs: they add a skip link, prompt editors for alt text, or flag problems while you write a post. Those are useful. None of them turns a site into a WCAG-conformant one, and a plugin that says it does is repeating the promise overlays make.

The reason is structural. WordPress output is the product of your theme, your page builder, every active plugin and the content your team publishes. A plugin sees only its own slice. Automated checks help find problems, but they only reach part of the picture: Deque's analysis of 13,000+ audited pages found that automated tests caught 57% of all issues, counted by volume (Deque coverage report (opens in new tab)). The rest needs a human reading the page with a keyboard and a screen reader. For the wider picture, see our WordPress accessibility guide.

When people search for a free WCAG plugin download, they are usually looking at one of three very different products. Knowing which is which saves money and avoids a false sense of safety.

• Fix-helper plugins. These change small, well-understood things in your output, such as adding a skip link, requiring alt text on upload, or making focus outlines visible. WP Accessibility is the long-standing free example. They patch gaps; they do not audit.
• Editor-side checkers. These scan a post or page as you edit and show issues in the WordPress admin. Equalize Digital's Accessibility Checker has a free tier that works this way. They catch mistakes before publishing, but they look at the content as stored, not always the final page after your theme and other plugins have run.
• Overlay and widget plugins. These inject a toolbar or script that claims to repair the site in the browser. They do not change your source markup, and accessibility advocates have been publicly critical of them for years. Our post on whether overlays work covers the evidence. If you already have one installed, treat it as an extra, not a fix.

Our recommendation in short: use a fix-helper and an editor-side checker if they suit your workflow, avoid relying on overlays, and test the finished pages with a scanner that loads them the way a visitor does.

There is no such thing as a WCAG-certified theme, so a theme page that uses that wording deserves a closer look. Instead of trusting a label, run through this short list on the theme's live demo:

1. Tab through the demo. You should always see where focus is, reach the menu, open and close dropdowns and modals, and never get stuck.
2. Look for a skip link. The first Tab press on a page should offer a link to skip to the main content.
3. Check the headings. There should be one logical h1, with h2 and h3 following in order, not chosen for their font size.
4. Test the contrast. Body text, buttons and placeholder text in the default colour scheme should hold up against their backgrounds.
5. Scan the demo URL. Run it through the WordPress accessibility checker or any other scanner and read what comes back.

A demo can look different from your finished site, so repeat the scan once your real content is in place.

1. Start from an accessibility-ready theme and keep customisations modest, especially colours and fonts.
2. Add one fix-helper and one editor-side checker if you want help while editing. Do not rely on an overlay as your main strategy.
3. Scan the rendered pages (home, a post, your contact form, checkout if you sell) with the WCAG checker. CompliaScan runs axe-core plus custom checks, 100+ accessibility checks in all, against the page as a browser sees it after your theme and plugins have run.
4. Fix what the scan finds, starting with contrast, missing labels, missing alt text and keyboard traps. AI fix suggestions are available with your own API key (bring-your-own-key) and are a starting point for a developer. Nothing changes your site's markup automatically.
5. Test by hand. Spend ten minutes with the keyboard only, and ideally some time with a screen reader, on your key pages.
6. Re-scan after every theme, plugin or builder update. Regressions usually arrive with updates.

Plans for scheduled scans are on the pricing page.