Was ist ein Screenreader? So erleben blinde Menschen deine Webseite

Was ein Screenreader macht

Ein Screenreader ist Software, die den Bildschirminhalt vorliest oder auf eine Braillezeile ausgibt. Blinde und stark sehbehinderte Menschen nutzen Screenreader, um Computer, Smartphones und Webseiten zu bedienen. Weltweit sind schätzungsweise 2,2 Milliarden Menschen von Sehbehinderungen betroffen -- Screenreader sind für viele von ihnen das Tor zum digitalen Leben.

Die wichtigsten Screenreader im Vergleich

Nicht jeder Screenreader funktioniert gleich. Für Entwickler ist es wichtig, die Unterschiede zu kennen:

• NVDA (NonVisual Desktop Access) -- Windows, kostenlos und Open Source. Der meistgenutzte Screenreader für Tests, da er frei verfügbar ist. Unterstützt Firefox und Chrome am besten.
• JAWS (Job Access With Speech) -- Windows, kommerziell (ca. 1.000 USD Lizenz). Marktführer im professionellen Umfeld mit dem umfangreichsten Feature-Set. Beste Unterstützung für Internet Explorer und komplexe Webapplikationen.
• VoiceOver -- macOS, iOS und iPadOS, vorinstalliert. Aktivierung auf dem Mac: Cmd+F5. Auf dem iPhone: Einstellungen > Bedienungshilfen > VoiceOver. Nutzt den Safari-Browser am effektivsten.
• TalkBack -- Android, vorinstalliert. Aktivierung: Einstellungen > Bedienungshilfen > TalkBack. Funktioniert am besten mit Chrome für Android.

Wichtig: Die vier Screenreader interpretieren HTML und ARIA-Attribute teilweise unterschiedlich. Was in NVDA korrekt vorgelesen wird, kann in VoiceOver anders klingen. Für zuverlässige Barrierefreiheit solltest du mindestens zwei Screenreader testen.

Der Accessibility Tree: Was Screenreader wirklich sehen

Screenreader lesen nicht direkt den HTML-Code. Zwischen HTML und Screenreader steht eine Zwischenschicht: der Accessibility Tree. Weitere Informationen finden Sie im Screenreader-Glossar.

Der Browser erstellt aus dem DOM (Document Object Model) eine vereinfachte Baumstruktur, die nur die für assistive Technologien relevanten Informationen enthält. Jedes Element im Accessibility Tree hat vier Eigenschaften:

• Rolle (Role) -- Was ist das Element? Button, Link, Überschrift, Textfeld?
• Name (Accessible Name) -- Wie heißt es? Der sichtbare Text, das Label oder der aria-label-Wert.
• Zustand (State) -- In welchem Zustand ist es? Aktiviert, deaktiviert, ausgeklappt, angehakt?
• Wert (Value) -- Welchen Wert hat es? Der eingegebene Text, der Slider-Wert, die ausgewählte Option.

Du kannst den Accessibility Tree in den Chrome DevTools inspizieren: F12 > Elements > rechte Spalte > Accessibility. Das zeigt dir exakt, was ein Screenreader "sieht". Wenn dort Informationen fehlen, fehlen sie auch für den Nutzer.

Wie ein Screenreader eine Webseite liest

Der Screenreader liest nicht den visuellen Bildschirm ab, sondern navigiert durch den Accessibility Tree. Er erkennt:

• Überschriften (h1-h6) als Navigationsankerpunkte
• Links und Buttons als interaktive Elemente
• Bilder über ihre Alt-Texte (WCAG SC 1.1.1 Nicht-Text-Inhalte)
• Formulare über ihre Labels (WCAG SC 1.3.1 Info und Beziehungen)
• Listen, Tabellen und Landmarks als strukturelle Elemente

Wenn das HTML sauber und semantisch korrekt ist, funktioniert der Screenreader gut. Wenn nicht, ist die Seite unbenutzbar.

Überschriften-Navigation: Die wichtigste Screenreader-Funktion

Die meisten Screenreader-Nutzer navigieren nicht linear durch eine Seite. Stattdessen springen sie von Überschrift zu Überschrift -- ähnlich wie sehende Nutzer eine Seite visuell scannen. In NVDA drückt man dafür die Taste "H" (nächste Überschrift) oder "1"-"6" für eine bestimmte Ebene.

Deshalb ist eine saubere Überschriften-Hierarchie entscheidend (WCAG SC 1.3.1, SC 2.4.6 Überschriften und Labels):

• Genau eine <h1> pro Seite
• Keine Ebenen überspringen (kein h1 > h3 ohne h2)
• Überschriften müssen den folgenden Inhalt beschreiben
• Überschriften nur für Struktur verwenden, nie nur für Styling

Landmark-Navigation: Seitenbereiche erkennen

HTML5-Landmarks wie <nav>, <main>, <aside>, <header> und <footer> geben dem Screenreader die Seitenstruktur vor. In NVDA springt man mit "D" zum nächsten Landmark. Das entspricht der barrierefreien Navigation, die WCAG SC 2.4.1 (Blöcke umgehen) fordert.

Ohne Landmarks muss ein Screenreader-Nutzer sich durch die gesamte Navigation kämpfen, bevor er zum Hauptinhalt kommt. Mit einem einfachen <main>-Tag kann er direkt dorthin springen.

Tabellen-Navigation

Screenreader bieten spezielle Tastenkombinationen für Datentabellen. In NVDA: Strg+Alt+Pfeiltasten bewegen den Fokus zellenweise durch die Tabelle. Bei jeder Zelle wird automatisch die zugehörige Spalten- und Zeilenüberschrift vorgelesen.

Das funktioniert aber nur, wenn:

• <th>-Elemente für Kopfzellen verwendet werden (WCAG SC 1.3.1)
• Bei komplexen Tabellen scope="col" oder scope="row" gesetzt ist
• Layout-Tabellen vermieden oder mit role="presentation" markiert werden
• Eine Tabellenüberschrift via <caption> vorhanden ist

Tipp: Verwende Tabellen nur für tabellarische Daten, nie für Layout. Ein Screenreader kündigt eine Tabelle an ("Tabelle mit 5 Zeilen und 3 Spalten") -- wenn das für ein Layout-Element passiert, verwirrt es den Nutzer.

Formulare und Screenreader

Formulare sind der häufigste Stolperstein für Screenreader-Nutzer. Damit ein Formular funktioniert, muss jedes Eingabefeld ein sichtbares, programmatisch verknüpftes Label haben (WCAG SC 1.3.1, SC 3.3.2). Das geht am einfachsten mit dem <label>-Element und dem for-Attribut:

<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email">

Weitere wichtige Aspekte:

• Pflichtfelder mit aria-required="true" oder dem HTML5-Attribut required kennzeichnen
• Fehlermeldungen müssen programmatisch mit dem Feld verknüpft sein (aria-describedby auf die Fehlermeldung zeigen)
• Gruppierungen mit <fieldset> und <legend> für zusammengehörige Felder (z.B. Zahlungsart, Adresse)
• Autocomplete-Attribute für persönliche Daten (WCAG SC 1.3.5 Eingabezweck bestimmen)

ARIA-Live-Regions: Dynamische Inhalte ankündigen

Moderne Webseiten aktualisieren Inhalte dynamisch -- ohne Seitenneuladen. Screenreader bekommen davon nichts mit, es sei denn, du nutzt ARIA-Live-Regions (WCAG SC 4.1.3 Statusmeldungen).

Es gibt zwei Varianten:

• aria-live="polite" -- der Screenreader wartet, bis der Nutzer die aktuelle Aktion beendet hat, und liest dann die Änderung vor. Verwende dies für Statusmeldungen, Warenkorbaktualisierungen, Suchergebnisse.
• aria-live="assertive" -- der Screenreader unterbricht sofort und liest die Änderung vor. Verwende dies nur für dringende Meldungen wie Fehlermeldungen oder Zeitlimits.

Ohne Live-Regions sind AJAX-Updates, Single-Page-Apps und dynamische Formulare für Screenreader-Nutzer unsichtbar.

Ein Tag im Leben eines Screenreader-Nutzers

Stell dir vor: Du öffnest eine Webseite und hörst: "Bild, Bild, Bild, Link: hier klicken, Link: hier klicken, Eingabefeld, Eingabefeld." Kein Kontext, keine Beschreibung, keine Orientierung. Das ist die Realität auf einer schlecht programmierten Webseite.

Ein barrierefreier Shop dagegen: "Hauptnavigation, Überschrift: Unsere Produkte, Bild: Roter Laufschuh Nike Air Max 90, Button: In den Warenkorb." Jedes Element hat einen Namen, eine Rolle und einen Kontext.

Screenreader-Nutzer verwenden durchschnittlich 30-40 Tastenkombinationen, um effizient durch Webseiten zu navigieren. Sie sind Experten in ihrer Software -- die Frage ist, ob deine Webseite ihnen die richtigen Informationen liefert.

Screenreader-Testing für Entwickler: So fängst du an

Du musst kein Screenreader-Experte werden. Aber ein Grundverständnis hilft enorm, Barrierefreiheitsprobleme zu finden, die kein automatisierter Test erkennt.

Schnellstart mit NVDA (Windows)

1. NVDA herunterladen -- kostenlos von nvaccess.org. Installation dauert 2 Minuten.
2. Starten -- NVDA läuft im Hintergrund. Strg+Alt+N startet es.
3. Browser öffnen -- Öffne deine Webseite in Firefox oder Chrome.
4. Navigieren -- Drücke Tab für interaktive Elemente, H für Überschriften, D für Landmarks, T für Tabellen.
5. Zuhören -- Was wird vorgelesen? Fehlen Beschreibungen? Ist die Reihenfolge logisch?
6. NVDA beenden -- Insert+Q.

Schnellstart mit VoiceOver (Mac)

1. Aktivieren -- Cmd+F5 (oder: Systemeinstellungen > Bedienungshilfen > VoiceOver)
2. Navigieren -- VO-Taste (Ctrl+Option) + Pfeiltasten. VO+Cmd+H für Überschriften.
3. Rotor nutzen -- VO+U öffnet den Rotor, eine Übersicht aller Überschriften, Links, Landmarks und Formulare.

Prüfe mit dem bf-check Scanner zuerst die automatisch erkennbaren Probleme -- dann ergänze mit einem manuellen Screenreader-Test die Dinge, die nur ein Mensch hören kann.

Häufige Missverständnisse über Screenreader

• "Screenreader lesen die Seite wie ein Buch von oben nach unten" -- Falsch. Erfahrene Nutzer springen gezielt über Überschriften, Landmarks und Links. Lineare Navigation ist nur der Fallback.
• "Wenn es visuell gut aussieht, ist es auch für Screenreader ok" -- Falsch. Ein visuell perfekter Button, der als <div onclick="..."> gebaut ist, existiert für Screenreader nicht als Button. Semantisches HTML ist Pflicht (WCAG SC 4.1.2 Name, Rolle, Wert).
• "ARIA-Attribute machen jede Webseite barrierefrei" -- Falsch. Die erste Regel von ARIA lautet: Verwende kein ARIA, wenn ein natives HTML-Element existiert. <button> braucht kein role="button".
• "Blinde Menschen nutzen keine Smartphones" -- Falsch. VoiceOver (iPhone) und TalkBack (Android) sind vollwertige Screenreader. Mobile Barrierefreiheit ist genauso wichtig wie Desktop.
• "Screenreader-Nutzer sind eine kleine Minderheit" -- Falsch. Allein in Deutschland leben ca. 500.000 blinde und stark sehbehinderte Menschen. Dazu kommen Menschen mit temporären Einschränkungen und Power-User, die Screenreader zur Effizienzsteigerung nutzen.

Warum das für dich relevant ist

In Deutschland nutzen ca. 500.000 Menschen Screenreader. Wenn deine Webseite für sie nicht funktioniert, verlierst du nicht nur Kunden -- du verstößt seit Juni 2025 gegen das BFSG. Die WCAG 2.1 Level AA, die das BFSG als Maßstab heranzieht, ist im Kern eine Anleitung dafür, wie du deine Seite Screenreader-kompatibel machst.

Die gute Nachricht: Sauberes, semantisches HTML ist der Schlüssel, und das ist keine Raketenwissenschaft. Wer <button> statt <div>, <nav> statt <div class="nav"> und echte <label>-Elemente verwendet, hat bereits 80% der Arbeit erledigt.

Dieser Artikel ersetzt keine Rechtsberatung. Bei konkreten rechtlichen Fragen zum BFSG wende dich an einen spezialisierten Anwalt.

Häufig gestellte Fragen