The European Accessibility Act for digital services: what applies to Indian providers

01The position today

Directive (EU) 2019/882, the European Accessibility Act (opens external site), lays down shared accessibility requirements for a defined set of products and services. It works through national law: Member States had until 28 June 2022 to adopt their transposing acts and had to apply them from 28 June 2025. Since that date, a covered service that consumers can buy in the EU must comply in every Member State where it is sold.

Where the provider is established makes no difference. An Indian company that sells to European consumers through its own online shop, or publishes e-books on the EU market, provides a covered service and answers to the national law of each target country. An Indian company that builds the app or portal of a European bank, airline or retailer meets the same requirements through its customer’s contract.

The Act sits next to the Web Accessibility Directive, (EU) 2016/2102, which for some years has governed the sites and apps of public sector bodies. It extends similar expectations to private companies, but only for the products and services listed in it.

02Digital services the Act covers

Article 2(2) lists the consumer services within scope:

• E-commerce: selling at a distance through a website or an app, at the consumer’s request, to conclude a consumer contract. Put simply, any online store or booking journey that sells to the public.
• Consumer banking: loans and credit, payment services and payment accounts, e-money, and some investment services for consumers.
• Passenger transport by air, bus, rail and water: the websites and apps, e-tickets and ticket sales, journey information including live updates, and interactive self-service terminals; for city, suburban and regional transport, only those terminals.
• Electronic communications and access to audiovisual media, for instance the apps and on-screen interfaces of streaming and TV services.
• E-books, and the software made for reading them.

Products fall under it too: computers and their operating systems, smartphones, card terminals, cash machines, ticket and check-in kiosks, and e-readers. Indian firms that write software for such hardware, for example for a European terminal manufacturer, meet the product requirements through that customer.

A service sold only to businesses is outside the Act, although many corporate buyers now write the same level into their procurement. When one portal is used by consumers and by companies, the consumer part falls within scope.

03The exemption for microenterprises

Under Article 4(5), a microenterprise that provides services does not have to meet the accessibility requirements for those services. The directive counts a firm as a microenterprise when it has fewer than 10 staff and either its annual turnover or its balance sheet total is EUR 2 million or less. Only services benefit; a small firm that puts covered products on the market must still make them compliant.

What counts is the size of the provider, not of whoever built the service. A large retailer whose shop was developed by a small agency, in India or elsewhere, still offers a covered service.

04What compliance means for a site or app

The requirements sit in Annex I. For services, websites, the online applications linked to them and mobile apps must be made accessible consistently and adequately, which the Annex expresses as “perceivable, operable, understandable and robust”. The four words come from the Web Content Accessibility Guidelines (WCAG), and each turns into checks a tester can run:

• Perceivable: alternative text for images, captions on video, enough colour contrast, and layouts that reflow on a small screen or at high magnification without hiding content.
• Operable: every function reachable from the keyboard, a visible focus that moves in a sensible order, no dialog the user cannot leave, and time limits that can be extended.
• Understandable: plain labels and instructions, error messages that name the problem and the fix, and navigation that behaves the same way throughout.
• Robust: sound semantics, so that a screen reader or other assistive technology can tell what each control is called, what it does and what state it is in.

Some services face extra requirements. Online shops must make sign-in, security and payment steps accessible, and must show the accessibility information about the goods sold whenever the responsible economic operator provides it. Consumer banking must also cover identification methods, e-signatures, security features and payment services, and must write its information so that it is understandable at a level no higher than B2 of the Common European Framework of Reference for Languages.

Providers must also explain how their service complies. Annex V asks for that explanation in the general terms and conditions, or in a comparable document, and in accessible formats. A common solution is an accessibility statement that the footer and the terms both link to.

Standards: EN 301 549, WCAG and IS 17802

Article 15 gives a presumption of conformity to products and services that follow harmonised standards published by reference in the Official Journal, for the requirements those standards address. Europe’s standard on accessible ICT products and services is EN 301 549. Its version 3.2.1 serves as the harmonised standard for the Web Accessibility Directive and, for web content, takes over the WCAG 2.1 success criteria of levels A and AA.

Standards written specifically for the Accessibility Act are under preparation following a Commission standardisation request, so confirm which references have appeared in the Official Journal before relying on the presumption. In practice, authorities, auditors and customers already measure against EN 301 549. WCAG 2.2, a W3C Recommendation since October 2023, introduces criteria such as a minimum target size and accessible authentication; designing to WCAG 2.2 at level AA satisfies 2.1 and gets ahead of the next edition of the standard.

Indian teams have a matching national reference. IS 17802, the Bureau of Indian Standards accessibility standard for ICT products and services (Part 1: 2021, Part 2: 2022), is aligned with WCAG 2.1 and EN 301 549. The Guidelines for Indian Government Websites and Apps (GIGW 3.0, March 2023) require WCAG 2.1 level AA for government websites and apps. SEBI’s circular of 31 July 2025 under the Rights of Persons with Disabilities Act, 2016 requires the digital platforms of its regulated entities to be accessible. A design system built to WCAG 2.2 AA and tested against EN 301 549 is therefore a sound base for a product sold in Europe and for one launched in India.

05Disproportionate burden and fundamental alteration

Article 14 contains two escape routes. A requirement stops applying to the extent that meeting it would change the basic nature of the service fundamentally, or would place a disproportionate burden on the provider. Neither is easy to use:

• The provider makes the assessment itself, using the Annex VI criteria, and keeps it in writing.
• A provider that receives outside funding to improve accessibility may not plead disproportionate burden.
• The assessment is redone whenever the service changes, whenever an authority asks, and at least once every five years.
• A provider using the exception tells the market surveillance authorities of each Member State concerned; microenterprises are spared this step.

An exception reaches only the specific requirement that is disproportionate, never the service as a whole. Treat it as a last resort: most barriers come from components and content that are inexpensive to correct when found early.

06Transitional periods

Article 32 sets out three transitional periods; Member States had to adopt the first two, and the third was left to them:

• Up to 28 June 2030, a provider may go on delivering its services with products it was lawfully using for similar services before 28 June 2025.
• Service contracts signed before 28 June 2025 may run on unchanged until they expire, but not beyond five years from that day.
• If national law opts in, self-service terminals lawfully installed before 28 June 2025 may remain in operation for their economic life, but never more than 20 years from when they were first used.

The periods shield existing hardware and existing contracts. They give no extra time for a site or app that you redesign, relaunch or open to new customers. Each national law words its transitional rules in its own way.

07National laws in the EU markets where we work

Enforcement is organised country by country. Every Member State names its own market surveillance authorities and its own penalties, which have to be effective, proportionate and dissuasive, so an Indian provider selling into several EU countries answers to several authorities. The principal transposing acts in the markets where FromNine works:

08Accessibility as part of delivery

Few accessibility failures are chosen. Typically a component was built with no semantics, content went live without text alternatives, or a third-party widget was never tested. A review a week before go-live therefore disappoints: it uncovers dozens of defects that were cheap to avoid and are costly to repair late. What works is to handle accessibility the way mature teams handle security, as something the delivery process guarantees. When teams in Europe and India build the same product, that also means one shared definition of done.

• A design system that is accessible by construction. Buttons, forms, dialogs, menus, tabs and data grids receive proper semantics, keyboard handling and focus management a single time, are tried with screen readers, and are then reused across the product; colour tokens pass contrast checks in both light and dark themes.
• Accessibility in the definition of done. Each user story states how it must behave for keyboard users, which labels it needs and how it reports errors, and reviewers verify that as they would any requirement.
• Automated checks in CI. Rule-based scanners run with every build and stop regressions. They detect only a share of defects, such as missing labels, weak contrast or broken markup, so they support manual testing and never stand in for it.
• Manual testing by people fluent in assistive technology. Keyboard alone, screen readers on desktop and phone, 400 percent zoom and reduced motion, across the journeys that matter: logging in, searching, checking out, paying and managing an account.
• Sessions with disabled users on the most important journeys, before release and after major changes.
• Third-party components under contract. Payment and identity widgets, chatbots, consent banners, maps and embedded video are part of what the customer experiences; ask each vendor for an accessibility conformance report and test their components in your own context.
• Content and documents. Editors are trained to write alternative text, meaningful headings and descriptive links; documents customers rely on, such as contracts and invoices, are published as tagged PDFs or with an accessible alternative.

We build customer portals and enterprise software on these lines: the CI pipeline runs accessibility checks, and each release leaves behind the evidence an accessibility statement needs and that customers and regulators ask for. The same applies to AI service assistants and to portals on platforms such as Salesforce: the platform offers accessible building blocks, while custom components and content determine whether the finished service stays accessible.

09A plan for an Indian provider serving EU consumers

1. 01List services by country. Record each consumer-facing site, app, terminal and document per EU country, decide whether the Act applies, and file the reasoning, including for services you judge out of scope.
2. 02Set a baseline. Have an expert evaluate the critical journeys against EN 301 549 and run automated scans across the whole site; rank findings by their effect on users rather than by count.
3. 03Repair at the source. Fix the design system and shared components first, so that one correction reaches every page built on them.
4. 04Publish the information. Describe compliance in the terms or in an accessibility statement, name a contact for feedback, and update it as the service changes.
5. 05Make it part of delivery. Definition-of-done criteria, CI scans, scripted manual tests and a release gate on critical journeys, applied by every team, in Europe or in India.
6. 06Hold vendors to it. Put accessibility requirements and evidence into contracts with agencies, platform vendors and widget suppliers.
7. 07Record exceptions. Where disproportionate burden is claimed, keep the written assessment, inform the authority if the law requires it, and set a review date.

10Developments to follow

• Harmonised standards for the Act, a revised EN 301 549 among them, and their citation in the Official Journal.
• Guidance and the first enforcement cases from market surveillance authorities in each country where you sell.
• Revisions of national transitional rules, and of which authority supervises sectors such as banking or transport.
• In India, further SEBI guidance on the accessibility of its regulated entities’ platforms, and any revision of IS 17802 or GIGW.

The European Commission keeps an overview of the European Accessibility Act (opens external site). Put a date on every internal note about the Act, because national practice is still settling.