Your AI support chatbot is covered by the EAA, and its Article 50 disclosure has to reach more than one sense

If you put an AI chatbot on an EU e-commerce site, you did not take on one compliance obligation. You took on two, from two different regulations, and in most implementations they fail at the same place: the little badge that says you are talking to an AI.

Most teams get this wrong in three predictable ways:

• The AI disclosure is rendered only as a visual chip, sometimes aria-hidden, sometimes inside an icon with no text alternative.
• The disclosure lives in the input placeholder, which disappears on focus and is announced inconsistently by screen readers.
• There is a "talk to a human" escape hatch that is reachable with a mouse and unreachable with a keyboard.

Each of those is a single Article 50 problem in the AI Act. Under the European Accessibility Act, each is also an accessibility failure on a service that has been in scope since 28 June 2025.

1. Open the chat widget and press Tab from the page body. If you cannot reach the launcher, the disclosure and the human handoff by keyboard, stop and fix that first.
2. Turn the screen off and use a screen reader. If the AI disclosure is never announced, it does not exist for that user.
3. Move the disclosure out of placeholder and out of any icon-only element, into persistent text in the accessible name or the message stream.
4. Confirm the disclosure survives copy and paste. If the user cannot get it into a text buffer, it is not in a format that can be turned into an assistive one.
5. Record which Annex I obligations you just satisfied, with the date. The assessment is the evidence, not the fix.

The widget is a related online application, so Section III (c) already binds it

Before support services are mentioned at all, Annex I Section III (c) covers this:

making websites, including the related online applications, and mobile device-based services, including mobile applications, accessible in a consistent and adequate way by making them perceivable, operable, understandable and robust;

A chat widget embedded in your storefront is a related online application. It does not matter that a vendor supplies it, that it renders in an iframe, or that it loads from someone else's CDN. If it is part of the service you offer, perceivable, operable, understandable and robust applies to it.

Real-world example: a shop embeds a hosted chatbot whose launcher is a div with a click handler and no role, no tabindex and no accessible name. Sighted mouse users see a helpful bubble. Keyboard and screen reader users encounter nothing at all. The service is not operable, and the fact that the vendor built the widget does not move the obligation off the service provider.

If it answers support questions, Section III (d) binds it too

Section III (d) names the category explicitly:

where available, support services (help desks, call centres, technical support, relay services and training services) providing information on the accessibility of the service and its compatibility with assistive technologies, in accessible modes of communication.

Read the list again. Help desks. Call centres. Technical support. Relay services. An AI chatbot that has replaced your first-line support is a help desk that happens to be automated. Automating it does not remove it from the list, and there is no carve-out in the Directive for support delivered by software rather than by a person.

Note what (d) actually obliges, because it is narrower than people assume: the support service must provide information on the accessibility of the service and its compatibility with assistive technologies, in accessible modes of communication. That is a specific duty about a specific topic. It is not a blanket rule that everything the bot ever says must meet a standard.

The blanket rule is (c), above. You need both, and they do different work.

The Article 50 disclosure is information about the functioning of the service

Here is where the two regulations meet on one element.

Article 50(1) of Regulation (EU) 2024/1689 requires that people are informed they are interacting with an AI system, and it has applied since 2 August 2026. The Commission's Article 50 Guidelines of 20 July 2026 set out what the disclosure has to convey, including its artificial nature and the identity of the principal behind it.

Now put that next to Annex I Section III (b), which governs information about how the service functions:

making the information available via more than one sensory channel;

and:

making the information content available in text formats that can be used to generate alternative assistive formats to be presented in different ways by the users and via more than one sensory channel;

An AI disclosure is information about the functioning of the service. It tells the user what they are dealing with and what its answers are worth. So under (b)(i) it has to reach more than one sensory channel, and under (b)(iv) it has to exist in a text format that can be converted into alternative assistive formats.

That is the specific test a visual badge fails. Not "it would be nice if it were accessible". It reaches exactly one sensory channel, and if it is baked into an icon, a sprite or a canvas, it cannot be converted into anything.

Real-world example: a team ships a grey pill reading "AI" beside the assistant's name, styled with CSS and marked aria-hidden="true" so it does not clutter the screen reader output. That decision satisfies a design review and breaks both obligations at once. Article 50 is not discharged, because a blind user is never told the responder is a machine. Section III (b)(i) is not met, because the information exists on one channel only.

The fix is dull and takes ten minutes: put the disclosure in the assistant's accessible name and as a real text message in the transcript, so it is read, copied, and translated like any other text.

The relay services line, which almost nobody reads

Section III (d) names relay services as a support service. Relay services are how many deaf and hard-of-hearing users reach a help desk: a human or automated intermediary sits between the user and your support channel.

If your only support path is an AI chat widget that a relay operator cannot navigate, you have not merely built an awkward experience. You have closed the channel that the Directive assumes exists.

This is also the most common place where the "we have a human handoff" answer falls apart. A handoff that requires clicking an unlabelled icon, or that opens a modal which traps focus, is not a handoff for the users most likely to need one.

What accessible modes means for a chat widget, concretely

The Directive does not hand you a checklist, and no harmonised standard is cited in the Official Journal under the EAA, so there is no presumption of conformity to lean on. We wrote about that in detail in EN 301 549 does not make you EAA compliant.

What the text does give you is operational, if you read it as requirements rather than aspirations:

Real-world example: a bot answers "is your checkout screen reader accessible?" with a generic fallback and no escalation. That is a Section III (d) failure in its purest form, because the one topic (d) explicitly names is the one topic the support service cannot handle.

Enforcement, honestly

Nobody is going to fine you next week for an inaccessible chat badge, and you should be sceptical of anyone who says otherwise.

Under the BFSG, the German market surveillance authority is the Marktüberwachungsstelle der Länder für Barrierefreiheit von Produkten und Dienstleistungen. Its practical mode is complaint-driven, and consumers and qualified bodies can file. The realistic sequence is a complaint, a request for information, a deadline to remedy, and escalation only if you ignore it.

So the honest risk model is not a surprise penalty. It is that a complaint arrives, you are asked what assessment you did, and you have nothing dated to show. The EAA is a documentation regime as much as a design one, which is the same shape as the disproportionate burden trap we covered in Disproportionate burden is not a get-out.

Common pitfalls, and how to avoid them

• Assuming the vendor owns it. If you embed it, you offer it. The remedy is contractual, requiring conformance from the vendor or replacing the widget. It is not a disclaimer in your accessibility statement.
• Treating Article 50 as a legal-page item. It is product UX. A disclosure nobody perceives has not been made.
• Using the wrong accessibility statement. The Annex V statement for private service providers is not the public sector one, and it has to be available orally. See the accessibility statement you are copying is the wrong one.
• Believing microenterprise status covers you. It exempts microenterprises providing services, on a live headcount and turnover test, and it is not a transition period. See the microenterprise test.
• Fixing it and recording nothing. An undocumented fix is indistinguishable from luck when someone asks what you assessed and when.

Does the EAA apply to chatbots?

Not as a named category. It applies to the service the chatbot is part of. A chat widget on a covered service is a related online application under Annex I Section III (c), and if it functions as a help desk it is also a support service under Section III (d).

Does an AI disclosure have to be accessible?

The disclosure is information about the functioning of the service, so Annex I Section III (b) applies: more than one sensory channel, understandable, and in a text format convertible to alternative assistive formats. A visual-only badge does not meet that.

Is a "powered by AI" badge enough for Article 50?

Article 50(1) requires that the person is informed they are interacting with an AI system. The Commission's Article 50 Guidelines of 20 July 2026 address artificial nature and the identity of the principal. A badge that is decorative, hidden from assistive technology, or ambiguous about who is responsible does not discharge it.

Can I rely on my chatbot vendor's accessibility statement?

No. The obligation sits with the service provider offering the service in the EU. A vendor conformance claim is useful evidence and a contractual lever, not a transfer of duty.

What about the human handoff?

Section III (d) names relay services among support services. A handoff route that is not keyboard reachable, not announced, or that traps focus is not usable by the people most likely to need it.

The obligations behind this

Each of these is a page carrying the obligation's own text, who it binds, and from when. They are generated from a dated corpus, not written by hand.

• Accessibility requirements
• Article 13, obligations of service providers
• Article 2, scope
• All 256 obligations under Directive (EU) 2019/882
• Article 50: Transparency Obligations

Official legal text

• Directive (EU) 2019/882, OJ L 151, 7.6.2019: EUR-Lex HTML · ELI
• Regulation (EU) 2024/1689, Article 50: EUR-Lex HTML
• Barrierefreiheitsstärkungsgesetz (BFSG): gesetze-im-internet.de
• Marktüberwachungsstelle der Länder (MLBF): mlbf-barrierefrei.de

Disclaimer

Legalithm materials are operational guidance only and do not constitute legal advice. The authentic texts are those published in the Official Journal of the European Union and prevail over this representation in every case.