Skip to content
Back to blog
EAAAI ActEN 301 549accessibility-statement

AI Act accessibility rules: how they connect to the EAA

Article 16(l) of the AI Act points at the European Accessibility Act. What the Digital Omnibus deferral changed, and what applies now.

P

Pavel Charkasau

The AI Act writes no accessibility rules of its own. It points at the ones the EU already has. Article 16(l) of Regulation (EU) 2024/1689 tells providers of high-risk AI systems to "ensure that the high-risk AI system complies with accessibility requirements in accordance with Directives (EU) 2016/2102 and (EU) 2019/882" (AI Act, Article 16). Those are the Web Accessibility Directive and the European Accessibility Act. So the technical bar is the one you already know: Annex I of the EAA, and through it EN 301 549 and WCAG 2.1 Level AA.

Two dates decide what that means today. The Digital Omnibus on AI, Regulation (EU) 2026/1744, moved Sections 1, 2 and 3 of Chapter III to 2 December 2027 for stand-alone Annex III systems and 2 August 2028 for AI inside regulated products. Article 16 sits in that block, so its accessibility point moved too. Article 50 did not move. Article 50(5) requires the notice telling someone they are dealing with an AI to "conform to the applicable accessibility requirements", and that has applied since 2 August 2026.

The EAA has applied since 28 June 2025 either way.

What does the AI Act say about accessibility?

One operative sentence and one recital, and neither invents a criterion.

Article 16(l) is the obligation. It is a cross-reference, not a standard. Recital 80 explains the reasoning: the Union and its member states signed the UN Convention on the Rights of Persons with Disabilities, so providers "should ensure full compliance with accessibility requirements" and build them in by design, integrating the measures into the design of the high-risk AI system rather than bolting them on (AI Act, Recital 80).

There is no AI accessibility standard to go and buy. Nothing in the AI Act tells you what contrast ratio a generated caption needs or how a streaming response should be announced. Those answers live in EN 301 549 and, through it, in WCAG. If you have an EAA programme running, the AI Act adds a legal hook to it rather than a second workstream.

Did the Digital Omnibus delay the AI Act's accessibility duty?

Yes, along with the rest of the high-risk obligations.

Regulation (EU) 2026/1744 was adopted on 8 July 2026, published in the Official Journal on 24 July 2026, and entered into force on 27 July 2026, six days before the deadline it was rewriting. It sets the date of application of Sections 1, 2 and 3 of Chapter III at 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and 2 August 2028 for those classified under Article 6(1) and Annex I.

Article 16 belongs to Chapter III, Section 3. Point (l) travels with it.

RuleWhat it coversApplies from
AI Act Art. 16(l)Accessibility of Annex III high-risk systems2 December 2027
AI Act Art. 16(l)Accessibility of Annex I product-embedded systems2 August 2028
AI Act Art. 50(5)Accessibility of the AI disclosure2 August 2026
EAA (Dir. 2019/882)Accessibility of the service itself28 June 2025

Read the bottom row again. The deferral changed the AI Act's timing, not your accessibility obligations, because for most of the companies asking me about this the binding rule was never Article 16 in the first place.

Which accessibility rule applies to AI systems right now?

Article 50(5), and it is narrower than people expect but immediate.

Article 50(1) requires providers to design AI systems intended to interact directly with people so that those people are told they are interacting with an AI system. Paragraph 5 adds how: the information goes to them "in a clear and distinguishable manner at the latest at the time of the first interaction or exposure", and "shall conform to the applicable accessibility requirements" (AI Act, Article 50). The Omnibus left Article 50 alone apart from a grace period to 2 December 2026 for machine-readable marking of synthetic content already on the market (White & Case).

In practice this is a very small piece of UI with a real legal duty attached. If your disclosure is a 12px grey line at #999 on white inside the chat header, it fails contrast before it fails anything else. If it lives in a title attribute on the launcher button, a screen reader user may never get it. If the chat panel renders the notice in a container the assistive technology never reaches, the notice was not provided.

Does the EAA already cover the AI in your product?

If the service around it is in scope, yes. The EAA regulates services, not techniques.

Directive (EU) 2019/882 has applied since 28 June 2025 (Article 31) to the consumer services listed in Article 2: e-commerce, consumer banking, e-books, electronic communications, the access services of audiovisual media, and elements of passenger transport. Annex I Section III sets the general requirements for those services, including that information about how the service works reaches people through more than one sensory channel, in an understandable form, and as text that assistive technology can turn into an alternative format.

Nothing in that text cares whether an answer came from a model or a decision tree. A support assistant embedded in an EU consumer shop is part of an e-commerce service, so its accessibility is already assessed against the same Annex I requirements as the checkout it sits next to. Conformity with the harmonised standard gives you the presumption of conformity under Article 15, which is why the practical target stays EN 301 549 and WCAG 2.1 AA.

Where do AI features actually fail?

The failures I see are ordinary WCAG failures wearing a new component name.

  • Streamed responses in a plain div. Tokens append to the DOM and a screen reader says nothing, because there is no aria-live="polite" region and no status role. The user watches a silent box.
  • A launcher that is not a button. <div class="chat-bubble" onclick=...> with a background image gives no role and no accessible name, which is a 4.1.2 failure whatever is behind it.
  • Focus stolen by autoscroll. Each new chunk scrolls the transcript and moves focus, so keyboard users lose their place mid-message.
  • Session timeouts. An assistant that drops the conversation after inactivity without warning runs into 2.2.1 the same way any other timed process does.
  • Generated alt text nobody read. Our scanner will tell you the alt attribute exists. It cannot tell you the model wrote "image of a person" for the illustration explaining your payment error.

That last one is the honest boundary. Automated testing catches somewhere between about 30% and 57% of issues depending on whether you count by volume or by success criteria (Deque), and conversational interfaces sit heavily on the manual side of that line. Someone has to open the chat with a screen reader and listen.

What should you do before December 2027?

Four things, in order, and the first one is cheap.

  1. Check whether any of your AI is Annex III at all. The eight areas are biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential services including creditworthiness and insurance, law enforcement, migration and border control, and the administration of justice and democratic processes. A shopping assistant is not on that list. A CV-screening tool is.
  2. Treat the EAA as the live obligation. If you sell a listed service to EU consumers, your AI surfaces are in scope now, and December 2027 changes nothing about that.
  3. Test the AI components like components. Run them through the same EN 301 549 clause list as the rest of the interface. The EN 301 549 checklist covers the clauses, and the manual part means a keyboard and a screen reader on the real chat, not on a static screenshot of it.
  4. Keep the record. Dated scan exports, plus manual test notes that name the assistive technology used. On top of those, a clause-by-clause conformance table. That file is what feeds an honest accessibility statement, and it is the artefact almost nobody has when an authority asks.

My own view, after reading both texts end to end: the AI Act's accessibility clause is close to symbolic for the companies I talk to. It defers to law that already binds them, on a date two years out, for a system category most of them do not operate. The clause worth putting in a sprint is Article 50(5), because it is live today and it sits on a widget most teams shipped without an accessibility review.

FAQ

Does the EU AI Act require WCAG?

Not directly. Article 16(l) requires high-risk AI systems to meet the accessibility requirements of Directives (EU) 2016/2102 and (EU) 2019/882, and those route through EN 301 549 to WCAG 2.1 Level AA. WCAG arrives by reference rather than by name.

Is a customer-support chatbot a high-risk AI system?

Usually not. Annex III lists eight specific areas, and general customer support is not among them. The same chatbot becomes high-risk if it does something on that list, such as screening job applicants or assessing creditworthiness. Article 50's disclosure duty applies either way.

Did the Digital Omnibus cancel the AI Act's accessibility requirement?

No, it deferred it. Regulation (EU) 2026/1744 moved Sections 1 to 3 of Chapter III, which contain Article 16, to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. The obligation still arrives, and the EAA already applies in the meantime.

Which standard should I test an AI feature against?

EN 301 549, which points to WCAG 2.1 Level AA for web content. Conformity with the harmonised standard gives a presumption of conformity with the EAA under Article 15, so the clause list you use for the rest of the product is the right one for the chat panel too.

Where to start

Run a scan of the pages where your AI features live, then open one of them with a screen reader and see whether the two findings match. Start a free scan and use the result as the first dated entry in your evidence file. A scan finds the machine-detectable failures; the conversation with a screen reader finds the rest.


Written by Pavel Charkasau, founder of WCAG Compliance. Last updated: 1 September 2026.

Sources