All articles
WCAGCheck Editorial

EAA and UK Equality Act: What Web Developers Need to Know Now

The European Accessibility Act is live and the UK Equality Act applies to websites. Here's what developers need to do about it.

EAA and UK Equality Act: What Web Developers Need to Know Now

The European Accessibility Act (EAA) came into force in June 2025. If you're building websites for clients who sell to EU customers, this affects you directly. And if you're working in the UK, the Equality Act's "reasonable adjustments" requirement hasn't gone anywhere—it still applies to digital services.

Here's what's actually changed and what you need to do about it.

What the EAA Requires

The EAA applies to products and services sold within the EU, including:

  • eCommerce websites
  • Banking services
  • Transport ticketing
  • E-books and e-readers
  • Streaming services

The standard it references is EN 301 549, which maps directly to WCAG 2.1 Level AA. So if you're already building to WCAG 2.1 AA, you're largely covered. The EAA doesn't invent new technical requirements—it makes existing ones legally enforceable across all EU member states.

For eCommerce specifically, this means your checkout flows, product filters, search functionality, and account management all need to meet accessibility standards. Not just the homepage. Not just the "main" pages. Everything a customer touches during a purchase.

The UK Situation

The UK isn't bound by the EAA, but the Equality Act 2010 still requires service providers to make "reasonable adjustments" for disabled people. Courts have consistently interpreted this to include websites.

There's no explicit WCAG requirement written into UK law, but WCAG 2.1 AA has become the de facto standard. If your site fails basic accessibility checks and a disabled user can't complete a purchase, you're exposed to a discrimination claim.

The practical difference: the EAA gives EU regulators specific enforcement powers. The UK relies on individual complaints and legal action. Both routes end up in the same place—you need an accessible website.

Where eCommerce Sites Typically Fail

If you're working on retail sites, these are the patterns that cause the most problems:

Dynamic Product Filters

Faceted search is everywhere in eCommerce. Size, colour, price range, brand—users expect to narrow results quickly. But many implementations fail WCAG 4.1.2 (Name, Role, Value) because filter controls don't communicate their state to assistive technology.

When a user selects "Size: Medium", screen reader users need to know that filter is active. If your checkboxes or buttons don't expose their checked/pressed state, users can't tell what's applied.

Fix: Use native HTML checkboxes or buttons with proper aria-pressed states. When filters update the page, announce the change with a live region.

Checkout Form Errors

Checkout abandonment is expensive. Inaccessible error handling makes it worse. WCAG 3.3.1 (Error Identification) requires that errors are identified and described in text. WCAG 3.3.3 (Error Suggestion) requires you to suggest corrections when you can.

The common failure: showing a red border around invalid fields without any text explanation. Colour alone doesn't work (1.4.1), and screen reader users get nothing.

Fix: Add visible error text next to each invalid field. Use aria-describedby to associate the error message with the input. Move focus to the first error when the form fails validation.

Third-Party Widgets

Payment processors, review widgets, chat plugins, cookie consent banners—eCommerce sites are full of embedded third-party code. You're still responsible for the accessibility of these components.

A keyboard user who can't dismiss your cookie banner can't use your site. A screen reader user who can't complete the payment iframe can't buy anything.

Fix: Test third-party components before you integrate them. Ask vendors for their VPAT or accessibility conformance report. If a widget isn't accessible, find an alternative or push the vendor to fix it.

Mobile Touch Targets

WCAG 2.2 added Success Criterion 2.5.8 (Target Size Minimum), requiring interactive elements to be at least 24×24 CSS pixels. Many mobile eCommerce interfaces fail this, especially quantity selectors, size pickers, and filter toggles.

Fix: Audit your tap targets. The 24×24 minimum is exactly that—a minimum. Apple recommends 44×44 points, and that's a better target for usability.

Building Accessibility Into Your Process

Retrofitting accessibility is expensive. Building it in from the start costs almost nothing extra. Here's what that looks like:

  1. Design phase: Check colour contrast before development starts. Tools like the WebAIM contrast checker take seconds to use.

  2. Component development: Test each component with keyboard navigation and a screen reader before it goes into the library.

  3. Code review: Add accessibility to your PR checklist. Does this form have labels? Does this button have accessible text? Does this modal trap focus correctly?

  4. QA: Run automated scans on every deployment. Automated tools catch about 30-40% of issues, but they catch them consistently.

  5. Manual testing: Schedule regular manual audits. Automated tools can't test whether your content makes sense or whether your user flows actually work.

The Business Conversation

If you're trying to convince a client to prioritise accessibility, skip the legal scare tactics. Focus on these points:

  • Accessible sites work better for everyone, including users on slow connections, older devices, or bright sunlight
  • Accessibility improvements often fix SEO issues simultaneously (heading structure, alt text, semantic HTML)
  • The cost of fixing issues increases the longer you wait

The EAA and Equality Act aren't going away. Building accessible sites is now part of professional web development, full stop.

WCAGCheck scans your website for WCAG compliance issues and tells you exactly what to fix. Try it free at wcagcheck.co.uk