Screenreader im Überblick: NVDA, JAWS, VoiceOver & Co.

Ein Screenreader ist die Software-Brücke zwischen Bildschirm und Ohr (oder Fingerspitze): Er liest aus, was Betriebssystem und Browser über die Oberfläche wissen, und gibt es als Sprache oder Blindenschrift aus. Entscheidend für Webentwickler: Der Screenreader sieht nicht deine Pixel, sondern den Accessibility Tree – die Struktur, die der Browser aus deinem HTML ableitet. Gutes Markup erzeugt eine gute Ansage, fast von allein.

Die wichtigsten Screenreader

In den WebAIM-Umfragen unter Screenreader-Nutzern liegen JAWS und NVDA auf dem Desktop seit Jahren nahezu gleichauf an der Spitze, VoiceOver folgt dahinter – auf dem Smartphone dominiert VoiceOver (iOS) vor TalkBack. Für die Praxis heißt das: Wer mit NVDA und VoiceOver testet, deckt die relevanten Welten gut ab.

Wie ein Screenreader arbeitet

Drei Konzepte erklären das meiste Verhalten:

1. Virtueller Puffer / Browse-Modus: Auf Webseiten navigiert der Screenreader durch eine eigene Dokument-Ansicht – mit Schnelltasten wie H für Überschriften oder K für Links. Die typischen Strategien bauen darauf auf.
2. Formular-/Fokus-Modus: In Eingabefeldern schaltet er um, damit Tastendrücke ins Feld gehen statt zu navigieren. Custom-Widgets, die Rollen und Zustände falsch setzen, brechen genau an dieser Weiche.
3. Der zugängliche Name: Zu jedem Element sagt der Screenreader Name, Rolle und Zustand an – „Absenden, Schalter“ oder „E-Mail, Eingabefeld, Pflichtfeld“. Woher der Name kommt (Textinhalt, <label>, aria-label), regelt WCAG 4.1.2 „Name, Rolle, Wert“.

Randnotiz – Screenreader sind keine Fehler-Melder. Ein Screenreader liest auch kaputte Seiten irgendwie vor – er warnt nicht, er interpretiert. Dass etwas „vorgelesen wird“, heißt also nicht, dass es verständlich oder bedienbar ist. Deshalb gehört zum Test immer die Frage: Würde ich nur mit dieser Ansage ans Ziel kommen?

Unterschiede, die dich betreffen

Screenreader interpretieren Grenzfälle unterschiedlich – ähnlich wie Browser. NVDA und JAWS unterscheiden sich etwa darin, wie sie Tabellen oder verschachtelte Listen ansagen; VoiceOver hat mit dem Rotor ein eigenes Navigationskonzept. Daraus folgt eine pragmatische Regel: Nah am Standard bleiben. Natives HTML wird überall am konsistentesten unterstützt; je exotischer das ARIA-Konstrukt, desto größer die Unterschiede. Und: mit echten Screenreadern testen statt raten – mit NVDA und mit VoiceOver gibt es hier je eine Schritt-für-Schritt-Anleitung.

Häufige Fragen

Mit welchem Screenreader soll ich als Entwickler testen?

Pragmatische Antwort: NVDA unter Windows (kostenlos, weit verbreitet, nah an JAWS) und VoiceOver auf dem iPhone (dominant im mobilen Web). Wer nur macOS hat, startet mit VoiceOver am Mac – besser ein Screenreader als keiner.

Muss meine Seite in jedem Screenreader identisch klingen?

Nein. Wie bei Browsern gilt: Das Verhalten muss funktionieren, nicht identisch sein. Ziel ist, dass Name, Rolle, Zustand und Struktur überall korrekt ankommen – die Formulierung der Ansage gehört dem Screenreader.

Erkenne ich Screenreader-Nutzer im Analytics?

Nein, und das ist Absicht: Assistive Technologien geben sich aus Datenschutzgründen nicht zu erkennen. Barrierefreiheit lässt sich nicht auf „unsere Nutzer haben das nicht“ herausmessen – die ehrliche Basis sind die Zahlen zur Verbreitung.

Fazit

JAWS, NVDA, VoiceOver, TalkBack – unterschiedliche Werkzeuge, ein Prinzip: Sie machen aus deinem Markup eine hörbare Oberfläche. Für Tests reichen NVDA und VoiceOver. Wie sich das Surfen damit anfühlt, beschreibt Wie Screenreader-Nutzer surfen; die Grundlagen und Grenzen des Testens erklärt Screenreader-Grundlagen.