Nachdem wir uns zuerst auf die Themenbasiertheit unseres Chatbots LiipGPT konzentriert hatten (zuletzt präsentiert beim ZüriCityGPT Relaunch), richteten wir unsere Aufmerksamkeit auf Barrierefreiheit mit dem Ziel, die WCAG-AA-Konformität zu erreichen. Wie bei vielen Funktionen haben wir zuerst untersucht, wie Branchenführende wie ChatGPT, Perplexity und Claude mit Barrierefreiheit umgehen. Obwohl wir überall Verbesserungspotenzial festgestellt haben, inspirierte uns das, darüber nachzudenken, wie wir es besser machen können.
Unsere Reise zur Barrierefreiheit folgte vier Hauptschritten: automatische Scans und Quick-Fixes, Tastaturnavigation, Optimierung für Mobile-Zoom und anschliessend für den Screen-Reader.
Automatische Scans und Quick-Fixes
Wir begannen mit automatisierten Accessibility-Tests mithilfe von Browser-Erweiterungen wie IBM Equal Access Accessibility Checker und axe DevTools. Diese Tools halfen uns, häufige Probleme zu identifizieren: fehlende Labels, unzureichender Farbkontrast, unsauberes semantisches HTML und fehlende ARIA-Attribute. Obwohl automatisierte Scans nur etwa 40% der Accessibility-Probleme erkennen, boten sie eine solide Grundlage für unsere Arbeit.
Tastaturnavigation
Eine korrekte Tastaturnavigation ist grundlegend für die Barrierefreiheit. Sicherzustellen, dass die grundlegende Tab-Navigation in der gesamten App funktioniert, ist relativ einfach. Komplexere Komponenten wie Tabs, Menüs und Modals erfordern jedoch erweiterte Tastaturinteraktionen: Pfeiltasten, Escape-Handling und Fokus-Management gemäss den offiziellen W3C-Richtlinien. Nutzer*innen, die auf Tastaturnavigation angewiesen sind, erwarten diese spezifischen Muster. Wenn davon abgewichen wird, führt das zu Verwirrung und Frustration. Anstatt diese Muster von Grund auf neu zu implementieren, nutzten wir Bits UI, eine Headless-UI-Bibliothek, die diese Accessibility-Richtlinien korrekt umsetzt.
Über einzelne Komponenten hinaus implementierten wir Fokus-Loops und Fokus-Wiederherstellung auf Anwendungsebene, damit Nutzer*innen beim Wechsel zwischen verschiedenen Bereichen der Chat-Oberfläche stets orientiert bleiben.
Optimierung für Mobile-Zoom
Während User-Tests für meinplatz.ch mit Nutzer*innen mit Behinderungen beobachteten wir etwas Auffälliges: Viele navigieren auf Websites auf mobilen Geräten mit 200% oder mehr Zoom und halten ihre Geräte nur etwa 10 cm vor die Augen. Diese Erkenntnis zeigte eine kritische Lücke in den meisten Chatbot-Implementierungen auf.
Die meisten Chatbots verwenden Elemente mit fixer Position: ein Chat-Input am unteren Rand und häufig eine Kopfzeile am oberen Rand. Wenn Nutzer*innen stark hineinzoomen, können fixierte Elemente den gesamten Viewport einnehmen und die Oberfläche unbenutzbar machen. Leider ist es in Browsern nicht möglich, das Zoom-Level zuverlässig zu erkennen. Unsere Lösung: Wir verwenden den Intersection Observer, um zu erkennen, wenn Header oder Footer mehr Platz einnehmen als erwartet. In diesem Fall entfernen wir ihre fixe Positionierung dynamisch, um die Nutzbarkeit wiederherzustellen.
Screen-Reader-Erfahrung
Barrierefreiheit für Screen-Reader entsteht nicht automatisch, sie erfordert sorgfältiges Design. Wir konzentrierten uns darauf, klaren Kontext durch eine saubere Seitenstruktur (Landmarks und Überschriften) bereitzustellen. So verstehen Nutzer*innen jederzeit, wo sie sich befinden und was gerade passiert, und erhalten Shortcuts zu den wichtigsten Bereichen der App.
Kontext bereitstellen
Wir implementierten eine umfassende Outline-Struktur mit Landmarks für die Hauptnavigation, die Einstellungen und die Eingabebereiche. Jede Nachricht enthält korrekte Überschriften und Labels. Zusätzlich haben wir nach dem Chat-Input (am unteren Seitenrand) einen Skip-Link eingefügt, der Nutzer*innen hilft, schnell zum Seitenanfang zurückzukehren.
Herausforderungen mit Web Components
Die Arbeit mit Web Components brachte eigene Herausforderungen mit sich. VoiceOver reagiert besonders empfindlich darauf, wie Bibliotheken implementiert sind. Wir arbeiteten eng mit dem Bits-UI-Team zusammen (das sehr schnell auf Bug-Reports reagierte) und implementierten beispielsweise lokale Portals für Dropdown-Menüs, um Navigationsprobleme mit VoiceOver zu vermeiden.
Umgang mit Ankündigungen
Eine der schwierigsten Herausforderungen war das Management von VoiceOver-Ankündigungen, wenn mehrere Ereignisse gleichzeitig auftraten. Da das Queueing von Ankündigungen nicht zuverlässig funktioniert, haben wir Ereignisse sorgfältig sequenziert und zusammengehörige Ankündigungen zusammengeführt. Wenn Nutzer*innen zum Beispiel „Alle Optionen auswählen“ in einer Liste anklicken, würden normalerweise einzelne Ankündigungen für jede Option ausgelöst und sich gegenseitig überschreiben. Stattdessen brechen wir diese einzelnen Ankündigungen ab und ersetzen sie durch eine einzige klare Meldung, die alles zusammenfasst (alle Elemente ausgewählt oder abgewählt, auf die vordefinierte Auswahl zurückgesetzt usw.).
Da der Chat eine SPA ohne Seiten-Reloads ist, war es zudem wichtig, alle Änderungen anzukündigen, die nur visuell sichtbar sind, zum Beispiel: Wechsel zwischen Light- und Dark-Mode, Sprachwechsel usw.
Chat-Flow für Screen Reader
Wir haben die Chat-Erfahrung speziell für Screen-Reader-Nutzer*innen gestaltet:
- Das Eingabefeld enthält sowohl einen Placeholder als auch ein aria-label mit dem Seitentitel. Dadurch wird beim Laden der Seite Kontext bereitgestellt, da das Eingabefeld automatisch fokussiert wird und Nutzer*innen den initialen Seiteninhalt überspringen.
- Wenn eine Antwort generiert wird, kündigen wir dies klar an und geben damit dasselbe Feedback wie bei einer visuellen Ladeanzeige.
- Sobald eine Antwort bereit ist, wird sie ohne Markdown-Formatierung vorgelesen (kein Kursiv, keine Links usw.), um einen natürlichen Lesefluss zu gewährleisten.
- Nach dem Vorlesen einer Antwort weisen wir darauf hin, dass Nutzer*innen direkt eine weitere Frage stellen oder zu den Optionen der letzten Nachricht navigieren können, um Feedback zu geben oder Referenzen anzusehen. Wir fügen diesen interaktiven Abschnitt der letzten Nachricht dynamisch zur Dokument-Outline hinzu und schaffen damit einen schnellen Navigations-Shortcut.
- Der Chat-Verlauf ist als Artikel mit Labels strukturiert, sodass frühere Konversationen leicht navigierbar sind.
Selbst ausprobieren
Du kannst diese Verbesserungen mit Alva erleben, dem Chatbot der Verwaltung Basel-Stadt. Versuche, mit VoiceOver (MacOS) oder NVA (Windows) zu navigieren, nur deine Tastatur zu verwenden oder auf einem mobilen Gerät stark hineinzuzoomen.
Eine fortlaufende Reise
Unser nächstes Ziel ist es, automatisierte Accessibility-Tests in unsere CI-Pipeline zu integrieren. Wie bereits erwähnt, erkennen automatisierte Scans jedoch nur rund 40 % der Accessibility-Probleme. Das bedeutet, dass wir weiterhin jede neue Funktion sorgfältig planen und manuell testen müssen. Nichts ersetzt menschliches Testen, wenn es um Barrierefreiheit geht. Automatisierte Tools können fehlende Labels oder Kontrastprobleme markieren, aber sie können nicht beurteilen, ob eine Oberfläche tatsächlich für jemanden nutzbar ist, der mit Screen-Reader oder Tastatur navigiert.
Barrierefreiheit ist eine fortlaufende Reise, kein Ziel. Wir setzen uns dafür ein, LiipGPT für alle nutzbar zu machen, und werden unseren Ansatz kontinuierlich auf Basis von Praxisfeedback weiterentwickeln.
Brauchst du Unterstützung bei deiner Accessibility?
Wir bieten Accessibility-Audits an, um Probleme in deinen Anwendungen zu identifizieren und zu beheben. Wenn du die Barrierefreiheit deines Produkts verbessern möchtest, kontaktiere uns, wir helfen gerne weiter.