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

Für eigene Tests reichen zwei Programme: NVDA unter Windows und VoiceOver auf dem iPhone. Sie decken die Kombinationen ab, in denen laut WebAIM-Survey #10 (Januar 2024) die große Mehrheit unterwegs ist – am Desktop teilen sich JAWS (40,5 %) und NVDA (37,7 %) den Markt, mobil führt VoiceOver mit 70,6 % klar vor TalkBack. Alle anderen Programme musst du kennen, aber nicht besitzen.

Das Wichtigste in Kürze

• Ein Screenreader sagt zu jedem Element Name, Rolle und Zustand an – „Nachricht senden, Schalter“ statt „blauer Kasten unten rechts“. Was er sagt, entsteht im Accessibility Tree, nicht im CSS.
• Stand Januar 2024 (WebAIM-Survey #10, 1.539 Befragte) als primärer Desktop-Screenreader: JAWS 40,5 %, NVDA 37,7 %, VoiceOver 9,7 %, Dolphin SuperNova 3,7 %, ZoomText/Fusion 2,7 %, Orca 2,4 %.
• 71,6 % nutzen mehr als einen Desktop-Screenreader, 43 % drei oder mehr. „Ein Nutzer, ein Screenreader“ ist die falsche Vorstellung.
• 91,3 % nutzen zusätzlich einen mobilen Screenreader – dort führt VoiceOver mit 70,6 % vor TalkBack (34,7 %).
• 38 % lassen sich die Ausgabe parallel über eine Braillezeile geben, arbeiten also zeitweise völlig lautlos.
• Häufigste Browser-Kombination ist JAWS mit Chrome (24,7 %), gefolgt von NVDA mit Chrome (21,3 %) und JAWS mit Edge (11,4 %).
• Für Deutschland gibt es keine belastbare Statistik. Die WebAIM-Umfrage erreicht überwiegend den englischsprachigen Raum; JAWS ist hierzulande als kassenfinanziertes Hilfsmittel verbreiteter, als der weltweite Schnitt vermuten lässt.
• Ein Screenreader ist kein Prüfwerkzeug: Er liest auch kaputte Seiten vor. Die Testfrage lautet nicht „wird etwas vorgelesen?“, sondern „komme ich allein mit dieser Ansage ans Ziel?“.

Abgrenzung – drei Seiten, drei Fragen. Diese Seite ist die Übersicht: welche Screenreader es gibt, wie verbreitet sie sind und mit welchen zwei du testest. Wie ein Screenreader technisch aus HTML eine Ansage macht, steht unter Screenreader-Grundlagen. Wie Menschen damit tatsächlich navigieren – Überschriftensprünge, Elementliste, Vorlesereihenfolge –, steht unter Wie Screenreader-Nutzer surfen.

Wie die Ansage entsteht – kurz gefasst

Der verbreitetste Irrtum steckt schon im Namen: Ein Screenreader liest keinen Screen. Er fragt Betriebssystem und Browser nach dem Accessibility Tree ab, einer gefilterten Fassung des DOM, in der jedes Element einen Namen, eine Rolle und einen Zustand trägt. Aus diesen drei Angaben entsteht die Ansage „Nachricht senden, Schalter“ – CSS hat auf diesem Weg keine Haltestelle, weshalb ein div, das wie ein Button aussieht, im Baum ein stummer Textknoten bleibt. Welchen Namen ein Element bekommt, regelt WCAG 4.1.2 „Name, Rolle, Wert“.

Diese Kette im Detail – welche Technik ein Element aus dem Baum entfernt, welche es nur unsichtbar macht und was ein Screenreader-Test damit belegen kann – steht unter Screenreader-Grundlagen. Auf dieser Seite geht es um die Programme selbst: welche es gibt, wie verbreitet sie sind und wo sie sich im Alltag tatsächlich unterscheiden.

Nebenbei erklärt derselbe Mechanismus, warum sauberes Markup auch außerhalb der Barrierefreiheit zählt: Ein Suchmaschinen-Crawler und ein Sprachmodell lesen ebenfalls Struktur statt Optik und stehen vor demselben stummen div – siehe Semantik & SEO.

Die Programme, die zählen

JAWS ist der Veteran und in Deutschland stark verbreitet, weil er als Hilfsmittel anerkannt und damit unter Umständen über Krankenkasse oder Integrationsamt finanzierbar ist. Für Nutzer bedeutet das: kein Preisschild. Für dich als Entwickler bedeutet es, dass die JAWS-Ansage im deutschen Arbeitsumfeld wahrscheinlich häufiger vorkommt, als die weltweite Statistik nahelegt.

NVDA von NV Access hat den Markt verändert, weil es nichts kostet. Es ist damit der einzige vollwertige Desktop-Screenreader, den du ohne Beschaffungsvorgang installieren kannst – und verhält sich nah genug an JAWS, dass sich die meisten Befunde übertragen.

VoiceOver ist zweigeteilt: Am Mac ein solides, aber eigenwilliges Programm mit eigener Modifier-Logik (VO = Ctrl+Alt), auf dem iPhone der mit Abstand meistgenutzte Screenreader überhaupt. Wer nur mobil testen kann, testet trotzdem etwas sehr Relevantes.

TalkBack liegt mobil auf Platz zwei und weicht in Details ab, etwa bei Überschriftennavigation und Live-Regionen. Orca und Dolphin SuperNova sind Nischen, die du kennen, aber nicht testen musst. Der Windows-Erzähler spielt als Hauptwerkzeug kaum eine Rolle; er ist die Notlösung, mit der man einen frisch aufgesetzten Rechner überhaupt bedienen kann.

Verbreitung: was die Zahlen hergeben – und was nicht

Die einzige regelmäßige Erhebung ist der WebAIM Screen Reader User Survey, Stand Juli 2026 zuletzt als Ausgabe #10 (Dezember 2023/Januar 2024, 1.539 gültige Antworten, davon 89,9 % Menschen mit Behinderung). Drei Befunde daraus sind für die Praxis wichtiger als die Rangliste selbst.

Erstens: Fast alle nutzen mehrere Programme. 71,6 % geben an, mehr als einen Desktop-Screenreader zu verwenden, 43 % drei oder mehr, 17,4 % vier oder mehr. Wer sich auf eine Software festlegt, kommt bei manchen Websites nicht weiter – die Nutzer haben sich längst darauf eingestellt und wechseln. Für dich heißt das: Ein Fehler, der nur unter JAWS auftritt, ist trotzdem ein Fehler, aber selten ein Totalausfall.

Zweitens: Die Browser-Kombination zählt mit. Häufigste Paarung ist JAWS mit Chrome (24,7 %), dann NVDA mit Chrome (21,3 %), JAWS mit Edge (11,4 %), NVDA mit Firefox (10,0 %) und VoiceOver mit Safari (7,0 %). Der Accessibility Tree wird vom Browser gebaut – Chrome, Firefox und Safari legen manche Regeln unterschiedlich aus. Ein Test ist immer ein Test des Paares, nie eines einzelnen Programms.

Drittens: Die Zahlen sind nicht deutsch. Die Umfrage läuft auf Englisch und erreicht vor allem den anglo-amerikanischen Raum. Domingos de Oliveira, der seit Jahren aus der deutschen Perspektive schreibt, hält fest, dass es hier schlicht keine validen offiziellen Statistiken gibt und JAWS und NVDA sich auf dem Desktop ungefähr die Waage halten. Ich würd deshalb keine Priorisierung allein auf Prozentwerte stützen: Der Unterschied zwischen 40 % und 38 % Marktanteil ändert an deiner Arbeit exakt nichts.

Zwei Konzepte, an denen sich die Programme scheiden

Die Moduslogik. Unter Windows arbeitet ein Screenreader auf Webseiten in einer eigenen Dokumentansicht, in der Schnelltasten navigieren – H nächste Überschrift, K Link, D Landmarke. Sobald der Fokus in ein Eingabefeld springt, gehen Tastendrücke stattdessen ins Feld. NVDA und JAWS schalten dabei automatisch um; VoiceOver kennt diese Trennung so nicht, sondern steuert über eine Interaktionsebene. Das erklärt einen guten Teil der Verhaltensunterschiede zwischen Windows und Apple – die Mechanik dahinter steht unter Screenreader-Grundlagen, die Tastenstrategien unter Wie Screenreader-Nutzer surfen.

Der zugängliche Name. Er entsteht nach einer festen Rangfolge: aria-labelledby schlägt aria-label, das wiederum den sichtbaren Textinhalt schlägt. Diese Reihenfolge ist im W3C-Standard genormt und einer der wenigen Punkte, an denen sich alle Programme gleich verhalten. Deshalb überschreibt ein aria-label einen völlig korrekten Linktext in jedem Screenreader – ein Fehler, den man beim Lesen des Codes nicht sieht, beim Hören aber sofort. Custom-Widgets, die Rollen und Zustände falsch setzen, versagen dagegen je nach Programm unterschiedlich – dieselbe Ursache, drei verschiedene Symptome.

Randnotiz – ARIA an generischen Elementen verpufft. Ein aria-label braucht eine Rolle, an der es hängen kann. An einem div ohne role wird es je nach Screenreader ignoriert oder inkonsistent ausgegeben. Das ist kein Bug, sondern die Spezifikation: Ohne Rolle gibt es kein Element, das benannt werden könnte.

<!-- Falsch: Rolle fehlt, der Name hängt in der Luft -->
<div aria-label="Hauptnavigation">
  <ul>…</ul>
</div>

<!-- Richtig: Rolle kommt vom Element, Name vom Attribut -->
<nav aria-label="Hauptnavigation">
  <ul>…</ul>
</nav>

Wo sich die Programme wirklich unterscheiden

Screenreader interpretieren Grenzfälle unterschiedlich – nicht anders als Browser vor zwanzig Jahren. Die Unterschiede, die mir in Tests am häufigsten begegnen:

• Listen und Tabellen. JAWS und NVDA kündigen „Liste mit 3 Einträgen“ an, verschachtelte Listen aber unterschiedlich ausführlich. Bei Tabellen entscheidet allein die Auszeichnung: Ohne <th> und scope ist eine Preistabelle in jedem Programm eine Zahlenwolke – siehe Tabellen semantisch aufbauen.
• Interpunktion und Zahlen. „1.4.3“ wird je nach Stimme und Einstellung als Datum, als Version oder als drei Zahlen gelesen. Verlass dich nie darauf, dass eine Zeichenkette so klingt, wie sie aussieht.
• Live-Regionen. Was aria-live="polite" wann meldet, ist der wohl uneinheitlichste Bereich überhaupt: Timing, Wiederholungen und die Frage, ob eine Änderung überhaupt bemerkt wird, unterscheiden sich deutlich. Praxisregeln dazu stehen unter Live-Regionen.
• VoiceOver-Rotor statt Schnelltasten. Am iPhone gibt es keine H-Taste – die Navigationseinheit wird über eine Zwei-Finger-Drehgeste eingestellt. Dieselbe Überschrift, ein völlig anderes Bedienkonzept.

Daraus folgt die einzige Regel, die stabil bleibt: Nah am Standard bleiben. Natives HTML wird überall am konsistentesten unterstützt. Je exotischer das ARIA-Konstrukt, desto größer die Streuung – das ist der praktische Kern der ersten Regel von ARIA.

So testest du es

1. Installiere NVDA (kostenlos, rund 100 MB) und starte es mit Strg+Alt+N. Alternative ohne Installation: die Windows-Sprachausgabe mit Win+Strg+Enter, am Mac VoiceOver mit Cmd+F5.
2. Schalte den Sprachausgaben-Betrachter ein – im NVDA-Menü unter „Werkzeuge → Der Sprachausgaben-Betrachter“. Er zeigt jede Ansage zusätzlich als Text in einem Fenster; das erspart dir am Anfang das Mithören und macht die Ausgabe kopierbar.
3. Springe nur mit H durch deine Startseite. Ergibt die Folge der Überschriften ein schlüssiges Inhaltsverzeichnis, ohne dass du auf den Bildschirm schaust?
4. Öffne die Elementliste mit NVDA+F7 und lies nur die Linktexte. Verrät jeder davon sein Ziel, oder steht dort dreimal „Weitere Informationen“?
5. Bediene ein Formular komplett blind. Dunkle den Bildschirm ab. Sagt jedes Feld seinen Namen, seinen Zustand („Pflichtfeld“) und im Fehlerfall die Ursache an?
6. Wiederhole Schritt 3 bis 5 mit VoiceOver am iPhone (Einstellungen → Bedienungshilfen → VoiceOver; wer den Bedienungshilfen-Kurzbefehl belegt, schaltet ihn per Dreifachklick auf die Seitentaste). Was in beiden funktioniert, funktioniert fast überall.

Die ausführlichen Anleitungen dazu stehen unter mit NVDA testen, mit JAWS testen, mit VoiceOver am Mac testen sowie – für die mobile Seite – VoiceOver auf iPhone und iPad und TalkBack.

Häufiger Fehler in der Praxis

Marktanteile als Testplan lesen. Aus 40,5 % gegen 37,7 % lässt sich keine Reihenfolge ableiten – der Abstand liegt innerhalb dessen, was eine Selbstauswahl-Umfrage hergibt. Die verwertbare Zahl steht daneben: 71,6 % nutzen ohnehin mehrere Programme. Wer ein Formular in einem Screenreader sauber bedienbar macht, hilft der Mehrheit auch dann, wenn er das „falsche“ getestet hat.

Mit Standardtempo getestet. Die Werkseinstellung der Sprachausgabe ist quälend langsam; geübte Nutzer hören mit rund dem doppelten Sprechtempo. Wer im Demo-Tempo testet, überschätzt die Geduld für lange Vorreden und unterschätzt, wie sehr eine fehlende Sprungmarke wehtut.

Am Mac getestet und Windows-Verhalten angenommen. VoiceOver hat keine Trennung in Lese- und Formularmodus. Genau an dieser Weiche versagen unter NVDA und JAWS aber die meisten selbstgebauten Widgets. Ein Mac-Test ist deshalb ein guter Anfang und ein schlechter Abschluss – die häufigste Fehlerklasse überhaupt bekommt er nicht zu sehen.

Den Windows-Erzähler für gleichwertig halten. Er ist an Bord und deshalb verlockend, aber er ist als Notlösung gebaut, nicht als Arbeitsgerät: In der WebAIM-Erhebung nutzt ihn praktisch niemand als primären Screenreader. „Funktioniert im Erzähler“ ist kein Befund, auf den sich eine Abnahme stützen lässt.

Häufige Fragen

Mit welchem Screenreader soll ich als Entwickler testen?

Mit NVDA unter Windows und VoiceOver auf dem iPhone. NVDA kostet nichts, liegt mit 37,7 % fast gleichauf mit JAWS und verhält sich ähnlich genug, dass sich Befunde übertragen lassen. VoiceOver deckt die mobile Seite ab, wo es mit 70,6 % die klare Nummer eins ist. Wer nur einen Mac hat, startet mit VoiceOver am Mac – ein Screenreader ist unendlich viel besser 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 – wie die Ansage formuliert wird, entscheidet der Screenreader und die persönliche Einstellung des Nutzers. Eine unterschiedliche Wortwahl ist kein Fehler, eine fehlende Rolle schon.

Erkenne ich Screenreader-Nutzer in meiner Statistik?

Nein, und das ist gewollt. Assistive Technologien geben sich aus Datenschutzgründen nicht zu erkennen; es gibt keinen zuverlässigen User-Agent und keinen Analytics-Wert dafür. Das Argument „unsere Nutzer haben das nicht“ lässt sich also gar nicht belegen – die belastbare Grundlage sind stattdessen die Zahlen zur Verbreitung.

Ersetzt ein automatischer Test den Screenreader?

Nein. Automatische Prüfwerkzeuge finden fehlende Alt-Attribute, kaputte Label-Verknüpfungen und Kontrastfehler – also die Hälfte der WCAG-Kriterien, grob geschätzt. Ob ein Alt-Text sinnvoll ist, ob eine Reihenfolge logisch klingt oder ob ein Dialog die Aufmerksamkeit richtig lenkt, entscheidet nur ein Mensch mit Screenreader. Welche Werkzeuge was können, steht unter Tools.

Brauche ich JAWS, wenn meine Zielgruppe Behörden sind?

Nützlich ja, zwingend nein. Im deutschen Arbeitsumfeld – Verwaltung, Ausbildung, große Unternehmen – ist JAWS über die Hilfsmittelversorgung stark vertreten. Wenn du für öffentliche Stellen baust und die Abnahme über einen BITV-Test läuft, prüft ohnehin ein Profi mit seiner eigenen Ausstattung. Für die tägliche Entwicklung reicht NVDA.

Verwandte Themen

• Wie Screenreader-Nutzer surfen – die Navigationsstrategien hinter den Schnelltasten
• Braillezeile – wie 38 % der Befragten zusätzlich taktil lesen
• Sehbehinderung und Blindheit – wer diese Programme nutzt und warum
• Screenreader-Grundlagen – was ein Test leisten kann und was nicht
• Mit NVDA testen – Schritt für Schritt zum ersten eigenen Test; für die anderen Programme JAWS, VoiceOver am Mac, VoiceOver mobil und TalkBack
• Landmarks und Outline – das Gerüst, das die D-Taste überhaupt erst füllt

Quellen

• Screen Reader User Survey #10 (WebAIM, Erhebung Dezember 2023/Januar 2024 – alle Prozentangaben zu Verbreitung, Browser-Kombinationen und Mehrfachnutzung)
• How People with Disabilities Use the Web: Tools and Techniques (W3C WAI – Funktionsweise von Screenreadern und Braillezeilen)
• NVDA User Guide (NV Access – Tastenbefehle, Lesemodus, Sprachbetrachter)
• Welche Screenreader Blinde verwenden (Domingos de Oliveira – Einordnung der Verbreitung für den deutschsprachigen Raum)
• Accessible Name and Description Computation (W3C – Rangfolge bei der Ermittlung des zugänglichen Namens)