Im Jahr 2026 rüsten zahlreiche Unternehmen ihre Websites mit KI-Chatbots und Voice-Assistenten nach. Was als reine Effizienzmaßnahme im Kundenservice gedacht ist, hat eine rechtliche Dimension, die häufig übersehen wird: Ein Chatbot oder Voice-Bot, der Teil einer Dienstleistung im elektronischen Geschäftsverkehr ist, fällt unter das Barrierefreiheitsstärkungsgesetz (BFSG), das seit dem 28. Juni 2025 gilt (BFSG, 2025). In Deutschland lebten zum Jahresende 2025 gut 7,8 Millionen Menschen mit schwerer Behinderung (Statistisches Bundesamt, 2026). Ein Bot, dessen Dialog ein Screenreader nicht vorliest, der sich nicht per Tastatur bedienen lässt oder dessen Audioausgabe keine Textalternative hat, schließt einen Teil dieser Menschen aus. Dieser Artikel zeigt die typischen Fallen und wie eine Conversational UI mit semantischem HTML, ARIA-Live-Regions und Fokus-Management konform wird.
Das Wichtigste in Kürze
- Ein Chatbot, der Teil einer Dienstleistung im elektronischen Geschäftsverkehr ist, fällt unter das BFSG; Prüfmaßstab ist EN 301 549 mit den WCAG auf Level AA. Ein eingekauftes Widget verlagert diese Verantwortung nicht.
- Der Verlaufs-Container steht von Anfang an leer mit role=log und aria-live="polite" im DOM. Wird die Live-Region erst beim Öffnen erzeugt, bleibt die erste Bot-Antwort unangekündigt.
- Jede Nachricht braucht einen für Screenreader lesbaren Hinweis auf Absender und Uhrzeit, weil Position, Farbe und Sprechblase diese Zuordnung nur sehenden Nutzern liefern.
- Das Widget muss per Tastatur zu öffnen, zu bedienen und per Escape zu schließen sein; nach dem Absenden bleibt der Fokus im Eingabefeld statt an den Seitenanfang zu springen.
- Synthetische Sprachausgabe ersetzt keinen Screenreader: Jede Audioantwort braucht denselben Inhalt als Text im DOM, jede Spracheingabe eine gleichwertige Texteingabe, denn jede Funktion muss auch per Tastatur bedienbar sein (WCAG 2.1.1).
- Ob eine Live-Region zum richtigen Zeitpunkt das Richtige ankündigt, zeigt kein automatischer Scan; der Dialog wird per Tastatur und mit Screenreadern durchlaufen.
Wann KI-Chatbots unter das BFSG fallen
Das BFSG verpflichtet Anbieter bestimmter Produkte und Dienstleistungen, ihre digitalen Angebote barrierefrei zu gestalten. Erfasst sind unter anderem der elektronische Geschäftsverkehr, also Websites und Apps, über die Verbraucher Verträge über Dienstleistungen oder Waren abschließen können (BFSG, Paragraf 1). Ein Chatbot, der Bestellungen entgegennimmt, Produkte empfiehlt, Termine bucht oder den Support abwickelt, ist Teil dieses Angebots und damit keine optionale Spielerei, sondern ein konformitätspflichtiger Bestandteil der Dienstleistung. Die Aufsichtsbehörden können bei Verstößen Bußgelder von bis zu 100.000 Euro (BFSG, Paragraf 37) verhängen und im Extremfall die Bereitstellung der Dienstleistung untersagen.
Als technischer Maßstab für diese Barrierefreiheit dient die europäische Norm EN 301 549. Ihre Fassung V3.2.1 bildet die Web Content Accessibility Guidelines (WCAG) 2.1 auf Konformitätsstufe AA ab; die im September 2026 erschienene Fassung V4.1.1 wurde für die EU-Richtlinie 2019/882 erarbeitet, auf der das BFSG beruht, und ist an WCAG 2.2 angepasst (EN 301 549). Wer einen Chatbot betreibt, muss die einschlägigen WCAG-Erfolgskriterien also auch auf das Chat-Widget und seine dynamischen Inhalte anwenden. Das ist anspruchsvoller als bei statischen Seiten, weil ein Bot fortlaufend neue Inhalte erzeugt, den Fokus verschiebt und oft mit Audio oder synthetischer Sprache arbeitet.
Die Dringlichkeit ergibt sich auch aus dem Ist-Zustand. Der WebAIM Million Report (2024) hat festgestellt, dass 95,9 Prozent (WebAIM Million, 2024) der untersuchten Startseiten erkennbare WCAG-Fehler aufweisen, mit durchschnittlich 56,8 Fehlern (WebAIM Million, 2024) pro Seite. Ein nachträglich integrierter Chatbot landet meist auf genau diesen Seiten und kann die Fehlerlast zusätzlich erhöhen, weil dynamische Komponenten eigene Fehlerquellen mitbringen. Die BFSG-Anforderungen im Überblick und die Kostenseite klären wir im Beitrag zu Accessibility-Audit, Kosten und ROI.
Konkret betrifft das mehrere Nutzergruppen, die im Tagesgeschäft leicht übersehen werden. Blinde und sehbehinderte Menschen bedienen die Seite mit einem Screenreader und sind darauf angewiesen, dass jede Bot-Antwort als Text im DOM steht. Motorisch eingeschränkte Menschen navigieren ausschließlich per Tastatur oder über alternative Eingabegeräte, die den Tastaturpfad nutzen. Gehörlose und schwerhörige Menschen können eine reine Sprachausgabe nicht hören. Und ältere Menschen, die häufig mehrere dieser Einschränkungen kombinieren, bilden eine wachsende Zielgruppe im E-Commerce. Ein barrierefreier Chatbot ist damit nicht nur eine rechtliche Pflicht, sondern erschließt einen erheblichen Teil der Kundschaft, der sonst beim ersten Kontaktpunkt verloren geht.
Eingekaufte Bot-Widgets befreien nicht von der Pflicht
Die typischen Fallen bei Conversational UI
Chatbots und Voice-Bots scheitern selten an einem einzelnen exotischen Detail, sondern an einer Handvoll wiederkehrender Muster. Die folgenden vier Fallen treten typischerweise auf, wenn eine Conversational UI nachgerüstet wird, ohne dass Barrierefreiheit von Anfang an mitgedacht war.
Screenreader liest den Dialog nicht
Neue Bot-Antworten erscheinen visuell, werden aber nicht angekündigt, weil keine Live-Region eingerichtet ist. Screenreader-Nutzer wissen nicht, dass eine Antwort vorliegt, und müssten manuell danach suchen.
Keine vollständige Tastaturbedienung
Schnellauswahl-Buttons, das Schließen des Widgets oder das Absenden reagieren nur auf Mausklick. Wer auf die Tastatur angewiesen ist, kommt im Dialog nicht weiter oder kann das Fenster nicht verlassen.
Fokus springt unkontrolliert
Nach dem Absenden landet der Fokus am Seitenanfang oder verschwindet ganz. Der Nutzer muss sich mühsam zurück in den Dialog navigieren, was die Konversation in der Praxis unbenutzbar macht.
Audio ohne Textpfad
Voice-Bots geben Antworten als synthetische Sprache aus, ohne dass derselbe Inhalt als Text vorliegt. Gehörlose und schwerhörige Nutzer sowie alle, die in einer stillen Umgebung sind, bleiben außen vor.
Die gemeinsame Ursache dieser Fallen ist, dass Conversational UI dynamisch ist. Anders als eine statische Seite verändert sich der Inhalt fortlaufend nach dem Laden, der Fokus wandert, und es kommen Modalitäten wie Audio hinzu, die in klassischen Webformularen nicht vorkommen. Wer diese Dynamik nicht aktiv für assistive Technologien beschreibt, baut ein Interface, das für sehende Maus-Nutzer einwandfrei funktioniert und für alle anderen unsichtbar ist.
Den Bot-Dialog als Live-Region ankündigen
Der Kern eines barrierefreien Chatbots ist die Live-Region. Sie weist den Screenreader an, neue Inhalte in einem bestimmten DOM-Bereich automatisch vorzulesen, ohne dass der Fokus dorthin wandern muss. Für einen Chat-Verlauf ist die Rolle role=log die passendste Wahl: Sie ist genau für sequenziell hinzukommende Informationen wie Protokolleinträge oder Chat-Nachrichten gedacht und hat einen impliziten aria-live-Wert von polite (W3C WAI, ARIA23). Polite bedeutet, dass der Screenreader die laufende Ausgabe nicht unterbricht, sondern die neue Nachricht erst nach einer Sprechpause vorliest. Das W3C führt den Chat-Verlauf ausdrücklich als Beispiel für diese Technik (W3C WAI, ARIA23).
Eine verbreitete Verwechslung betrifft den Unterschied zwischen polite und assertive. Eine assertive Live-Region unterbricht die laufende Ausgabe sofort. Für einen Chatbot ist das in der Regel die falsche Wahl, weil jede Bot-Antwort den Nutzer aus seiner aktuellen Tätigkeit reißen würde. Assertive ist Fehlern und Sitzungs-Zeitüberschreitungen vorbehalten, der normale Gesprächsfluss gehört in eine polite Region.
Die Live-Region muss vor der ersten Nachricht im DOM stehen
<!-- Verlauf existiert von Anfang an mit role=log -->
<div id="chat-log" role="log" aria-live="polite"
aria-label="Gespraechsverlauf">
<!-- Nachrichten werden als Kindelemente angehängt -->
</div>
<script>
function addBotMessage(text) {
const item = document.createElement('div');
// Sprecher und Uhrzeit für den Screenreader hörbar machen
item.innerHTML =
'<span class="vh">Assistent, ' + timeNow() + ': </span>' + text;
document.getElementById('chat-log').appendChild(item);
}
// .vh ist visuell versteckt, aber für Screenreader lesbar
</script>Jede einzelne Nachricht sollte für den Screenreader erkennbar machen, von wem sie stammt und wann sie gesendet wurde. Sehende Nutzer entnehmen das aus Position, Farbe und Sprechblase. Screenreader-Nutzer brauchen diese Information als Text, etwa durch einen visuell versteckten Präfix wie Assistent oder Sie samt Uhrzeit. So lässt sich der Verlauf später nachvollziehbar durchnavigieren, und es bleibt klar, welche Nachricht vom Bot und welche vom Nutzer stammt. Wie Live-Regions und Statusmeldungen grundsätzlich funktionieren, vertiefen wir im Beitrag zu barrierefreien Fehlermeldungen und Statusmeldungen.
Tastaturbedienung und Fokus-Management
Ein Chatbot muss vollständig per Tastatur bedienbar sein. Das umfasst das Öffnen und Schließen des Widgets, das Erreichen jedes Schnellauswahl-Buttons, das Eingeben und Absenden einer Nachricht sowie das Verlassen des Dialogs. Das WCAG-Erfolgskriterium 2.1.1 Tastatur verlangt, dass jede Funktionalität per Tastatur verfügbar ist (W3C WCAG 2.2). In der Praxis scheitert das oft an Buttons, die als nicht fokussierbares div oder span umgesetzt sind, oder an einer Tabulator-Reihenfolge, die nicht der visuellen Reihenfolge entspricht.
Mindestens ebenso wichtig ist das Fokus-Management. Wenn ein Nutzer eine Nachricht absendet, darf der Fokus nicht verloren gehen. Ein typischer Fehler bei dynamisch nachgeladenen Antworten ist, dass der Fokus nach dem Absenden an den Seitenanfang springt, weil das Eingabefeld kurzzeitig aus dem DOM entfernt und neu gerendert wird. Für Screenreader- und Tastatur-Nutzer ist die Konversation dann praktisch unbenutzbar, weil sie sich nach jeder Nachricht erneut in den Dialog navigieren müssen. Der Fokus sollte stattdessen im Eingabefeld bleiben oder kontrolliert auf das passende Element gesetzt werden.
- Das Widget öffnet und schließt sich per Tastatur, und der Fokus wandert beim Öffnen in den Dialog.
- Escape schließt das Chat-Fenster und gibt den Fokus an das auslösende Element zurück.
- Alle Schnellauswahl-Buttons sind native Buttons, fokussierbar und mit Enter sowie Leertaste auslösbar.
- Nach dem Absenden bleibt der Fokus im Eingabefeld oder wird gezielt gesetzt und geht nicht verloren.
- Die Tabulator-Reihenfolge folgt der visuellen Reihenfolge des Dialogs.
- Ein sichtbarer Fokus-Indikator zeigt jederzeit, welches Element gerade aktiv ist.
Wird der Chatbot als modaler Dialog über der Seite geöffnet, gelten zusätzlich die Regeln für Modals: Der Fokus sollte innerhalb des Dialogs gehalten werden (Fokus-Falle), damit der Tabulator nicht versehentlich auf die dahinterliegende Seite springt. Die Details dazu beschreiben wir im Beitrag zu barrierefreien Modals und Overlays sowie im Beitrag zum Fokus-Management in Single-Page-Apps.
Voice-Bots: der Textpfad zu jeder Audioausgabe
Voice-Assistenten und Bots mit synthetischer Sprachausgabe stellen eine zusätzliche Hürde dar. Wenn die einzige Ausgabe gesprochenes Audio ist, sind gehörlose und schwerhörige Menschen ausgeschlossen, ebenso alle, die in einer lauten oder stillen Umgebung keinen Ton nutzen können. Die WCAG verlangen für aufgezeichnete Audioinhalte eine gleichwertige textliche Alternative: Erfolgskriterium 1.2.1 fordert eine Alternative für aufgezeichnete reine Audioinhalte (W3C WCAG 2.2). Für einen Voice-Bot, dessen Antworten erst im Gespräch entstehen, ist derselbe Grundsatz die sichere Bauweise: Jede gesprochene Antwort erscheint gleichzeitig als lesbarer Text im Verlauf.
Umgekehrt gilt dasselbe für die Eingabe: Ein Bot, der ausschließlich auf Spracheingabe setzt, schließt Menschen mit Sprechbehinderung oder in geräuschvoller Umgebung aus. Das WCAG-Erfolgskriterium 2.1.1 verlangt, dass jede Funktion auch über die Tastaturschnittstelle bedienbar ist; eine reine Spracheingabe erfüllt das nicht. Eine barrierefreie Voice-UI bietet daher stets auch eine Texteingabe als gleichwertigen Weg an. Der Grundsatz lautet: Sprache ist eine zusätzliche Modalität, nicht die einzige.
| Modalität | Barriere ohne Alternative | Barrierefreie Umsetzung |
|---|---|---|
| Audioausgabe des Bots | Gehörlose und schwerhörige Nutzer hören die Antwort nicht | Jede Antwort erscheint zusätzlich als Text im Verlauf (vgl. WCAG 1.2.1) |
| Spracheingabe | Nutzer mit Sprechbehinderung oder in lauter Umgebung können nicht antworten | Texteingabefeld als gleichwertiger Weg vorhanden |
| Automatisches Abspielen | Töne überlagern den Screenreader und verwirren | Audio startet erst auf Nutzeraktion, mit Stopp-Möglichkeit (WCAG 1.4.2) |
| Zeitlimit für Antwort | Nutzer mit motorischen Einschränkungen schaffen die Eingabe nicht | Kein Zeitdruck oder Limit verlängerbar (WCAG 2.2.1) |
Synthetische Sprache ersetzt keinen Screenreader
Eine barrierefreie Conversational UI Schritt für Schritt
Die einzelnen Anforderungen ergeben zusammengesetzt eine klare Bauanleitung. Wir gehen in der barrierefreien Webentwicklung bei Conversational UI in dieser Reihenfolge vor, weil die frühen Schritte das Fundament für die späteren bilden.
Für die Umsetzung gilt ein Grundsatz: Die Conversational UI sollte die übrige Seite nicht beeinträchtigen. Ein Chat-Widget, das beim Laden den Fokus an sich reißt, automatisch Töne abspielt oder eine assertive Live-Region einrichtet, stört assistive Technologien auf der ganzen Seite, nicht nur im Dialog. Deshalb startet der Bot zurückhaltend, kündigt sich über einen klar benannten Auslöser an und übernimmt den Fokus erst, wenn der Nutzer das Widget aktiv öffnet. So bleibt der Bot ein zusätzliches Angebot, das die Seite ergänzt, statt ihre Bedienbarkeit zu untergraben. Dieses Prinzip der behutsamen Erweiterung lässt sich von Anfang an einplanen und ist im Nachhinein deutlich aufwendiger zu korrigieren.
- Semantisches Grundgerüst: Das Chat-Fenster ist ein klar benannter Bereich, das Eingabefeld ein echtes label-verknüpftes Formularfeld, alle Buttons sind native Buttons mit zugänglichem Namen.
- Live-Region einrichten: Der Verlaufs-Container steht von Anfang an mit role=log und aria-live=polite im DOM, leer, bevor die erste Nachricht hinzukommt.
- Nachrichten attribuieren: Jede Nachricht trägt einen für den Screenreader lesbaren Hinweis auf Sprecher und Uhrzeit, sehende Nutzer sehen Position und Farbe.
- Fokus steuern: Beim Öffnen wandert der Fokus in den Dialog, beim Absenden bleibt er im Eingabefeld, Escape schließt und gibt den Fokus zurück.
- Textpfad sichern: Jede Audioausgabe hat eine gleichwertige Textversion, jede Spracheingabe eine gleichwertige Texteingabe.
- Mit echten Screenreadern testen: Der gesamte Dialog wird per Tastatur und mit Screenreadern durchlaufen, bevor er live geht.
Künstliche Intelligenz kann Barrierefreiheit fördern, etwa beim automatischen Untertiteln oder beim Übersetzen in Leichte Sprache. Damit das gelingt, muss Inklusion von Anfang an mitgedacht werden, nicht erst nachträglich.
Der letzte Schritt ist der entscheidende. Automatisierte Prüfwerkzeuge erkennen einen Teil der Fehler, etwa fehlende Beschriftungen oder ungültige ARIA-Werte. Das W3C weist jedoch darauf hin, dass Prüfwerkzeuge nicht alle Aspekte der Barrierefreiheit automatisch prüfen können und menschliches Urteil nötig bleibt (W3C/WAI). Ob eine Live-Region zum richtigen Zeitpunkt das Richtige ankündigt, ob der Fokus nach dem Absenden sinnvoll sitzt und ob der Textpfad inhaltlich gleichwertig ist, zeigt nur ein manueller Test mit echten Screenreadern. Genau diese Prüfung ist Teil unseres WCAG-Audits.
Verwandte Artikel
ARIA Live: Barrierefreie Fehler- und Statusmeldungen
Barrierefreie Fehler- und Statusmeldungen nach WCAG 4.1.3: ARIA Live Regions, role=alert, role=status und aria-describedby für Formulare und dynamische Inhalte.
ARIA richtig einsetzen: Rollen, Zustände, Live-Regions
WAI-ARIA in der Praxis: Rollen vs. natives HTML, Zustände wie aria-expanded und aria-selected, Live-Regions mit polite und assertive sowie häufige Fehler.
Accessibility by Design: Barrierefreiheit von Anfang an
Barrierefreiheit früh verankern statt teuer nachrüsten: Kostenvorteil der Shift-Left-Strategie, klare Rollen, Design-Tokens und Definition of Done fürs BFSG.