Screen Reader: Was es ist, Arten von Screenreadern und Funktionsprinzip

Was ist ein Screen Reader?

Screen Reader (Bildschirmlesegerät) ist eine unterstützende Technologie (Assistive Technology, AT), die die grafische Benutzeroberfläche interpretiert und in nicht-visueller Form darstellt: durch synthetische Sprache oder einen taktilen Braille-Bildschirm. Screenreader sind das wichtigste Mittel für Menschen mit vollständigem oder teilweisem Sehverlust, um auf Computer und mobile Geräte zuzugreifen.

Die ersten Screenreader erschienen in den späten 1980er Jahren für MS-DOS (z. B. Vocal-Eyes) und später für Windows (JAWS, NVDA). Auf mobilen Plattformen wurden Screenreader auf Systemebene integriert: Apple integrierte VoiceOver in das iPhone 3GS im Jahr 2009, Google integrierte TalkBack in Android 1.6 im selben Jahr. Bis 2025 verfügen praktisch alle modernen Smartphones über einen integrierten Screenreader, der keine zusätzliche Softwareinstallation erfordert.

Ein Screenreader liest nicht nur Text vom Bildschirm — er analysiert die Hierarchie der Oberfläche, bestimmt Elementtypen (Schaltfläche, Link, Überschrift, Eingabefeld), deren Zustände (aktiviert/deaktiviert, ausgewählt/nicht ausgewählt) und Beziehungen (Eltern-Kind, Gruppe). Diese Informationen werden dem Benutzer über Sprachansagen oder taktile Rückmeldungen eines Braille-Displays übermittelt, das die Zellen in Echtzeit entsprechend der Fokusposition aktualisiert.

Wie funktioniert ein Screen Reader?

Ein Screenreader arbeitet eng mit dem Betriebssystem zusammen und erhält Zugriff auf dessen interne Darstellung der Oberfläche — den Accessibility Tree. Dieser Mechanismus ist auf iOS und Android identisch, obwohl die API-Namen unterschiedlich sind.

Text-to-Speech (TTS)

Der Hauptausgabekanal eines Screenreaders ist ein Sprachsynthesizer (Text-To-Speech, TTS). Wenn der Accessibility-Fokus auf einem Element landet, extrahiert der Screenreader dessen Textinhalt (oder die vom Entwickler bereitgestellte Beschreibung) und sendet ihn an die TTS-Engine. Moderne TTS-Engines wie Apple Speech Synthesis und Google Text-to-Speech verwenden neuronale Netze, um natürliche Sprache mit korrekter Intonation, Pausen und Betonung in Abhängigkeit von Zeichensetzung und Inhaltstyp zu erzeugen.

Der Benutzer kann die Sprechgeschwindigkeit (normalerweise 60–80 % des Maximums für eine angenehme Wahrnehmung), Tonhöhe und Lautstärke einstellen. Einige Screenreader unterstützen mehrere Stimmen und wechseln je nach Inhaltstyp zwischen ihnen — zum Beispiel eine langsamere Stimme zum Lesen von Text und eine schnellere für die Oberflächennavigation. Braille-Displays werden über Bluetooth verbunden und zeigen bis zu 40–80 Zeichen gleichzeitig an, wobei sie die Zeile bei jeder Fokusänderung aktualisieren.

Fokusverwaltung und Navigation

Ein Screenreader verwendet das Konzept des Accessibility-Fokus, der sich vom Standard-Eingabefokus unterscheidet. Der Benutzer bewegt den Accessibility-Fokus mit Gesten (Berührung, Wischen), und der Screenreader gibt das Element unter dem Fokus bekannt. Die Navigationsreihenfolge folgt standardmäßig der visuellen Reihenfolge: von links nach rechts, von oben nach unten. Der Entwickler kann diese Reihenfolge für komplexe Layouts überschreiben.

Der Screenreader unterstützt auch verschiedene Navigationsmodi, die der Benutzer über den Rotor (VoiceOver) oder das Menü (TalkBack) umschaltet: nach Überschriften, Links, Zeichen, Wörtern, Formularen. Im Überschriftenmodus bewegt sich der Screenreader nur zwischen H1–H6 — dies ist für eine effiziente Navigation durch lange Seiten und Dokumente entscheidend. Der Zeichenmodus hilft bei der Eingabe von Bestätigungscodes oder komplexen Passwörtern, indem er jedes Zeichen einzeln ausspricht.

Wichtige Screenreader für mobile Plattformen

Zwei Screenreader dominieren die mobilen Plattformen: VoiceOver auf iOS und TalkBack auf Android. Sie haben unterschiedliche APIs, Gesten und Fähigkeiten, aber das gemeinsame Prinzip ist das Lesen des Accessibility Tree und die Gestensteuerung.

VoiceOver (iOS)

VoiceOver ist Apples Screenreader, der in iOS, iPadOS und macOS integriert ist. Er verwendet die UIAccessibility-API, um Informationen über Elemente zu erhalten, und unterstützt den Rotor zum Umschalten der Navigationsmodi. VoiceOver ist mit iCloud (Einstellungen werden geräteübergreifend synchronisiert), Apple Pay (Zahlungsbestätigung per Touch ID oder Face ID) und dynamischem Text (Schriftart passt sich den Benutzereinstellungen an) integriert.

VoiceOver-Gesten unterscheiden sich von TalkBack: Es verwendet Zweifingerdrehung (Rotor), Dreifachtippen für Screen Curtain und Zweifinger-Doppeltippen zum Abbrechen einer Aktion. VoiceOver unterstützt benutzerdefinierte Rotoren, die der Entwickler über UIAccessibilityCustomRotor hinzufügt — zum Beispiel für die schnelle Navigation durch App-Abschnitte unter Umgehung der Standardreihenfolge.

TalkBack (Android)

TalkBack ist Googles Screenreader, Teil der Android Accessibility Suite. Er verwendet AccessibilityService und AccessibilityNodeInfo für den Zugriff auf die Oberfläche. TalkBack unterstützt ein globales Menü über L-förmiges Wischen, benutzerdefinierte Aktionen für Elemente und LiveRegion für dynamische Aktualisierungen. Ab Android 14 erhielt TalkBack Unterstützung für Einhandgesten und eine verbesserte Integration mit Google Assistant.

TalkBack verfügt über ein flexibleres Gestensystem als VoiceOver: Der Benutzer kann praktisch jede Geste jeder Aktion zuweisen. TalkBack unterstützt auch die Bildschirm-Braille-Eingabe (BrailleBack) — der Benutzer gibt Text mit Braille-Zeichen direkt auf dem Touchscreen in einem speziellen 3×2-Layout pro Finger ein, was die Texteingabe im Vergleich zur Bildschirmtastatur erheblich beschleunigt.

Neben VoiceOver und TalkBack gibt es weniger verbreitete mobile Screenreader: Select to Speak (Android, spricht ausgewählten Bereich), Samsung Voice Assistant (ersetzt TalkBack auf Samsung-Geräten mit One UI) und Drittanbieterlösungen für spezielle Nischen — zum Beispiel für Benutzer chinesischer Smartphones ohne Google-Dienste.

Wie interagiert ein Screen Reader mit der App

Ein Screenreader hat keinen direkten Zugriff auf die UI-Komponenten der App. Stattdessen arbeitet er über eine Zwischenschicht — die Accessibility-API des Betriebssystems. Das Betriebssystem erstellt einen Accessibility Tree, den der Screenreader durchläuft und analysiert.

Accessibility Tree auf iOS und Android

Auf iOS wird der Accessibility Tree aus UIAccessibilityElement-Objekten erstellt, die jeder View auf dem Bildschirm entsprechen. Jedes Element enthält ein Label (Haupttext), Traits (Elementtyp: Schaltfläche, Überschrift, Link), Hint (Tooltip), Value (aktueller Wert für Schieberegler und Indikatoren) und Frame (Berührungsbereich). Das System erstellt automatisch Elemente für Standard-UI-Komponenten, aber der Entwickler kann sie hinzufügen und anpassen.

Auf Android wird der Accessibility Tree aus AccessibilityNodeInfo-Objekten erstellt. Jeder Knoten enthält: text (Text oder contentDescription), className (Elementtyp), contentDescription (Beschreibung), stateDescription (Zustand), isEnabled, isChecked, isClickable und andere Flags. Android unterstützt auch AccessibilityAction — eine Liste von Aktionen, die der Screenreader im Namen des Benutzers ausführen kann: Klicken, langes Drücken, Scrollen, Fokus setzen, Text setzen.

Accessibility-Ereignisse

Wenn eine Änderung in der Oberfläche auftritt (ein neues Element erscheint, Text ändert sich, ein Element wird sichtbar oder unsichtbar), sendet das Betriebssystem ein AccessibilityEvent. Der Screenreader abonniert diese Ereignisse und reagiert darauf: Zum Beispiel verschiebt der Screenreader beim Erscheinen eines Dialogfelds automatisch den Fokus auf dessen Titel und gibt den Inhalt bekannt.

// Abhören von Accessibility-Ereignissen auf Android
class CustomAccessibilityService : AccessibilityService() {
    override fun onAccessibilityEvent(event: AccessibilityEvent?) {
        event ?: return
        when (event.eventType) {
            TYPE_VIEW_CLICKED ->
                handleClick(event)
            TYPE_WINDOW_STATE_CHANGED ->
                handleWindowChange(event)
            TYPE_VIEW_TEXT_CHANGED ->
                handleTextChange(event)
        }
    }
}

Auf iOS werden ähnliche Ereignisse über UIAccessibility.Notification behandelt: layoutChanged (Layout geändert), screenChanged (völlig neuer Bildschirm), announcement (benutzerdefinierte Ansage), pageScrolled (Seitenscrollen). Der Entwickler sendet diese Ereignisse über UIAccessibility.post, damit der Screenreader korrekt auf Änderungen reagiert. Beim Öffnen eines modalen Fensters muss beispielsweise screenChanged mit dem neuen Titel gesendet werden — andernfalls bleibt VoiceOver auf dem vorherigen Element unter dem Fenster.

Entwicklung von Apps für Screenreader

Eine zugängliche App zu erstellen bedeutet nicht, jedem Element contentDescription hinzuzufügen — es geht darum, die Benutzererfahrung für nicht-visuelle Interaktion zu gestalten. Die Grundregeln sind für beide Plattformen gleich, obwohl die Implementierung variiert.

Grundlegende Accessibility-Regeln

Alle interaktiven Elemente müssen eine aussagekräftige Beschreibung haben: Ein „Senden“-Button sollte als „Nachricht senden“ beschrieben werden, nicht nur als „Button“. Dekorative Elemente (Trennzeichen, Hintergrundbilder, nicht funktionale Symbole) sollten vor dem Screenreader verborgen werden. Die Navigationsreihenfolge sollte dem logischen Fluss des Bildschirms folgen, nicht dem visuellen Layout. Der Textkontrast sollte mindestens 4.5:1 für Fließtext und 3:1 für großen Text betragen (WCAG AA).

// iOS: korrekte Konfiguration für ein komplexes Element
let customControl = UIControl()
customControl.isAccessibilityElement = true
customControl.accessibilityLabel = "Lautstärke"
customControl.accessibilityValue = "75 Prozent"
customControl.accessibilityTraits = [
    .adjustable,
    .button
]
customControl.accessibilityHint =
    "Erhöht oder verringert die Lautstärke"

// Aktualisierung bei Wertänderung
func didChangeVolume(newValue: Float) {
    customControl.accessibilityValue =
        "\(Int(newValue)) Prozent"
    UIAccessibility.post(
        notification: .layoutChanged,
        argument: customControl
    )
}

Auf iOS aktiviert das Flag isAccessibilityElement die VoiceOver-Unterstützung für benutzerdefinierte Elemente. Die Traits-Kombination (.adjustable + .button) teilt VoiceOver mit, dass das Element durch Wischen nach oben/unten eingestellt und durch Doppeltippen aktiviert werden kann. Nach einer Wertänderung muss eine layoutChanged-Benachrichtigung gesendet werden — andernfalls gibt VoiceOver weiterhin den alten Wert bekannt.

Plattformspezifische Empfehlungen

Für iOS: Verwenden Sie accessibilityElements zum Überschreiben der Lesereihenfolge, accessibilityCustomActions für zusätzliche Aktionen im Kontextmenü und shouldGroupAccessibilityChildren zum Gruppieren von Elementen in logische Gruppen. Für SwiftUI verwenden Sie die Modifikatoren .accessibilityLabel(), .accessibilityAddTraits() und .accessibilityRespondsToUserInteraction(). Vermeiden Sie isAccessibilityElement = false auf Containern mit interaktiven untergeordneten Elementen — dies versteckt sie vor VoiceOver.

Für Android: Verwenden Sie accessibilityTraversalBefore und accessibilityTraversalAfter für die Navigationsreihenfolge, AccessibilityDelegate für benutzerdefinierte Elemente und LiveRegion (polite/assertive) für dynamische Aktualisierungen. Verwenden Sie in Compose den Modifikator .semantics {} mit contentDescription, stateDescription und customActions. Vermeiden Sie focusable = true auf nicht-interaktiven Elementen — dies erzeugt falsche Fokuspunkte für TalkBack und verwirrt den Benutzer.

Testwerkzeuge

Tests mit einem Screenreader müssen auf einem physischen Gerät durchgeführt werden. Ein Emulator/Simulator bietet ein grundlegendes Verständnis, aber Gesten und Reaktionsgeschwindigkeit unterscheiden sich. Verwenden Sie den Accessibility Inspector (Xcode) für iOS und Accessibility Scanner (Android) für die automatische Fehlererkennung.

Wichtige Testszenarien: Registrierung (Formular ausfüllen, Validierung, Absenden), Suche und Katalognavigation, Checkout, Passwortwiederherstellung. Jedes Szenario muss ohne visuelle Kontrolle — nur durch Sprachansagen des Screenreaders — abschließbar sein. Wenn ein Screenreader-Benutzer ein Szenario nicht in der gleichen Zeit wie ein normaler Benutzer abschließen kann (±50%), benötigt die App Accessibility-Verbesserungen.