No checklist can promise that your WooCommerce store will never face an ADA claim. You can, however, remove barriers that stop people from shopping and keep a reliable record of what you tested and fixed. That is more useful to customers than a compliance badge.

Reviewed September 28, 2026 against the U.S. Department of Justice’s web accessibility guidance and the W3C WCAG 2.2 standard. This is a technical work plan, not a legal opinion about a particular store.

What the ADA guidance says

The DOJ says Title III applies to businesses open to the public and that their goods and services offered on the web must be accessible. It gives examples of barriers including poor contrast, absent image alternatives, forms without usable labels and errors, and mouse-only navigation. The DOJ does not have a Title III regulation setting out a detailed website technical standard for private businesses. WCAG is helpful technical guidance, not a universal statutory safe harbor.

Do not borrow deadlines from the DOJ’s separate Title II web rule for state and local governments. Nor can you assume that every online store has identical legal facts. Ask qualified counsel about a specific claim, settlement demand, or question of coverage.

Find the barriers in the actual purchase path

Start with a representative product, a variable product, cart, checkout, account sign-in, and any third-party payment step. Include mobile navigation and support contact. A scan can find some missing names, image alternatives, and contrast candidates. The DOJ cautions that a clean automated report does not necessarily mean everything is accessible.

Then test tasks, not just pages:

  1. Choose and buy a product with a keyboard. Follow focus through variations, cart drawers, coupon panels, shipping options, and payment. If you cannot reach or activate a control, record the step.
  2. Repeat with a screen reader. Listen for the product option, price or stock change, field name, error, and order confirmation. The tester must be able to tell what happened.
  3. Review the content. Describe meaningful product images in context. An empty alt is appropriate for a decorative image; copying a title onto every image is rarely enough for a gallery.
  4. Check form recovery. Trigger a checkout error. Confirm the message identifies the problem and the customer can find and correct the field without starting over.
  5. Inspect third-party controls. Payment iframes, chat, cookie banners, and product add-ons are part of the experience even when someone else wrote them.

Prioritize a blocker that prevents a purchase or prevents someone from getting help. Next fix patterns repeated across templates. Recheck after changing a theme, plugin, or checkout provider.

Keep a record that describes the work

For each finding, keep the URL, date, browser, input method, steps to reproduce, person responsible, change made, and retest result. Note which pages a scanner did and did not cover. Keep an open-issues list rather than hiding unfinished work behind a green score.

An accessibility statement can give customers a way to report problems and explain known limits. Publish one that reflects your real process and gives a working contact route. Do not claim that the statement, a scan export, or a plugin install prevents litigation. The DOJ describes automated tools as aids that need careful use, not certificates.

If you receive a demand letter, preserve the relevant records and get advice from qualified counsel about the claim and response. Continue fixing barriers for customers, but do not turn a technical blog post into a litigation playbook.

Assess plugin claims carefully

The FTC’s 2025 final order against accessiBe addressed unsupported claims that its automated product could make any site WCAG compliant. The order is about that vendor’s representations; it did not ban every overlay or declare that a different plugin guarantees compliance. Ask any vendor to show the specific checks and changes its tool makes, then verify the result yourself.

Disclosure: AmazingPlugins publishes AP Accessibility Fixer for WooCommerce. We reviewed the public WordPress.org 1.5.1 release and code on September 28, 2026. It is free, with no Pro tier. Its scan includes configured WooCommerce pages and up to three randomly selected published product pages per run. The fixers include a product-image alt fallback, a skip link, and selected focus, form, and error changes. They do not fix every checkout or payment flow, measure all text contrast, or establish ADA compliance. The report download is HTML.

Questions store owners ask

What is the fastest useful first step?

Try to complete a purchase with a keyboard. Record the first point where the task fails and the extension or template responsible. Run an automated scan as a second source of findings, not as a replacement for that task test.

Will WCAG conformance prevent a lawsuit?

No one can promise that a claim will not be filed. WCAG gives you concrete criteria to test and improve accessibility. A legal assessment depends on the facts of the business and claim.

Should I wait until every issue is fixed before publishing an accessibility statement?

You can publish a truthful statement with a contact method and known limitations while work continues. Make sure someone monitors that contact route and fixes reported barriers.