WooCommerce EAA compliance plugin guide for 2026
A plugin can help find and remove accessibility barriers in a WooCommerce store. It cannot determine whether the European Accessibility Act (EAA) applies to your business or certify that your entire service meets it. Choose a tool by the parts of the shopping journey it actually checks, then test the results yourself.
Reviewed September 28, 2026 against the EAA directive, W3C’s WCAG 2.2 standard, and the public AP Accessibility Fixer for WooCommerce 1.5.1 release. For a task list rather than plugin selection, use the EAA ecommerce checklist.
Check scope before shopping for software
The directive covers specified products and services, including ecommerce services offered to consumers in the EU after June 28, 2025. It defines a service provider to include someone making offers to consumers in the Union. It also exempts microenterprises providing services from its accessibility requirements and contains other qualifications. Member states implement and enforce the directive through national law. An EU site visit by itself does not answer whether your business is covered. Get advice on your particular service and markets when you need a legal determination.
The EAA’s service requirements cover information, websites and mobile services, support, and parts of the ecommerce transaction. Do not reduce the question to a single WCAG version or a plugin badge. WCAG gives your team testable web criteria; the directive and applicable national rules determine the obligation.
Ask what the plugin actually inspects
A store page is assembled from your theme, WooCommerce, product options, filters, payment services, and other extensions. Ask the plugin vendor for a check-by-check list, then compare it with your own buying path:
| Store area | Questions to ask |
|---|---|
| Products | Does the scan cover the images, gallery controls, variations, stock messages, and add-to-cart state? How many products does one scan include? |
| Search and filters | Can someone use each control with a keyboard and learn when results change? |
| Cart and checkout | Are field names, instructions, errors, coupon panels, shipping choices, and payment controls covered? |
| Account | Can customers sign in with a password manager or paste a code? Are recovery errors clear? |
| Other services | Who owns chat, cookie consent, reviews, loyalty panels, and payment iframes? Can you test them in context? |
A scanner can flag certain missing attributes or suspicious markup. It cannot judge whether product alt text is useful or whether a payment iframe works with a screen reader. Ask how to inspect, reverse, and retest each automatic change. A generated report should say which URLs and states were checked and what remains open.
Test the purchase path after every change
Use a staging copy for plugin changes. Run a baseline check on a simple product, a variable product, cart, checkout, and account pages. Add pages created by your extensions. Then:
- Complete a purchase with a keyboard. Watch focus through menus, dialogs, validation errors, and payment.
- Repeat with a screen reader. Listen for product options, price changes, field names, and order confirmation.
- Review image alternatives in context. A copied product title may be too vague; a decorative image may need empty alt text.
- Check text contrast against the rendered background and test small controls at mobile widths.
- Record the URL, browser, steps to reproduce, change made, owner, and retest result.
The U.S. DOJ makes a useful general point: a clean automated report does not prove that a site is accessible. The same technical limit applies when you use a plugin as part of EAA work.
What our plugin does in the public release
Disclosure: AmazingPlugins publishes AP Accessibility Fixer for WooCommerce. We reviewed the public WordPress.org 1.5.1 package and code on September 28, 2026. It is free, with nine fixers and no Pro tier.
Its scanner fetches configured WooCommerce pages, a distinct front page, and up to three randomly selected published product pages per run. Its checks are limited HTML heuristics, not a full WCAG or EAA audit. The fixers include a fallback for missing product-image alt text, a skip link, selected focus and error styles, and form labels within content processed by WordPress’s the_content filter. Some fixes use inline JavaScript. It does not measure and repair arbitrary text contrast, audit every product, or guarantee that custom checkout and payment controls work. The report download in this release is print-friendly HTML, not a promised PDF.
Use it for the issues it can identify or change. Keep your own test results and a list of work still assigned to your theme, checkout, content, or payment provider.
Questions merchants ask
Is WCAG 2.2 AA the EAA’s universal legal requirement?
No single WCAG 2.2 AA sentence covers every EAA service obligation. W3C recommends adopting 2.2 as a current technical target. Check the directive, relevant standards, and national law for the service you provide.
Will an accessibility toolbar satisfy the EAA?
A toolbar may help with a narrow preference, but it cannot by itself show that product options, checkout, payment, and support are usable. Judge any plugin, including ours, by the barriers it actually removes and the results of manual testing.
What should I fix first?
Start with a task a buyer cannot finish: choosing a product, adding it to the cart, paying, or reaching support. Rank the remaining issues by their effect on users and retest after each change.