The European Accessibility Act in Malta: what digital services have had to meet since June 2025

01The position in Malta

Directive (EU) 2019/882, the European Accessibility Act (opens external site), lays down shared accessibility requirements for a defined set of products and services. A directive works only through national law, so each Member State had until 28 June 2022 to adopt its rules and had to apply them from 28 June 2025. From then on, a covered service offered to consumers has to comply in every Member State where it is offered.

In Malta the directive is transposed by the Accessibility Measures (European Accessibility Act) Regulations, S.L. 627.03 (opens external site). The Commission for the Rights of Persons with Disability (CRPD) is the market surveillance authority, and a memorandum of understanding with the Malta Competition and Consumer Affairs Authority (MCCAA) gives it technical support.

Public bodies were covered earlier. The Web Accessibility Directive, (EU) 2016/2102, has governed the sites and apps of the public sector for some years, and Malta transposed it through S.L. 418.03, so Government ministries, departments and public entities already work to similar requirements. The European Accessibility Act brings that kind of expectation to private companies, but only for the products and services it lists.

02Which digital services are covered

Article 2(2) names the services that fall within the Act when consumers are the customers:

• E-commerce services: services delivered at a distance through websites and mobile apps, at a consumer’s request and aimed at concluding a consumer contract. In practice that means every online shop or booking flow selling to consumers, a hotel group’s direct booking site included.
• Consumer banking services: credit agreements, payment services and accounts, electronic money, and certain investment services offered to consumers.
• Passenger transport by air, bus, rail and sea: the booking websites and apps, e-tickets and ticket sales, journey information including live updates, and interactive self-service machines. For city, suburban and regional transport, only those machines are in scope.
• Electronic communications services, and services giving access to audiovisual media services, for example the apps and interfaces of streaming and television providers.
• E-books and the software dedicated to them.

Products fall within the Act as well, among them computers and their operating systems, smartphones, payment terminals, ATMs, ticketing and check-in machines, and e-readers. Software written for such hardware meets the product requirements through the customer who sells it.

Services aimed only at businesses fall outside, even though more and more business buyers ask for the same standard in their tenders. A client portal used by both consumers and companies is covered for the part consumers use.

03Microenterprises are exempt for services

Under Article 4(5) of the directive, and under S.L. 627.03 in Malta, microenterprises that provide services do not have to meet the accessibility requirements for those services. The directive treats as a microenterprise a business with fewer than 10 staff and an annual turnover or balance sheet total of no more than EUR 2 million. The exemption is for services only: a small firm that places covered products on the market still has to meet the product requirements.

The exemption follows the provider, not the service. If a larger Maltese retailer runs an online shop that a small agency built, the shop is covered.

04What a website or app has to do

The requirements themselves are in Annex I. For services, the core duty is that websites, the online applications linked to them and mobile apps are made accessible in a consistent and adequate way, which the directive spells out as making them “perceivable, operable, understandable and robust”. Those four words are the principles of the Web Content Accessibility Guidelines (WCAG), and each translates into checks a tester can run:

• Perceivable: images carry text alternatives, videos have captions, colours contrast enough, and content reflows on a phone or at high zoom without anything going missing.
• Operable: each function can be used from the keyboard, the focus is visible and moves in a sensible order, no one gets stuck inside a dialog, and time limits can be extended.
• Understandable: labels and instructions are clear, error messages explain what went wrong and how to put it right, and navigation behaves predictably.
• Robust: the semantics are correct, so screen readers and other assistive technologies can tell each control’s name, role and state.

Some services have further duties. An online shop has to make its log-in, security and payment steps accessible, and has to show the accessibility information about the goods it sells whenever the manufacturer or other responsible operator provides it. A bank serving consumers must likewise make its identification methods, e-signatures, security features and payment services accessible, and must keep its explanations understandable for a reader at level B2 of the Common European Framework of Reference for Languages or below.

Providers must also explain how their service complies. Annex V asks for that explanation in the general terms and conditions or a comparable document, offered in accessible formats. Many organisations publish it as an accessibility statement linked from the footer and from the terms.

Standards: EN 301 549 and WCAG

Article 15 links compliance to standards: where a product or service follows harmonised standards whose references appear in the Official Journal, it is presumed to meet the requirements those standards address. For ICT products and services the European standard is EN 301 549. Version 3.2.1 already serves as the harmonised standard under the Web Accessibility Directive, and for web content it adopts the WCAG 2.1 success criteria at levels A and AA.

Standards drafted for the European Accessibility Act itself are still being prepared under a standardisation request from the Commission, so before leaning on the presumption, check which references have actually been published. Until then, authorities, auditors and buyers measure against EN 301 549. WCAG 2.2, published by the W3C in October 2023, brings new criteria such as a minimum size for touch targets and authentication that does not depend on memory tests. Aim for WCAG 2.2 at level AA: it includes WCAG 2.1 and puts you ahead of the next revision of the standard.

05Disproportionate burden and fundamental alteration

Article 14 allows two exceptions. A requirement falls away to the extent that meeting it would change the basic nature of the service fundamentally, or would place a disproportionate burden on the provider. Both are applied strictly:

• The provider carries out the assessment itself, against the criteria of Annex VI, and keeps a written record.
• A provider that receives funding from other sources to improve accessibility cannot plead a disproportionate burden.
• The assessment is renewed when the service changes, when an authority asks for it, and in any event at least every five years.
• A provider relying on the exception must tell the market surveillance authorities of the Member States concerned, in Malta the CRPD. Microenterprises do not have to do so.

The exception covers the particular requirement that is disproportionate, never the entire service. Use it only when nothing else works: most barriers come from components and content that cost little to fix if they are spotted early.

06Transitional periods

Article 32 sets transitional periods. Member States must apply the first two below; the third is up to them:

• Up to 28 June 2030, providers may keep delivering their services with products they lawfully used for similar services before 28 June 2025.
• Service contracts concluded before 28 June 2025 may run on unchanged until they expire, for at most five years after that date.
• If national law permits, self-service terminals lawfully in use before 28 June 2025 may remain in service until the end of their economic life, for no more than 20 years from when they were installed.

These periods shield existing hardware and contracts. They do not delay the requirements for a website or app that you modify, relaunch or open to new customers. Check the precise transitional rules in S.L. 627.03 and in each other national law that applies to you.

07How Malta and other Member States implement the Act

Market surveillance and penalties are a national matter. Every Member State appoints its own authorities and sets penalties that must be effective, proportionate and dissuasive. A Maltese provider selling to consumers elsewhere in the EU meets the law of each of those countries too. The main implementing acts:

08Accessibility as part of how software is built

Few accessibility failures are deliberate design choices. They come from components built without semantics, content published without alternatives, and third-party widgets that nobody tested. That is why a final audit before launch disappoints: it turns up dozens of issues that would have been cheap to prevent and are costly to fix so late. What works is to treat accessibility as you treat security, as a quality of the delivery process.

• An accessible component library. Buttons, form fields, dialogs, menus, tabs and tables are built a single time with the right semantics, keyboard behaviour and focus handling, verified with screen readers and then used throughout. Colour tokens are contrast-checked for both themes.
• Done includes accessible. Every user story lists what keyboard use, labelling and error messages must achieve, and reviewers hold the work to that like any other criterion.
• Automated checks in the pipeline. Rule-based scanners run with each build and stop regressions. They catch only some problems, such as missing labels, poor contrast and invalid markup, so they add to manual testing and never stand in for it.
• Hands-on testing by specialists. Using only the keyboard, using screen readers on computer and phone, enlarging to 400 percent and switching off animation, across the journeys that count most: logging in, finding something, ordering, paying and managing the account.
• Tests with disabled users on the most important journeys, before release and after major changes.
• Contracts for what others supply. A payment widget, a sign-in provider, a chat assistant, a cookie banner, an embedded map or a video player all form part of what your customer experiences. Ask each supplier for an accessibility conformance report, then test the component as it behaves on your own pages.
• Content and documents. Editors are trained to write alt text, clear headings and link wording that makes sense out of context. Documents customers depend on, contracts and invoices for example, are published as tagged PDFs or in another accessible format.

We work this way when we deliver enterprise software and client portals: the pipeline runs accessibility checks, and every release leaves behind the evidence you need for your accessibility statement and for questions from clients or the CRPD. It applies equally to service assistants and to portals on platforms such as Salesforce, for instance at an insurer: the platform gives you accessible components, and what you add on top determines whether the end result is still accessible.

09A plan you can work through

1. 01List your services. Record the websites, apps, terminals and documents consumers use in each country, decide for each whether the Act applies, and note the reasoning, including for services you judge to be outside it.
2. 02Establish where you stand. Have an expert evaluate the critical journeys against EN 301 549 and scan the whole site automatically. Rank the findings by their effect on users, not by how many there are.
3. 03Fix at the source. Correct the design system and shared components first, so one fix reaches every page that uses them.
4. 04Publish the information. Explain in your terms or an accessibility statement how the service complies, give a contact point for feedback, and keep it up to date.
5. 05Make it part of delivery. Acceptance criteria, automated checks, manual test scripts and a release gate on the critical journeys.
6. 06Manage suppliers. Write accessibility requirements and evidence into contracts with agencies, platforms and widget providers.
7. 07Record exceptions. Where you invoke disproportionate burden, document the assessment, inform the CRPD or the relevant foreign authority where required, and schedule the review.

10What to follow

• Harmonised standards under the European Accessibility Act, a revised EN 301 549 among them, and their citation in the Official Journal.
• Guidance and first enforcement by the CRPD in Malta, and by the market surveillance authorities of the other countries where you serve consumers.
• Amendments to S.L. 627.03 and to other national transitional rules, and changes to the authorities named for sectors such as banking and transport.

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