Barrierefreie KI-Chatbots: WCAG-konforme Voice-Bots
Im Jahr 2026 ruesten 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 auf einer Verbraucher-Website ist eine digitale Dienstleistung und fällt damit unter das Barrierefreiheitsstärkungsgesetz (BFSG), das seit dem 28. Juni 2025 gilt (BFSG, 2025). Genau hier entstehen die teuersten Lücken. In Deutschland sind rund 13 Millionen Menschen (Aktion Mensch, 2024) aufgrund von Behinderung oder Alter auf barrierefreie Inhalte angewiesen. Ein Bot, dessen Dialog ein Screenreader nicht vorliest, der sich nicht per Tastatur bedienen lässt oder dessen Audioausgabe keine Textalternative hat, schließt diese Gruppe systematisch aus. Dieser Artikel zeigt die typischen Fallen und wie eine Conversational UI mit semantischem HTML, ARIA-Live-Regions und Fokus-Management konform wird.
Warum 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össen Bussgelder von bis zu 100.000 Euro (BFSG, Paragraf 37) verhängen und im Extremfall die Bereitstellung der Dienstleistung untersagen.
Der technische Massstab für diese Barrierefreiheit ist die harmonisierte europäische Norm EN 301 549, die im Kern auf die Web Content Accessibility Guidelines (WCAG) 2.1 auf Konformitätsstufe AA verweist (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 erhöht die Fehlerlast zusätzlich, weil dynamische Komponenten besonders fehleranfällig sind. 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 begegnen uns in nahezu jedem Projekt, in dem eine Conversational UI nachgerüstet wurde, 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 aussen 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 reissen würde. Die Nielsen Norman Group (2023) weist darauf hin, dass häufige assertive Unterbrechungen schnell als belastend empfunden werden. 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. Der häufigste 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 jeden über Audio vermittelten Inhalt eine gleichwertige textliche Alternative: Erfolgskriterium 1.2.1 fordert eine Alternative für reine Audioinhalte (W3C WCAG 2.2). Für einen Voice-Bot bedeutet das konkret, dass jede gesprochene Antwort gleichzeitig als lesbarer Text im Verlauf erscheinen muss.
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 1.3.6 und die Prinzipien der Bedienbarkeit verlangen, dass Eingaben nicht an eine einzige Modalität gebunden sind. 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 (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 typischerweise in dieser Reihenfolge vor, weil die frühen Schritte das Fundament für die späteren bilden.
In der Umsetzung bewährt sich ein Grundsatz: Die Conversational UI sollte die übrige Seite nicht beeinträchtigen. Ein Chat-Widget, das beim Laden den Fokus an sich reisst, 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 mindestens zwei 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. Studien zeigen jedoch, dass automatisierte Tests nur einen Teil der WCAG-Erfolgskriterien überhaupt prüfen können (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.