Barrierefreiheit ≠ Overlay: wenn ein Overlay den Screenreader beeinträchtigt
Screenreader geben die programmatisch bereitgestellten Informationen einer Oberfläche per Sprache oder Braille aus. Nutzer lernen ihre Befehle, konfigurieren Präferenzen und navigieren gezielt durch Überschriften, Links, Regionen, Formulare und Bedienelemente. W3C zählt Screenreader zu den assistiven Technologien für die Webnutzung. Ausgangspunkt sollte deshalb eine korrekt aufgebaute Website sein, nicht der Versuch, die Technologie des Nutzers auf der Seite zu ersetzen.
Der Screenreader ist bereits die assistive Technologie des Nutzers
Screenreader geben die programmatisch bereitgestellten Informationen einer Oberfläche per Sprache oder Braille aus. Nutzer lernen ihre Befehle, konfigurieren Präferenzen und navigieren gezielt durch Überschriften, Links, Regionen, Formulare und Bedienelemente. W3C zählt Screenreader zu den assistiven Technologien für die Webnutzung. Ausgangspunkt sollte deshalb eine korrekt aufgebaute Website sein, nicht der Versuch, die Technologie des Nutzers auf der Seite zu ersetzen.
Was ein Screenreader wirklich von einer Website benötigt
Die Interoperabilität hängt vom Code ab: semantisches HTML, echte Überschriften, erkennbare Links und Schaltflächen, zugeordnete Beschriftungen, korrekte zugängliche Namen, Rollen, Zustände und Werte sowie ein schlüssiges Fokusmanagement. W3C beschreibt, dass Screenreader Überschriftenstrukturen zur Navigation nutzen können und Standard-HTML-Elemente die Zusammenarbeit mit assistiven Technologien unterstützen. Wenn diese Grundlage fehlerhaft ist, liegt das Problem in der Implementierung.
Was sich durch ein Overlay verändert
Einige Overlays fügen JavaScript von Drittanbietern ein, analysieren die Seite und versuchen Frontend-Probleme zu reparieren. Assistive Technologien können dadurch eine veränderte Oberfläche erhalten. Das Overlay Fact Sheet warnt vor langsameren Ladezeiten und unerwarteten Seitenänderungen für Nutzer assistiver Technologien. Nicht jedes Overlay verursacht immer denselben Fehler, aber es kommt eine zusätzliche Variable zwischen Website und Screenreader hinzu.
Fokus, Tastatur und Struktur: Kleine Änderungen können große Barrieren werden
Für Menschen, die ohne Sicht navigieren, bestimmt der Fokus Position und nächstes Bedienelement. Unerwartete Fokuswechsel, abgefangene Tasten oder veränderte Semantik können stark desorientieren. Gleiches gilt für künstliche Überschriften, unzuverlässige Namen oder falsch vermittelte Zustände. Im Overlay Fact Sheet berichten Screenreader-Nutzer unter anderem von Fokus-Sprüngen und erschwerter Navigation.
Ein „Screenreader-Profil“ stellt die falsche Frage
Entscheidend ist nicht, ob ein spezielles Profil aktiviert wurde, sondern ob die Website von Anfang an mit der gewohnten assistiven Technologie funktioniert. W3C weist darauf hin, dass Menschen unterschiedliche Werkzeuge und Einstellungen nach ihren Bedürfnissen verwenden. Ein Widget erst finden, öffnen und einen zusätzlichen Modus wählen zu müssen, schafft weitere Schritte, ohne die ursprünglichen Barrieren zwingend zu beheben.
Nicht alle Screenreader-Nutzer navigieren gleich
NVDA, JAWS, VoiceOver, TalkBack und andere Lösungen unterscheiden sich in Befehlen und Modi. Nutzer konfigurieren außerdem Sprache, Geschwindigkeit, Zeichensetzung, Braille und Navigation individuell. Eine universelle „Screenreader-Erfahrung“ ist daher riskant. Robuste Barrierefreiheit stellt standardisierte, vorhersehbare Informationen bereit.
Korrekte Semantik lässt den Nutzer entscheiden, wie er navigiert
Eine Überschrift ist nicht allein deshalb gut, weil sie groß aussieht. Ein Formularfeld wird nicht durch benachbarten sichtbaren Text zugänglich. Mit geeignetem HTML und, wo nötig, korrekt eingesetztem ARIA kann der Screenreader Struktur vermitteln und der Nutzer mit eigenen Befehlen navigieren. W3C empfiehlt nach Möglichkeit native Elemente und nutzt ARIA zur Vermittlung von Rollen, Zuständen und Eigenschaften.
Mit einem Screenreader testen heißt nicht nur zu prüfen, ob die Seite spricht
Dass Text vorgelesen wird, beweist keine Nutzbarkeit. Es müssen vollständige Aufgaben geprüft werden: Hauptinhalt erreichen, Hierarchie verstehen, Menüs und Formulare bedienen, Fehler erkennen, Dialoge und dynamische Komponenten nutzen und nach Interaktionen die Orientierung behalten. Auch Tastaturtests und Tests mit erfahrenen Nutzern sind wichtig.
Was Unternehmen tun sollten, statt sich auf eine Schicht zu verlassen
Zuerst reale Barrieren identifizieren und anschließend im verursachenden Baustein, Template, Theme oder in der Anwendung beheben. Dazu gehören semantisches HTML, zugängliche Patterns, korrektes Fokusmanagement und Tests mit repräsentativen Browser-/AT-Kombinationen. Automatisierung kann einzelne Probleme finden, ersetzt aber keine funktionalen und menschlichen Tests.
Barrierefreiheit ≠ Overlay
Lieferung 06 konzentriert sich auf eine einfache Idee: Der Screenreader gehört dem Nutzer, nicht der Website. Die Website muss eine stabile, vorhersehbare Oberfläche bereitstellen. Verändert eine zusätzliche Schicht Struktur, Fokus oder Semantik, kann aus einer bekannten Barriere eine neue, schwerer diagnostizierbare werden. Nachhaltig bleibt die Korrektur an der Quelle und das Testen mit realen assistiven Technologien.
Offizielle und technische Quellen
W3C Web Accessibility Initiative (WAI)
Tools and Techniques — How People with Disabilities Use the Web
Page Structure Tutorial
WAI-ARIA Overview
Overlay Fact Sheet
Overlay Fact Sheet — assistive technology experiences and limitations
Entrega 06 — Overlays y lectores de pantalla.