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. Was der Test findet, landet am Ende im Code: Bei einer individuell entwickelten Web-Applikation lassen sich Rollen, Namen und Fokusführung direkt in den Komponenten verankern.
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.
