Wenn ich Entwickler-Teams trainiere, ist eine Übung Pflicht: Wir starten einen Screenreader und lassen die Teilnehmer hören, wie ihre eigene Website tatsächlich klingt. Die Stille im Raum danach ist jedes Mal dieselbe. Plötzlich verstehen Menschen, die seit Jahren Code für andere Menschen schreiben, was ein Screenreader wirklich macht – und warum so viele Websites für blinde Nutzer eine Zumutung sind. Diese Vorlese-Software ist das wichtigste Werkzeug, mit dem Menschen mit Sehbehinderung das Web nutzen, und sie funktioniert auf eine Art, die für Sehende meistens völlig unsichtbar bleibt. In diesem Ratgeber zeige ich Ihnen, was ein Screenreader ist, wie er Inhalte verarbeitet – und mit einem konkreten transkribierten Beispiel, wie eine schlecht gebaute Navigation für ihn tatsächlich klingt.
Was ein Screenreader ist und wie er funktioniert
Ein Screenreader ist eine Software, die digitale Inhalte vom Bildschirm in synthetische Sprache oder Braille umwandelt. Hauptzielgruppe sind blinde und stark sehbehinderte Menschen, die Computer und Smartphones nicht über das visuelle Interface bedienen können. Im Web liest der Screenreader nicht das, was auf dem Bildschirm sichtbar ist, sondern was im HTML-Code steht – genauer: was im sogenannten Accessibility Tree des Browsers ankommt, einer Repräsentation der Seite, die Inhalt, Rolle und Zustand jedes Elements beschreibt. Die Konsequenz daraus ist fundamental: Ein Screenreader liest, was Sie als Entwickler geschrieben haben, nicht, wie das Ergebnis aussieht. Sauberer, semantischer Code ist deshalb die Grundlage – kosmetische Tricks im CSS helfen ihm nichts.
Die wichtigsten Screenreader im Überblick
Es gibt nicht den einen Screenreader, sondern eine Handvoll etablierter Werkzeuge, die unterschiedliche Plattformen und Nutzergruppen bedienen:
- JAWS (Job Access With Speech): Der kommerzielle Marktführer im professionellen Umfeld, ausschließlich für Windows, weit verbreitet in Behörden und Unternehmen.
- NVDA (NonVisual Desktop Access): Kostenlos und Open Source, ebenfalls Windows, in der weltweiten Nutzergemeinde am stärksten verbreitet.
- VoiceOver: Tief in macOS und iOS integriert, kostenlos verfügbar, besonders unter iPhone-Nutzern sehr beliebt.
- TalkBack: Der Pendant auf Android, vorinstalliert auf den meisten Geräten.
- Narrator: Der in Windows mitgelieferte Screenreader, hat in den letzten Jahren deutlich an Qualität gewonnen.
Wer mit Audits zu tun hat, muss verstehen, dass diese Werkzeuge nicht identisch funktionieren. Wie sich JAWS, NVDA und VoiceOver in der Praxis unterscheiden und warum echte Audits mit mehreren Werkzeugen geprüft werden, lesen Sie in JAWS, NVDA und VoiceOver: Wie echte Nutzer Ihre Website wirklich erleben.
Wie ein Screenreader Inhalte liest und Nutzer navigieren
Ein Screenreader-Nutzer hört eine Website nicht sequenziell von oben nach unten – jedenfalls nicht, wenn die Seite gut gebaut ist. Stattdessen nutzt er Tastenkürzel, um schnell durch die Seite zu springen: Eine Taste für Überschriften, eine andere für Landmarks (also nav, main, footer), eine weitere für Links, Formularfelder oder Tabellen. Beim Fokussieren eines Elements liest der Screenreader drei Dinge vor: den Inhalt, die Rolle und den Zustand. Ein Button heißt dann beispielsweise „Speichern, Schaltfläche“, eine Überschrift „Unsere Produkte, Überschrift Ebene 2″, eine Liste wird mit „Liste mit drei Elementen“ eingeleitet. Diese Ansage gibt es nur, wenn die zugrundeliegende HTML-Semantik stimmt. Wenn alles div ist, hört der Nutzer nur nackten Text ohne Struktur – und verliert die Orientierung.
Wie eine Seite klingt: Ein transkribiertes Beispiel
Theoretisch ist das alles abstrakt. Konkret wird es, wenn wir denselben Inhalt zweimal an einen Screenreader übergeben – einmal kaputt gebaut, einmal semantisch sauber. Nehmen wir eine ganz normale Hauptnavigation mit Logo, zwei Menüpunkten und einem Warenkorb-Symbol.
Die kaputte Version im Code
<div class="nav">
<div class="item"><img src="logo.png"></div>
<div class="item"><a href="#">Hier klicken</a></div>
<div class="item"><span onclick="zeigeProdukte()">Produkte</span></div>
<div class="item"><img src="cart.svg"></div>
</div>Was der Screenreader daraus macht
Ein NVDA-Nutzer tabbt durch diese „Navigation“ und hört, sinngemäß:
„Grafik. Link, Hier klicken. Produkte. Grafik.“
Das war alles. Kein Hinweis auf eine Navigation, weil kein nav-Element vorhanden ist. Kein Hinweis auf einen Warenkorb, weil das zweite Bild nur als „Grafik“ angekündigt wird – Alt-Text fehlt. Der Link „Hier klicken“ hat keinen Kontext, niemand weiß, wohin er führt. Das Element „Produkte“ wird gar nicht als Schaltfläche erkannt, weil es ein span mit onclick ist – ohne Rolle und ohne Tastatur-Funktion. Der Screenreader-Nutzer hört vier zusammenhanglose Wortfetzen.
Die saubere Version im Code
<nav aria-label="Hauptnavigation">
<a href="/"><img src="logo.png" alt="IFDB Startseite"></a>
<ul>
<li><a href="/leistungen">Unsere Leistungen</a></li>
<li><button onclick="zeigeProdukte()">Produkte anzeigen</button></li>
</ul>
<a href="/warenkorb" aria-label="Warenkorb, 3 Artikel">
<img src="cart.svg" alt="">
</a>
</nav>Was der Screenreader jetzt vorliest
„Navigation, Hauptnavigation. Link: IFDB Startseite. Liste mit zwei Elementen. Link: Unsere Leistungen. Schaltfläche: Produkte anzeigen. Liste Ende. Link: Warenkorb, drei Artikel.“
Derselbe Inhalt, vollständig anderes Erlebnis. Der Nutzer weiß, dass er in einer Hauptnavigation steht. Er hört, was das Logo bedeutet, wohin die Links führen, dass eines der Elemente eine Schaltfläche und kein Link ist, und dass im Warenkorb drei Artikel liegen. Er kann gezielt entscheiden, wo er hingehen will. Die Grundlagen dieser semantischen Sauberkeit habe ich in Semantisches HTML als Fundament der Barrierefreiheit ausführlich beschrieben.
Warum Ihre Website für Screenreader-Nutzer relevant ist
Die Frage „wie viele Screenreader-Nutzer haben wir denn überhaupt“ höre ich oft – und sie führt regelmäßig in die Irre. Schätzungen variieren, aber zwischen 0,5 und 2 Prozent der Web-Nutzer arbeiten regelmäßig mit Screenreadern. Auf eine Million Besucher sind das fünf- bis zwanzigtausend Menschen – eine Größenordnung, die jeden Marketing-Verantwortlichen aufhorchen lassen sollte. Hinzu kommen Gelegenheitsnutzer mit altersbedingter Sehverschlechterung und Menschen mit kognitiven Einschränkungen, die Vorlesefunktionen schätzen. Zusammen ergibt das eine relevante, nicht-erschlossene Zielgruppe – und seit 2025 auch eine rechtlich nicht mehr verhandelbare. Wer für diese Nutzer nicht erreichbar ist, verliert nicht nur Reichweite, sondern verstößt gegen das BFSG.
Die häufigsten Frust-Erlebnisse, die Sie vermeiden sollten
In meinen Audits mit echten Screenreader-Nutzern höre ich immer wieder dieselben Reaktionen auf dieselben Mängel:
- „Grafik, Grafik, Grafik“: Bilder ohne Alt-Texte oder mit dem Dateinamen als Beschriftung. Wer „IMG_4523.png“ vorgelesen bekommt, weiß nichts.
- „Link, Link, Link“: Eine Seite voller Links, die alle „Mehr erfahren“ oder „Hier klicken“ heißen. Ohne Kontext sind sie nutzlos.
- Endlose Wiederholungen im Header: Wenn der gleiche Navigationsblock auf jeder Seite ohne Skip-Link kommt, muss der Nutzer ihn jedes Mal vortabben, bevor er zum Inhalt kommt.
- Stille Updates: Ein neues Suchergebnis erscheint, ein Formular hat einen Fehler, ein Modal öffnet sich – aber der Screenreader sagt nichts, weil keine Live-Region eingerichtet ist.
- Tabellen ohne Köpfe: Daten werden vorgelesen, aber niemand weiß, zu welcher Spalte und Zeile sie gehören, weil die Kopfzellen fehlen oder falsch ausgezeichnet sind.
Jeder dieser Mängel kann eine Komponente unbenutzbar machen. Und keiner davon ist exotisch – sie alle stammen aus aktuellen Audits realer Mittelstands- und Großkundenwebsites.
Warum Tests mit echten Nutzern mehr leisten als ein Scanner
Automatische Prüfwerkzeuge können einen Teil dieser Probleme finden: fehlende Alt-Texte, kaputte Überschriftenhierarchien, mangelhafte Formular-Labels. Was sie nicht können, ist beurteilen, ob ein Alt-Text inhaltlich sinnvoll ist, ob die Lesereihenfolge wirklich verständlich ist, ob ein Live-Update zum richtigen Zeitpunkt angekündigt wird oder ob die Bedienung einer komplexen Komponente im Screenreader Sinn ergibt. Wo die Grenzen automatischer Tests verlaufen und warum sie nie die ganze Wahrheit liefern, habe ich in Warum automatische Tests nur einen Teil finden: Die Grenzen von KI-Scannern ausführlich beschrieben.
Unser Tiefen-Audit Access Ready setzt deshalb auf eine Kombination, die Scanner allein nicht leisten können: automatisierte Prüfung gegen die vollständige EN 301 549, kombiniert mit der Bedienung Ihrer Website durch echte Nutzer assistiver Technologien – JAWS, NVDA und VoiceOver, je nach Plattform und Zielgruppe. Diese Menschen hören, was Ihr Code ausgibt, navigieren wie ein echter Screenreader-Nutzer und dokumentieren, wo die Bedienung scheitert, hakt oder verwirrend wird. Das Ergebnis ist ein belastbares Zertifikat, das in BFSG-Verfahren als Nachweis der Sorgfaltspflicht trägt – und Ihnen vorher zeigt, was Ihre Nutzer wirklich hören würden, wenn sie Ihre Seite besuchen.
