The European Accessibility Act for digital services: what applies since June 2025

01Where things stand

The European Accessibility Act (opens external site), Directive (EU) 2019/882, sets common accessibility requirements for a list of products and services. As a directive, it works through national laws: Member States had to adopt them by 28 June 2022 and apply them from 28 June 2025. Since that date, a service in scope that is offered to consumers in the EU has to meet the requirements in each country where it is offered.

The Act sits next to the Web Accessibility Directive, (EU) 2016/2102, which has covered the websites and apps of public sector bodies for several years. The European Accessibility Act extends similar expectations to the private sector, but only for the products and services it lists.

02Which digital services are in scope

Article 2(2) lists the services covered when they are provided to consumers:

• E-commerce services: services provided at a distance, through websites and mobile apps, at the request of a consumer with a view to concluding a consumer contract. In practice, any online shop or booking flow that sells to consumers.
• Consumer banking services: credit agreements, payment services and payment accounts, electronic money and certain investment services for consumers.
• Elements of air, bus, rail and waterborne passenger transport services: websites, mobile apps, electronic tickets and ticketing services, travel information including real-time information, and interactive self-service terminals. For urban, suburban and regional transport, only the self-service terminals are covered.
• Electronic communications services, and services providing access to audiovisual media services, such as the apps and interfaces of streaming and television providers.
• E-books and dedicated software.

The Act also covers products, such as computers and operating systems, smartphones, payment terminals, ATMs, ticketing and check-in machines, and e-readers. If you build software for such hardware, the product requirements reach you through your customer.

Services offered only to businesses are outside the scope, although many business customers now ask for the same level in procurement. A customer portal that serves both consumers and companies is in scope for its consumer use.

03The microenterprise exemption

Microenterprises that provide services are exempt from the accessibility requirements for those services (Article 4(5)). The directive defines a microenterprise as an enterprise that employs fewer than 10 persons and has an annual turnover, or an annual balance sheet total, not exceeding EUR 2 million. The exemption covers services only. A small company that places products in scope on the market still has to meet the product requirements.

The exemption applies to the provider, not to the service. When a larger company runs an online shop built by a small agency, the shop is in scope.

04What the requirements mean for a website or app

Annex I sets the requirements. For services, the core is that websites, related online applications and mobile apps are made accessible in a consistent and adequate way, by making them "perceivable, operable, understandable and robust". Those four principles come from the Web Content Accessibility Guidelines (WCAG), and they translate into concrete checks:

• Perceivable: text alternatives for images, captions for video, sufficient colour contrast, content that reflows on a small screen or at high zoom without losing information.
• Operable: every function works with a keyboard, focus is visible and follows a logical order, nobody gets trapped in a dialog, and time limits can be extended.
• Understandable: clear labels and instructions, error messages that say what went wrong and how to fix it, predictable navigation.
• Robust: correct semantics, so that screen readers and other assistive technologies can identify each control, its name, role and state.

Some services have specific requirements on top. E-commerce services must make identification, security and payment functions accessible, and pass on the accessibility information about the products sold where the responsible economic operator provides it. Consumer banking services must also make identification methods, electronic signatures, security features and payment services accessible, and provide information that is understandable without exceeding level B2 of the Common European Framework of Reference for Languages.

Service providers must also explain how their service meets the requirements. Annex V asks for this information in the general terms and conditions or an equivalent document, available in accessible formats. Many organisations publish it as an accessibility statement and link it from the footer and the terms.

Standards: EN 301 549 and WCAG

Products and services that conform to harmonised standards cited in the Official Journal are presumed to meet the requirements those standards cover (Article 15). The European standard for accessibility of ICT products and services is EN 301 549. Its version 3.2.1 is the harmonised standard under the Web Accessibility Directive, and for web content it incorporates the WCAG 2.1 success criteria at levels A and AA.

Harmonised standards specific to the European Accessibility Act are being developed under a Commission standardisation request; check which references have been cited before you rely on the presumption of conformity. Either way, EN 301 549 is the yardstick that authorities, auditors and customers use today. WCAG 2.2, a W3C Recommendation since October 2023, adds criteria such as minimum target sizes and accessible authentication. Building to WCAG 2.2 level AA today covers WCAG 2.1 and prepares you for the next version of the standard.

05Disproportionate burden and fundamental alteration

Article 14 allows two exceptions. A requirement does not apply to the extent that meeting it would fundamentally alter the basic nature of the service, or would impose a disproportionate burden on the provider. Both are narrow:

• The provider has to make the assessment itself, against the criteria in Annex VI, and document it.
• A provider that receives funding for improving accessibility from other sources cannot claim a disproportionate burden.
• Service providers renew the assessment of disproportionate burden when the service changes, when the authorities ask, and in any case at least every five years.
• Providers that rely on the exception have to inform the market surveillance authorities of the Member States concerned. Microenterprises are exempt from this.

An exception covers the specific requirement that is disproportionate, not the whole service. Treat it as a last resort: most barriers come from components and content that cost little to fix when they are caught early.

06Transitional periods

Article 32 provides for transitional periods. The first two below are mandatory for Member States, the third is optional:

• Until 28 June 2030, service providers may continue to provide their services using products they lawfully used for similar services before 28 June 2025.
• Service contracts agreed before 28 June 2025 may continue unchanged until they expire, but no longer than five years from that date.
• Where the national law allows it, self-service terminals lawfully used before 28 June 2025 may stay in use until the end of their economically useful life, but no longer than 20 years after they were put into use.

These periods protect existing hardware and contracts. They do not postpone the requirements for a website or app that you change, relaunch or offer to new customers. Check the exact transitional rules in each national law.

07National laws in our markets

Market surveillance and penalties are national. Each Member State designates its own authorities and sets penalties that must be effective, proportionate and dissuasive. The main implementing acts in the markets we work in:

08Accessibility as engineering practice

Most accessibility failures are not design decisions. They are the result of components built without semantics, content published without alternatives, and third-party widgets nobody tested. That is why an audit just before launch disappoints: it finds dozens of issues that are cheap to prevent and expensive to fix late. What works is treating accessibility like security, as a property of the delivery process.

• An accessible design system. Buttons, forms, dialogs, menus, tabs and data tables are built once with correct semantics, keyboard support and focus handling, tested with screen readers, and reused everywhere. Colour tokens are checked for contrast in light and dark themes.
• A definition of done that includes accessibility. Each user story names its acceptance criteria for keyboard use, labels and error handling, and reviewers check them like any other requirement.
• Automated checks in the pipeline. Rule-based scanners run on every build and block regressions. They find only part of the problems, such as missing labels, contrast and invalid markup, so they complement manual testing and never replace it.
• Manual testing by people who know assistive technology. Keyboard only, screen readers on desktop and mobile, zoom to 400 percent, and reduced motion, on the critical journeys: sign-in, search, checkout, payment, account management.
• Testing with disabled users on the journeys that matter most, before release and after large changes.
• Third-party components under contract. Payment widgets, identity providers, chat assistants, cookie banners, maps and video players are part of your service. Ask suppliers for an accessibility conformance report and test them in your context.
• Content and documents. Editors learn to write alternative text, headings and link texts. PDFs that customers need, such as contracts and invoices, are tagged or offered in an accessible alternative format.

This is how we build enterprise software and customer portals: accessibility checks run in the pipeline, and every release produces the evidence for the accessibility statement and for the questions customers and authorities ask. The same applies to service assistants and portals on platforms such as Salesforce: the platform provides accessible building blocks, and custom components and content decide whether the result stays accessible.

09A practical plan

1. 01Map your services. List the consumer-facing websites, apps, terminals and documents per country, and decide for each whether it falls under the Act. Record the reasoning, including for services you consider out of scope.
2. 02Measure the current state. Run an expert evaluation against EN 301 549 on the critical journeys, combined with automated scans of the full site. Prioritise by impact on users, not by the number of findings.
3. 03Fix the source. Correct issues in the design system and shared components first, so that each fix reaches every page that uses them.
4. 04Publish the information. Describe how the service meets the requirements in your terms or an accessibility statement, with a contact point for feedback, and keep it current.
5. 05Build it into delivery. Acceptance criteria, automated checks, manual test scripts and a release gate for the critical journeys.
6. 06Govern suppliers. Add accessibility requirements and evidence to contracts for agencies, platforms and widgets.
7. 07Document exceptions. Where you rely on disproportionate burden, write down the assessment, inform the authority where required, and plan the review.

10What to watch

• The publication of harmonised standards under the European Accessibility Act, including a revision of EN 301 549, and their citation in the Official Journal.
• Guidance and first enforcement actions of the market surveillance authorities in each country where you offer services.
• Changes to national transitional rules and to the authorities designated for specific sectors, such as banking and transport.

The European Commission maintains an overview of the European Accessibility Act (opens external site). Date every internal note you write on it: national practice is still taking shape.