Skip to main content

Accessibility plugins for WordPress: what they fix and what they miss

· WordPress · accessibility · WCAG · plugins

An accessibility plugin for WordPress solves a narrow slice of a wide problem. The slice is real and worth fixing — focus styles, skip navigation, ARIA landmark roles — but it represents perhaps 15 to 20 percent of what WCAG 2.1 AA actually requires. If you install a plugin and assume your WooCommerce store is compliant, you will find the gaps when a regulator or assistive technology user does. This guide explains exactly what gets fixed, what does not, and how to build a realistic compliance plan.

What WordPress accessibility plugins actually fix

The techniques that accessibility overlay and remediation plugins apply are those that can be injected into a rendered page through JavaScript, without touching your CMS content or theme source files.

Skip navigation links. A "Skip to main content" link at the top of every page lets keyboard users jump past repeated navigation. A plugin can inject this link reliably across all templates. It is one of the simpler WCAG fixes and one that plugins handle well.

Focus indicator styles. Many commercial WordPress themes remove the browser's default focus ring with outline: none in CSS. A plugin can re-inject visible focus styles so keyboard users can see where they are on the page. This addresses WCAG 2.4.7 (Focus Visible) without requiring theme edits.

ARIA landmark roles. Plugins can add role="main", role="navigation", role="banner", and similar attributes to structural page elements, giving screen reader users a way to jump between sections. This helps when a theme generates HTML that lacks semantic structure.

Adjustable text size and contrast. Some plugins add a widget that lets users increase font size or switch to a high-contrast mode. These are not WCAG requirements — the standard applies to the default page state, not to optional overlays — but they can improve usability for people with low vision.

These fixes have genuine value. A page with visible focus styles and working skip navigation is meaningfully more accessible than one without. The problem is the scope of what they cannot touch.

What accessibility plugins cannot fix

The things plugins cannot fix are, in most cases, the things that matter most for WCAG compliance.

Missing alt text on existing images. A plugin cannot write alt text for your product photos. It cannot see what is in the images. Every image uploaded to WordPress without alt text stays inaccessible after any plugin runs. WCAG 1.1.1, the most-cited failure criterion in EU accessibility audits, requires meaningful text alternatives for all non-decorative images. This is a content problem, not a code problem, and it must be fixed at the source.

Semantic HTML structure. If your theme outputs a heading hierarchy that jumps from <h1> to <h4>, or uses <div> elements where <button> or <nav> belong, a JavaScript overlay cannot restructure the DOM cleanly. Injecting ARIA attributes over poor HTML is fragile and frequently produces inconsistent screen reader behaviour.

Colour contrast of theme text. If your theme renders body text in a colour that fails the 4.5:1 contrast ratio required under WCAG 1.4.3, a plugin cannot change your brand colours. The fix requires a theme CSS change.

Keyboard navigation in custom components. Mega menus, image galleries, custom date pickers, and modal dialogues built for WordPress or WooCommerce often trap keyboard focus or skip it entirely. Fixing these requires code changes to the component itself. An overlay plugin can add ARIA attributes, but if the component does not respond to arrow keys or return focus correctly when closed, the problem remains.

Page language declarations. If your <html> element lacks a lang attribute, screen readers will announce your content in the wrong language voice. A plugin sometimes patches this, but for multilingual WooCommerce stores with per-page language settings, the fix needs to live in the theme or a dedicated multilingual plugin.

In practice, overlay-style plugins have drawn significant scrutiny from accessibility advocates and regulators. The US Federal Trade Commission investigated accessiBe, a prominent overlay provider, following formal complaints that the product misrepresented its compliance coverage. No UK or EU enforcement action has followed the same fact pattern at the time of writing, but the underlying concern is well-founded: a plugin that tells users their site is compliant when material WCAG failures remain is a compliance risk, not a compliance solution.

How to add alt text to WordPress images

Alt text in WordPress lives in the Media Library entry for each image. Here is how to add or edit it.

For a single image:

  1. Go to Media > Library in the WordPress admin.
  2. Click the image you want to edit.
  3. In the "Attachment Details" panel on the right, find the "Alt Text" field.
  4. Type your description and click "Update".

The change applies wherever that image is used across the site.

For WooCommerce product images:

Product images in WooCommerce have their own alt text field, separate from the Media Library entry. Go to Products > the product, then scroll to the Product Image box on the right. Hover over the image and click the edit pencil icon. Update the "Alt Text" field there.

For a catalogue of hundreds of products, the only realistic path is bulk processing. WordPress does not offer native bulk alt text editing, so options are an import via a plugin that supports CSV editing of media metadata, or an automated tool that generates alt text and writes it back to the database through the WordPress API.

WooCommerce-specific considerations

WooCommerce product pages carry three distinct categories of images, each requiring separate attention.

Main product image: The primary photograph shown at the top of the product page. This carries the most weight for screen reader users who arrive on a product URL directly.

Product gallery images: Additional photos (side views, detail shots, lifestyle images) displayed in the gallery below the main image. Each needs its own alt text describing what that specific view shows. "Navy linen shirt, collar detail" is more useful than repeating the product name for every image in the gallery.

Variation images: If your product has colour or style variants and each variant has its own image, each image needs distinct alt text that identifies the variant. "Ceramic mug in sage green" and "Ceramic mug in terracotta" are separate descriptions, not the same text applied to both.

Failing to address variation images is a common gap. Most audits find that main product images have reasonable alt text added during setup, but variation and gallery images were uploaded later and never updated.

A realistic approach for WCAG 2.1 AA compliance on WordPress

Achieving WCAG 2.1 AA on WordPress requires combining automated tooling with manual fixes. Here is a sensible order of operations.

Start with an audit. Run a free WCAG scan of your storefront homepage and two or three representative product pages. The results give you a prioritised list of failures: missing alt text, contrast failures, missing form labels, keyboard navigation issues.

Fix what plugins can actually fix. Install a reputable accessibility plugin to handle skip navigation and focus styles. These are quick wins that address real WCAG criteria.

Address alt text systematically. Export your Media Library and identify images with empty alt text. For a WooCommerce catalogue, work through product images first, then gallery images, then variation images. For anything above 100 products, automated generation and review is faster than manual writing.

Fix theme-level issues manually or with your developer. Colour contrast, heading hierarchy, and broken keyboard navigation in custom components require code changes. Budget for this separately; it is typically a one-off remediation project.

Test with a real screen reader. NVDA (Windows, free) and VoiceOver (macOS and iOS, built-in) let you navigate your site as a screen reader user would. The experience is often revealing even after automated testing looks clean.

Document your status. The EAA requires an Annex V accessibility statement that names what meets the standard, what does not, and what the remediation timeline is. That statement cannot be generated by a plugin — it requires an honest audit of your current state.

Run a free WCAG scan on your storefront to see exactly where you stand — then start free to fix image alt text at scale.