Marcus Morba

Wenn visuelle Darstellung und Sprachausgabe auseinander driften

Zusammenfassung

Dieser Beitrag befaßt sich in erster Linie mit der sprachlichen Ausgabe von Screenreadern (Bildschirmlese-Programmen) und damit verbundenen Verantwortlichkeiten, um das Verständnis für diese zu fördern. In diesem Zusammenhang wird auch die Verwendung von ARIA besprochen und welche Auswirkungen eine falsche Anwendung haben kann, auch auf andere assistive Technologien (AT).

Leser*innen, für die der Themenbereich Screenreader neu ist, sollten zum besseren Verständnis zuerst den Beitrag “Screenreader-Nutzer ist nicht gleich Screenreader-Nutzer” lesen.

Die folgenden Themen zeigen auf, wie wichtig es ist, Barrierefreiheit von Anfang an im Umsetzungprozess zu berücksichtigen, dabei gemeinsam und teamübergreifend zu arbeiten und betroffene Nutzer*innen bei diesen Prozess mitwirken zu lassen, damit eine gelungene inklusive und barrierefreihe Lösungen realisiert werden kann.

Hauptthemen

  • Je nach Schreibweise ist die sprachliche Ausgabe in der genutzen Browser und Screenreader-Kombinationen sehr unterschiedlich, was zu Verständnisschwierigkeiten führen kann.
  • Die zunehmende Verwendung von ARIA führt bedauerlicherweise auf Grund von falscher Anwendung zu mehr Problemen, statt zu weniger.

Schon einzelne Zeichen machen einen Unterschied

Selbst einfache Zeichen, können bei der Sprachausgabe einen Unterschied machen. Besonders im vom BFSG betroffenen Bereich E-Commerce Bereich.

Insbesondere dann, wenn die Dokumentsprache nicht oder falsch gesetzt ist. Laut aktueller WebAIM-Umfrage (WebAIM Million 2026 report) fehlen bei 13,5% der meistbesuchten
Webseiten weltweit noch immer korrekt hinterlegte Angaben zur verwendeten Sprache, damit Screenreader eine korrekte Aussprache des vorhandenen Inhalts bereitstellen können.

Die Folge: eine Website deren Oberfläche in deutsch dargestellt wird, wird von Screenreadern ggf. mit einem anderssprachigen Verhalten (z.B. Englisch) vorgelesen, wenn Deutsch als Sprache nicht korrekt im HTML-Header der Seite festgelegt und vom Screenreader erkannt wird. Oder auch andersherum: eine englischsprachige Seite wird mit deutscher Stimme und Sprachverhalten vorgelesen.

Ergebnis in jedem Falle ist: Wörter werden unverständlich ausgesprochen.

Dies ist besonders kritisch bei Produktnamen, Preisauszeichnungen, Datums- oder Zeit-Angaben.

Der zugehörige BITV 2.0-Prüfschritt lautet “9.3.1.1 Hauptsprache angegeben”. Ebenfalls relevant wird der Prüfschritt “9.3.1.2 Anderssprachige Wörter und Abschnitte ausgezeichnet”, wenn innerhalb einer Seite Wörter und Textabschnitte in einer anderen Sprache vorkommen.

Selbst wenn die Sprache korrekt hinterlegt ist, gibt es immer noch eine ganze Reihe von Herausforderungen zu meistern um die Ausgabe für Screenreader-Nutzende zu verbessern, ohne dadurch andere Nutzer (z.B. Tastaturnutzer ohne Screenreader) negativ zu beeinflussen oder den Aufwand für die technische Umsetzung und Pflege nicht zu komplizieren.

Oft genutzte Schreibweisen und deren sprachliche Ausgabe

Testumgebungen
Bei den folgenden Beispielen wurden diese OS-, Browser-, Screenreader-Varianten (Standardeinstellung) genutzt.

  • NVDA 2026.1 unter Windows 11 mit Firefox (neueste Versionen)
  • VoiceOver unter iOS 26.x mit Safari (neueste Versionen)
  • TalkBack unter Android 14.x mit Chrome (neueste Versionen)

Obige Testumgebungen zeigen auch gleich eine andere Herausforderung auf, denn die gewählten Kombinationen stellen nur eine kleine Auswahl der in der Realität genutzen Kombinationen von Browser und assistiven Technologien (AT) dar. Zum Beispiel ist VoiceOver nicht gleich VoiceOver, denn VoiceOver in MacOS unterscheidet sich von der iOS-Version, welche besser funktionert als die MacOS-Version.

Verschiedene Versionskombinationen von OS, Browser und Screenreader können variieren. Zusätzliche Ausgabegeräte, wie zum Beispiel eine Braillezeile oder andere assistive Technologien sind hier auch noch nicht berücksichtigt.

Nutzerforschung und Crowdtesting können hier Abhilfe schaffen und zudem auch gleich weiteres Nutzer*innen-Feedback für UX-Verbesserungen liefern.

Beispiele

  1. Preisangabe mit Punkt und Eurozeichen: 1.299 €
    • iOS/VoiceOver: „Eintausendzweihundertneunundneunzig Euro“
    • NVDA/Firefox: „Eins Zweihundertneunundneunzig Euro“
    • Android/TalkBack: „Eintausendzweihundertneunundneunzig Euro“
  2. Preisangabe mit Komma und Eurozeichen: 12,99 €
    • iOS: „Zwölf Euro und Neunundneunzig Cent“
    • NVDA: „Zwölf Euro und Neunundneunzig Cent“
    • TalkBack: „Zwölf Euro und Neunundneunzig Cent“
  3. Preisangabe mit Zeitraumangabe: 2,10 € / Monat oder € 2,10 / Monat
    • iOS: „Zwei Euro und zehn Cent Schrägstrich Monat“
    • NVDA: „Zwei Euro zehn Cent Schrägstrich Monat“
    • TalkBack: „Zwei Euro zehn Cent pro Monat“
  4. Zeitraumangabe mit ASCII‑Minus oder En-Dash, mit und ohne Leerzeichen davor/danach: 1. – 3. Monat, 1.-3. Monat oder 1.–3. Monat, 1. – 3. Monat
    • iOS: „Eins Dritter Monat“ (unabhängig von Lehr- und Trennzeichen)
    • NVDA: „Ein Punkt minus Dritter Monat“ (ohne Lehrzeichen) oder „Erster Dritter Monat“ (mit Leerzeichen)
    • TalkBack: „Erster minus Drei Monat“ (ohne Lehrzeichen) oder „Erster Drei Monat“ (mit Leerzeichen)
  5. Datumsangabe: 21.5 und 21.05.26 (Jahreszahl zweistellig)
    • iOS/VoiceOver: „Einundzwangig Punkt Fünf“ und „Einundzwangig Punkt Null Fünf Punkt Sechsundzwanzig“
    • NVDA/Firefox: „Einundzwangig Punkt Fünf“ und. „Einundzwangig Punkt Null Fünf Punkt Sechsundzwanzig“
    • Android/TalkBack: „Einundzwangig Punkt Fünf“ bzw. „Einundzwangister Mai Sechsundzwanzig“
  6. Uhrzeit mit Punkt und Doppelpunkt: 9.30 Uhr und 9:30 Uhr
    • iOS/VoiceOver: „Neun Punkt Dreißig Uhr“ und „Neun Dreißig Uhr“
    • NVDA/Firefox: „Neun Uhr und Dreißig Minuten“ und „Neun Uhr und Dreißig Minuten“
    • Android/TalkBack: „Neun Punkt Drei Null Uhr“ und „Neun Uhr Dreißig“

Weitere problematische Fälle: Abkürzungen und Formatierungen

Diese Schreibweisen führen häufig zu inkonsistenter Ausgabe: 24/7, 3x, 2GB, ca., Mo-Fr, 1,5l oder 10°C. Auch wenn zur optischen Formatierung zu viele<span>-Tags angewendet werden, verändert dies oft die Sprachausgabe, da jeweils die einzelnen Tag-Inhalte dann, je nach verwendeter Plattform, Screenreader und Umsetzungsmethode, blockweise per Tag vorgelesen werden.

Empfehlung für eine konsistente Aussprache

  • „5 bis 7 Tage“, statt „5-7 Tage“
  • „9 bis 17 Uhr“, statt „09:00-17:00 Uhr“
  • „zum Beispiel“, statt „z.B.“
  • „5 Kilometer“, statt „5 km“
  • „21. Mai“, statt „01.05“

Herausforderungen bei der Anwendung von ARIA

Vermeidung von falscher Anwendung

ARIA-Attribute werden oft bei Tags genutzt, bei denen eine Anwendung von ARIA gar nicht vorgesehen ist. Dies geschieht vor allem bei Tags mit einer „generic“-Rolle (ARIA: generic role
– MDN) wie <div>, <span>, <p> oder<a> (ohne href-Attribut).

Wenn diese Tags von nicht interaktiven Elementen jedoch kein explizites und korrektes Rollenattribut (Beispiel:role="button") haben, ist dies eine Verwendung in nicht vorgesehener Weise. Tükisch ist dies vor allem dann, wenn nur mit einer Screenreader und Browser-Kombinationen getestet wird, welche diese falsche Verwendung trotzdem interpretiert.

Der Versuch Aussprachefehler auf diese Weise mittels ARIA zu korrigieren, kann dazu führen, dass beispielsweise die Braille-Ausgabe völlig unlesbar gemacht wird. Auch andere, nicht getestete assistive Technologien, welche auf eine korrekte Verwendung angewiesen sind, funktionieren dann nicht mehr in der vorgesehenen Weise.

Eine ausführliche Erläuterung dieser Problematik mit Beispielcode liefert Ben Myers mit seinem englischen Blogbeitrag Don’t Use aria-label on Static Text Elements.

Richtiges Verständnis für die Auswirkungen bei der Anwendung

Oft werden auch Labels via ARIA-Attribut definiert, wo dies gar nicht nötig wäre, da der sichtbare Text schon ein
ausreichendes Label liefert.

ARIA-Label ersetzt alle vorkommenden Inhalte als Label.
Beispiel 1:
<a aria-label="Statt den sichtbaren Link-Text liest der Screenreader diesen Satz vor.">Link-Text</a>

Beispiel 2: <a aria-label="Do not use ARIA.">Do not use ARIA.</a>

Das ARIA-Label in Beispiel 2 entspricht dem schon vorhandenen Textinhalt und ist somit gar nicht notwendig.

Wichtige ARIA-Regeln

Für die Verwendung von ARIA gibt es einige Empfehlungen, die unbedingt ernst genommen werden sollten.

  1. „Nutze kein ARIA“: ARIA sollte nur dann genutzt werden, wenn es wirklich sinnvoll ist. Meist
    läßt sich die Notwendigkeit für ARIA, schon alleine durch die Verwendung des richtigen HTML-Tags vermeiden.
  2. „Kein ARIA ist besser als schlechtes ARIA“: wenn ARIA angewendet wird, muss es richtig und in der vorgesehen Weise nach den vorgegeben Spezifikationen angewendet werden (W3C WAI-ARIA Overview).

Besondere Vorsicht ist bei mittlerweile öfters auftretenden Umsetzungsvarianten geboten, bei denen statt einer Ausgabe der visuell vorhandenen Information, diese für Screenreader versteckt und stattdessen durch eine komplett nicht sichtbare Variante ersetzt werden. Durch einen solchen Ansatz entstehen oft weitere Probleme, die dabei nicht mit bedacht wurden.

  • Das aria-hidden="true" Attribut wird von Screenreadern ignoriert, wenn interaktive Unterelemente vorhanden sind, was bedeuted das diese Elemente trotzdem via Screenreader und Tastaturnavigation erreichbar sind.
  • Visuell versteckte Elemente für Screenreader, welche interaktive Elemente enthalten, sind auch via Tastaturnavigation ohne Screenreader erreichbar und führen dann dazu, dass der Fokus-Indikator ebenso unsichtbar ist, wenn das versteckte Element angesteuert wird.
  • Doppelter Code, bedeutet auch doppelter Aufwand und erhöht die Wahrscheinlichkeit, dass bei Anpassungen eine Variante vergessen wird.

Fazit: Wer sich noch nicht wirklich intensiver mit ARIA und den Auswirkungen auf assistive Technologien beschäftigt hat, sollte dies zuerst und vor der Anwendung von ARIA tun.

Weiterführende Informationen

Fronta11y-Beiträge

Weiterführende Informationen in deutscher Sprache

Weiterführende Informationen in englischer Sprache

Weiterführende detaillierte Informationen in englischer Sprache zu Screenreader-/Browser-Kombinationen