When companies think about EU AI Act compliance, they think about risk classes, documentation, and human oversight. One requirement is almost always overlooked, even though it sits directly in the obligations catalog for providers of high-risk AI: accessibility.
Article 16(l) of the AI Act explicitly obliges providers of high-risk AI systems to make their systems accessible. And not by self-chosen standards, but according to existing EU law. This requirement is easy to miss because it sits at the end of a long list of provider obligations. But it has significant practical consequences, precisely because it links accessibility to product safety and liability.
This article explains what Article 16(l) actually requires, which laws it references, why accessibility becomes a safety and liability question, and what providers and deployers should consider now.
What Article 16(l) requires
The wording is brief. Providers of high-risk AI systems must ensure that their systems comply with the accessibility requirements of two EU directives:
Web Accessibility Directive (Directive EU 2016/2102)
Governs the accessibility of websites and mobile applications of public bodies. Particularly relevant when high-risk AI is used in public services or administration.
European Accessibility Act (Directive EU 2019/882)
The EAA is the central provision. It requires certain digital products and services to be accessible and usable by people with disabilities. It has applied since 28 June 2025 and affects a broad range of private-sector providers.
The crucial design point: the AI Act itself does not define technical accessibility standards. Instead, it references existing EU law. This is not a mere cross-reference but genuine integration. Providers must ensure that the requirements of the EAA and the Web Accessibility Directive are actually reflected in the design and development of their high-risk AI systems.
Why this matters: Accessibility is therefore no longer a voluntary best practice or a downstream fix. It is a legal obligation embedded in the conformity of the high-risk system. A system that fails to meet accessibility requirements does not fully satisfy the provider obligations under Article 16.
The connection to the European Accessibility Act
The EAA is the practically more important of the two referenced directives because it covers a broad range of private-sector providers. It applies, among others, to computers and operating systems, ATMs and payment terminals, e-books, e-commerce services, consumer banking services, and electronic communications services.
As soon as a high-risk AI is embedded in one of these products or services and is accessible to consumers, the EAA requirements apply via Article 16(l) within the AI Act framework too. For the roughly 87 million people with disabilities in the EU, this is about real access: Can they use an AI-powered banking portal? Do they understand the outputs of an AI system? Can they interact with an AI-based user interface?
One detail SMEs should know: microenterprises with fewer than 10 employees and an annual turnover or balance sheet total not exceeding 2 million euros are fully exempt from the EAA service requirements. But this exemption does not automatically release them from other AI Act obligations. It only concerns the accessibility requirements for services.
When accessibility becomes a safety question
Perhaps the most important point: accessibility shortcomings are not confined to usability. In certain configurations, they become a product safety and liability matter.
The background lies in the logic of EU product law. The safety of a product is assessed by reference to its "reasonably foreseeable conditions of use". This explicitly includes use by a diverse range of users, including people with disabilities.
It follows that if an accessibility barrier means certain users cannot properly understand the outputs of an AI system or cannot adequately interact with it, this can go beyond a pure usability question. It can become relevant to product safety, and thus to liability, where harm results.
The risk
An AI system produces safety-relevant information that a blind user cannot perceive because the output isn't compatible with screen readers. If harm results, this can trigger liability that goes beyond the AI Act.
The better approach
Consider accessibility from the start of the design. Inclusive user interface design, accessible output formats, compatibility with assistive technologies. This reduces not only compliance risk but liability risk too.
This is reinforced by developments in product liability law. The revised EU Product Liability Directive has modernized the notion of "product" and now explicitly includes software, including AI systems. This brings the question of whether an AI system is safely usable for all foreseeable users closer to the question of liability.
Relevant below high-risk too: Article 5(1)(b)
Article 16(l) applies only to high-risk systems. But there's an accessibility dimension that applies to all AI systems, regardless of risk class.
Article 5(1)(b) prohibits AI systems that exploit the vulnerabilities of persons due to age, disability, or a specific social or economic situation, where this could cause significant harm. This provision is among the prohibited practices and has applied since 2 February 2025.
For companies, this means: even a chatbot or automated decision system not classified as high-risk must not exploit a user's disability in a harmful way. Accessibility and the protection of vulnerable groups are thus anchored in the AI Act on two levels: as a positive design obligation for high-risk systems (Art. 16(l)) and as a prohibition of exploitative practices for all systems (Art. 5(1)(b)).
What providers should do now
For providers of high-risk AI systems, Article 16(l) creates a concrete to-do list.
Check whether the EAA and Web Accessibility Directive apply
Does your high-risk AI system fall under a product or service covered by the EAA? Is it used in public services, so the Web Accessibility Directive applies? This preliminary check determines the scope of obligations.
Integrate accessibility into design, don't retrofit
Consider accessibility from the concept phase onward. User interfaces, output formats, and interaction patterns should be compatible with assistive technologies like screen readers. Retrofitting is more expensive and often incomplete.
Include accessibility in the technical documentation
Since Article 16(l) is part of the provider obligations, compliance with accessibility requirements should be demonstrable in the technical documentation and conformity assessment process. Document which standards were applied and how they were tested.
Assess vulnerability as a safety factor in risk management
Include in your Article 9 risk management whether accessibility shortcomings can lead to safety risks for certain user groups. This connects the accessibility obligation with the risk management obligation and closes a common gap.
What deployers should consider
Article 16(l) is a provider obligation. But deployers also have an interest in the accessibility of the systems they use.
Anyone deploying a high-risk AI system should specifically ask about accessibility during vendor selection. Does the system meet EAA requirements? Is there documentation? Is the user interface compatible with assistive technologies? A provider that can't answer these questions delivers a compliance risk along with the product.
In addition, deployers who make the system accessible to their own customers, employees, or citizens may themselves fall under accessibility obligations, for example if they are public bodies or offer services covered by the EAA. The provider obligation under Article 16(l) and the deployer's own obligations then interlock.
Summary
Accessibility is one of the most frequently overlooked requirements of the EU AI Act. Article 16(l) obliges providers of high-risk AI systems to comply with the requirements of the European Accessibility Act and the Web Accessibility Directive. The AI Act defines no standards of its own but integrates existing accessibility law into the conformity framework.
The crucial shift in perspective: accessibility is not just a question of inclusion, but becomes, in certain configurations, a product safety and liability question. Those who consider accessibility from the start not only fulfill a legal obligation but also reduce the risk of harm and the associated liability.
For providers, this means: accessibility belongs in the design, in the technical documentation, and in risk management. For deployers, it means: ask specifically during vendor selection and keep your own obligations in view.
Capture all provider obligations with structure
SimpleAct guides you through all obligations under Article 16, from risk classification to accessibility, and documents every piece of evidence in an auditable way. All in one place.
Get started for free →This article is for general information purposes only and does not constitute legal advice. Specific accessibility requirements depend on the individual case and applicable sectoral law. If in doubt, we recommend seeking legal counsel. Last updated: May 2026.
About SimpleAct: SimpleAct is a German compliance platform that helps companies structurally document their AI systems in accordance with the EU AI Act. From registration to risk assessment to exportable audit reports. All in one place.
Tags
Yannick | SimpleAct Team
Author · SimpleAct Team
