Wie Screenreader funktionieren

Was ein Screenreader ist – und was nicht

Ein Screenreader(auf Deutsch oft „Bildschirmleseprogramm“) ist eine Software, die digitale Oberflächen für blinde und stark sehbehinderte Menschen zugänglich macht. Die Ausgabe erfolgt über synthetische Sprache oder über eine Braillezeile – ein Gerät, das einzelne Textzeilen in tastbare Punktschrift umsetzt.

Der Name führt leicht in die Irre. Ein Screenreader liest nicht das ab, was visuell auf dem Bildschirm zu sehen ist – also keine Pixel, keine Farben, keine Positionen. Stattdessen wertet er die strukturierte Information hinter der Oberfläche aus: Welches Element ist eine Überschrift? Was ist ein Link, was ein Button? Ist dieses Kontrollkästchen gerade aktiviert? Aus diesen Bausteinen entsteht ein Modell der Seite, durch das Nutzer:innen gezielt navigieren können.

Das ist der wichtigste Gedanke für die Praxis: Eine Website ist nicht deshalb zugänglich, weil sie gut aussieht, sondern weil sie semantisch korrekt ausgezeichnet ist. Was kein Element mit klarer Bedeutung hat, existiert für den Screenreader schlicht nicht – oder nur als bedeutungsloser Text.

Der Accessibility-Tree: die Brücke zwischen Code und Sprache

Wenn ein Browser eine Webseite lädt, baut er aus dem HTML zunächst das DOM auf (Document Object Model) – die Baumstruktur aller Elemente. Parallel dazu erzeugt er eine zweite, reduzierte Struktur: den Accessibility-Tree(Barrierefreiheits-Baum).

Dieser Baum ist eine vereinfachte Übersetzung des DOM. Er enthält pro Element vor allem drei Angaben, die zusammen die Grundlage jeder Screenreader-Ausgabe bilden:

• Name – die zugängliche Bezeichnung. Bei einem Button etwa sein Text, bei einem Bild der Alternativtext, bei einem Formularfeld sein zugehöriges <label> .
• Rolle (Role) – um was für ein Element es sich handelt: Schaltfläche, Link, Überschrift der Ebene 2, Listenpunkt.
• Zustand und Eigenschaften (State, Value) – ob ein Element ausgewählt, deaktiviert, aufgeklappt ist, oder welchen Wert es gerade hat.

Genau dieses Trio – Name, Rolle, Wert – ist in den Web Content Accessibility Guidelines als eigenes Erfolgskriterium festgeschrieben (WCAG 2.2, Kriterium 4.1.2 „Name, Role, Value“). Nicht jedes DOM-Element landet im Accessibility-Tree: Was visuell versteckt ist oder rein dekorativ, wird ausgelassen. Und umgekehrt kann ein falsch ausgezeichnetes Element mit einer irreführenden Rolle im Baum landen – dann hört die Nutzer:in „Schaltfläche“, wo eigentlich ein Link gemeint war.

Wenn du natives HTML verwendest – ein echtes <button> , eine echte <h2> , ein verbundenes <label> – entstehen Name und Rolle automatisch. Erst bei selbstgebauten Komponenten (etwa ein Menü aus <div> -Elementen) musst du diese Informationen über ARIA-Attribute von Hand nachliefern. Das ist auch der Grund, warum die erste ARIA-Regel lautet: Nimm, wenn möglich, das native Element.

Plattform-APIs: wie System, Browser und Screenreader zusammenspielen

Der Accessibility-Tree lebt zunächst nur im Browser. Damit ein Screenreader ihn lesen kann, gibt der Browser ihn über eine Accessibility-API des Betriebssystems weiter – eine standardisierte Schnittstelle, über die assistive Technologien Programminhalte abfragen. Jede Plattform hat dafür ihre eigene API:

• Windows – UI Automation, ergänzt um den offenen Standard IAccessible2.
• macOS und iOS – NSAccessibility (oft kurz „AX-API“).
• Android – die Accessibility-Service-Schnittstelle.
• Linux – AT-SPI.

Man kann sich die Kette als Übersetzungsstrecke vorstellen: Dein HTML wird zum DOM, das DOM zum Accessibility-Tree, der Tree wird über die Plattform-API bereitgestellt, und der Screenreader fragt diese API ab und macht daraus Sprache oder Braille. An jedem Übergang kann Information verloren gehen – meist ganz am Anfang, wenn das HTML schon keine klare Bedeutung trägt.

Diese Kette erklärt auch eine Eigenheit, die bei Tests immer wieder auffällt: Screenreader sind eng an bestimmte Browser gekoppelt. VoiceOver entfaltet seine volle Wirkung mit Safari, weil dieser die Apple-Accessibility-API am vollständigsten bedient. Für NVDA gilt die Kombination mit Firefox als verlässlicher Ausgangspunkt. Ein Test sollte deshalb immer ein reales Screenreader-Browser-Paar nutzen, nicht nur einen automatischen Prüfbericht.

Browse-Modus und Fokus-Modus

Desktop-Screenreader wie NVDA und JAWS arbeiten beim Lesen von Webseiten mit einem virtuellen Puffer: einer linearisierten Textfassung der ganzen Seite, durch die sich Nutzer:innen Zeile für Zeile mit den Pfeiltasten bewegen. Dieser Zustand heißt Browse-Modus(bei JAWS „Virtual Cursor“, bei NVDA „Lesemodus“).

Im Browse-Modus haben einzelne Tasten besondere Funktionen: H springt zur nächsten Überschrift, K zum nächsten Link, F zum nächsten Formularfeld, D zur nächsten Landmark-Region – also zum nächsten ausgezeichneten Seitenbereich wie <nav> oder <main> . So lesen geübte Nutzer:innen eine Seite nicht von oben bis unten, sondern überfliegen sie – ganz ähnlich, wie sehende Menschen eine Seite mit den Augen scannen. Voraussetzung ist allerdings, dass es überhaupt Überschriften, Links und Regionen gibt, an denen entlang gesprungen werden kann.

Auf einen Blick: die wichtigsten Sprung-Befehle im Browse-Modus (NVDA und JAWS)

Taste	Springt zur nächsten Stelle
H	Überschrift
K	Link
F	Formularfeld
D	Landmark-Region – ausgezeichneter Seitenbereich wie <nav> oder <main>

Sobald die Nutzer:in in ein Eingabefeld gelangt, wechselt der Screenreader in den Fokus-Modus(auch „Formularmodus“). Jetzt werden Tastendrücke direkt an die Anwendung weitergegeben, damit man wirklich Text eintippen kann. Viele Zugänglichkeitsprobleme bei selbstgebauten Widgets entstehen genau an dieser Stelle: Wenn ein Bedienelement nicht klar signalisiert, welcher Modus gerade sinnvoll ist, landen Nutzer:innen im falschen und die Komponente reagiert scheinbar gar nicht.

Ausgabe: Sprache und Braille

Die bekannteste Ausgabeform ist die Sprachsynthese. Sie ist schnell, sprachunabhängig und für die meisten Nutzer:innen der Alltag. Geübte Menschen hören dabei Sprechgeschwindigkeiten, die ungeübte Ohren kaum noch als Wörter erkennen.

Die zweite, oft unterschätzte Ausgabeform ist die Braillezeile. Sie wandelt jeweils eine Textzeile in fühlbare Punktschrift um, die mit den Fingern gelesen wird. Braille ist besonders wichtig für taubblinde Menschen, für präzises Arbeiten an Quelltext oder Zahlen und für das Erlernen korrekter Rechtschreibung. Für dich als Entwickler:in heißt das: Es geht nicht nur darum, wie etwas klingt , sondern auch darum, dass der Text als Text korrekt vorliegt – Sonderzeichen, Abkürzungen und Strukturen werden ungefiltert ertastet.

Die wichtigsten Screenreader im Überblick

Es gibt nicht „den“ Screenreader, sondern mehrere – je nach Betriebssystem und Vorliebe. Die folgende Übersicht ordnet die verbreiteten Programme ein, ohne sie gegeneinander zu bewerten.

Verbreitete Screenreader nach Plattform und Bezug

Screenreader	Plattform	Bezug
NVDA	Windows	Kostenlos und quelloffen, entwickelt von NV Access.
JAWS	Windows	Kommerziell, lange am Markt etabliert.
Narrator	Windows	In Windows integriert.
VoiceOver	macOS, iOS	In das Apple-Betriebssystem integriert.
TalkBack	Android	In Android integriert, von Google.
Orca	Linux	Quelloffen, Teil vieler Linux-Desktops.

Zur Verbreitung der einzelnen Programme im deutschsprachigen Raum gibt es keine belastbare, repräsentative Erhebung. Die häufig zitierte WebAIM-Umfrage zu Screenreadern beruht auf einer überwiegend englischsprachigen Stichprobe und lässt sich nicht zuverlässig auf Deutschland, Österreich und die Schweiz übertragen. Wir verzichten hier deshalb bewusst auf Marktanteils-Zahlen – die Datenlage gibt sie für den DACH-Raum nicht her. Für die Praxis ist die Verteilung ohnehin zweitrangig: Wer auf semantisch sauberem HTML aufbaut, bedient alle genannten Programme.

Was das für deine Arbeit bedeutet

Wenn du verstanden hast, dass der Screenreader nur mit der ausgezeichneten Struktur arbeitet, ergeben sich daraus ein paar sehr konkrete Konsequenzen:

• Native Elemente zuerst. Ein <button> , eine <nav> , eine echte Überschriften-Hierarchie liefern Name und Rolle ohne Zusatzaufwand. ARIA ist die Ausnahme, nicht der Standard.
• Überschriften sind Navigation. Sie sind nicht nur große Schrift, sondern die Sprungmarken, mit denen Nutzer:innen eine Seite überfliegen. Eine logische, lückenlose Hierarchie ist Pflicht.
• Jedes Formularfeld braucht ein Label. Ohne verknüpftes <label> hat das Feld keinen zugänglichen Namen – der Screenreader sagt dann nur „Eingabefeld“.
• Mit echten Screenreadern testen. Automatische Prüfwerkzeuge finden viele, aber längst nicht alle Probleme. Ein kurzer Durchgang mit NVDA oder VoiceOver zeigt schnell, ob deine Seite wirklich navigierbar ist.

Der Screenreader ist am Ende ein ehrlicher Prüfstein: Er belohnt sauberes, bedeutungstragendes HTML und bestraft jedes Element, dem die Bedeutung fehlt. Wer für ihn baut, baut fast nebenbei auch robuster für alle anderen.