Einleitung: operative Herausforderungen

Die Bereitstellung eines KI‑Avatars auf einem Kiosk oder Bildschirm im öffentlichen Raum erfordert sicherzustellen, dass Menschen mit visuellen, auditiven, motorischen oder kognitiven Beeinträchtigungen Zugang haben, ohne die mehrsprachige Qualität oder die 24/7‑Verfügbarkeit zu beeinträchtigen. Dieser Leitfaden zielt darauf ab, allgemeine Prinzipien in konkrete Elemente zu überführen, die in Lastenheft, Pilot und Runbook für den Betrieb aufgenommen werden können.

Projektverantwortliche, IT‑Leiter und Accessibility‑Teams finden hier: den relevanten regulatorischen Rahmen, technische Prüfkriterien, UX‑Empfehlungen für Konversation und Oberfläche, ein Testprotokoll für Nutzer mit Behinderungen sowie eine einsatzbereite Audit‑Checklist.

Regulatorischer Rahmen und Anwendung der WCAG

Zugänglichkeitsrahmenwerke wie die WCAG bieten ein technisches Fundament, das auch für die Schnittstellen von interaktiven Kiosken relevant ist. In der Praxis geht es darum, die Prinzipien zu Medienalternativen, Tastaturbedienbarkeit, visueller Lesbarkeit und Robustheit anzuwenden.

Vor dem Rollout prüfen Sie, welche Pflichten lokal für Ihr Projekt gelten (nationale Regelungen, öffentliche Aufträge, interne Richtlinien). Konkrete Anforderungen können je nach Ortstyp und Status der Organisation variieren. Betrachten Sie die WCAG als technischen Leitfaden, den Ihre Oberfläche in Gestaltungsregeln und Abnahmekriterien übersetzen muss.

Wesentliche technische Kriterien für die Kiosk‑Schnittstelle

Die Kompatibilität mit assistiven Technologien hängt sowohl von der Interface‑Software als auch von Hardware und Integration ab. Um Interoperabilität mit Screenreadern und Hilfstechnologien zu gewährleisten, fordern Sie, dass die Oberfläche konkrete Prinzipien erfüllt: klare semantische Struktur, zugängliche Beschriftungen, logische Tab‑Reihenfolge und sichtbare Fokusanzeige.

Weitere technische Punkte für das Lastenheft: vollständige Tastaturnavigation, skalierbare Texte ohne Funktionsverlust, sichtbare Kontraste, textliche Alternativen für nicht‑textuelle Elemente und Mehrfach‑Eingabemodi (Touch, Sprache, Tastatureingabe).

Screenreader‑Kompatibilität und Struktur der Antworten

Damit ein Screenreader die vom Avatar erzeugten Inhalte korrekt ansagt, muss die Interface‑Schicht textuelle Elemente und relevante ARIA‑Attribute bereitstellen. Planen Sie textliche Ausgaben, die äquivalent zu gesprochenen Meldungen sind, damit blinde oder sehbehinderte Nutzer dieselben Informationen erhalten.

Testen Sie bei der Integration die Lesbarkeit kurzer Antworten und die Klarheit der Beschriftungen. Vermeiden Sie rein ikonische oder animierte Darstellungen ohne textliche Alternative. Die Bildschirmarchitektur sollte es dem Besuchenden ermöglichen, den Sitzungsstatus (Warten, in Behandlung, Ergebnis) schnell zu erkennen.

Sprachinteraktion, hörgeschädigte Nutzer und visuelle Alternativen

Sprachinteraktion ist für viele Anwendungsfälle zentral, muss aber stets von einer visuellen Alternative begleitet werden. Stellen Sie ein sichtbares Texteingabefeld, eine virtuelle Tastatur und klare Bedientasten zum Starten, Stoppen oder Wiederholen einer Interaktion bereit.

Untertitel und Echtzeit‑Transkription verbessern die Zugänglichkeit für Hörbehinderte. Diese Funktionen erfordern in der Regel eine spezifische Integration mit einem STT‑/Transkriptionsdienst und eine Komponente zur Anzeige der Untertitel. Planen Sie diese Bedürfnisse im Lastenheft und definieren Sie die erforderlichen APIs oder Webhooks.

Physische Ergonomie und Standort der Kioske

Physische Zugänglichkeit hängt von Standortwahl und hardwareseitiger Ergonomie ab: Positionierung, die Rollstuhlnutzung ermöglicht, ausreichend Auflagefläche, Neigung des Bildschirms, Lesbarkeit aus verschiedenen Blickwinkeln und Schutz gegen Blendung. Diese Aspekte sind abhängig von der gewählten Hardware und den Gegebenheiten vor Ort.

Berücksichtigen Sie auch Sitz‑ vs. Steh‑Nutzung, eine Armauflage oder Schreibfläche zur Eingabe sowie eine klare Beschilderung, die Nutzende zum Kiosk leitet. Die Mikrofon‑ und Lautsprecherqualität beeinflusst die Flussfähigkeit der Sprachinteraktion und sollte in Tests unter realen Bedingungen geprüft werden.

Kognitive Zugänglichkeit und Gestaltung der Konversation

Die konversationelle Gestaltung für Menschen mit kognitiven Beeinträchtigungen erfordert klare Sprache, kurze Sätze, begrenzte Auswahlmöglichkeiten und schrittweise Hilfen. Planen Sie einfache Bestätigungen und leicht zugängliche Wiederaufnahme‑Optionen, wenn der Avatar nicht verstanden hat.

Die Persona des Avatars sollte vorhersehbar und konsistent bleiben. SANIA kann entsprechend der Tätigkeit und den Bedürfnissen des Auftraggebers angepasst werden, wodurch Ton, Sprechtempo und Wortschatz an die Zielgruppe angepasst werden können.

Testprotokoll mit Nutzergruppen mit Behinderungen für einen Pilotbetrieb

Ein barrierefreier Pilot umfasst Tests mit Personen mit visuellen, auditiven, motorischen und kognitiven Beeinträchtigungen. Definieren Sie klare Testziele: Validierung der Tastaturnavigation, Verständnis sprachlicher und textlicher Antworten, Nutzung bei realem Geräuschpegel und Bewertung der physischen Beschilderung.

Organisieren Sie repräsentative Szenarien (z. B.: einfache Information finden, Wegbeschreibung erfragen, Sprache wechseln). Sammeln Sie in jeder Sitzung qualitative Beobachtungen, protokollieren Sie Unterbrechungspunkte und erfragen Sie Rückmeldungen zur Benutzbarkeit und Verständlichkeit. Führen Sie Tests in mehreren Sprachen durch, wenn der Standort ein mehrsprachiges Publikum empfängt.

Einsatzbereite Audit‑Checklist für den Betrieb

Diese Liste kann in das Lastenheft integriert und während Pilot sowie Betrieb verwendet werden. Sie umfasst Oberfläche, Sprache, Hardware und Tests.

  • Für jede gesprochene Meldung ist eine zugängliche Text‑Alternative vorhanden.

  • Vollständige Tastaturnavigation und logische Tab‑Reihenfolge in der Oberfläche.

  • Klare Beschriftung der Steuerelemente mit zugänglichen Attributen (ARIA) und sichtbaren Labels.

  • Sichtbare Fokusanzeige und explizite Statusrückmeldungen (wird gerade vorgelesen, wartet).

  • Ausreichend große Touch‑Ziele und leicht erreichbare Eingabeflächen.

  • Farbkontrast der Texte und interaktiven Elemente entspricht den WCAG‑Empfehlungen oder, falls nicht möglich, sind visuelle Alternativen hervorgehoben (Symbole mit Text). Beachten Sie, dass die genauen Kontrastverhältnisse in den WCAG definiert sind und je nach angestrebtem Konformitätsziel geprüft werden müssen. Ein praktischer Hinweis: testen Sie die Oberfläche unter unterschiedlichen Lichtbedingungen, um die tatsächliche Lesbarkeit zu validieren.

Beispielkonfigurationen von SANIA und Punkte für das Lastenheft

Nachfolgend drei illustrative Konfigurationen und die zu spezifizierenden Elemente im Lastenheft. Achtung: Manche Funktionen erfordern spezifische Integrationen und werden nicht automatisch ohne Entwicklungsaufwand bereitgestellt.

Konfiguration 1 – Touch‑Interface und zugänglicher Text: SANIA wird auf einem interaktiven Bildschirm/Kiosk mit Touch‑Interface und vollständigen textlichen Ausgaben betrieben. Zu definierende Merkmale: Tastaturnavigation, ARIA‑Beschriftungen, Fokusmanagement, anpassbare Schriftgrößen. Hinweis zu SANIA: Der Avatar kann mit Touch‑ und Textoberfläche betrieben werden und nutzt eine organisationsspezifische Wissensbasis.

Konfiguration 2 – Erweiterte Sprachinteraktion: SANIA stellt Sprach‑Interface und Sprachsynthese bereit. Legen Sie im Lastenheft fest, wie mit sprachlichen Unterbrechungen umzugehen ist, wie Sprachwechsel in einer Sitzung gehandhabt werden und welche Qualitätsanforderungen an Mikrofone und Lautsprecher bestehen. Hinweis zu SANIA: SANIA kann in mehr als 100 Sprachen kommunizieren, rund um die Uhr betrieben werden und Unterbrechungen einer Sprachantwort verarbeiten, wenn der Nutzende wieder spricht.

Konfiguration 3 – Erweiterte Zugänglichkeit (Untertitel und Transkription): Für Untertitel oder Echtzeit‑Transkription ist eine spezifische Integration mit einem STT‑Dienst und einer Komponente zur Untertitelanzeige erforderlich. Geben Sie die APIs, akzeptable Latenz und Fallback‑Modi an, falls der Transkriptionsdienst nicht verfügbar ist. Diese Ebene ist eine Integration und erfordert die Festlegung der Verantwortlichkeiten zwischen den Beteiligten.

Vorsichtspunkte und häufige Fehler

Beschränken Sie Barrierefreiheit nicht auf reine Sprachinteraktion: Ein Kiosk muss immer textliche und taktile Alternativen bieten. Vermeiden Sie es, Spracherkennung als universelle Lösung zu betrachten, ohne Notfall‑Szenarien vorzusehen.

Verwechseln Sie nicht Software‑Barrierefreiheit mit Hardware‑Barrierefreiheit. Ungeeignete Hardware‑Entscheidungen (z. B. nicht ablesbarer Bildschirm bei Sonnenlicht, schlecht positioniertes Mikrofon) können eine gut gestaltete Softwareoberfläche wirkungslos machen.

Schlussendlich gehen Sie nicht von Konformität aus: Beziehen Sie betroffene Personen in den Pilot ein und dokumentieren Sie getroffene Entscheidungen, um sie im Falle eines Audits begründen zu können.

Praktisch: Pilot und Runbook für den Betrieb vorbereiten

Integrieren Sie Zugänglichkeitskriterien bereits bei der Erstellung des Lastenhefts und planen Sie Tests unter realen Bedingungen, bevor Sie eine breite Einführung vornehmen. Definieren Sie operative Review‑Punkte zur Überprüfung der Verfügbarkeit von Sprach‑ und Transkriptionsdiensten, wenn diese integriert sind.

Dokumentieren Sie Wartungs‑ und Support‑Prozeduren für Hardware und Software, Kontakte zu Drittanbietern (z. B. STT‑Anbieter) und Degradationsszenarien (z. B. reiner Textmodus, wenn die Sprachfunktion nicht verfügbar ist). Legen Sie außerdem eine klare Anweisung fest, wie Besucher zu menschlicher Hilfe geleitet werden, wenn der Avatar nicht antworten kann.