Screen-Reader

Ein Screen-Reader ist eine Software, die den Inhalt eines Bildschirms in Sprache oder Braille ausgibt und damit blinden und stark sehbehinderten Menschen die Bedienung von Betriebssystemen, Websites und Online-Shops ermöglicht. Er liest nicht das Bild, sondern die strukturierte Repräsentation dahinter: Überschriften, Links, Formularfelder, Rollen, Zustände und Beschriftungen. Was dort nicht ankommt, existiert für den Nutzer nicht.

Damit ist der Screen-Reader das wichtigste Prüfinstrument für digitale Barrierefreiheit und gleichzeitig der Grund, warum semantisches HTML kein Stilthema ist. Ein Button, der als <div> gebaut wurde, sieht im Browser aus wie ein Button. Für den Screen-Reader ist er ein Textabsatz.

Wie ein Screen-Reader arbeitet

Die verbreitete Vorstellung, ein Screen-Reader lese die Seite „von oben nach unten vor", beschreibt nur den Sonderfall. In der Praxis ist er ein Navigationswerkzeug, das auf eine Datenstruktur zugreift, die der Browser bereitstellt.

Vom DOM zum Accessibility Tree

Der Browser baut aus dem HTML zunächst den DOM-Baum und daraus einen zweiten, reduzierten Baum: den Accessibility Tree. In diesem Baum trägt jedes relevante Element drei Informationen. Erstens eine Rolle (Button, Link, Überschrift, Textfeld, Tabelle). Zweitens einen zugänglichen Namen, der nach einem festgelegten Algorithmus aus Beschriftung, alt-Attribut, aria-label oder verknüpftem Text ermittelt wird. Drittens Zustände und Eigenschaften, etwa ob ein Kontrollkästchen aktiviert, ein Feld ungültig oder ein Menü ausgeklappt ist.

Der Screen-Reader liest diesen Baum über eine Plattform-Schnittstelle aus, unter Windows über UI Automation beziehungsweise IAccessible2, unter macOS über die NSAccessibility-Schnittstelle. Daraus folgt eine Regel, die im Alltag viel erklärt: Nicht das Aussehen entscheidet über die Ausgabe, sondern das Markup. CSS kann ein Element visuell in einen Button verwandeln, am Accessibility Tree ändert es nichts.

Browse-Modus und Formular-Modus

Windows-Screen-Reader wie JAWS und NVDA legen den Seiteninhalt in einem virtuellen Puffer ab und arbeiten darin in zwei Betriebsarten. Im Lesemodus (Browse Mode, bei NVDA „Browse-Modus", bei JAWS „Virtual Cursor") sind die Buchstabentasten Navigationsbefehle: H springt zur nächsten Überschrift, F zum nächsten Formularfeld, T zur nächsten Tabelle, D zur nächsten Landmark-Region. Sobald der Fokus in ein Eingabefeld wechselt, schaltet der Screen-Reader in den Fokusmodus (Forms Mode) und leitet Tastendrücke an die Anwendung weiter.

Dieser Moduswechsel ist der Grund, warum eigenentwickelte Widgets so häufig scheitern. Ein selbstgebautes Dropdown ohne korrekte Rolle löst den Wechsel nicht aus. Der Nutzer bleibt im Lesemodus, seine Pfeiltasten wandern durch den Text statt durch die Optionen, und die Auswahl funktioniert nicht.

Welche Screen-Reader tatsächlich im Einsatz sind

Die belastbarste öffentliche Datenquelle zur Verbreitung ist die WebAIM Screen Reader User Survey #10. Sie wurde im Dezember 2023 und Januar 2024 erhoben und hat 1.539 gültige Antworten. Die Stichprobe ist nicht kontrolliert und damit nicht repräsentativ für alle Screen-Reader-Nutzer, aber sie ist die Reihe, die seit 2009 konsistent fortgeschrieben wird.

Zwei Ableitungen sind für die Testpraxis wichtiger als die Prozentzahlen. Erstens: JAWS und NVDA liegen nahezu gleichauf, zusammen deutlich über drei Viertel der Desktop-Nutzung. Wer nur mit VoiceOver auf dem Mac testet, prüft eine Minderheitensituation. Zweitens: Die regionale Streuung ist erheblich, in Nordamerika lag JAWS klar vor NVDA, europäische Teilnehmer stellten mit 30,7 % die zweitgrößte Gruppe. Für den deutschsprachigen Markt ist NVDA deshalb die sinnvolle Mindestkonfiguration: kostenlos, quelloffen, unter Windows mit Chrome und Firefox einsetzbar.

Mobil verschiebt sich das Bild vollständig. Dort dominieren die im Betriebssystem enthaltenen Lösungen, VoiceOver unter iOS und TalkBack unter Android. Ein Shop, dessen Traffic überwiegend mobil ist, braucht mindestens einen Testdurchlauf mit VoiceOver auf einem echten iPhone, weil Gesten-Navigation und Fokusverhalten sich von der Desktop-Situation unterscheiden.

Warum Screen-Reader für Online-Shops zählen

Rechtlich ist die Sache seit 2025 eindeutig. Das BFSG verpflichtet B2C-Online-Shops zur Barrierefreiheit, technischer Maßstab sind die WCAG in der Konformitätsstufe AA, europäisch gerahmt durch die harmonisierte Norm EN 301 549. Ein erheblicher Teil der Erfolgskriterien lässt sich nur mit einem Screen-Reader sinnvoll prüfen, weil es um die Frage geht, was tatsächlich angekündigt wird: der Name eines Buttons, die Verknüpfung einer Fehlermeldung, die Änderung eines Warenkorbzählers.

Wirtschaftlich zählt eine zweite Größe. Ein Kaufprozess, der mit dem Screen-Reader nicht abschließbar ist, produziert keinen Bounce, sondern einen abgebrochenen Checkout mit gefülltem Warenkorb. Und die Defekte, die dabei stören, sind fast nie exotisch.

Die Stellen, an denen Shops regelmäßig scheitern

Die WebAIM-Erhebung fragt seit Jahren nach den größten Hindernissen. Die Rangfolge ist über vierzehn Jahre nahezu unverändert und liest sich wie eine Mängelliste typischer Shop-Frontends:

• CAPTCHAs mit Bildtext stehen mit deutlichem Abstand an der Spitze. Relevant überall dort, wo Registrierung, Kontaktformular oder Newsletter abgesichert werden.
• Interaktive Elemente, die sich nicht wie erwartet verhalten: Mega-Menüs, Tabs und modale Dialoge. Im Shop betrifft das die Hauptnavigation, die Variantenauswahl und die Adressauswahl im Checkout.
• Links und Buttons ohne sinnvollen Namen. Fünf Elemente, die alle „Mehr erfahren" heißen, sind in einer Linkliste unbrauchbar. Symbol-Buttons ohne Beschriftung, etwa Warenkorb, Wunschliste und Suche, gehören in dieselbe Kategorie.
• Bereiche, die sich unerwartet ändern. Nachladende Produktlisten, Filter mit Auto-Submit, ein sich aktualisierender Warenkorb: ohne Live-Region bleibt die Änderung unangekündigt.
• Fehlende Tastaturbedienbarkeit. Screen-Reader-Nutzer bedienen die Seite über die Tastatur; was nicht fokussierbar ist, ist nicht erreichbar.
• Bilder ohne oder mit unpassendem Alt-Text, im Shop typischerweise Produktbilder, Größentabellen als Grafik und Badges wie „Sale".
• Komplexe Formulare und fehlende oder falsche Überschriften, beides Kernbestandteile jedes Checkouts.

Besonders instruktiv ist die Frage, wie Nutzer auf einer längeren Seite Informationen suchen. 71,6 % der Befragten navigieren zuerst über die Überschriften, nur 13,6 % greifen zur Suchfunktion des Screen-Readers und 3,7 % zu den Landmark-Regionen. 88,8 % halten die Überschriftenebenen dabei für sehr oder ziemlich nützlich. Eine saubere h1-bis-h3-Hierarchie auf der Produktdetailseite ist damit keine SEO-Kosmetik, sondern das primäre Navigationsgerüst.

Realbeispiel: die Produktkarte im Listing

Ein wiederkehrendes Muster in Shop-Templates ist die Produktkarte, die aus Bild, Titel, Preis und einem Button besteht. Visuell funktioniert sie. Mit dem Screen-Reader entsteht daraus oft folgende Ausgabe, wenn die Karte als reine div-Struktur gebaut ist und der Button nur ein Icon trägt: „Grafik. Link. 89,90 Euro. Schaltfläche." Marke, Produktname und Bedeutung des Buttons fehlen, und in einer Liste mit 24 Produkten wiederholt sich das Muster 24-mal identisch.

Die Korrektur besteht nicht aus zusätzlichem ARIA, sondern aus drei einfachen Schritten. Das Produktbild erhält einen Alt-Text mit Marke und Produktbezeichnung, wobei bei einem verlinkten Bild der Alt-Text das Ziel beschreibt und nicht das Motiv. Der Produkttitel wird zur Überschrift der passenden Ebene, damit er in der Überschriftenliste auftaucht. Der Button bekommt einen Namen, der ohne Umgebung trägt: „In den Warenkorb, Produktname" statt eines nackten Warenkorbsymbols. Danach liest dieselbe Karte als eigenständige, unterscheidbare Einheit.

In Shopware 6 ist dieser Punkt inzwischen teilweise ab Werk gelöst. Mit Version 6.7 sind die Accessibility-Verbesserungen des Standard-Themes dauerhaft aktiv, die in 6.6 noch hinter einem Feature-Flag lagen, darunter korrektes Listen-Markup in Listing und Warenkorb sowie Alt-Texte für Symbol-Buttons. Die Praxis-Erfahrung bleibt allerdings: Sobald ein Custom Theme die Karte überschreibt, gilt für dieses Markup wieder die Verantwortung des Entwicklers.

Screen-Reader-Test in der Praxis

Ein Screen-Reader-Test ersetzt keine automatisierte Prüfung und wird nicht von ihr ersetzt. Werkzeuge wie axe oder WAVE finden fehlende Namen, falsche Rollen und Kontrastfehler zuverlässig und schnell. Ob eine Fehlermeldung im richtigen Moment angekündigt wird und ob die Reihenfolge verständlich ist, entscheidet sich erst im Hören.

Für einen belastbaren Durchlauf reicht ein knappes Skript. Die Grundbefehle in NVDA unter Windows:

• Strg + Alt + N startet NVDA, Einfg + Q beendet es.
• H und Umschalt + H springen vorwärts und rückwärts durch Überschriften, 1 bis 6 gezielt auf eine Ebene.
• D wechselt zur nächsten Landmark-Region, F zum nächsten Formularfeld, T zur nächsten Tabelle, B zum nächsten Button.
• Einfg + F7 öffnet die Elementliste mit allen Links, Überschriften und Landmarks der Seite. Das ist der schnellste Weg, um zu sehen, ob eine Seite navigierbar strukturiert ist.
• Einfg + Pfeil nach unten liest ab der aktuellen Position fortlaufend vor.

Als Prüfpfad in einem Shop bewährt sich die Kette Startseite, Kategorielisting mit einem gesetzten Filter, Produktdetailseite mit Variantenwechsel, Warenkorb, Checkout mit einem absichtlich erzeugten Formularfehler, Bestellabschluss. Der eingebaute Fehler ist der wichtigste Schritt, weil er zeigt, ob die Meldung angekündigt wird oder stumm im DOM liegt.

Häufige Missverständnisse

„Ein Overlay-Tool macht den Shop screenreader-tauglich." Eine eingeblendete Bedienleiste mit Vorlesefunktion ändert das darunterliegende Markup nicht. Ein Bild ohne Alt-Text bleibt ohne Alt-Text, ein Dialog ohne Fokusverwaltung bleibt eine Sackgasse. Für manche Nutzergruppen ist eine solche Leiste ein Komfortgewinn, als Konformitätsnachweis taugt sie nicht.

„Mehr ARIA hilft." Zusätzliche Attribute überschreiben die native Semantik und richten häufiger Schaden an als Nutzen. Die erste Regel der ARIA-Spezifikation lautet, kein ARIA zu verwenden, wenn ein natives HTML-Element dieselbe Rolle mitbringt. Ein <button> ist einem <div role="button"> in jedem Punkt vorzuziehen.

„Screen-Reader sind nur für blinde Nutzer relevant." Sie werden auch von Menschen mit Sehrest in Kombination mit Vergrößerungssoftware, von Nutzern mit Lese- und Konzentrationseinschränkungen und situativ genutzt. Die Maßnahmen, die einen Screen-Reader-Durchlauf verbessern, wirken zudem auf Tastaturbedienung, Sprachsteuerung und maschinelles Verständnis der Seite.

„Die Vorlesefunktion des Browsers ist dasselbe." Vorlesefunktionen geben Text als Audio aus. Ein Screen-Reader vermittelt zusätzlich Rollen, Zustände und Struktur und erlaubt Navigation darin. Das ist der entscheidende Unterschied.

Einordnung und Entwicklung

Die Bedienlogik der Screen-Reader ist über Jahre stabil geblieben, das Umfeld nicht. Mit der Verbreitung von Single-Page-Anwendungen und clientseitig nachgeladenen Inhalten hat die Zahl der Situationen zugenommen, in denen sich die Seite ändert, ohne dass eine neue Seite geladen wird. Genau dort entstehen die unangekündigten Änderungen, die in der Problemliste weit oben stehen. Live-Regionen und bewusste Fokussteuerung sind deshalb von Randthemen zu Kernanforderungen geworden.

Parallel wachsen die Fähigkeiten auf der Ausgabeseite. Aktuelle Screen-Reader binden Bilderkennung ein und können ein Bild ohne Alt-Text näherungsweise beschreiben. Das entlastet Nutzer im Alltag, verschiebt aber keine Pflicht: Eine automatisch erzeugte Beschreibung kennt weder Variante noch Kontext noch Funktion eines Bildes im Kaufprozess, und die Normen verlangen einen bereitgestellten Alternativtext. Wer darauf setzt, verlagert seine Konformität in die Hand eines Dritten.

FAQ

Welcher Screen-Reader eignet sich zum Testen? NVDA unter Windows, in Kombination mit Chrome oder Firefox. Er ist kostenlos, quelloffen und deckt zusammen mit JAWS die große Mehrheit der Desktop-Nutzung ab. Ergänzend VoiceOver auf einem iPhone für den mobilen Pfad.

Ersetzt ein Screen-Reader-Test die automatisierten Tools? Nein, und umgekehrt genauso wenig. Automatisierte Prüfungen decken nur einen Teil der WCAG-Erfolgskriterien maschinell ab. Beide Verfahren prüfen unterschiedliche Fehlerklassen und gehören in dieselbe Testroutine.

Wie lange dauert ein erster Durchlauf durch einen Shop? Für den Kernpfad von der Startseite bis zur Bestellbestätigung sind wenige Stunden realistisch, wenn jemand die Tastenbefehle kennt. Der Aufwand liegt anschließend in der Behebung, nicht im Test.

Muss jedes Bild einen Alt-Text haben? Jedes informative Bild braucht einen. Rein dekorative Bilder erhalten ein leeres alt="", damit der Screen-Reader sie überspringt. Ein fehlendes Attribut ist nicht dasselbe wie ein leeres, denn ohne Attribut liest die Software im Zweifel den Dateinamen vor.

Reicht es, wenn die Seite per Tastatur bedienbar ist? Tastaturbedienbarkeit ist die Voraussetzung, nicht das Ziel. Ein Element kann fokussierbar sein und trotzdem keinen Namen und keine Rolle haben. Dann ist es erreichbar, aber nicht verständlich.