Screenreader

Wie funktioniert ein Screenreader?

Ein Screenreader gibt aus, was der Browser über eine Seite an das Betriebssystem meldet. Der Browser baut dafür aus dem HTML-Code einen Barrierefreiheitsbaum auf, in dem jedes Element einen Namen und eine Rolle hat, etwa „Link“ oder „Schaltfläche“. Was dort fehlt, kann auch der Screenreader nicht vorlesen.

Die Ausgabe läuft über eine Sprachausgabe oder eine Braillezeile. Am Computer steuern Nutzer den Screenreader per Tastatur, am Smartphone mit Gesten.

Nur wenige lesen eine lange Seite von oben nach unten, in der WebAIM-Umfrage 2026 waren es 9,7 % der Befragten. Die meisten springen gezielt weiter, am häufigsten von Überschrift zu Überschrift. In NVDA gelten dafür zum Beispiel diese Tasten.

• H. Springt zur nächsten Überschrift. Mit den Ziffern erreichen Nutzer eine bestimmte Ebene.
• K. Führt zum nächsten Link.
• F. Wechselt zum nächsten Formularfeld.
• D. Bringt den Fokus zum nächsten Seitenbereich, etwa zur Navigation oder zum Hauptinhalt.
• NVDA+F7. Öffnet eine Liste aller Links oder Überschriften der Seite.

Welche Screenreader gibt es?

Am Computer sind JAWS und NVDA am weitesten verbreitet, am Smartphone VoiceOver von Apple.

WebAIM Screen Reader User Survey #11, Juli bis August 2026, 1.780 gültige Antworten. Die Stichprobe ist nicht repräsentativ, gut die Hälfte der Befragten kommt aus Nordamerika. In Europa lagen JAWS mit 42,8 % und NVDA mit 42,3 % gleichauf.

Was brauchen Websites, damit Screenreader sie gut vorlesen?

Screenreader lesen nur vor, was im HTML-Code steht. Fünf Punkte sorgen dafür, dass Inhalte und Funktionen dort ankommen. Die Anforderungen dahinter beschreiben die WCAG.

• Echte Überschriften. Zwischentitel sind als HTML-Überschriften ausgezeichnet, ohne Ebenen zu überspringen. In der WebAIM-Umfrage springen 67,8 % der Befragten auf langen Seiten zuerst über die Überschriften. Übersprungene Ebenen fand WebAIM auf 41,8 % der meistbesuchten Startseiten.
• Alternativtexte. Informative Bilder haben einen Alt-Text, dekorative ein leeres alt-Attribut, damit der Screenreader sie überspringt.
• Beschriftete Felder und Schaltflächen. Jedes Formularfeld ist mit seiner Beschriftung verknüpft, jede Schaltfläche hat einen Namen. Auf den meistbesuchten Startseiten war ein Drittel der Formularfelder nicht korrekt beschriftet.
• Tastaturbedienung. Menüs und Dialoge lassen sich ohne Maus bedienen, weil Screenreader-Nutzer am Computer mit der Tastatur arbeiten.
• Sparsames ARIA. ARIA-Attribute ergänzen HTML um Rollen und Zustände für Hilfsmittel. Laut W3C bringen sie kein Tastaturverhalten mit, und falsch eingesetzt verschlechtern sie die Bedienung. Startseiten mit ARIA hatten bei WebAIM im Schnitt 59,1 erkannte Fehler, Seiten ohne ARIA 42, waren aber auch komplexer.

So testen Sie Ihre Website mit einem Screenreader

1. Screenreader starten. Unter Windows eignet sich das kostenlose NVDA, am Mac schalten Sie VoiceOver mit Command + F5 ein.
2. Überschriften prüfen. Springen Sie in NVDA mit H durch die Seite. Die Überschriften sollten zusammen ein sinnvolles Inhaltsverzeichnis ergeben.
3. Links prüfen. Öffnen Sie mit NVDA+F7 die Liste der Links. Jeder Linktext sollte auch ohne Umgebung verständlich sein, „Mehr“ oder „Hier“ reichen dafür nicht.
4. Formular ausfüllen. Füllen Sie ein Formular nur mit der Tastatur aus und senden Sie es mit einem Fehler ab. Der Screenreader sollte jedes Feld benennen und die Fehlermeldung vorlesen.

Ein Selbsttest zeigt grobe Fehler schnell, auch ohne Übung mit dem Screenreader. In der Prüfung zur digitalen Barrierefreiheit testen wir Abläufe wie Anfrage und Bestellung auch mit Screenreader.

Typische Fehler, die Screenreader-Nutzer ausbremsen

• Überschriften nur optisch. Fett gesetzter Text sieht aus wie ein Zwischentitel, der Screenreader erkennt darin aber keine Überschrift.
• Schaltflächen ohne Namen. Ein Icon ohne Text wird nur als „Schaltfläche“ vorgelesen. Leere Schaltflächen fand WebAIM auf 30,6 % der meistbesuchten Startseiten, leere Links auf 46,3 %.
• Stumme Statusmeldungen. Hinweise wie „In den Warenkorb gelegt“ erscheinen nur am Bildschirm. Kriterium 4.1.3 der WCAG 2.2 (Stufe AA) verlangt, dass Hilfsmittel solche Meldungen vorlesen können, ohne dass der Fokus dorthin springt.