# The European Accessibility Act: what your website must do now

*Published: 2026-07-14*

*Author: Roberto — Full-Stack Developer*

The EAA has applied since June 28, 2025, and 2026 is the year regulators started enforcing it. Here is who it covers, what compliant actually means, and how to remediate without panic.

The European Accessibility Act has applied since June 28, 2025. If your business sells products or services to consumers in the EU, whether or not you are based there, your website most likely needs to meet WCAG 2.1 AA. Enforcement started in 2025 and picked up pace in 2026, so the sensible move is a structured remediation plan, not panic and not an overlay widget.

That is the short version. The rest of this guide covers who exactly is on the hook, what "compliant" means in concrete terms, why the quick fixes being sold to you do not work, and the order we would fix things in if it were our site.

## What is the European Accessibility Act, and who does it cover?

The EAA (Directive (EU) 2019/882) is an EU law that requires certain products and services to be accessible to people with disabilities. For websites and apps, it covers e-commerce, banking and financial services, electronic communications, transport booking, e-books, and audiovisual media services. If consumers in the EU can buy something on your site, you are almost certainly in scope through the e-commerce category, which is deliberately broad.

Two things surprise people about the scope.

First, it is consumer law, not public sector law. Earlier EU accessibility rules applied mainly to government websites. The EAA goes after private businesses, and e-commerce is the category that pulls most companies in.

Second, the exemption is narrower than people assume. Microenterprises providing services are exempt, but a microenterprise here means fewer than 10 staff AND under EUR 2 million in annual turnover. Both conditions, not either. A 12-person agency does not qualify. A profitable 8-person e-commerce brand doing EUR 3 million a year does not qualify either. And the exemption covers services, not products, so a small manufacturer placing products on the EU market still has product obligations.

The EAA is a directive, which means each member state wrote it into national law with its own enforcement body and its own penalty regime. The requirements are broadly the same everywhere; the consequences of ignoring them vary by country.

![55](https://media.secondseason.studio/magnific_recreate-img1_UPz5ioNwny-c3555f1ab96a12e8.webp)

## Does the EAA apply to non-EU businesses?

Yes. The law follows the market, not your registered address. A US company selling to consumers in France, a UK brand shipping to Germany, an Australian SaaS with EU consumer customers: all in scope for the services they offer into the EU.

This works the same way GDPR does, and companies that went through GDPR compliance will recognize the pattern. What matters is where your customers are. If you accept orders from EU consumers, take payment in euros, ship to EU addresses, or market to EU audiences, a regulator can treat you as offering a service in their market.

There is no registration threshold and no minimum revenue from the EU that triggers it. In principle, one German customer buying from your checkout puts that checkout in scope. In practice, enforcement attention goes to companies with a visible EU presence, but "we're small in Europe" is a risk calculation, not a legal defense.

If you sell into the EU and have been treating the EAA as someone else's problem, it is worth rereading your customer list before a regulator does.

## What does "compliant" actually mean for a website?

In practice: WCAG 2.1 level AA, applied through the harmonized European standard EN 301 549. The directive itself describes functional accessibility requirements in general terms (information must be perceivable, operable, understandable, and reliable for assistive technology), but EN 301 549 is the standard that presumes conformity, and its web requirements map onto the WCAG 2.1 AA success criteria. When an auditor or regulator checks your site, WCAG 2.1 AA is the checklist they are working from.

WCAG 2.1 AA is not exotic. It is the same standard serious web teams have targeted for years. Concretely, it means things like:

- Every image that carries meaning has a text alternative.
- The whole site works with a keyboard alone, including menus, modals, and checkout.
- Text has sufficient color contrast against its background (4.5:1 for normal text).
- Forms have programmatically associated labels and understandable error messages.
- The page has a logical heading structure and works with a screen reader.
- Nothing traps keyboard focus, and focus is visible as you tab through.
- Content reflows on small screens and at 200% zoom without loss of function.

There are 50 success criteria at A and AA level, and a full audit checks all of them. But most real-world failures cluster in a handful of areas: unlabeled form fields, broken keyboard navigation, poor contrast, missing alt text, and custom components (dropdowns, date pickers, carousels) built without accessibility in mind.

One more obligation people miss: the EAA also expects you to document how your service meets the requirements and to provide accessibility information to the public. An accessibility statement on your site is part of compliance, not decoration.

## Why won't an accessibility overlay save you?

Overlay widgets do not confer compliance, and buying one is the most common expensive mistake we see. An overlay is a JavaScript snippet that adds a settings panel (bigger text, contrast toggles, screen reader hints) on top of your existing site. The pitch is one line of code, instant compliance. The problem is that your actual code, the thing auditors and assistive technologies interact with, has not changed.

An overlay cannot add a label to a form field that was never labeled. It cannot make a div-based button reachable by keyboard. It cannot fix a checkout flow where the error messages never reach a screen reader. Some overlays actively interfere with the assistive technology settings blind users have already configured, which is why hundreds of accessibility advocates have publicly asked vendors to stop selling them as compliance tools.

The related trap is trusting automated scanners as proof of compliance. Automated testing is genuinely useful for catching regressions, but automated scanners catch roughly a quarter to a third of accessibility issues. A green score from a scanning tool tells you the easy problems are absent. It says nothing about whether a person using a screen reader can complete a purchase. WCAG conformance requires manual testing: keyboard walkthroughs, screen reader testing, and human judgment on things like whether alt text is actually meaningful.

If a vendor tells you their widget or scanner makes you EAA compliant, that claim itself should end the conversation.

![39](https://media.secondseason.studio/magnific_recreate-img1_rg6f1w0xtc-1bd7a93730df8e38.webp)

## How is enforcement actually going in 2026?

Faster than the skeptics predicted. The EAA has applied since June 28, 2025, and enforcement began within weeks. In July 2025, the French regulator sent formal notices to Auchan, Carrefour, E.Leclerc, and Picard, four of the country's biggest retailers, over accessibility failures. By November 2025, France had escalated to injunctions. According to Level Access's analysis of how EAA enforcement evolved into 2026, this pattern of notice first, then escalation, is what other member states are following as their enforcement bodies get moving.

A few honest observations about where things stand in mid 2026:

Enforcement is uneven across countries. France moved early and publicly. Other member states are slower, and some national enforcement bodies are still staffing up. That gap will close; directives always roll out unevenly and then converge.

Regulators are starting with large, visible consumer businesses. The first notices went to household-name retailers, not 15-person startups. This gives smaller companies time, but it is time to remediate, not time to ignore, because complaints are the other enforcement trigger. Any customer who hits an accessibility barrier can file one, and complaints do not sort themselves by company size.

The reputational cost arrives before the legal one. Being named in a regulator's notice, as those French retailers were, is public. For consumer brands, that coverage stings before any fine is calculated.

We would rather be clear than dramatic here: nobody has been ruined by an EAA fine yet. But the trajectory from July 2025 notices to November 2025 injunctions took four months, and the machinery only points one direction.

## What does a realistic remediation plan look like?

Do not start by trying to fix everything. Start by finding out what is broken, then fix in order of user impact and legal exposure. Here is the sequence we recommend, roughly in the order a mid-sized e-commerce or service business should run it:

1. Audit what you have. Run an automated scan for the baseline, then a manual audit of your key user journeys: homepage, search, product or service pages, forms, checkout, account. The manual part is non-negotiable, since scanners catch only a fraction of issues. For most sites this takes a specialist days, not months.
2. Triage by user impact. A broken checkout for keyboard users outranks a low-contrast footer link. Group findings into blockers (a disabled user cannot complete a core task), serious friction, and minor issues.
3. Fix the transactional path first. Checkout, sign-up, contact, and payment flows are where the EAA's e-commerce scope bites hardest and where a complaint is most likely to originate.
4. Fix templates before pages. One accessible product template fixes a thousand product pages. Global components (navigation, footer, cookie banner, search) come next because they appear everywhere.
5. Deal with content debt in batches. Alt text, heading structure, and link text across old content can be worked through progressively. Document the plan; showing an active, dated remediation program matters if a regulator asks.
6. Publish an accessibility statement. Say what standard you target, what you know is not yet fixed, and how users can report barriers. Then actually route those reports to someone.
7. Stop making new debt. Add accessibility checks to your development workflow: automated tests in CI, keyboard testing in QA, accessibility criteria in your definition of done. Remediation without this step is a treadmill.
8. Re-test on a schedule. An annual manual audit plus continuous automated scanning is a reasonable rhythm for most businesses.

If you are planning a redesign anyway, fold remediation into it rather than patching a site you are about to replace. Just do not use the redesign as an excuse to delay: "we'll fix it in the new site next year" is exactly the posture that turns a complaint into a notice. And if you do rebuild, protect your search visibility while you are at it; we cover that process in [how to redesign your website without losing SEO](/posts/website-redesign-without-losing-seo).

## How do we build for accessibility at Second Season?

The honest answer is that accessibility built in from the start costs a fraction of accessibility bolted on later, and we have seen both sides of that math in client work.

When we audit sites that were built without accessibility in mind, the same pattern shows up almost every time: the visual design is fine, the HTML underneath is not. Buttons that are actually divs with click handlers. Custom dropdowns that a keyboard cannot open. Form validation that flashes a red border but never tells a screen reader what went wrong. None of this was malicious; it is what happens when a team ships fast and nobody on it has ever watched a blind user try to buy something.

So our process front-loads the boring parts. Semantic HTML first, custom components only when a native element genuinely cannot do the job, and when we do build custom components we build them to the WAI-ARIA authoring patterns and test them with a keyboard and a screen reader before they ship. Color contrast gets checked at the design stage, in Figma, because fixing a brand palette after launch is a political problem, not a technical one. On Next.js builds we wire automated accessibility checks into CI so regressions get caught in pull requests rather than in audits.

One pattern worth stealing regardless of who builds your site: make accessibility a property of your design system, not of individual pages. A rebuild we did for a retail client had accessibility issues on effectively every page; the fix touched about a dozen shared components. That is where the effort concentrates and pays back. Page-by-page remediation is how projects stall.

What annoys us, frankly, is how often accessibility gets framed as a tax. Most of WCAG 2.1 AA is just craftsmanship: real labels, real buttons, readable contrast, layouts that survive zoom. Sites built this way are also easier to maintain and, since assistive technologies and search crawlers parse structure the same way, easier for machines to read too.

![22](https://media.secondseason.studio/magnific_recreate-img1_gOAqz4YSXO-fb506875dbfa0f64.webp)

## FAQ

### Is there a deadline extension for existing websites?

No general extension exists for websites. The transition periods cover other things: service contracts signed before June 28, 2025 can run until they expire, at the latest June 28, 2030, and self-service terminals already in use may stay until the end of their economic life, capped at 20 years. A live website selling to EU consumers is expected to comply now.

### Can my business be fined under the European Accessibility Act?

Yes. Each EU member state sets its own penalties, so amounts and procedures vary by country. Enforcement so far has typically started with a formal notice and a deadline to fix issues, with fines and injunctions as the escalation path. France began sending formal notices to major retailers in July 2025.

### Do accessibility overlay widgets make my site compliant?

No. Overlay widgets do not confer compliance. They sit on top of your code and cannot fix missing form labels, broken keyboard navigation, or inaccessible checkout flows. Regulators and accessibility auditors evaluate the underlying site against WCAG 2.1 AA, and several overlay vendors have faced complaints from the very users the tools claim to help.

### Does the EAA apply to companies outside the EU?

Yes, if you sell products or services to consumers in the EU. The law follows the market, not your headquarters. A US or UK e-commerce company shipping to EU customers falls under it. The microenterprise exemption for services applies only to businesses with under 10 staff and under EUR 2 million turnover.

### What standard does my website actually have to meet?

In practice, WCAG 2.1 level AA, applied through the European standard EN 301 549. The EAA itself describes functional requirements rather than naming WCAG, but EN 301 549 is the harmonized standard auditors and regulators use, and its web chapters map directly to WCAG 2.1 AA success criteria.

## A note on scope, and where to go from here

One caveat before you act on any of this: we are a design and development studio, not a law firm, and this article is not legal advice. National implementations of the EAA differ, and if you operate in a regulated sector like banking, get counsel who knows your specific market. What we can vouch for is the technical side: what WCAG 2.1 AA requires, what auditors look for, and how to build sites that pass.

The EAA is also not the only EU rule arriving on your desk this decade. WCAG itself is evolving (we compare the versions in [WCAG 2 vs WCAG 3](/posts/wcag-2-vs-3-compliance)), and if your business uses AI anywhere customer-facing, the EU AI Act has its own dates worth knowing; our [EU AI Act guide for SMEs](/posts/eu-ai-act-small-business-guide) walks through them.

Second Season designs and builds websites and platforms with accessibility treated as a build requirement, not an afterthought. If you want an audit of where your site stands against WCAG 2.1 AA, or you are planning a rebuild and want it done right the first time, [talk to us](/contact).
