Because the European Accessibility Act started applying on 28 June 2025, and a lot of businesses only found out afterwards. It turns accessibility from a nice idea into a legal requirement for certain products and services sold to people in the European Union. Websites are squarely inside its scope.
We started fielding questions about this from clients who sell into Europe but are not based there. That is the part most people miss. The Act follows the market, not the office address.
This article is our plain reading of what the rules say and who they touch. We build websites, we are not lawyers, and anything with real money attached deserves proper legal advice.
The European Accessibility Act is Directive (EU) 2019/882. It sets common accessibility requirements for a defined list of products and services across the European Union. According to the EUR-Lex summary of the Directive, it had to become law in EU countries by 28 June 2022 and has applied in practice from 28 June 2025.
The goal stated by the European Commission is to improve the functioning of the internal market for accessible products and services by removing barriers created by different rules in different member states. Before this, every country had its own patchwork.
It is worth separating this from the older Web Accessibility Directive, which is Directive (EU) 2016/2102. That one covers public sector bodies. The European Accessibility Act reaches into the private sector, which is why it landed on so many desks at once.
It applies if you sell one of the covered services to consumers in the European Union, no matter where your company is registered. The trigger is the market you serve. A studio in Australia running an ecommerce store that ships to Ireland is inside the scope, and a large EU company with no covered service may sit outside it.
This surprises people. They assume a directive only binds companies with a European address. It does not work that way, because the point is protecting European consumers rather than regulating European companies.
The practical test we walk clients through has two parts. First, is what you sell on the covered list. Second, do you sell it to consumers in the EU. If both answers are yes, you should assume you are in scope and get advice.
The Directive names specific services rather than covering the whole web. The EUR-Lex summary lists telephony services, services giving access to audiovisual media, certain elements of air, bus, rail and water transport services such as websites, mobile services and electronic tickets, consumer banking, e-books, ecommerce, and answering emergency calls.
Ecommerce is the one that catches the most businesses. If you take orders from consumers online, the website doing that is a covered service, not just a brochure that happens to sit near your product.
Transport is broader than it sounds too, because the Directive calls out the websites, the mobile services, the electronic tickets and the information around those journeys. A booking flow is part of the service.
What is not on the list is just as useful. A marketing site for a plumbing business, or a portfolio for a design studio, is not automatically covered by this Act. That does not make it a good idea to ship it inaccessible, and we will come back to that.
Some are. The Directive exempts microenterprises that provide services. A microenterprise is defined as a business employing fewer than 10 people with an annual turnover not above 2 million euro, or an annual balance sheet total not above 2 million euro. The exemption covers services, and the Directive still encourages those businesses to be accessible anyway.
Read that definition slowly, because the exemption is narrower than most founders hope. It is scoped to microenterprises providing services. If you are at eleven staff, you are not a microenterprise.
There is a second escape valve in the Directive, and it is not a loophole. Accessibility requirements apply provided they do not fundamentally alter the nature of the product or service, or impose a disproportionate burden on the operator. That assessment has to be documented, not assumed over coffee.
There are transitional arrangements as well. The EUR-Lex summary explains that member states may give service providers whose facilities were already lawfully in use by 28 June 2025 a further five years, until 28 June 2030. Self service terminals can run to the end of their economically useful life up to 20 years, and countries could delay compliance for the European emergency number 112 until 28 June 2027.
In practice, teams build to the European standard EN 301 549, which is the accessibility requirements standard for ICT products and services. The European Commission states that EN 301 549 draws heavily from the Web Content Accessibility Guidelines version 2.1 published by the W3C, and that it also includes requirements that are not part of WCAG 2.1.
That last clause matters. The Commission says plainly that meeting the WCAG 2.1 success criteria alone will not guarantee compliance with the Web Accessibility Directive. So treating WCAG as the finish line is a mistake even before you get to the European Accessibility Act.
On versions, the Commission confirms that only two versions of EN 301 549 have been harmonised so far. Version 2.1.2 was harmonised in December 2018 and has since been replaced, and version 3.2.1 was harmonised on 18 August 2021.
WCAG itself has moved on. The W3C publishes WCAG 2.2 as a Recommendation dated 12 December 2024, adding nine new success criteria across focus visibility, input modalities and input assistance. We build to WCAG 2.2 Level AA on new work because it costs almost nothing extra at build time and ages better. Our fuller walkthrough of the criteria lives in our guide to making a website WCAG accessible.
Enforcement is national. The Directive sets the requirements, and each EU country enforces them through its own implementing law with its own authorities and its own penalties. That means there is no single European fine you can look up, and we will not quote you a number we cannot source.
The more immediate risk for most businesses is not a fine at all. It is a complaint, a procurement questionnaire you cannot answer, or an enterprise customer asking for an accessibility statement you have never written.
We have watched deals stall over exactly that. A sales team gets a vendor assessment form, and nobody can honestly tick the accessibility box, so the deal sits for a month while a developer retrofits focus states.
Start with the service, not the site. Write down what a customer actually buys from you and check that against the covered list in the Directive. Then check whether consumers in the EU can buy it. If both line up, assume scope and take proper legal advice on your specific case.
After that, get a real picture of the current state. Automated tools catch a slice of the problem, so we run Google Lighthouse for a baseline, then axe DevTools from Deque and WAVE from WebAIM to widen the net.
Then test with actual assistive technology, because the automated pass rate is not the truth. We tab through the whole page with no mouse, then listen to it with NVDA on Windows and VoiceOver on macOS. Keyboard traps and unlabelled form fields show up in seconds that way.
If you are on Webflow, a lot of this is fixable inside the Designer without custom code, and we covered the platform specifics in our guide to building an accessible website in Webflow.
Yes, and we would argue that fairly strongly. Accessible markup is better markup. Proper headings, real buttons, labelled inputs and visible focus states help screen reader users, and they also help search crawlers and AI answer engines parse the page correctly.
There is a commercial argument too. Every keyboard trap and unlabelled field is a place where a paying customer gives up. We have never seen a checkout get worse by being made operable without a mouse.
The cost argument is about timing rather than total. Fixing contrast and focus states while a design is still in Figma costs almost nothing. Retrofitting them after launch means touching components that are already live and already tested.
This is why we fold accessibility checks into pre-launch testing rather than treating it as a separate audit that happens later, if budget survives.
Do three things this month. Confirm whether what you sell is on the covered list, run a keyboard only pass through your main conversion flow, and write down what you find. That gives you a real position instead of a vague worry.
If you are clearly in scope, get legal advice on your specific situation and start budgeting the fixes. If you are clearly outside it, fix the keyboard and contrast issues anyway, because they are cheap and they earn you customers.
If you would like help working out where you stand, or you want the fixes built properly rather than patched with an overlay widget, we are happy to walk through it. Reach out at phoenix.studio and we will give you a straight answer about the size of the job.
Tell us where you want to go. We'll tell you how we'd get you there.