If your UK business sells to consumers in the EU through its website, the European Accessibility Act (EAA) very likely applies to you, even though the UK never adopted it. Since 28 June 2025, online stores selling to EU shoppers have been expected to meet EN 301 549, which in practice means WCAG 2.1 AA. On a WordPress or WooCommerce site, most of the work is code fixes to forms, keyboard focus, contrast, headings and checkout. Budget roughly £350 to £5,000+ for a UK manual audit, then $2,000 to $8,000 for remediation on a typical small business site.
Below: who's in scope, why an overlay widget won't get you there, a WCAG 2.2 fix list for WordPress and WooCommerce, and what audits and fixes actually cost.
Does the European Accessibility Act apply to UK businesses?
Yes, if the UK business sells to EU consumers. It's the customer's location that counts, not where your company is registered. Scandiweb's EAA guide for online stores says a UK store selling to shoppers in Ireland, Germany or France has to meet the national version of the act in each of those countries.
| Your situation | Covered by the EAA? | Why |
|---|---|---|
| UK store shipping to consumers in EU countries | Yes | It's an e-commerce service to EU consumers |
| UK site taking paid online bookings from EU consumers | Possibly, get advice | It may count as concluding a consumer contract online |
| Store that sells only to verified business accounts | Generally no | The act covers consumer contracts, not B2B |
| Microenterprise: under 10 staff and turnover or balance sheet up to €2m | Exempt for services | Microenterprise exemption |
| Sells only to UK customers | No | The Equality Act 2010 still requires reasonable adjustments |
Two caveats. The microenterprise exemption is narrow: with 10 or more staff, or more than €2 million in both turnover and balance sheet, you're covered. And being outside the EAA doesn't mean you're off the hook. UK service providers already owe disabled customers reasonable adjustments under the Equality Act 2010.
It's easy to drift into scope without meaning to. On Wow Vastra I built a currency switcher and worldwide checkout so the store could sell beyond the UK. Changes like that can bring a UK store under the EAA, and accessibility is easy to overlook when you switch on international shipping.
What standard does the EAA expect your website to meet?
The European Accessibility Act expects websites to meet EN 301 549, whose web section is built on WCAG 2.1 AA. The EAA itself sets functional requirements, and you're also expected to explain how your service meets them. Most sites do that with an accessibility statement.
My advice: build and test against WCAG 2.2 AA. It includes everything in 2.1, and the newer criteria land right on product pages and checkout. They cover focus hidden behind sticky headers, minimum target sizes, not making people re-enter information, and accessible login. If you're paying to fix a site anyway, I don't see the point of aiming at the older version.
What are the penalties for not complying with the EAA?
Each EU member state sets its own European Accessibility Act penalties, ranging from €5,000 up to €450,000 at the top end. Germany's implementing law allows fines of up to €100,000. AudioEye's country table lists up to €450,000 in the Netherlands and €5,000 to €60,000 in Ireland. Those are statutory maximums, though. WebYes noted no confirmed fines under Germany's law as of June 2026.
So in the near term, a big fine isn't the likely problem. A complaint is. Then a regulator asking you to fix the service, and in the meantime, customers who give up because they can't get through checkout. That last one is costing you sales today, regulator or not.
Why don't accessibility overlays make a site compliant?
Overlays run on top of your existing markup and can't truly repair it. An overlay is a JavaScript widget, usually a little person icon in the corner, that promises to make your site accessible with one line of code. It has no idea what an unlabelled icon button does or what your product photo shows. It can't untangle a heading structure the designer picked for looks, or rebuild a variation picker made of clickable divs. Screen reader users already have their own assistive technology, and a widget can get in its way.
Regulators have noticed. In 2025 the US Federal Trade Commission finalised a $1 million fine against accessiBe for misrepresenting what its overlay could do. In the US, 22.6% of web accessibility lawsuits in the first half of 2025 targeted sites that had an overlay installed. I go through the US side in ADA website compliance: what it costs to fix your site.
A widget is not a fix
Conformance is judged on your actual pages. If an overlay is the only accessibility work you've done, assume the site still fails and budget for real code fixes.
What does WCAG 2.2 mean for a WordPress or WooCommerce site?
For a WordPress or WooCommerce site, WCAG 2.2 mostly comes down to six areas: forms, keyboard focus, colour contrast, headings, target sizes and checkout. On page builder sites, these problems tend to live in a handful of templates. That's good news for your budget. Fix the template once and every page using it is fixed too.
| Area | Common WordPress or WooCommerce problem | Fix | WCAG 2.2 criteria |
|---|---|---|---|
| Forms | Placeholder text used as the label, errors shown only in red | Visible labels, text errors linked to the field, autocomplete attributes | 1.3.1, 1.3.5, 3.3.1, 3.3.2 |
| Focus | Theme CSS removes outlines, sticky header covers the focused element | Clear focus style, scroll padding under sticky bars | 2.4.7, 2.4.11, 2.1.1 |
| Contrast | Light grey text, buttons placed on photos, pale sale badges | 4.5:1 for body text, 3:1 for large text and controls | 1.4.3, 1.4.11 |
| Headings | Heading levels picked for font size, several H1s per page | One H1, a logical H2 and H3 outline, styling done in CSS | 1.3.1, 2.4.6 |
| Targets | Tiny quantity buttons, colour swatches, close icons | At least 24 by 24 CSS pixels, or enough spacing | 2.5.8 |
| Checkout | Mouse-only variation pickers, cart drawers that lose focus, re-typing addresses | Native controls, managed focus, a same-as-billing option | 2.1.1, 2.4.3, 3.3.7 |
Forms
Contact, enquiry and newsletter forms are where page builders cause the most trouble. Error messages should say what went wrong in words, such as "Enter a valid postcode", so screen readers can announce them. Autocomplete on name, email, phone and address fields helps everyone, and 1.3.5 requires it.
Keyboard focus
Put your mouse away and press Tab from the top of your homepage. Every place you lose track of where you are goes on the fix list. Mega menus that only open on hover and popups you can't close with Escape are the other usual suspects.
Colour contrast
Brand palettes love light greys and pastels. Body text needs a 4.5:1 contrast ratio against its background. Large text, button borders, form field outlines and icons need 3:1. Text over hero images needs a solid or semi-opaque backing, not just a hopeful drop shadow.
Headings and structure
In a builder, it's tempting to pick H2 because it looks the right size. But screen reader users navigate by headings, so the outline has to make sense: one H1, then sections and sub-sections in order. Bricks lets you set the HTML tag on almost any element, and Elementor's heading widget has an HTML tag setting, so you can keep the look and fix the semantics. Clean headings help search engines too, so this overlaps with technical SEO work you'd want anyway.
Product pages and checkout
This is where a WooCommerce store passes or fails. A customer who can't pay can't buy. Check these:
- Variation swatches built as clickable divs should be real radio buttons or selects, so they work with a keyboard and announce their state.
- Add to cart messages should be announced through a live region, not just shown as a quiet green bar.
- Mini cart drawers should move focus into the drawer, keep it there, close on Escape and send focus back to the trigger.
- Price filter sliders need typed min and max inputs as an alternative to dragging (2.5.7).
- Checkout fields need labels and inline errors, plus a "ship to the same address" option so nobody types their address twice (3.3.7).
- Login and account pages shouldn't block password managers or pasting, and shouldn't depend on puzzle CAPTCHAs with no alternative (3.3.8).
- Product images need alt text that describes the product, not the file name.
Payment fields from Stripe and similar providers load in their own iframes, so test the whole flow by keyboard and with a screen reader, not just the fields you control. If you're also seeing failed payments, my post on WooCommerce Stripe checkout failures covers that side.
How much does a European Accessibility Act audit and remediation cost in the UK?
A manual WCAG audit in the UK typically costs £350 to £5,000+. Remediation on a small business site commonly runs $2,000 to $8,000, and $15,000 to $50,000+ for medium sites with complex flows. Here are the published ranges:
| Item | Typical price | Source |
|---|---|---|
| Self-test tools with guidance | From €49 a month | sitebrunch |
| UK manual WCAG audit, single site | £350 to £5,000+ | Accessimo |
| Full WCAG 2.2 audit, established UK specialist | From £2,500, or £3,000 with disabled testers | Jim Byrne |
| Manual audit priced per page | About £80 to £200 per page | Accessible Pixels |
| Full audit against EN 301 549 and WCAG | €1,500 to €8,000 | sitebrunch |
| Remediation, typical small business site | $2,000 to $8,000 | Connect Media Agency |
| Remediation, medium sites with complex flows | $15,000 to $50,000+ | DigDesigns |
| Ongoing monitoring plan, one US agency | $300 to $1,800 a month | Connect Media Agency |
The remediation figures are US prices, because UK firms rarely publish theirs. Treat them as a rough guide, not a quote.
What moves the price:
- Unique templates, not page count. A WooCommerce store with 2,000 products might only have eight templates that matter: home, category, product, cart, checkout, account, blog post and contact.
- Custom JavaScript. Bespoke filters, quick-view modals and custom checkout steps take far longer to fix than standard WooCommerce templates.
- Builder and theme. A clean custom theme or Bricks build is quicker to fix than a deeply nested page builder layout with plugins stacked on top.
- Plugins you can't edit. Third-party widgets, chat tools and review carousels sometimes need replacing rather than fixing.
- Content volume. Writing alt text and fixing headings across hundreds of posts is editorial work, and the hours add up.
- Retesting. A proper job includes a second pass to confirm the fixes and catch anything the first round broke.
Where should you start?
Start with a free automated check and a keyboard-only test purchase. Then get a manual audit of your core templates before you pay anyone for fixes. In order:
- 1
Run a free first check
Paste the HTML of your header, a product form and your checkout into the free Accessibility Checker to get WCAG 2.2 issues ranked by severity, with corrected code.
- 2
Try buying with the keyboard only
Tab from the homepage to a completed test order. Every place you get stuck or lose track of focus goes on the fix list.
- 3
Audit the core templates
Get a manual audit of the templates and journeys that matter, rather than paying per page for thousands of near-identical URLs.
- 4
Fix in code, on staging
Make changes in the child theme, builder templates or a small custom plugin so they survive updates, then test before going live.
- 5
Retest, publish, maintain
Confirm the fixes, publish an accessibility statement and add accessibility checks to your regular maintenance so new content doesn't undo the work.
I built the Accessibility Checker for that first step. It reviews pasted HTML, JSX or a component against WCAG 2.2: missing labels and alt text, heading order, keyboard and focus problems, misused ARIA and colour contrast risks. Each issue links to its WCAG success criterion. It's free and there's no sign-up. It won't replace a manual audit, but you'll know roughly how big the job is before anyone sends you a quote.
What should you ask a developer before hiring?
Ask how they'll fix, test and document the work. If the answer is an overlay, walk away. These five questions are enough:
- Will you fix the templates in code, or install a plugin or widget? If an overlay comes up, keep looking.
- Which standard will you test against? You want WCAG 2.2 AA, or at minimum WCAG 2.1 AA as referenced by EN 301 549.
- How do you test? Automated scans only catch part of the problems. Ask about keyboard testing and screen reader testing with NVDA or VoiceOver.
- Will the fixes survive updates? Edits made directly in a parent theme or plugin files get wiped on the next update.
- Do I get a report? You need a record of what was tested and fixed to write an honest accessibility statement.
How do you get your site fixed for the EAA?
If your site sells into the EU, run your product page and checkout through the free Accessibility Checker first. Then book a 20-minute call and bring the results. I'll tell you which fixes belong in the theme or builder templates and which are content work. On an existing site, I can make those fixes as part of my technical SEO and Core Web Vitals work or a maintenance retainer, or build them into a new WordPress site on Bricks, Elementor or Oxygen.
