The European Accessibility Act (EAA) has applied since 28 June 2025. If you sell to consumers in the EU, your online store is very likely in scope. The technical benchmark is EN 301 549, which points to WCAG 2.1 Level AA.
Most WooCommerce owners I talk to aren't against accessibility. They're stuck because "make the site accessible" sounds like a six-month agency project. It doesn't have to start that way. You can do a useful first audit in one afternoon by focusing on the pages where a barrier actually costs you a sale.
This guide walks through that afternoon.
Quick note: this isn't legal advice. Whether the EAA applies to you depends on things like company size (microenterprises providing services have an exemption) and where your customers are. If you're unsure, ask a lawyer who knows EU law.
Why start with the purchase flow
A customer who can't read your blog post is a missed visitor. A customer who can't get through your checkout is a lost sale and the person most likely to complain. In WooCommerce, the pages that matter most are almost always the same five:
- The shop/category page
- A single product page
- The cart
- The checkout
- My Account (login, registration, orders)
If those five work for someone using a keyboard, a screen reader, or zoom, you've covered most of what an EAA-minded customer actually does on your site.
Step 1: Run an automated scan (30 minutes)
Automated tools can't make you compliant. They reliably catch only about a third to a half of WCAG issues. But they find the cheap, common problems fast, so you can spend your manual time on what really needs a person's judgement.
The industry-standard engine is axe-core, which is open source. You can run it through browser extensions, or inside WordPress with a plugin. I built OpenAisle, an accessibility scanner for WooCommerce, for exactly this WooCommerce case. It's a free plugin that runs a bundled copy of axe-core on your own server against your real, rendered shop, product, cart, checkout, and My Account pages. Nothing leaves your server. It maps each finding to a WCAG criterion, the WooCommerce flow it affects, and whether it falls under EAA/EN 301 549.
Whatever tool you use, scan the rendered pages, not just your theme's source code. Many WooCommerce problems, like low-contrast sale badges, unlabeled variation dropdowns, and AJAX cart messages, only appear once JavaScript has run.
Step 2: Fix the usual suspects (1–2 hours)
These are the failures that show up again and again on WooCommerce stores.
Missing product image alt text (WCAG 1.1.1). Every product photo needs a short description of what it shows, like "Navy linen shirt, front view", not "IMG_4821.jpg" or the product name repeated. Check your whole catalog, not just one product. Stores with hundreds of SKUs usually have far more gaps than they expect.
Low colour contrast (WCAG 1.4.3). Grey placeholder text, pale "Sale!" badges, and light buttons are the classic culprits. Normal text needs a contrast ratio of at least 4.5:1, and large text needs 3:1.
Form fields without labels (WCAG 1.3.1, 3.3.2, 4.1.2). Checkout fields, coupon boxes, quantity inputs, and variation selects (size, colour) all need a programmatic label, not just placeholder text that disappears when you start typing.
Error messages that aren't announced (WCAG 3.3.1, 4.1.3). When checkout validation fails, a screen reader user needs to hear what went wrong and where. Test it on purpose by submitting checkout with a required field left empty.
Buttons and links with no accessible name (WCAG 2.4.4, 4.1.2). Icon-only buttons are the usual problem: the cart icon, the "×" that removes an item, the search magnifier. They need text a screen reader can read.
Missing or skipped headings (WCAG 1.3.1). Your product name should be a real heading, and headings shouldn't jump levels just to get a certain font size.
Many of these fixes are a theme setting, a CSS change, or filling in a field. Write down each one as you fix it.
Step 3: Do the manual checks no tool can do (1 hour)
Put your mouse away and try to buy something.
- Keyboard only. Use Tab, Shift+Tab, Enter, and Space to go from the shop page through to placing an order. Can you always see where focus is? Can you open and close the mini-cart, pick a variation, and apply a coupon? Do you ever get stuck?
- Zoom to 200% and 400%. Does the checkout still work, or does content overlap or disappear (WCAG 1.4.4, 1.4.10)?
- A screen reader for five minutes. NVDA (free, Windows) or VoiceOver (built into macOS and iOS) is enough. Listen to your product page. Do the price, the variation choices, and "Add to cart" make sense without seeing the screen?
- Payment gateways and third-party widgets. Embedded payment fields, cookie banners, and chat widgets often bring their own barriers. If you can't fix them yourself, record them and ask the vendor.
Automated scanners can't judge any of this reliably, and these checks are where you'll find the problems that actually block purchases.
Step 4: Publish an accessibility statement
Under the EAA, service providers are expected to give information about how their service meets accessibility requirements. A good statement says, in plain language:
- which standard you're working towards (WCAG 2.1 AA / EN 301 549),
- what you've tested and when,
- known issues you're still working on,
- how a customer can contact you if they hit a barrier.
Be honest. A statement that lists known gaps and a contact route is more credible than one claiming "100% compliant." (OpenAisle's free version includes a basic statement template you can start from.)
Step 5: Keep a record and re-check
Accessibility isn't a one-time badge. New products, theme updates, and plugin updates all bring regressions back. What protects you, and your customers, is a documented, ongoing process:
- Save your scan results with dates.
- Log what you fixed and when.
- Re-scan after theme or plugin updates, and on a regular schedule (monthly is a sensible start).
A dated record of steady improvement is a good-faith answer if anyone asks what you're doing about accessibility. It also gives you one number to watch improve.
The one-afternoon checklist
- [ ] Automated scan of shop, product, cart, checkout, My Account
- [ ] Alt text on product images across the catalog
- [ ] Text and button contrast fixed
- [ ] Every form field has a real label
- [ ] Checkout errors are announced and explained
- [ ] Icon buttons have accessible names
- [ ] Full keyboard-only purchase completed
- [ ] Checkout works at 200% and 400% zoom
- [ ] Five-minute screen reader pass on a product page
- [ ] Accessibility statement published with a contact route
- [ ] Results and fixes saved with dates, re-scan scheduled
Where to go from here
You won't reach full WCAG 2.1 AA in an afternoon, and no tool can promise that you will. But you'll have fixed the most common barriers in the part of your store that makes money, and you'll have a record showing you're taking it seriously.
If you want to run the automated part inside WordPress, OpenAisle is free on WordPress.org. It gives you a 0–100 score, a severity-sorted issue list with how-to-fix guidance, an EAA-relevance filter, and a catalog-wide alt-text audit. The optional Pro upgrade adds AI-written alt text using your own OpenAI or Gemini API key, PDF compliance reports, and scheduled re-scan reminders. The free version covers everything in this guide.
