European Accessibility Act: what it means for your website and app

Key points

• The EAA is an EU directive, applied through each country’s national law from 28 June 2025.
• It covers consumer services such as online shops, consumer banking, e-books, electronic communications and passenger transport websites and apps.
• Microenterprises providing services, those with fewer than 10 people and a small turnover or balance sheet, are exempt from the service requirements.
• Where your company is based does not decide it: the test is whether you provide a covered service to consumers in the EU.
• EN 301 549 is the European standard behind it, and its web and app requirements follow WCAG. WCAG 2.2 level AA is the practical target.
• You also have to publish how your service meets the requirements, and keep it accessible as the product changes.

What the European Accessibility Act is

The European Accessibility Act, Directive (EU) 2019/882, sets common accessibility requirements for a list of products and services across the EU. The European Commission says it covers the products and services most important for people with disabilities that were also most likely to have different rules from country to country.

Because it is a directive, it works through national law. Member states had to adopt their laws by 28 June 2022 and apply them from 28 June 2025. Enforcement is national too: each country names the authorities that check services and sets its own penalties, which the directive says must be effective, proportionate and dissuasive. The exact rules, authorities and penalties therefore differ by country.

This guide is general information, not legal advice. It explains the directive from the official texts listed below. Whether your service is covered, and what you must do in a given country, is a question for that country’s authority or a lawyer.

Which services and products it covers

Article 2 lists the services provided to consumers after 28 June 2025 that are covered, and the products placed on the market after that date.

The products include computers and their operating systems, smartphones, e-readers, ATMs, ticketing and check-in machines and payment terminals.

Some website and app content is excluded, including pre-recorded audio and video and office documents published before 28 June 2025, third-party content you neither fund, develop nor control, and archived content that is no longer updated. Article 32 also allows transitional periods, such as service contracts agreed before 28 June 2025 continuing unchanged until they end, for a limited time.

Who it reaches, and who is exempt

• Consumer-facing services. The service categories are about services provided to consumers. A product sold only to other businesses is generally outside those categories, though business customers may still ask for accessibility in their contracts.
• Companies outside the EU. The directive does not turn on where the provider is based. If you run an online shop or a banking app from the US, the UK or India and serve consumers in the EU, assume it can apply to you and check with a lawyer.
• Microenterprises providing services are exempt. Article 4 exempts them from the accessibility requirements for services and the obligations that come with them. Article 3 defines a microenterprise as one with fewer than 10 people and an annual turnover or balance sheet total under a set threshold. The exemption does not cover microenterprises dealing in products.
• Fundamental alteration and disproportionate burden. Article 14 says the requirements apply only as far as they do not fundamentally change the service or impose a disproportionate burden. A provider relying on this must assess it against the criteria in the directive, document it, and renew the assessment when the service changes, when asked, and at least every five years.

How EN 301 549 and WCAG fit in

For websites and apps, the directive asks for them to be accessible in a consistent and adequate way by making them perceivable, operable, understandable and robust. Those four words are the principles of WCAG, the Web Content Accessibility Guidelines from the W3C. What is WCAG? explains the guidelines and their A, AA and AAA levels.

The directive does not name WCAG directly. Article 15 says a service that meets a harmonised standard cited in the Official Journal of the EU is presumed to meet the requirements that standard covers. The standard written for this purpose is EN 301 549, from the European standards bodies ETSI, CEN and CENELEC.

Check whether the new version has been cited in the Official Journal when you read this. Either way, building to WCAG 2.2 level AA covers the core of the web and app requirements in both versions. EN 301 549 adds requirements beyond WCAG, for example for documentation and support services.

What to do: audit, fix, publish, keep checking

1. Decide whether you are in scope. List the services you provide to consumers in the EU, check them against Article 2, and note whether the microenterprise exemption applies.
2. Audit the website and app against WCAG 2.2 level AA. Automated tools catch part of the problems; a person testing with a keyboard, a screen reader and zoom finds many more. What is a UX audit? explains how an audit is run.
3. Fix the paths that matter most first: sign-up, sign-in, search, product pages, checkout, account settings and support. Forms are where most people get stuck; Form design best practices covers labels, errors and input help.
4. Fix the mobile app as well as the website. Mobile app accessibility is a checklist for iOS and Android.
5. Write and publish the accessibility information, covered next.
6. Make accessibility part of every release: components in the design system that are accessible by default, automated checks in the build, a manual check on new screens, and a contact route for people who hit a barrier.

Article 13 makes the last step a legal duty, not only good practice. Service providers must have procedures so the service stays compliant as it changes. If it stops complying, they must take corrective action and inform the competent national authorities in the countries where they provide it.

The accessibility information you must publish

Annex V asks service providers to include information on how the service meets the accessibility requirements in their general terms and conditions or an equivalent document, available to the public in written and oral form and in a way that is accessible itself. Where applicable, it should contain:

• A general description of the service in accessible formats.
• The descriptions and explanations needed to understand how the service works.
• A description of how the service meets the relevant accessibility requirements.

Many teams publish this as an accessibility statement page linked from the footer and the terms. The W3C recommends that a statement name the standard you applied, such as WCAG 2.2, list known limitations, and give a contact for people who run into problems, and it offers a free generator. Keep the information for as long as the service runs, and update it when the product or the standard changes.

Outside the EU: the UK and the US

• United Kingdom. The EAA is EU law and does not apply in the UK as such. UK government guidance says all UK service providers have a duty under the Equality Act 2010 to make reasonable adjustments for disabled people. Public sector bodies also have accessibility regulations from 2018 that require their websites and apps to meet WCAG 2.2 level AA and to publish an accessibility statement.
• United States. The Department of Justice says the ADA’s requirements apply to all the goods and services of businesses open to the public, including those offered on the web. It does not set a specific technical standard for businesses, and it points to WCAG as helpful guidance.

Other countries have their own rules, and how they apply to your product depends on the facts. Treat WCAG 2.2 level AA as a shared baseline, and ask a lawyer where you sell about the legal side.

When BYD Tech designs and builds a product, the founders are on the calls, AI-assisted work is reviewed by an engineer, and the code lives in the client’s GitHub from day one. UI/UX design describes how design work starts.