Barrierefreier KI-Chat-Assistent: BFSG umsetzen

Ein Chat-Assistent auf der Website ist ein interaktives Bedienelement: Menschen tippen, lesen mit und navigieren mit der Tastatur. Genau deshalb gelten für ihn dieselben Anforderungen wie für den Rest der Seite, seit der European Accessibility Act am 28. Juni 2025 (European Accessibility Act) EU-weit anwendbar geworden ist und Deutschland ihn mit dem Barrierefreiheitsstärkungsgesetz (BFSG) umgesetzt hat. Das Gesetz verpflichtet viele Anbieter digitaler Dienstleistungen, ihre Angebote barrierefrei zu gestalten. In der EU leben rund 90 Millionen (Europäische Kommission) Menschen mit einer Behinderung, in Deutschland allein gut 7,8 Millionen (Statistisches Bundesamt) schwerbehinderte Menschen. Trotzdem weisen 95,9 Prozent (WebAIM Million) der meistbesuchten Startseiten erkennbare Verstöße gegen die Web Content Accessibility Guidelines auf. Ein Chat-Widget, das nur mit der Maus funktioniert, den Fokus verschluckt oder für Screenreader unsichtbar bleibt, wird damit schnell zum schwächsten Glied einer sonst konformen Website. Dieser Beitrag zeigt konkret, was ein barrierefreier KI-Chat technisch braucht und warum es einen Unterschied macht, ob er nach WCAG-Kriterien gebaut oder als Fremd-Widget aufgesetzt wird.

Grafik vergrößern

Beschriftungen der Abbildung

• Wie kann ich Sie unterstützen?
• Ist der Chat barrierefrei?
• Ja. Er ist voll per Tastatur
• bedienbar und Screenreader-fest.
• Voll per Tastatur bedienbar:
• Tab
• Enter
• Esc
• Nachricht schreiben ...
• Sichtbarer Fokusring beim Tabben
• Maßstab: WCAG 2.2 AA
• Tastaturbedienung
• Alles ohne Maus erreichbar
• Screenreader-Support
• Semantik und ARIA-Rollen
• Sichtbarer Fokus
• Fokusring mit 3:1 Kontrast
• Kontrast nach AA
• Text mindestens 4,5:1
• Skalierung bis 200%
• Zoom ohne Textverlust
• Textkontrast
• 4,5:1
• AA-Minimum
• Maßstab EN 301 549
• Barrierefrei bauen: WCAG 2.2 AA · EN 301 549 · BFSG
• Volle Tastaturbedienung, Screenreader-Support und sichtbarer Fokus von Anfang an

Barrierefreier KI-Chat-Assistent

Warum das BFSG auch ein Chat-Widget umfasst

Das BFSG verpflichtet Anbieter bestimmter digitaler Dienstleistungen dazu, ihre Angebote barrierefrei bereitzustellen. Dazu zählt unter anderem der elektronische Geschäftsverkehr, also Onlineshops und Websites, über die ein Vertrag angebahnt oder geschlossen wird. Ein KI-Chat-Assistent ist dabei kein isoliertes Extra, sondern ein Bedienelement dieses Angebots: Er nimmt Anfragen entgegen, erklärt Produkte und führt zum Kauf oder zum Kontakt. Damit ist er Teil der Dienstleistung und von denselben Anforderungen erfasst wie das Formular, der Warenkorb oder die Navigation. Wer einen Website-Assistenten in die Seite einbindet, sollte ihn deshalb nicht als Insel behandeln, sondern in die Barrierefreiheit der Gesamtseite einbeziehen (Barrierefreiheitsstärkungsgesetz (BFSG)).

Nicht jedes Unternehmen ist gleichermaßen betroffen. Das Gesetz nimmt Kleinstunternehmen aus, die Dienstleistungen erbringen und weniger als zehn (Barrierefreiheitsstärkungsgesetz (BFSG)) Beschäftigte sowie höchstens zwei Millionen Euro (Barrierefreiheitsstärkungsgesetz (BFSG)) Jahresumsatz aufweisen. Für viele mittelständische Shops und Dienstleister gilt die Pflicht dagegen unmittelbar. Bei Verstößen können die Marktüberwachungsbehörden Bußgelder von bis zu 100.000 Euro (Barrierefreiheitsstärkungsgesetz (BFSG)) verhängen, und Verbände sowie Wettbewerber können Verstöße geltend machen. Barrierefreiheit ist zudem nur eine von mehreren Pflichten rund um einen KI-Chat: Parallel greifen der Datenschutz nach DSGVO und zunehmend die Kennzeichnungspflicht nach dem EU AI Act. Wichtiger als die Angst vor Sanktionen ist aber der eigentliche Zweck: Ein barrierefreier Chat erreicht mehr Menschen und senkt Hürden für alle.

WCAG 2.2 und EN 301 549 als Maßstab

Das BFSG selbst beschreibt keine einzelnen Prüfschritte, sondern verweist über die europäische Normung auf konkrete technische Anforderungen. Maßgeblich ist die harmonisierte europäische Norm EN 301 549, deren Erfüllung eine sogenannte Vermutungswirkung auslöst: Wer sie einhält, gilt zunächst als konform (EN 301 549). Diese Norm greift wiederum auf die Web Content Accessibility Guidelines des W3C zurück, die den international anerkannten Maßstab für barrierefreie Webinhalte bilden. In der aktuellen Fassung WCAG 2.2 (W3C) ist der Standard seit Oktober 2023 offizielle Empfehlung des W3C und ergänzt die frühere Version um neun (W3C) neue Erfolgskriterien, etwa zur Sichtbarkeit des Fokus und zur Mindestgröße von Bedienelementen.

Die Leitlinien ordnen sich um vier Grundprinzipien: wahrnehmbar, bedienbar, verständlich und robust. Übertragen auf ein Chat-Widget heißt das: Inhalte und Antworten müssen wahrnehmbar sein, auch ohne Bild oder Ton; jede Funktion muss bedienbar sein, auch ohne Maus; Aufbau und Sprache müssen verständlich bleiben; und die technische Umsetzung muss robust genug sein, damit assistive Technologien wie Screenreader zuverlässig damit arbeiten. Für die Konformitätsstufe AA, die im rechtlichen Kontext regelmäßig gefordert ist, gelten die Kriterien der Stufen A und AA zusammen. Ein Assistent, der diese vier Prinzipien erfüllt, ist damit nicht nur formal näher an der Norm, sondern für alle Besucher besser nutzbar.

Volle Tastaturbedienung im Chat

Der wichtigste Test für einen barrierefreien Chat ist einfach: Lässt sich alles allein mit der Tastatur erledigen? Das Widget öffnen, einen Vorschlag auswählen, eine Nachricht tippen, absenden, durch die Antworten navigieren und das Fenster wieder schließen, all das muss ohne Maus möglich sein. Nutzerinnen und Nutzer bedienen den Chat dann über die üblichen Tasten: mit Tab und Umschalt-Tab durch die Elemente, mit Enter zum Absenden, mit den Pfeiltasten durch Vorschläge und mit Escape zum Schließen. Fällt auch nur ein Schritt aus, weil er sich lediglich per Klick erreichen lässt, ist der Chat für einen Teil der Menschen unbenutzbar.

Genauso wichtig wie die Erreichbarkeit ist die Reihenfolge. Der Fokus sollte einer logischen Abfolge folgen und beim Öffnen des Widgets in den Dialog springen, damit die nächste Eingabe dort landet, wo der Mensch sie erwartet. Beim Schließen kehrt der Fokus an die auslösende Stelle zurück. Entscheidend ist außerdem, dass keine Tastaturfalle entsteht: Wer mit Tab in den Chat gelangt, muss ihn auch wieder verlassen können. Bei XICBOT wird der Assistent so in die Seite eingebunden, dass Fokusführung und Tastaturpfade Teil der Umsetzung sind; wie die technische Integration in Website und Systeme abläuft, beschreibt der jeweilige Beitrag.

• Widget mit der Tastatur öffnen und schließen (Enter zum Öffnen, Escape zum Schließen)
• Eingabefeld, Senden-Button und Vorschläge in logischer Reihenfolge per Tab erreichbar
• Nachricht mit Enter absenden, ohne dass die Maus nötig ist
• Fokus springt beim Öffnen in den Dialog und kehrt beim Schließen zurück
• Keine Tastaturfalle: der Chat lässt sich jederzeit wieder verlassen
• Der Fokus bleibt an keiner Stelle unsichtbar oder hängen

Screenreader und semantisches HTML mit ARIA

Screenreader lesen vor, was auf dem Bildschirm passiert, doch sie können nur weitergeben, was technisch sauber ausgezeichnet ist. Ein Chat aus verschachtelten, bedeutungslosen Containern bleibt für sie stumm. Deshalb braucht ein barrierefreier Assistent semantisches HTML und, wo nötig, passende ARIA-Rollen: Das Eingabefeld hat eine Beschriftung, der Senden-Button einen sprechenden Namen, der Nachrichtenbereich eine erkennbare Rolle. Jedes Bedienelement folgt dem Grundsatz aus Name, Rolle und Wert, damit assistive Technologien wissen, was ein Element ist und wie es sich bedienen lässt.

Ein Chat ist dynamisch: Antworten erscheinen nach und nach, Vorschläge tauchen auf, ein Ladehinweis kommt und geht. Damit ein Screenreader diese Änderungen mitbekommt, werden neue Nachrichten über eine Live-Region angekündigt, statt lautlos im DOM zu erscheinen. So hört ein blinder Nutzer, dass eine Antwort eingetroffen ist, ohne den Fokus zu verlieren. Auch der Inhalt selbst muss verlässlich sein: Ein Assistent, der seine Auskünfte eng an eine geprüfte Wissensbasis bindet und nicht frei erfindet, ist für Menschen, die auf jede vorgelesene Aussage angewiesen sind, besonders wertvoll. Wie sich unbelegte Antworten technisch vermeiden lassen, zeigt der Beitrag dazu, Halluzinationen mit einer Wissensbasis zu vermeiden.

Sichtbarer Fokus, Kontraste und Skalierung

Wer mit der Tastatur navigiert, muss jederzeit sehen, wo der Fokus gerade steht. Ein sichtbarer Fokusindikator, also ein deutlicher Rahmen um das aktive Element, ist dafür Pflicht. WCAG 2.2 hat diesen Punkt geschärft: Das Erfolgskriterium „Focus Appearance“ (Stufe AAA) verlangt einen ausreichend großen Fokusindikator mit einem Kontrast von mindestens 3:1 (W3C) zwischen fokussiertem und nicht fokussiertem Zustand. Neu ist auch eine Mindestgröße für Bedienelemente von 24 mal 24 (W3C) CSS-Pixeln, damit Buttons und Vorschläge nicht so klein werden, dass sie mit zittriger Hand oder am Touchscreen kaum zu treffen sind.

Der zweite große Block betrifft die visuelle Gestaltung. Text muss sich ausreichend vom Hintergrund abheben, für normalen Fließtext mit einem Kontrast von mindestens 4,5:1. Genau hier scheitern viele Seiten: Zu geringer Textkontrast ist mit Abstand das häufigste erkennbare Problem und findet sich auf 83,9 Prozent (WebAIM Million) der untersuchten Startseiten. Ebenso wichtig ist, dass Informationen nicht allein über Farbe transportiert werden, dass sich Text ohne Hilfstechnik bis 200 Prozent (W3C) vergrößern lässt, ohne dass Inhalte oder Funktionen verloren gehen, und dass sich Animationen reduzieren lassen, wenn ein Nutzer das im System eingestellt hat. Ein Chat, der diese Punkte beachtet, bleibt auch bei starkem Zoom und reduzierter Bewegung voll bedienbar.

Barrierefrei gebaut statt aufgesetzt

Der Markt kennt zahlreiche fertige Chat-Bausteine, die sich schnell einbinden lassen. Viele davon sind jedoch auf Optik und Geschwindigkeit optimiert, nicht auf Barrierefreiheit, und lassen sich nachträglich nur mühsam anpassen. Auch pauschale Zusatzskripte, die Barrierefreiheit automatisch nachrüsten sollen, lösen das Problem selten vollständig, weil sie an der eigentlichen Struktur wenig ändern. Ein Widget, das von Grund auf nach WCAG-Kriterien gebaut ist, umgeht diese Nachbesserung. Es ist Teil des eigenen Seitenaufbaus, folgt denselben Regeln wie der Rest der Website und bleibt damit prüf- und wartbar.

XICBOT baut den Chat-Assistenten als individuelles Element Ihrer Website, statt ein fremdes Fenster darüberzulegen. Tastaturbedienung, Fokusführung, semantische Auszeichnung und Kontraste sind dabei von Anfang an eingeplant und werden zusammen mit dem übrigen Auftritt geprüft. So bleibt die gesamte Seite konform, statt an der Stelle des Chats eine Lücke zu reißen. Wie sich ein individuell gebauter Assistent grundsätzlich von einem generischen Baukasten unterscheidet, vertieft der Beitrag individueller Assistent versus Standard-Chatbot. Übergibt der Assistent bei Bedarf an einen Menschen, etwa über den Support-Assistenten, bleibt auch dieser Übergang zugänglich gestaltet. Welche Leistungen und welches Paket dazugehören, zeigen die Funktionsübersicht und die Preisübersicht.

Barrierefreiheit ist kein Schalter, den man später umlegt, sondern eine Eigenschaft, die man von der ersten Zeile an mitbaut.

Checkliste: einen barrierefreien KI-Chat erkennen

Aus den technischen Anforderungen ergibt sich eine überschaubare Prüfliste, mit der sich ein Chat-Assistent grob einordnen lässt. Sie ersetzt keine vollständige Konformitätsbewertung und keine Rechtsberatung, hilft aber, die wichtigsten Schwachstellen früh zu erkennen. Wer die folgenden Punkte erfüllt, ist bei der Barrierefreiheit seines Assistenten deutlich weiter als der Durchschnitt, bei dem laut Analyse weiterhin fast jede Startseite erkennbare Mängel aufweist.

• Lässt sich der gesamte Chat allein mit der Tastatur öffnen, bedienen und schließen?
• Ist der Fokus jederzeit sichtbar und folgt er einer logischen Reihenfolge?
• Sind Eingabefeld und Buttons beschriftet und als echte Bedienelemente ausgezeichnet?
• Werden neue Nachrichten für Screenreader über eine Live-Region angekündigt?
• Erreicht der Text einen Kontrast von mindestens 4,5:1 und dient die Farbe nicht als einziger Hinweis?
• Bleibt der Chat bei einer Vergrößerung auf 200 Prozent (WCAG 2.2, Kriterium 1.4.4) vollständig nutzbar?
• Werden Animationen reduziert, wenn ein Nutzer das im System eingestellt hat?
• Ist der Assistent Teil des barrierefreien Seitenaufbaus statt ein aufgesetztes Fremd-Widget?

Für den eigenen Auftritt legen wir offen, wie wir prüfen und wo noch Einschränkungen bestehen: Unsere Erklärung zur Barrierefreiheit nennt Methode, Stand und bekannte Lücken und kann als Vorlage für Ihre eigene dienen.

Häufige Fragen