So prüfen Sie ein WebChat-Widget auf Tastatur- und Screenreader-Zugänglichkeit

Prüfen Sie die Seite, das Widget und den Wechsel zwischen beiden

Ein Chat-Widget funktioniert nicht isoliert. Sein Starter befindet sich auf einer Host-Seite, während die geöffnete Unterhaltung in einem Panel, Dialog oder einer anderen Oberfläche angezeigt werden kann. Testen Sie das tatsächlich eingebundene Erlebnis: die Seite rund um den Starter, das Widget selbst und das Verhalten beim Wechsel hinein und wieder hinaus.

Notieren Sie vor dem Test die URL der Seite, die Widget-Konfiguration, Browser und Betriebssystem, die unterstützende Technologie sowie die einbezogenen Oberflächenzustände. Berücksichtigen Sie den Starter, den geöffneten Chat, ein mögliches Formular vor dem Chat, den Nachrichtenaustausch, Validierungsfehler, den minimierten und den geschlossenen Zustand, sofern diese Funktionen vorhanden sind. Gehen Sie nicht davon aus, dass jedes Widget ein modales Dialogfeld verwendet: Stellen Sie zunächst fest, wie sich dieses Widget verhält.

• Umfang: Einbindung auf der Host-Seite, Bedienelemente des Widgets und relevante Unterhaltungszustände.
• Stichprobe: Wählen Sie repräsentative Seiten und Abläufe aus, darunter, sofern verfügbar, ein Formular- oder Fehlerzustand.
• Umgebung: Notieren Sie Browser, Betriebssystem, Screenreader und Eingabemethode.
• Zuständigkeit: Halten Sie fest, welche Bereiche Ihr Website-Team, der Widget-Anbieter oder der Kanal-Anbieter kontrolliert.

Erstellen Sie einen kleinen, wiederholbaren Testplan

Kombinieren Sie Tests ausschließlich mit der Tastatur mit Screenreader-Tests. Automatisierte Prüfungen auf Barrierefreiheit können einige Probleme aufdecken, belegen aber nicht, dass ein Widget barrierefrei ist. Laut WAI kann kein einzelnes Prüfwerkzeug feststellen, ob eine Website die Barrierefreiheitsstandards erfüllt; dafür ist die fachkundige Bewertung durch Menschen erforderlich.

Wählen Sie eine kleine Anzahl von Nutzungsszenarien aus, die Ihr Team nach Änderungen wiederholen kann. Öffnen Sie zum Beispiel das Widget, erreichen und vervollständigen Sie die Felder, senden Sie eine Nachricht, nehmen Sie eine Antwort wahr, schließen Sie das Widget und setzen Sie die Nutzung der Seite fort. Testen Sie denselben Ablauf sowohl ausschließlich mit der Tastatur als auch mit einem Screenreader.

• Verwenden Sie Tab und Umschalt+Tab, um zwischen Bedienelementen zu wechseln, und Eingabe oder Leertaste, um Schaltflächen zu aktivieren.
• Nutzen Sie die üblichen Lese- und Formularnavigationstasten des Screenreaders, um Namen, Rollen, Anweisungen und Aktualisierungen zu prüfen.
• Führen Sie gegebenenfalls einen automatisierten Scan aus, überprüfen Sie die Ergebnisse anschließend manuell und testen Sie Verhaltensweisen, die das Werkzeug nicht beurteilen kann.
• Verwenden Sie keine sensiblen Testdaten und senden Sie während einer Prüfung keine echten Kundeninformationen.

Prüfen Sie das Öffnen und Schließen sowie die Rückgabe des Fokus

Navigieren Sie ohne Maus zum Starter. Prüfen Sie, ob er einen aussagekräftigen zugänglichen Namen hat, sichtbar fokussiert wird und sich mit Eingabe oder Leertaste aktivieren lässt. Ermitteln Sie nach dem Öffnen des Chats, wohin der Fokus wechselt und ob dieses Ziel den nächsten Schritt verständlich macht.

Verhält sich der Chat wie ein modales Dialogfeld, vergleichen Sie sein Tastaturverhalten mit dem Muster für modale Dialogfelder in den WAI-ARIA Authoring Practices: Der Fokus wechselt in den Dialog, Tab und Umschalt+Tab bleiben darin, Escape schließt ihn und der Fokus kehrt in der Regel zum auslösenden Bedienelement zurück. Wenden Sie dieses Muster nur an, wenn die Oberfläche tatsächlich modal ist. Prüfen Sie bei einem nicht-modalen Panel, ob Nutzende zwischen Panel und Seite wechseln können, ohne eingeschlossen zu werden oder die Orientierung zu verlieren.

Schließen Sie den Chat per Tastatur und bestätigen Sie, dass der Fokus an eine sinnvolle Stelle zurückkehrt – in der Regel zum Starter – und sichtbar bleibt. Öffnen Sie das Widget erneut und prüfen Sie, ob der vorherige Unterhaltungszustand und das Fokusverhalten verständlich sind.

• Lassen sich der Starter und die Schließen-Schaltfläche per Tastatur erreichen und aktivieren?
• Ist der Fokus vor und nach dem Öffnen, Schließen und erneuten Öffnen sichtbar?
• Wechselt der Fokus beim Öffnen des Widgets an einen sinnvollen Ausgangspunkt?
• Können Nutzende das Widget ohne Zeigegerät und ohne unerwartete Fokuseinschränkung verlassen?
• Können Nutzende nach dem Schließen an einer sinnvollen Stelle auf der Host-Seite fortfahren?

Prüfen Sie Reihenfolge, Bedienelemente und Formularhinweise

Navigieren Sie mit der Tabulatortaste durch das geöffnete Widget und die nahegelegenen Bedienelemente der Seite. Der Fokus sollte sich in einer sinnvollen Reihenfolge bewegen, die den Zusammenhang erhält und die Bedienung der Oberfläche ermöglicht. Achten Sie darauf, ob der Fokus hinter ein Overlay springt, ein Bedienelement überspringt, in verborgene Inhalte gelangt oder das Widget unerwartet verlässt. Prüfen Sie, ob jedes fokussierte Bedienelement einen sichtbaren Fokusindikator hat.

Untersuchen Sie Schaltflächen, Links, Felder und andere interaktive Komponenten mit einem Screenreader. Ihre Namen und Rollen sollten verständlich machen, worum es sich handelt und welche Aktion sie ausführen. Zustandsänderungen wie erweitert, ausgewählt oder deaktiviert sollten, sofern zutreffend, ebenfalls vermittelt werden. Ein visuelles Symbol allein bietet möglicherweise keinen aussagekräftigen Namen.

Prüfen Sie bei jeder Eingabe, ob verständlich ist, welche Informationen erwartet werden und ob Beschriftung oder Hinweis, sofern erforderlich, programmatisch mit dem Feld verknüpft sind. Testen Sie neben der erfolgreichen Eingabe auch den Fehlerfall: Lösen Sie einen sicheren, vorhersehbaren Validierungsfehler aus und prüfen Sie anschließend, ob das fehlerhafte Feld und das Problem textlich kenntlich gemacht werden. Falls eine passende Korrektur bekannt ist, prüfen Sie, ob sie erklärt wird.

• Prüfen Sie die Tastaturreihenfolge für Starter, Unterhaltung, Nachrichtenfeld, Senden-Schaltfläche und gegebenenfalls Formular vor dem Chat.
• Prüfen Sie den sichtbaren Fokus und das sinnvolle Fokusverhalten, wenn Inhalte erscheinen oder Bedienelemente ihren Zustand ändern.
• Prüfen Sie Namen, Rollen und Zustände der Bedienelemente mit einem Screenreader, nicht nur anhand ihres Aussehens.
• Stellen Sie sicher, dass jede Eingabe eine klare, zugeordnete Beschriftung oder Anweisung hat.
• Senden Sie ungültige Testdaten ab und prüfen Sie, ob der Fehler kenntlich gemacht wird und gegebenenfalls hilfreiche Hinweise zur Korrektur verfügbar sind.

Prüfen Sie Ansagen zu Nachrichten und Statusänderungen

Senden Sie eine Testnachricht und prüfen Sie, wie der Screenreader sie wiedergibt. Lassen Sie dann eine Antwort oder eine andere Aktualisierung erscheinen, während sich der Fokus an anderer Stelle befindet. Nutzende sollten erkennen können, dass relevante neue Informationen eingegangen sind, ohne die Unterhaltung durchsuchen zu müssen oder dass sich der Fokus unerwartet bewegt.

Prüfen Sie außerdem Statusänderungen, die den Fokus nicht verschieben, etwa Validierungshinweise oder eine Meldung zum Verbindungsstatus, sofern dieser Zustand Teil des getesteten Nutzungsszenarios ist. Erfolgskriterium 4.1.3 der WCAG 2.2 behandelt Statusmeldungen, die programmatisch ermittelt werden können, damit unterstützende Technologien sie ohne Fokuswechsel ausgeben können. Vermeiden Sie Ansagen jeder geringfügigen visuellen Änderung: Die Ansagen sollten nützlich sein und die Unterhaltung nicht überfrachten.

• Kann ein Screenreader-Nutzer eingehende Nachrichten und deren Absender erkennen?
• Werden wichtige Aktualisierungen angesagt, während der Fokus an seiner Stelle bleibt?
• Werden Validierungs- und andere Statusmeldungen an unterstützende Technologien übermittelt, ohne dass eine visuelle Suche nötig ist?
• Sind die Ansagen verständlich und rechtzeitig und vermeiden sie unnötige Wiederholungen?

Dokumentieren Sie Fehler und weisen Sie sie der richtigen Stelle zu

Beschreiben Sie jeden Befund so, dass eine andere Person ihn nachvollziehen kann. Nennen Sie die Seite und den Zustand des Widgets, die Testumgebung, den Ausgangspunkt, die genauen Schritte mit Tastatur oder Screenreader, das beobachtete Ergebnis und das erwartete Ergebnis. Beschreiben Sie die praktische Auswirkung – zum Beispiel: „Tastaturnutzende können die Senden-Schaltfläche nicht erreichen“ – statt nur auf eine Norm zu verweisen.

Unterscheiden Sie wahrscheinliche Probleme bei der Einbindung auf der Host-Seite von Problemen im Widget. Entscheidend ist jedoch das eingebundene Nutzungserlebnis. Wenn die Zuständigkeit unklar ist, bitten Sie Website-Team und Widget-Anbieter, das Problem gemeinsam nachzustellen. Ein Befund, der beide Bereiche betrifft – etwa wenn der Fokus beim Öffnen des Panels in verborgene Seiteninhalte wechselt – muss möglicherweise von beiden Teams untersucht werden.

• Dokumentieren Sie: Fehler-ID, URL, Datum, Browser/Betriebssystem, unterstützende Technologie, Schritte, tatsächliches und erwartetes Ergebnis.
• Ergänzen Sie: Auswirkung auf Nutzende, gegebenenfalls einen Screenshot oder eine kurze Aufzeichnung sowie die wahrscheinliche Zuständigkeit.
• Ordnen Sie den Fehler einer Kategorie zu: Host-Seite, Widget, Integration oder gemeinsame/unklare Zuständigkeit.
• Wiederholen Sie nach einer Korrektur dieselben Schritte und dokumentieren Sie das Ergebnis auf der eingebundenen Seite – nicht nur in einer lokalen Komponenten-Vorschau.

Nutzen Sie WCAG- und WAI-Leitlinien und testen Sie Änderungen erneut

Nutzen Sie WCAG 2.2 als Referenz für die Bewertung der Tastaturbedienbarkeit, der Fokusreihenfolge und des sichtbaren Fokus, der Beschriftungen und Anweisungen, der Fehlererkennung, der Namen und Rollen von Komponenten sowie der Statusmeldungen. Die WAI-ARIA Authoring Practices bieten nützliche Interaktionshinweise für modale Dialogfelder und Schaltflächen. Richten Sie sich nach dem tatsächlichen Verhalten der Oberfläche und nicht nur nach ihrem visuellen Erscheinungsbild.

Die Evaluierungsleitlinien der WAI empfehlen, frühzeitig und während der gesamten Entwicklung zu prüfen. Wiederholen Sie die relevanten Tests, wenn sich Widget-Konfiguration, Gestaltung der Website, Integrationscode oder Widget-Version ändern. Führen Sie eine kurze Checkliste für Regressionstests und bewahren Sie die Befunde auf, damit Teams erkennen können, ob ein Fehler erneut auftritt.

• WCAG 2.2: https://www.w3.org/TR/wcag/
• WAI-Übersicht zur Bewertung der Barrierefreiheit: https://www.w3.org/WAI/test-evaluate/
• WAI-ARIA-APG-Muster für modale Dialogfelder: https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/
• WAI-ARIA-APG-Muster für Schaltflächen: https://www.w3.org/WAI/ARIA/apg/patterns/button/
• WCAG-EM-Evaluierungsmethodik: https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/

Bieten Sie einen persönlichen Kontaktweg, wenn das Widget den Zugang verhindert

Kann eine Person den Chat nicht erreichen oder nutzen, darf das nicht barrierefreie Widget nicht der einzige Weg zum Support sein. Bieten Sie einen alternativen Kontaktweg an, der selbst barrierefrei ist, und erklären Sie klar, wie die Person einen Menschen erreichen kann. Teams, die webchat.vip nutzen, können Unterhaltungen organisieren und Abläufe konfigurieren, die Gespräche an Mitarbeitende übergeben oder weiterleiten. Diese Funktion allein belegt jedoch nicht, dass ein bestimmtes Widget oder ein bestimmter Ablauf eine Barrierefreiheitsprüfung besteht.

Bestimmen Sie ein konkretes Team oder eine Rolle, die Barrierefreiheitsbefunde entgegennimmt, die Zusammenarbeit mit den zuständigen Website- und Widget-Verantwortlichen koordiniert und Korrekturen bestätigt. Ist die Ursache unklar, lassen Sie den Vorgang offen und stellen Sie das Problem gemeinsam nach, statt betroffene Nutzende aufzufordern, die technische Zuständigkeitsgrenze zu ermitteln.

• Informieren Sie Nutzende über einen barrierefreien alternativen Kontaktweg, falls sie den Chat nicht nutzen können.
• Leiten Sie ungelöste Zugangsprobleme an einen menschlichen Supportkontakt und eine verantwortliche Person für Website oder Barrierefreiheit weiter.
• Prüfen Sie den alternativen Kontaktweg und das korrigierte eingebundene Nutzungserlebnis mit Tastatur und Screenreader.