Website accessibility plugins for WooCommerce: what they can do

An accessibility plugin can find or change some problems on a website. It cannot tell you, by itself, whether customers can complete a purchase with a keyboard or screen reader. For a WooCommerce store, that distinction matters more than a score on a dashboard.

Disclosure and method (September 28, 2026): AmazingPlugins publishes WooCommerce Accessibility Fixer. This guide draws on W3C guidance, public vendor documentation, and the released Fixer 1.5.1 package. We did not run a controlled comparison of the vendors or audit a representative WooCommerce store for this article. Product scope can change.

Start with the problem you need to solve

A scanner identifies possible failures. A fixer changes selected markup, styles, or behavior. A widget offers controls to visitors and may also make automated adjustments. Some vendors combine all three with human audits and custom work. Check the exact product and plan instead of treating these as exclusive categories.

ApproachUseful forStill needs work from you
ScannerFinding repeatable issues across pagesReviewing results and fixing the site
Targeted WordPress pluginChanging known WordPress or WooCommerce patternsTesting your theme, extensions, and content
Visitor widget with automated remediationUser controls and runtime adjustmentsVerifying what was changed and what remains
Expert audit or serviceTesting complex flows and planning custom fixesImplementing and maintaining the agreed fixes

The W3C’s evaluation-tools guide is clear: tools help, but some checks require human judgment and automated results can mislead. WCAG 2.2 conformance is evaluated on full pages, including interactive states.

What to check on a store

Start with the pages customers use: search, product details, variations, cart, checkout, payment errors, and order confirmation. A homepage scan misses many of those states. Check at least these questions:

  • Can a keyboard user reach every control, operate it, and see where focus is?
  • Do form fields have useful names and instructions, including fields added by extensions?
  • Are validation errors announced and associated with the right fields?
  • Does the screen reader announce product options, price changes, cart updates, and totals?
  • Do product images have alternative text that serves their purpose?
  • Is text readable against its background in each theme state, including errors and disabled controls?

Use automated checks to catch repeatable problems. Then complete the purchase with a keyboard and screen reader. Record the page, state, steps, and result. Recheck after theme, checkout, or payment updates.

Read plugin claims carefully

A claim to “fix contrast” might mean a preset visitor control, a CSS rule for selected elements, or a measured contrast audit across every theme state. Those are different jobs. Ask for the exact elements covered and test them. Similarly, “form labels” may cover a standard checkout template but miss a custom payment form or a field inserted in an iframe.

Inspect whether a fix changes saved theme or content files, modifies server-rendered output, or runs in CSS or JavaScript while the tool is active. Runtime work can be useful. It also means you need to test loading failures, conflicts, and behavior when the tool is removed. A WordPress-native plugin can use inline scripts too; installation type alone does not tell you whether a fix survives removal.

An audit report should say what was checked, what was fixed, and what remains. The W3C report template includes scope, process, results, and recommendations. A badge or single score cannot replace that detail.

Where our plugin fits

WooCommerce Accessibility Fixer 1.5.1 is a free WordPress plugin with nine targeted fixers: alternative text, focus indicators, selected focus and error contrast styling, error messages, some form labels, heading hierarchy, selected modal keyboard behavior, landmarks, and skip links. These are implementation areas, not nine WCAG criteria certified as passing.

The form-label fixer works on selected rendered content; it does not fix every checkout or payment field. The contrast fixer does not measure text contrast or recolor a theme to meet a ratio. Several fixers use inline JavaScript or CSS. There is no released Pro tier, catalog-wide scanner, PDF compliance report, or one-click WCAG certificate. Inspect each change on your own theme before relying on it.

The plugin cannot write contextually useful product image descriptions, repair every custom widget, or test whether a person can finish a purchase. For those jobs, assign content review, development, and hands-on testing.

A practical evaluation workflow

  1. Make a staging copy and record the starting state. Note the theme, checkout type, payment provider, and active extensions.
  2. Run an automated check on several page types. Include product, cart, and checkout, not just the homepage. Save the findings.
  3. Install one candidate and inspect the change. Test with the tool active and inactive. Note which changes depend on a script or the plugin staying enabled.
  4. Use a keyboard through a full purchase. Include invalid and corrected entries so you see error handling.
  5. Repeat with a screen reader. Confirm labels, status messages, totals, and focus order in the same flow.
  6. Review content and visual states. Check alternative text, instructions, headings, zoom, mobile layouts, and contrast. Human judgment is required here.
  7. Fix what remains and retest. Give each unresolved issue an owner. Repeat after changes to themes, templates, and extensions.

This process produces a useful list of verified improvements and remaining barriers. It does not produce a legal guarantee. Requirements depend on where you operate and who you serve, so get qualified advice for a specific legal question.

Common questions

Does a plugin make a store WCAG compliant?

No single installation proves that. WCAG conformance concerns the full page. Automated tools can help find and fix selected issues, but a person must test content and interactions too.

Are widgets only cosmetic?

No. For example, accessiBe and UserWay describe automated adjustments as well as visitor controls. Ask which problems the specific product addresses and test the result on your store. Don’t infer coverage from the presence or absence of a floating button.

Is AudioEye only a reporting service?

No. AudioEye lists automated fixes and expert services alongside monitoring. Confirm what your plan includes and which fixes will reach your checkout.

Can I run more than one accessibility tool?

You can use multiple read-only evaluation tools. Before running multiple tools that change the page, test for duplicate controls, conflicting CSS or scripts, and different focus behavior. Run a full purchase after each change.

Should I keep an accessibility report?

Yes, if it describes actual testing and remaining issues. Record the date, pages, assistive technology, findings, fixes, and owners. A report is evidence of work performed, not proof that every page conforms.

Sources

Product descriptions were checked September 28, 2026. This guide is a documentation review, not a hands-on vendor benchmark or legal assessment.