Nine mistakes to avoid when buying an accessibility checker

A checker can save time, but only if you know which pages it checks and what happens after it finds a problem. Here are nine ways WooCommerce merchants buy more confidence than evidence.

Disclosure and method (September 28, 2026): AmazingPlugins publishes WooCommerce Accessibility Fixer. This guide uses W3C evaluation guidance, public vendor documentation, and the released Fixer 1.5.1 package. We have not run a controlled comparison of vendors. The advice is a test plan, not a legal assessment.

1. Treating installation as proof

A widget, plugin, scanner, or audit contract does not prove that customers can use your checkout. Ask which page states were tested and which barriers remain. WCAG conformance applies to full pages, not the presence of a tool. Run a purchase with a keyboard and screen reader.

2. Trusting one compliance score

An automated score covers the checks and states the tool can reach. It can miss a payment error, a variation picker, or an account-only page. Ask for the failed element, WCAG criterion, test method, and unresolved findings. The W3C notes that tools can return false or misleading results.

3. Ignoring WooCommerce states

Product variations, cart updates, coupon errors, shipping choices, and third-party payment fields behave differently from a static page. Check them on your actual theme and extensions. Ask a vendor to demonstrate coverage rather than assuming that “WordPress support” includes your checkout.

4. Asking only for a WCAG version label

WCAG 2.2 added criteria such as focus not obscured and target size. A dashboard labeled “WCAG 2.2” may still need manual checks for those interactions. Ask which criteria are automated, which require a person, and how each finding is verified. See the W3C list of additions.

5. Paying before trying the purchase flow

Get a baseline on staging first. Use only a keyboard to choose a variable product, update the cart, trigger a checkout error, correct it, and submit an order. Repeat with a screen reader. Give each vendor the same scenario and compare what changed. Check the current quote and contract after you know what work you need.

6. Confusing page count with coverage

A crawler may scan hundreds of product URLs while never opening the mini-cart or triggering validation. Ask how it reaches dynamic and logged-in states. A smaller test covering real interactions can reveal more than a large count of static pages.

7. Buying findings without a repair plan

A report is useful when each issue has an owner. Some fixes belong in content, some in a theme or extension, and some may be handled by a plugin or vendor service. Ask what the product changes automatically, what it recommends, and what it cannot touch.

8. Accepting automatic text as final content

An empty product-image alt attribute can be detected. A product title may be a useful fallback, but only a person can decide whether it describes a specific image’s purpose. The same applies to link purpose, headings, and instructions. Put manual review in the plan.

9. Skipping retests after updates

A checkout extension or theme update can change focus order, labels, and errors. Keep a dated issue log and rerun the purchase flow after changes. The W3C evaluation report template shows how to record scope and methods, not just a pass/fail claim.

Before you buy

  • Test product, cart, checkout, and account states.
  • Ask what is automated and what needs human review.
  • Ask whether a fix is saved in your code or runs while the tool is active.
  • Request a dated list of findings, fixes, and unresolved issues.
  • Confirm the current quote, limits, support, and renewal terms.

Where our plugin fits

WooCommerce Accessibility Fixer 1.5.1 contains nine free, targeted fixers. They include product-image alt fallbacks, selected form and error handling, focus styles, landmarks, and skip links. Some use inline CSS or JavaScript. The plugin does not scan a catalog, measure text contrast, repair every checkout label, or provide a Pro tier or PDF report. Test its effect on your theme and extensions as you would any other tool.

Questions buyers ask

No product can guarantee that. Use the tool to find and resolve actual barriers, keep records of testing, and seek qualified advice for legal questions specific to your business.

Are visitor widgets only cosmetic?

No. accessiBe and UserWay both describe automated adjustments as well as visitor controls. Verify the result on your site and ask about documented limitations.

Is a free scanner enough?

It is a useful starting point. You still need someone to act on findings and test the interactions the scanner cannot assess.

Sources