Selling digital services to EU consumers: the European Accessibility Act

01How the Act reaches a provider in Malaysia

The European Accessibility Act (opens external site) is a directive, so it works through the laws of the Member States. They were due to adopt those laws by 28 June 2022 and have applied them since 28 June 2025. From that day, any covered service that consumers in the EU can use must comply in each Member State where it is offered.

The obligation follows the market, not the provider’s address. Picture a Malaysian company that sells to EU consumers through an online shop, runs a banking or payment app with EU users, sells tickets for European passenger transport or distributes e-books to EU readers. For those services it stands where an EU competitor would stand. Your counsel confirms whether a given service is caught.

Public sector websites and apps in the EU have had their own rules for years under Directive (EU) 2016/2102. The European Accessibility Act extends similar expectations to private companies, but only for what it lists. This article does not deal with accessibility requirements under Malaysian law.

02Digital services the Act names

Article 2(2) lists the services caught when the customer is a consumer. In plain terms:

• Online selling: a website or mobile app through which a consumer, at a distance, enters into a contract. Every online shop and booking flow aimed at EU consumers qualifies.
• Retail banking: consumer credit, payments and payment accounts, e-money, and some investment services offered to consumers.
• Passenger transport by air, bus, rail and water: the websites and apps, e-tickets and ticket sales, travel and real-time information, and interactive self-service terminals. For city, suburban and regional transport, only the terminals count.
• Telecoms and audiovisual access: electronic communications services, and the apps and interfaces that let viewers reach streaming or television content.
• E-books, along with the software made for reading them.

Hardware is covered as well, from computers, operating systems and smartphones to ATMs, payment and ticketing terminals, check-in kiosks and e-readers. A Malaysian electronics or software firm that builds for such devices feels these rules through its EU customer.

Business-to-business services are outside the Act. Even so, many corporate buyers now write the same level into their tenders. A portal with both consumer and business users is in scope for the consumer part.

03The exemption for microenterprises

Article 4(5) releases microenterprises from the requirements for the services they provide. A microenterprise, in the directive’s terms, employs fewer than 10 people and has a yearly turnover or balance sheet of no more than EUR 2 million. The release covers services only; covered products sold on the EU market by a small firm must still comply.

Size is measured at the provider. A large retailer whose shop was built by a three-person agency is not exempt.

04What a compliant website or app looks like

Annex I holds the requirements. For services, the core is that websites, connected online applications and mobile apps are accessible in a consistent and adequate way, so that users can perceive, operate, understand and rely on them. The four ideas come from the Web Content Accessibility Guidelines (WCAG). In a delivery team they become concrete checks:

• Perceivable: pictures have text equivalents, video has captions, contrast is strong enough, and layouts adapt to a narrow screen or heavy zoom with nothing lost.
• Operable: everything works from a keyboard, the focus indicator is visible and follows a logical path, no dialog becomes a trap, and users can get more time where a limit applies.
• Understandable: fields carry clear labels, an error tells the user what happened and what to do, and navigation does not surprise.
• Robust: the code exposes each control’s name, role and state correctly, so that screen readers and other assistive tools can interpret it.

Online shops carry extra duties: sign-in, security and payment steps must be accessible, and where the economic operator responsible for a product supplies accessibility information about it, the shop has to show it. Retail banking goes further still. Identification, electronic signatures, security features and payments must all be accessible, and the wording must stay within level B2 of the Common European Framework of Reference for Languages.

Each provider also has to tell users how its service complies. Annex V places that information in the general terms and conditions or a comparable document, itself available in accessible formats. A common answer is an accessibility statement linked from the footer and from the terms.

Standards: EN 301 549 and WCAG

Article 15 grants a presumption of conformity to anything that meets a harmonised standard whose reference appears in the Official Journal, for the requirements that standard addresses. In the EU, accessibility of ICT is the subject of EN 301 549. Version 3.2.1 is the harmonised standard for the public sector directive, and for web content it takes over the WCAG 2.1 criteria at levels A and AA.

Standards made specifically for the European Accessibility Act are still being drafted at the Commission’s request, so check what has been cited before you lean on the presumption. Until then, EN 301 549 is the benchmark used by supervisors, auditors and buyers alike. WCAG 2.2, published by W3C in October 2023, adds requirements on matters such as touch target size and sign-in that does not depend on a memory or puzzle test. Design to WCAG 2.2 at level AA and you meet WCAG 2.1 too, with the next revision of the standard already in hand.

05Disproportionate burden and fundamental alteration

Article 14 contains two escape routes, both narrow. A requirement does not apply where compliance would change what the service fundamentally is, or would weigh disproportionately on the provider. The conditions:

• The provider judges this for itself, applying the Annex VI criteria, and puts the judgment on paper.
• Outside funding received for accessibility work rules out a claim of disproportionate burden.
• The judgment is redone after any change to the service, on request from a supervisor, and at least once every five years.
• A provider using the exception tells the market surveillance authorities in each Member State concerned, unless it is a microenterprise.

Relief applies only to the particular requirement that is too heavy, never to the service as a whole. Most barriers sit in components and content that are inexpensive to fix early, so treat the exception as a last resort.

06Transitional periods

Article 32 provides three transitional arrangements. Member States must offer the first two and may choose to offer the third:

• Products that a provider lawfully used for a similar service before 28 June 2025 may keep supporting that service until 28 June 2030.
• Service contracts signed before 28 June 2025 may continue unaltered until they end, with a ceiling of five years from that date.
• Where national law says so, self-service terminals in lawful use before 28 June 2025 may remain until they are economically worn out, for up to 20 years from first use.

These arrangements protect installed equipment and signed contracts. A website or app that is redesigned, relaunched or sold to new customers gains no extra time. National laws may word the arrangements differently, so check each one.

07Where Member States differ

Supervision and sanctions are national. Each Member State appoints its own authorities and sets penalties that must be effective, proportionate and dissuasive, and a provider active in several of them meets several regimes. Six examples:

08Accessibility as part of engineering

Accessibility problems are rarely chosen. They creep in through components that lack semantic markup, content uploaded without alternatives, and plug-ins no one checked. A review held a week before launch then produces a long list of defects that were cheap to avoid and are now dear to fix. Teams that succeed handle accessibility the way they handle security: as something the delivery process produces, sprint after sprint.

• One accessible component library. Each control, from buttons and form fields to dialogs, menus, tabs and tables, is built a single time with proper semantics, keyboard behaviour and focus management, verified with a screen reader, then reused. Colour tokens are tested for contrast in both themes.
• Done means accessible. Stories state what keyboard users, labels and error messages must achieve, and code review treats those points as seriously as any functional criterion.
• Scanners in continuous integration. Rule-based tools stop regressions on each build. They see only a fraction of the issues, mainly absent labels, poor contrast and broken markup, so people still test by hand.
• Expert manual tests. Testers who use assistive technology daily try the key journeys (signing in, searching, buying, paying, managing an account) by keyboard alone, with screen readers on computer and phone, at 400 percent zoom and with motion reduced.
• Disabled users in the loop, testing the journeys that matter most before release and after significant changes.
• Suppliers held to account. Payment, identity, chat, cookie, map and video components all form part of what your customer experiences. Request a conformance report from each vendor and test the component inside your own pages.
• Accessible content. Editors are trained in alternative text, heading structure and meaningful link wording, and documents customers depend on, contracts and statements included, are tagged PDFs or come in another accessible format.

We work this way on enterprise software and customer portals. The pipeline runs the accessibility checks, and every release leaves a trail of evidence for the statement and for questions from EU customers or supervisors. The same discipline applies to service assistants and to portals built on Salesforce and similar platforms, whose standard parts are accessible; what you add on top determines whether the whole remains so.

09A practical plan

1. 01Know your EU consumer services. Per Member State, list the websites, apps, terminals and documents consumers use, decide whether each is covered, and record the reasoning, including for anything left out.
2. 02Take a baseline. An expert evaluation of the key journeys against EN 301 549, plus an automated scan of everything. Prioritise what blocks users, not what produces the most findings.
3. 03Fix once, centrally. Start with the component library, so that each repair flows to every screen that reuses it.
4. 04Tell users. Describe compliance in the terms or a statement, name a feedback contact, and update the text as the service changes.
5. 05Build it in. Acceptance criteria, pipeline checks, scripted manual tests and a release gate on the key journeys.
6. 06Contract for it. Agencies, platform vendors and widget suppliers commit to requirements and supply evidence.
7. 07Paper the exceptions. Any reliance on disproportionate burden gets a written assessment, a notification where the law asks for one, and a review date.

10What to watch

• New harmonised standards for the Act, a revision of EN 301 549 among them, and when the Official Journal cites them.
• Published guidance and early enforcement by supervisors in the Member States where you sell.
• Amendments to national transitional arrangements, and changes to which authority covers sectors like banking or transport.

The Commission’s overview of the European Accessibility Act (opens external site) is kept current. National practice is still taking shape, so date each internal note you write on it.