EU Accessibility Act Requirements: What the Law Means for Your Website and Web App

The EU Accessibility Act requirements apply to you if consumers in the EU can buy, book or sign a contract through your website or app, and your business is larger than a microenterprise. Since 28 June 2025, online shops, consumer banking, e-books, passenger transport and a few other services must be usable by people with disabilities, enforced through national law in every EU country. Pure B2B software, and businesses with fewer than 10 employees and no more than €2 million in turnover or balance sheet, are generally outside the scope.

I'm a developer, not a lawyer. This guide is based on the directive and on Denmark's version of it, which I know best. Check the national rules in the countries you sell to, and get legal advice if a lot is riding on the answer.

The short answer: does the EAA apply to you?

My rule of thumb: if a private individual can buy, book or enter into a contract directly on your site or in your app, and you're not a microenterprise, assume you're in scope. Accessibility belongs in planning and design, not in a clean-up round after launch. You can see where it fits in my overview of the software development process from idea to launch.

What the European Accessibility Act actually requires

The EAA is Directive (EU) 2019/882. Each member state writes a directive into its own law, so authorities, fines and procedures differ from country to country. In Denmark, for example, it's Act no. 801 of 7 June 2022, the Danish Business Authority supervises e-commerce, banking and e-books, and violations can be fined.

Which services are covered

The EAA covers products, such as computers and payment terminals, and services. For websites and web apps, the services are what matter. These are covered when provided to consumers:

• E-commerce services
• Consumer banking services, including credit, payments and investment services
• E-books and the software used to read them
• Websites, mobile apps and e-tickets for air, bus, rail and waterborne passenger transport
• Electronic communications services and services giving access to audiovisual media

E-commerce is the broadest category. The directive describes it as services provided at a distance through websites and apps, "at the individual request of a consumer", with a view to concluding a consumer contract. That covers online stores and, in my reading, booking systems where a customer orders and pays for a service online.

The directive defines a service provider as anyone who provides a service on the EU market or offers it to consumers in the EU. A US or UK store shipping to EU customers can be in scope.

What your service has to do

The core requirement is that websites and apps are "perceivable, operable, understandable and robust". Those are the four principles WCAG is built on, which is why WCAG ends up as the yardstick. E-commerce services have two extra obligations:

• Provide accessibility information about the products you sell, when the manufacturer supplies it.
• Make identification, security and payment functions accessible. In my reading, that includes a third-party payment flow you've built into your checkout.

On top of that, you must explain how your service meets the requirements, in your general terms and conditions or an equivalent document, and that information must itself be accessible. A dedicated accessibility statement linked from your footer and your terms is the simplest way to do this. You also need procedures that keep the service compliant as it changes, so this isn't a one-off project.

Exemptions and edge cases

Microenterprises

Microenterprises that provide services are fully exempt from the service requirements. A microenterprise employs fewer than 10 people and has either an annual turnover or a balance sheet total of no more than €2 million. If you grow past that line, the rules apply, so it's sensible to build a new product accessibly even if you're exempt today.

B2B products and public-sector customers

The EAA is about services for consumers. A B2B SaaS, a customer portal for business clients or an internal tool isn't covered. It can still become a requirement through your contracts, especially with large customers.

Public-sector customers are the clearest case. Public bodies across the EU are covered by a separate law, the Web Accessibility Directive (EU) 2016/2102, which requires accessible websites and apps and a published accessibility statement. If you sell software to a municipality or a government agency, the obligation is theirs, but the work ends up with you.

Older content and third-party content

Documents and pre-recorded audio or video published before 28 June 2025 are exempt, as are archives that haven't been updated since. So is third-party content that you neither fund, develop nor control. A payment module or booking widget you chose and integrated yourself doesn't fall under that exemption, in my view.

Disproportionate burden

You can skip requirements that would fundamentally alter your service or impose a disproportionate burden. But you have to assess it against set criteria, document it, keep the documentation for at least five years, renew the assessment at least every five years and inform the authority. And if outside funding pays for accessibility improvements, you can't claim disproportionate burden at all.

WCAG: the standard you'll actually build to

WCAG (Web Content Accessibility Guidelines) is the W3C's set of guidelines for accessible web content. It's made up of testable success criteria at three levels: A, AA and AAA. Level AA is the usual target in law and in contracts. AAA is too strict to be a realistic requirement for a whole product.

The EAA doesn't mention WCAG by name. Instead, products and services that follow harmonized European standards are presumed to conform. The European standard for digital accessibility is EN 301 549. Public-sector sites are already measured against it, and according to the W3C's overview of EU accessibility policy, version 3.2.1 includes WCAG 2.1 Level AA verbatim for web content.

The current version is WCAG 2.2. It adds six success criteria at Levels A and AA:

• Touch and click targets need a minimum size.
• The focused element can't be hidden behind something like a sticky header or a cookie banner.
• Logging in can't depend on memorizing or solving something, for example by blocking paste in password fields.
• Dragging needs a single-pointer alternative.
• Help and contact options stay in the same place when they repeat across pages.
• Users aren't asked to enter the same information twice in one process.

WCAG 2.2 builds on 2.1, so I recommend WCAG 2.2 AA for anything new. You're covered today and better prepared when the standards are updated.

Most sites have a long way to go. The WebAIM Million, an annual scan of one million home pages, found detectable WCAG failures on 95.9% of them in 2026. The same six issues keep topping the list: low-contrast text, images without alt text, form fields without labels, empty links, empty buttons and a missing page language. All six are cheap to avoid when you build from scratch.

How to make your website or web app accessible in six steps

1. Work out whether you're in scope. Use the table above and write down your reasoning, per country if you sell across the EU. If you're exempt, you'll have the answer ready when a customer or partner asks.
2. Pick the flows that matter most. Find the ones where a barrier costs you the most: search, cart, sign-up, login, checkout and contact. Start there instead of auditing every page.
3. Run an automated scan. Free tools such as Lighthouse (built into Chrome), axe and WAVE catch the common issues in minutes. They only find part of the problem. A tool can see that an image has no alt text, but not whether the alt text describes the image.
4. Test with a keyboard and a screen reader. Put the mouse away and complete a purchase using only Tab, Enter and the arrow keys. Can you always see where you are? Can you dismiss the cookie banner and choose a delivery option? Then try VoiceOver on a Mac or iPhone, or the free NVDA screen reader on Windows. This is where the serious problems show up.
5. Fix issues in the right order. First anything that blocks a purchase or a login, then anything that makes it harder, and cosmetic issues last. Fix the shared component, such as the button or form field, so the fix applies everywhere.
6. Publish your accessibility statement and build the habit. Describe the service, how to use it, which standard you follow and the known gaps. Put the requirement into your software requirements specification, so new features are tested before every release, not just once.

What drives the cost of accessibility work

I can't price this without seeing your product, and I won't make up averages. But the cost drivers are predictable:

• Whether it's built in from the start. On a new build, it's mostly about getting the basics right the first time: proper HTML, labels, contrast and visible focus. That costs far less than fixing it later.
• How the code is structured. With a shared set of components, you fix a button once. If every page was built separately, the same bug needs fixing in many places. It's one of the signs of a healthy codebase.
• Third-party tools. Cookie banners, chat widgets, payment and booking tools are often the hardest part, because you don't control their code. Sometimes the answer is to switch vendor.
• Content. Alt text, headings and link text are written by whoever edits the site. That takes a short guide and a CMS that asks for them.
• Design. If your brand colors were chosen without contrast in mind, the fix can touch your brand. That's a design decision, not just a coding task.

Accessibility is a lot like security in that respect: cheap to plan for, expensive to retrofit. I've written a similar list of the vulnerabilities every web app should be protected against.

When you don't need a developer for this

You can handle a good part of it yourself:

• If your store runs on a standard e-commerce platform, the theme and installed apps decide most of the outcome. Pick a theme whose developer documents its accessibility, and fix your content yourself.
• If you're a microenterprise with a simple website, the checklist below and an automated scan will get you a long way.
• If your question is whether you're in scope, or how to document an exemption, you need a lawyer, not a developer.

You need a developer when the problems sit in the code: custom components, a bespoke checkout, a web app with dynamic forms or a booking system built for you. And if you're commissioning a new build anyway, that's the right moment to get accessibility in.

Next steps

Use the checklist for a first pass over your site or app. It won't replace a proper audit, but it catches the issues that most often block real users.

If you're about to launch a new site, add these points to your website launch checklist. And if you want a website or online store that's accessible from day one, see how I work on my website development page.

Frequently asked questions

Does the EAA apply to companies outside the EU?+

Yes, if you offer a covered service to consumers in the EU. The directive's definition of a service provider includes anyone offering services to consumers in the EU, so a UK or US online store selling to EU customers can be in scope. In practice, it's the authorities in the countries where you sell that can act.

Who is responsible: my business or my developer?+

Your business is. The obligations sit with the service provider, meaning whoever offers the service to consumers, even if a freelancer or an agency built it. That's why your development contract should name the standard the product must meet, such as WCAG 2.2 Level AA, and how it will be tested. Then you have something concrete to hold your supplier to if it isn't met.

Does the EAA cover mobile apps?+

Yes, when the app is used for a covered service. The rules explicitly include mobile device-based services, so an app where consumers shop or book is covered just like your website. The principles are the same, but testing differs: use VoiceOver on iOS and TalkBack on Android, and check that text can be enlarged through the phone's settings without breaking the layout.

Do accessibility overlays make a site compliant?+

Rarely, in my view. An overlay is a script that adds a toolbar on top of your site, but it doesn't fix the underlying code, such as a button without a name or a form field without a label. Screen reader users also tend to rely on their own settings and assistive technology, so the toolbar adds little for them. I'd spend the money on fixing the code instead.