Soll Ihre Web-App Anweisungen vorlesen? Erst die Bedienung klären, dann die Stimme

Eine Vorlesefunktion kann helfen, eine kurze Anweisung zu hören und dabei auf die Arbeit zu schauen. Beauftragen Sie sie als freiwillige Ergänzung für klar ausgewählten Text: mit verlässlichem Stopp und weiterhin lesbarer Anleitung. Eine gelungene Stimmprobe beweist nicht, dass alle Geräte, Sprachen und Unterbrechungen funktionieren.

Hier geht es um Sprachausgabe innerhalb einer Browser-App. Gemeint sind weder Diktieren noch die Produktion einer Audiodatei. Die Funktion ersetzt auch keine mit assistiven Technologien bedienbare Anwendung.

Was genau soll vorgelesen werden?

Stellen Sie sich einen Geräteverleih vor, dessen Team eine kurze Vorbereitungsanweisung prüft. Das ist ein erfundenes Beispiel, kein Kundenbericht. Sinnvoll könnte „Vorbereitungsschritte vorlesen“ sein, nicht „Alles auf dieser Seite vorlesen“. Kundennamen, interne Kommentare und Navigation dürfen nicht allein deshalb mitgesprochen werden, weil sie danebenstehen.

Markieren Sie vor der Entwicklung den Inhaltsbereich. Wird ein Schritt, die gesamte Anleitung oder ein ausgewählter Absatz gesprochen? Erscheint eine Warnung an der richtigen Stelle? Bei einer Mengentabelle braucht es eine geprüfte Sprechreihenfolge; die optische Anordnung ergibt nicht automatisch verständliche Sprache.

Der sichtbare Text bleibt maßgeblich. Die Stimme soll keine kürzere Anweisung erfinden oder Bedingungen weglassen. Falls eine eigene Sprechfassung gepflegt wird, braucht es eine verantwortliche Person für die Übereinstimmung beider Fassungen.

Eine Spracheinstellung garantiert keine bestimmte Stimme

MDN beschreibt SpeechSynthesis als Schnittstelle für verfügbare Stimmen und Sprachbefehle. Die Methode getVoices liefert die auf dem aktuellen Gerät verfügbaren Stimmen. Ein Ereignis namens voiceschanged meldet Änderungen dieser Liste.

Lassen Sie deshalb die tatsächlich verfügbaren Stimmen prüfen, statt überall dieselbe benannte Stimme zu versprechen. Fehlt eine geeignete Stimme für die gewünschte Sprache, bleibt der Text lesbar. Erklären Sie die fehlende Sprachausgabe, statt unbemerkt eine unpassende Sprache zu wählen.

Prüfen Sie echte Beispielsätze jeder unterstützten Sprache mit Personen, die deren Aussprache beurteilen können. Namen, Abkürzungen, Dezimalmengen und gemischtsprachige Texte verdienen besondere Aufmerksamkeit. Technisch ausgegebener Ton beweist keine verständliche Anweisung. Offline-Betrieb oder ausschließlich lokale Verarbeitung sollten Sie erst nach einer gesonderten Prüfung der gewählten Stimme und Plattform zusagen.

Mehrfaches Drücken darf keine Warteschlange alter Texte erzeugen

Laut MDN fügt speak einen Sprechauftrag zur Warteschlange hinzu; vorherige Aufträge kommen zuerst. Für das Briefing heißt das: Mehrfaches Drücken von Vorlesen darf nicht versehentlich alte Anweisungen für später aufstauen.

Wählen Sie eine Regel. Während des Sprechens könnte dieselbe Bedienung pausieren und fortsetzen. Oder die Auswahl eines neuen Texts beendet die alte Ausgabe und startet den neuen Inhalt. Beschriften Sie die Aktionen eindeutig. MDN unterscheidet pause und resume von cancel, das Sprechaufträge aus der Warteschlange entfernt. Das sind verschiedene Verhaltensweisen, nicht beliebig austauschbare Beschriftungen.

Klären Sie auch, was Stopp bewirkt, wenn bereits ein weiterer Text wartet. Lassen Sie schnelles wiederholtes Aktivieren und den Wechsel zwischen zwei Anweisungen vorführen. Nutzer sollen verstehen, was gerade läuft und ob danach noch etwas folgt.

Wenn sich die Arbeit ändert

Soll der alte Text weitersprechen, wenn jemand einen anderen Auftrag öffnet, die Anleitung ändert oder sich abmeldet? Als Ausgangspunkt empfiehlt sich, veraltete Ausgabe zu beenden und für den neuen Text eine bewusste neue Aktion zu verlangen. Halten Sie das gewünschte Verhalten fest.

Denken Sie an die Umgebung: Gesprochene Kundendetails können Umstehende mithören. Starten Sie die Ausgabe nur auf Wunsch, machen Sie den Inhalt der Aktion erkennbar und vermeiden Sie automatische Ansagen privater Angaben. Das sind Gestaltungsempfehlungen, keine Vertraulichkeitsgarantie der Schnittstelle.

Scheitert das Vorlesen, muss die Anleitung als Text verfügbar bleiben. Zeigen Sie verständlich an, wenn die Ausgabe nicht verfügbar oder unterbrochen ist. Ein animiertes Lautsprechersymbol allein erklärt den Fehler nicht.

Den Ablauf abnehmen, nicht nur den Klang

Nutzen Sie unkritische Beispielanweisungen. Prüfen Sie auf jedem vereinbarten Gerät und Browser Start, Pause, Fortsetzung und Stopp nach der gewählten Bedienung. Aktivieren Sie Vorlesen mehrfach und wechseln Sie zum zweiten Inhalt. Es darf keine überraschende Altlast in der Warteschlange bleiben. Ändern Sie den Text oder verlassen Sie den Auftrag und prüfen Sie die Unterbrechungsregel.

Wiederholen Sie das für jede unterstützte Sprache, einschließlich einer fehlenden geeigneten Stimme, soweit reproduzierbar. Prüfen Sie Tastaturbedienung, klare Namen der Bedienelemente und das Zusammenspiel mit den im Projekt vereinbarten assistiven Technologien. Das ist eine gezielte Abnahme, keine vollständige Barrierefreiheitszertifizierung.

Bringen Sie Textarten, Geräte, Sprachen und Unterbrechungsregeln in ein Gespräch über Ihre Web-App mit. Das Ergebnis ist ein freiwilliger, verständlicher Hörablauf mit geprüften Grenzen, nicht bloß eine Schaltfläche, die Ton erzeugt.