Wer seine Website auf Barrierefreiheit prüft, beginnt meistens mit einem automatischen Tool.

Lighthouse starten.

WAVE öffnen.

axe DevTools durchlaufen lassen.

Fehler beheben.

Das ist ein sinnvoller Anfang.

Aber irgendwann kommt der Punkt, an dem man wissen möchte:

Wie hört sich meine Website eigentlich für jemanden an, der sie nicht sieht?

Genau dafür gibt es Screenreader.

Beim ersten Start wirkt ein Screenreader allerdings etwas ungewohnt. Plötzlich spricht der Computer beinahe ohne Pause. Links, Überschriften, Buttons, Formularfelder und andere Elemente werden vorgelesen. Die Bedienung funktioniert außerdem anders, als man es mit Maus und Bildschirm gewohnt ist.

Das kann anfangs ziemlich chaotisch wirken.

Die gute Nachricht:

Du musst nicht lernen, einen Screenreader so schnell und effizient zu bedienen wie jemand, der ihn täglich verwendet.

Für einen ersten Accessibility-Test reichen bereits einige grundlegende Funktionen.

Und schon dabei können Fehler auffallen, die Lighthouse, WAVE oder axe niemals zuverlässig beurteilen könnten.

Zum Beispiel:

Ein Produktbild besitzt zwar einen Alt-Text – aber dieser lautet nur „Produktbild“.

Ein Button ist technisch beschriftet – wird aber als „Weiter“ vorgelesen, obwohl niemand weiß, wohin er führt.

Eine Seite besitzt Überschriften – aber deren Reihenfolge ergibt überhaupt keinen Sinn.

Oder ein Checkout funktioniert mit der Maus hervorragend, während ein Screenreader-Nutzer zwischen Zahlungsart und Bestellbutton komplett die Orientierung verliert.

In diesem Beitrag schauen wir uns deshalb Schritt für Schritt an, wie du deine eigene Website als Anfänger mit einem Screenreader testen kannst.

Was ist ein Screenreader?

Ein Screenreader ist eine Software, die digitale Inhalte über Sprache oder eine Braillezeile zugänglich macht.

Er liest dabei nicht einfach stumpf den sichtbaren Text von oben nach unten vor.

Ein guter Screenreader erkennt die technische Struktur einer Website.

Zum Beispiel:

• Überschriften
• Absätze
• Links
• Buttons
• Bilder
• Listen
• Navigationen
• Formularfelder
• Checkboxen
• Tabellen
• Dialogfenster

Dadurch kann ein Nutzer gezielt zwischen verschiedenen Elementen navigieren.

Eine Überschrift ist also nicht nur große, fett geschriebene Schrift.

Für einen Screenreader ist sie ein Navigationselement.

Ein Button ist nicht einfach ein farbiges Rechteck.

Er besitzt eine Funktion, einen Namen und gegebenenfalls einen Zustand.

Genau deshalb ist sauberer HTML-Code für Barrierefreiheit so wichtig.

Warum sollte ich meine Website mit einem Screenreader testen?

Ein automatisiertes Prüfprogramm sieht bestimmte technische Eigenschaften.

Ein Screenreader zeigt dir dagegen, wie diese Eigenschaften bei einem Nutzer ankommen.

Das ist ein entscheidender Unterschied.

Beispiel: Alt-Text

Automatischer Test:

Alt-Text vorhanden.

Screenreader:

„Grafik produktbild final klein webp.“

Technisch ist vielleicht irgendeine Textalternative vorhanden.

Praktisch ist sie nutzlos.

Beispiel: Button

Automatischer Test:

Button besitzt zugänglichen Namen.

Screenreader:

„Weiter, Schaltfläche.“

Auf einer Seite mit fünf „Weiter“-Buttons hilft das kaum.

Beispiel: Formular

Automatischer Test:

Label vorhanden.

Screenreader:

„Eingabefeld erforderlich.“

Aber welches Feld?

E-Mail?

Name?

Postleitzahl?

Erst beim Anhören merkst du, ob die Informationen tatsächlich verständlich sind.

Muss ich blind sein, um einen Screenreader sinnvoll testen zu können?

Natürlich nicht.

Ein sehender Webdesigner oder Websitebetreiber kann einen Screenreader verwenden, um technische und inhaltliche Probleme zu entdecken.

Allerdings solltest du eine Sache im Hinterkopf behalten:

Du testest nicht exakt so wie ein erfahrener blinder Nutzer.

Jemand, der täglich mit einem Screenreader arbeitet, kennt zahlreiche Tastenkombinationen und navigiert deutlich schneller.

Dein eigener Test ist deshalb kein Ersatz für Tests durch tatsächliche Nutzer mit Behinderungen.

Trotzdem ist er sehr wertvoll.

Du bekommst zum ersten Mal einen Eindruck davon, welche Informationen deine Website ohne die visuelle Darstellung vermittelt.

Welchen Screenreader sollte ich verwenden?

Das hängt vor allem von deinem Betriebssystem ab.

Windows: NVDA

Für Windows ist NVDA eine sehr gute Möglichkeit zum Einstieg.

NVDA steht kostenlos zur Verfügung und wird sehr häufig für Webtests eingesetzt.

Der Name bedeutet:

NonVisual Desktop Access

Mit NVDA kannst du unter anderem Webseiten in Browsern wie Chrome oder Firefox bedienen.

Für Websitebetreiber ist das besonders interessant, weil keine teure Spezialsoftware notwendig ist.

Windows: Sprachausgabe/Narrator

Windows besitzt außerdem bereits einen eigenen integrierten Screenreader.

Du musst also nicht zwingend zusätzliche Software installieren, um einen ersten Test durchzuführen.

Für einen schnellen Einstieg kann die Windows-Sprachausgabe vollkommen ausreichen.

Wer häufiger Websites testet, wird häufig zusätzlich NVDA ausprobieren.

macOS: VoiceOver

Auf einem Mac ist VoiceOver bereits integriert.

Du brauchst keine zusätzliche Software.

VoiceOver lässt sich auf dem Mac beispielsweise über eine Tastenkombination aktivieren und bietet außerdem eine Einführung, in der die Bedienung geübt werden kann.

iPhone und iPad: VoiceOver

Auch iPhone und iPad besitzen VoiceOver.

Hier erfolgt die Bedienung hauptsächlich über spezielle Gesten.

Ein Smartphone-Test ist besonders interessant, weil mobile Webseiten häufig eine andere Navigation verwenden als die Desktop-Version.

Android

Android-Geräte besitzen ebenfalls Screenreader-Funktionen, insbesondere TalkBack.

Wer einen größeren Online-Shop betreibt, sollte langfristig nicht nur Desktop-Systeme betrachten.

Für den ersten Test würde ich trotzdem mit dem eigenen Desktop-System beginnen.

Mit welchem Browser sollte ich testen?

Für den Einstieg solltest du keine zehn Kombinationen gleichzeitig ausprobieren.

Unter Windows eignet sich beispielsweise:

NVDA + Chrome

oder:

NVDA + Firefox

Auf dem Mac:

VoiceOver + Safari

Das sind sinnvolle Ausgangspunkte.

Später kannst du weitere Kombinationen ergänzen.

Wichtiger als fünf verschiedene Browser oberflächlich zu testen ist zunächst, einen vollständigen Nutzerweg wirklich durchzugehen.

Vor dem ersten Test: Lautstärke etwas reduzieren

Das klingt banal, ist aber hilfreich.

Ein Screenreader spricht schnell und häufig.

Beim ersten Start kann das ziemlich hektisch wirken.

Stelle die Lautstärke angenehm ein.

Wenn möglich, reduziere zunächst auch die Sprechgeschwindigkeit.

Erfahrene Screenreader-Nutzer verwenden teilweise Geschwindigkeiten, bei denen Anfänger kaum noch einzelne Wörter verstehen.

Für deinen Test bringt das nichts.

Du möchtest hören, was ausgegeben wird.

Nicht einen Geschwindigkeitsrekord aufstellen.

Wichtig: Maus möglichst ignorieren

Sobald der Screenreader läuft, entsteht eine große Versuchung.

Man hört etwas nicht richtig.

Kurz mit der Maus klicken.

Weiter.

Damit überspringt man aber möglicherweise genau das Problem, das man finden möchte.

Versuche deshalb während eines Testabschnitts möglichst:

• Tastatur
• Screenreader-Befehle
• gegebenenfalls Screenreader-Gesten

zu verwenden.

Bei einem Desktop-Test kannst du die Maus sogar bewusst etwas zur Seite legen.

Dein erster Screenreader-Test

Beginne nicht gleich mit einem komplizierten WooCommerce-Checkout.

Nimm zunächst eine normale Inhaltsseite.

Zum Beispiel einen Blogartikel.

So kannst du dich an die Ausgabe gewöhnen.

Öffne die Seite.

Aktiviere den Screenreader.

Höre zunächst einfach zu.

Was wird als Erstes vorgelesen?

Idealerweise bekommst du direkt einen Hinweis darauf, auf welcher Seite du dich befindest.

1. Seitentitel prüfen

Der Seitentitel ist für Screenreader-Nutzer besonders wichtig.

Er hilft dabei zu erkennen:

Welche Seite habe ich gerade geöffnet?

Schlecht wäre beispielsweise:

„Startseite.“

und auf jeder Unterseite ebenfalls:

„Startseite.“

Besser:

„Kontakt – Müller Gebäudereinigung“

oder:

„Barrierefreie Produktbilder und Alt-Texte – digital-gelöst.de“

Jede wichtige Seite sollte einen aussagekräftigen Titel besitzen.

Was solltest du prüfen?

Öffne mehrere Seiten.

Hör dir den Seitentitel an.

Frage dich:

• Ist er eindeutig?
• Unterscheidet er sich von anderen Seiten?
• Weiß ich sofort, wo ich mich befinde?

2. Überschriften anhören

Überschriften gehören zu den wichtigsten Navigationsmöglichkeiten für Screenreader-Nutzer.

Viele Nutzer lesen nicht jede Webseite von der ersten bis zur letzten Zeile.

Stattdessen springen sie beispielsweise von Überschrift zu Überschrift.

Das funktioniert ähnlich wie ein Inhaltsverzeichnis.

Beispiel einer guten Struktur

H1: Screenreader-Test für Anfänger

H2: Welchen Screenreader verwenden?

H2: Navigation testen

H3: Hauptmenü

H3: Mobile Navigation

H2: Formulare testen

Das ergibt Sinn.

Eine problematische Struktur

H1: Screenreader-Test

H4: Formular

H2: Navigation

H6: Kontakt

Technisch existieren Überschriften.

Die Hierarchie wirkt aber chaotisch.

Dein Test

Lass dir die Überschriften der Seite nacheinander vorlesen.

Frage dich:

Wenn ich nur diese Überschriften hören würde, würde ich verstehen, worum es auf der Seite geht?

Wenn nein, sollte die Struktur überarbeitet werden.

3. Prüfe, ob optische Überschriften wirklich Überschriften sind

Das ist ein häufiger Fehler bei Pagebuildern.

Ein Text sieht aus wie eine Überschrift.

Groß.

Fett.

Blau.

Technisch ist er aber nur ein normaler Absatz.

Ein sehender Nutzer erkennt sofort:

Das ist eine Abschnittsüberschrift.

Ein Screenreader-Nutzer bekommt diese Information nicht.

Beim Screenreader-Test fällt das schnell auf.

Wenn ein wichtiger Abschnitt beim Navigieren durch Überschriften übersprungen wird, solltest du die technische Auszeichnung überprüfen.

4. Navigation testen

Jetzt kommt das Hauptmenü.

Versuche, dich nur über den Screenreader und die Tastatur durch die Navigation zu bewegen.

Achte darauf, was vorgelesen wird.

Zum Beispiel:

„Start, Link.“

„Leistungen, Link.“

„Über uns, Link.“

„Kontakt, Link.“

Das ist klar.

Problematisch wäre:

„Link.“

„Link.“

„Grafik.“

„Link.“

Dann fehlen wahrscheinlich verständliche Namen.

5. Dropdown-Menüs ausprobieren

Viele Websites besitzen Untermenüs.

Zum Beispiel:

Leistungen

→ Webdesign
→ SEO
→ WordPress

Teste:

• Wird angekündigt, dass es ein Untermenü gibt?
• Kannst du es öffnen?
• Kannst du die enthaltenen Links erreichen?
• Kannst du es wieder verlassen?
• Weißt du jederzeit, wo du dich befindest?

Gerade individuell programmierte Dropdowns verursachen häufig Probleme.

6. Skip-Link testen

Viele barrierefreie Websites besitzen einen sogenannten Skip-Link oder Sprunglink.

Damit kann ein Tastatur- oder Screenreader-Nutzer beispielsweise direkt zum Hauptinhalt springen.

Das spart Zeit.

Sonst müsste er bei jedem Seitenaufruf erneut durch:

Logo.

Hauptnavigation.

Suchfunktion.

Zusatznavigation.

und weitere Header-Elemente.

Ein Link wie:

„Zum Inhalt springen“

kann deshalb sehr hilfreich sein.

Prüfe, ob er funktioniert und tatsächlich zum Hauptinhalt führt.

7. Linktexte anhören

Screenreader können Links gezielt auflisten.

Das ist ein guter Test.

Stell dir folgende Liste vor:

„Hier klicken“

„Mehr“

„Mehr erfahren“

„Hier“

„Weiter“

Ohne den umgebenden Text weiß niemand, wohin diese Links führen.

Besser:

„Preisliste herunterladen“

„Mehr über Webdesign erfahren“

„Kontaktformular öffnen“

„Informationen zur Barrierefreiheit lesen“

Ein einfacher Test

Höre dir nur die Links an.

Frage dich:

Würde ich verstehen, wohin sie führen, wenn ich den restlichen Absatz nicht sehen könnte?

8. Icon-Buttons prüfen

Moderne Webseiten verwenden viele Icons.

Zum Beispiel:

• Lupe
• Warenkorb
• Herz
• Hamburger-Menü
• Pfeile
• X zum Schließen

Sehende Nutzer erkennen ihre Bedeutung häufig sofort.

Der Screenreader braucht aber einen zugänglichen Namen.

Schlecht:

„Schaltfläche.“

Oder:

„Grafik.“

Oder:

„X, Schaltfläche.“

Besser:

„Suche öffnen, Schaltfläche.“

„Warenkorb öffnen, Schaltfläche.“

„Zur Wunschliste hinzufügen, Schaltfläche.“

„Menü öffnen, Schaltfläche.“

„Dialog schließen, Schaltfläche.“

9. Bilder und Alt-Texte anhören

Jetzt wird es besonders interessant.

Lass dir die Bilder deiner Seite vorlesen.

Du hörst möglicherweise plötzlich Dinge, die du im WordPress-Backend längst vergessen hattest.

Zum Beispiel:

„Grafik IMG 3827 final final compressed.“

Das ist kein sinnvoller Alt-Text.

Ein guter Alt-Text

Produktbild:

Schwarzer Trekkingrucksack.

Sinnvolle Ausgabe:

„Schwarzer Trekkingrucksack mit orangefarbenen Reißverschlüssen und zwei seitlichen Netztaschen.“

Der Nutzer erhält relevante Informationen.

Was solltest du fragen?

Bei jedem Bild:

Erfahre ich durch den vorgelesenen Text ungefähr das, was ein sehender Nutzer durch das Bild erfährt?

Nicht jedes optische Detail.

Aber die wichtige Information.

10. Dekorative Bilder prüfen

Jetzt kommt die andere Seite.

Vielleicht liest der Screenreader:

„Grafik blaue Wellenlinie.“

„Grafik dekorativer Punkt.“

„Grafik Hintergrundform.“

Das ist unnötig.

Rein dekorative Bilder sollten normalerweise nicht den Lesefluss mit bedeutungslosen Informationen unterbrechen.

Ein Screenreader-Test zeigt sehr schnell, wenn eine Seite akustisch voller Dekoration ist.

11. Produktgalerien testen

Bei Online-Shops solltest du mehrere Produktbilder ausprobieren.

Eine Galerie könnte enthalten:

1. Produkt vorne
2. Rückseite
3. Innenansicht
4. Detail
5. Lieferumfang

Wenn der Screenreader fünfmal sagt:

„Produktbild.“

geht fast die komplette zusätzliche Information verloren.

Besser:

„Schwarzer Rucksack von vorne.“

„Rückansicht mit gepolsterten Schultergurten.“

„Geöffnetes Hauptfach mit Laptopfach.“

„Nahaufnahme des wasserabweisenden Materials.“

12. Buttons testen

Gehe alle wichtigen Buttons einer Seite durch.

Frage:

Verstehe ich sofort, was diese Schaltfläche macht?

Gut:

„Formular absenden.“

„In den Warenkorb.“

„Filter zurücksetzen.“

„Cookie-Einstellungen speichern.“

Weniger gut:

„OK.“

„Weiter.“

„Klick.“

„Button 3.“

Gerade bei mehreren ähnlichen Buttons wird das schnell problematisch.

13. Formulare testen

Formulare gehören zu den wichtigsten Screenreader-Tests.

Öffne beispielsweise dein Kontaktformular.

Navigiere Feld für Feld.

Der Screenreader sollte möglichst klar vermitteln:

Welches Feld ist das?

Ist es erforderlich?

Welche Eingabe wird erwartet?

Ein gutes Beispiel

„E-Mail-Adresse, erforderlich, Eingabefeld.“

Du weißt sofort, was zu tun ist.

Ein schlechtes Beispiel

„Eingabefeld.“

Was gehört hinein?

Name?

Telefonnummer?

E-Mail?

Keine Ahnung.

14. Platzhalter nicht mit Labels verwechseln

Optisch kann in einem Feld stehen:

E-Mail-Adresse

Das wirkt wie eine Beschriftung.

Vielleicht handelt es sich aber nur um einen Platzhalter.

Screenreader und andere Hilfstechnologien benötigen eine saubere technische Beschriftung.

Der praktische Test zeigt dir, welche Information tatsächlich ausgegeben wird.

15. Pflichtfelder prüfen

Wenn ein Feld verpflichtend ist, sollte diese Information verständlich sein.

Der Screenreader sollte nicht nur irgendein Sternchen vorlesen.

Idealerweise wird klar:

Dieses Feld ist erforderlich.

Teste mehrere Pflichtfelder.

Gerade WordPress-Formularplugins setzen solche Dinge unterschiedlich um.

16. Checkboxen prüfen

Ein klassisches Beispiel:

„Ich habe die Datenschutzerklärung gelesen.“

Der Nutzer sollte hören:

• Name der Checkbox
• aktueller Zustand

Zum Beispiel:

„Datenschutzerklärung akzeptieren, nicht aktiviert, Kontrollkästchen.“

Nach der Auswahl:

„aktiviert.“

Wenn lediglich:

„Kontrollkästchen.“

vorgelesen wird, fehlt die entscheidende Information.

17. Radio-Buttons testen

Bei Versand- oder Zahlungsarten werden häufig Radio-Buttons verwendet.

Zum Beispiel:

Standardversand

Expressversand

Der Screenreader sollte die Optionen verständlich benennen und erkennen lassen, welche gewählt wurde.

Das ist besonders wichtig im Checkout.

18. Dropdowns testen

Öffne ein Auswahlfeld.

Beispielsweise:

Land auswählen

oder:

Größe auswählen

Teste:

• Wird die Beschriftung vorgelesen?
• Wird die aktuelle Auswahl genannt?
• Kannst du Optionen wechseln?
• Wird die neue Auswahl bestätigt?

Individuell gestaltete Dropdowns sind deutlich fehleranfälliger als normale HTML-Auswahlfelder.

19. Formulare absichtlich falsch ausfüllen

Das ist einer der wichtigsten Tests.

Gib absichtlich falsche Daten ein.

Zum Beispiel:

E-Mail:

test@

Nachname:

leer.

Pflichtcheckbox:

nicht auswählen.

Dann Formular absenden.

Jetzt hörst du, wie gut die Fehlermeldungen wirklich funktionieren.

20. Fehlermeldungen anhören

Eine gute Meldung:

„Bitte geben Sie eine gültige E-Mail-Adresse ein.“

Schlecht:

„Error.“

Oder noch problematischer:

Es passiert akustisch überhaupt nichts.

Vielleicht erscheint irgendwo optisch ein roter Text.

Der Screenreader bekommt davon aber nichts mit.

Das ist ein typischer Fehler bei dynamischen Formularen.

21. Fokus nach einem Fehler beobachten

Du drückst:

„Absenden“

Das Formular hat drei Fehler.

Wo befindet sich der Screenreader jetzt?

Bleibt er einfach beim Absende-Button?

Dann weißt du möglicherweise nicht, dass weiter oben Fehler erschienen sind.

Eine gute Umsetzung führt den Nutzer sinnvoll:

• zur Fehlerübersicht
• oder zum ersten fehlerhaften Feld.

Das sollte praktisch getestet werden.

22. Erfolgsmeldungen testen

Auch eine erfolgreiche Aktion sollte erkennbar sein.

Beispiel:

Kontaktformular wurde abgeschickt.

Der Screenreader sollte verstehen können:

„Ihre Nachricht wurde erfolgreich gesendet.“

Wenn nur optisch ein grüner Haken erscheint, fehlt für manche Nutzer die Rückmeldung.

23. Akkordeons testen

Akkordeons findet man überall:

• FAQ
• Produktinformationen
• Versandinformationen
• Hilfe

Prüfe:

• Wird die Überschrift vorgelesen?
• Wird gesagt, ob der Bereich geöffnet oder geschlossen ist?
• Kann er aktiviert werden?
• Ist der geöffnete Inhalt anschließend erreichbar?

Ein Screenreader sollte beispielsweise erkennen können:

„Versandinformationen, eingeklappt, Schaltfläche.“

Nach dem Öffnen:

„ausgeklappt.“

24. Tabs testen

Tabs sind ähnlich.

Zum Beispiel:

Beschreibung

Technische Daten

Bewertungen

Der Screenreader sollte verstehen:

• dass es sich um Tabs handelt,
• welcher Tab ausgewählt ist,
• welcher Inhalt dazugehört.

Ein bloßer Link mit optischer Farbhervorhebung reicht dafür nicht immer.

25. Popups und Dialogfenster testen

Öffne ein Popup.

Beispielsweise:

• Newsletter
• Cookie-Einstellungen
• Login
• Filter
• Bildergalerie

Achte auf den Fokus.

Landet der Screenreader tatsächlich im neuen Fenster?

Oder liest er weiter die Website dahinter?

Bei einem echten modalen Dialog sollte der Nutzer verstehen, dass sich der Kontext geändert hat.

26. Dialog schließen

Jetzt versuche, den Dialog wieder zu schließen.

Wird der Schließen-Button verständlich vorgelesen?

Gut:

„Dialog schließen.“

Schlecht:

„X.“

Noch schlechter:

Der Button ist überhaupt nicht erreichbar.

27. Fokus nach dem Schließen kontrollieren

Ein sehr häufiger Fehler:

Popup öffnen.

Schließen.

Screenreader landet plötzlich ganz oben auf der Website.

Der Nutzer muss seine ursprüngliche Position neu suchen.

Besser ist häufig:

Der Fokus kehrt zu dem Element zurück, das den Dialog geöffnet hat.

28. Cookie-Banner testen

Das Cookie-Banner sollte unbedingt Teil deines Screenreader-Tests sein.

Öffne die Website dafür gegebenenfalls in einem privaten Browserfenster.

Höre:

• Überschrift
• Erklärung
• Akzeptieren
• Ablehnen
• Einstellungen
• Cookie-Kategorien
• Schalter

Ein schlechtes Banner könnte klingen wie:

„Button. Button. Switch. Button.“

Ein gutes Banner vermittelt:

„Alle Cookies akzeptieren.“

„Alle ablehnen.“

„Cookie-Einstellungen öffnen.“

„Marketing-Cookies, deaktiviert.“

29. Shop-Navigation testen

Bei WooCommerce oder anderen Shops solltest du anschließend einen echten Einkauf simulieren.

Beginne auf einer Kategorie.

Kannst du:

• Produkte finden?
• Überschriften verstehen?
• Preise zuordnen?
• Produktlinks erkennen?

Dann weiter zur Produktseite.

30. Produktvarianten mit Screenreader testen

Angenommen, ein T-Shirt gibt es in:

Schwarz.

Blau.

Grün.

S, M, L, XL.

Der Screenreader sollte klar verstehen können:

„Farbe Schwarz.“

„Größe M.“

und welchen Zustand die jeweilige Option besitzt.

Besonders problematisch sind grafische Farbfelder.

Ein Screenreader darf nicht nur hören:

„Button.“

31. Warenkorb testen

Lege ein Produkt in den Warenkorb.

Wird bestätigt, dass die Aktion erfolgreich war?

Kannst du anschließend:

• Menge ändern?
• Artikel entfernen?
• Gutschein verwenden?
• Checkout öffnen?

Höre besonders auf Icon-Buttons.

Ein Papierkorb sollte nicht einfach:

„Grafik.“

heißen.

32. Checkout mit Screenreader testen

Jetzt kommt der wichtigste Shop-Test.

Gehe den gesamten Checkout durch.

Prüfe:

• Adresse
• Pflichtfelder
• Versand
• Zahlungsart
• Checkboxen
• Fehlermeldungen
• Gesamtpreis
• Bestellbutton

Wenn du an irgendeiner Stelle nicht weißt, wie es weitergeht, solltest du diese Stelle genauer untersuchen.

33. Zahlungsanbieter testen

Viele Shops wechseln bei der Zahlung in eingebettete oder externe Systeme.

Dadurch kann sich die Screenreader-Ausgabe ändern.

Teste:

• Kreditkartenfelder
• PayPal-Auswahl
• Authentifizierung
• Sicherheitscode
• externe Zahlungsseite

Wichtig:

Der Kunde sollte jederzeit verstehen, wo er sich befindet und was als Nächstes notwendig ist.

34. Gesamtpreis prüfen

Vor einer Bestellung sollte eindeutig sein:

Wie viel bezahle ich?

Der Screenreader sollte Preisbestandteile nachvollziehbar ausgeben können.

Zum Beispiel:

Warenwert.

Versand.

Rabatt.

Gesamtbetrag.

Eine visuell schöne zweispaltige Übersicht kann technisch eine völlig chaotische Reihenfolge besitzen.

35. Bestellbutton anhören

Der letzte Button muss verständlich sein.

Nicht:

„Weiter.“

Sondern eine Formulierung, die klar macht, dass jetzt der Kauf abgeschlossen wird.

Die genaue rechtliche Formulierung hängt vom Angebot ab.

Für Accessibility gilt:

Die Funktion muss eindeutig sein.

36. Bestellbestätigung prüfen

Nach dem Abschluss:

Wird die Bestätigung sinnvoll vorgelesen?

Findest du:

• Bestellnummer
• Zahlungsstatus
• Gesamtbetrag
• weitere Schritte?

Eine schöne große grüne Erfolgsgrafik hilft einem Screenreader-Nutzer wenig, wenn keine entsprechende Textinformation vorhanden ist.

37. Tabellen testen

Websites enthalten manchmal Tabellen.

Zum Beispiel:

• Preise
• Größen
• technische Daten
• Vergleiche

Ein Screenreader sollte verstehen können, welche Werte zu welchen Überschriften gehören.

Besonders bei komplexeren Tabellen fällt schlechte Struktur schnell auf.

38. PDFs nicht vergessen

Wenn deine Website wichtige PDFs verlinkt, gehört auch das zum Nutzerweg.

Beispielsweise:

• Preisliste
• Formular
• Anleitung
• Produktdatenblatt

Der Screenreader-Test der Website endet nicht unbedingt beim Download-Link.

Wenn eine zentrale Information nur in einem unzugänglichen PDF steckt, bleibt eine Barriere bestehen.

39. Sprache und Aussprache prüfen

Manchmal wird Text merkwürdig vorgelesen.

Das kann daran liegen, dass die Seitensprache technisch falsch oder gar nicht angegeben wurde.

Eine deutsche Website sollte entsprechend gekennzeichnet sein.

Bei englischen Passagen können Sprachwechsel ebenfalls eine Rolle spielen.

Wenn der Screenreader plötzlich deutsche Texte mit englischer Aussprache vorliest, lohnt sich ein Blick auf die Sprachangaben.

40. Versteckte Texte entdecken

Screenreader können Inhalte finden, die du optisch gar nicht bemerkst.

Beispielsweise:

• versteckte Menüpunkte
• unsichtbare Formularfelder
• ausgeblendete Tabs
• alte Texte
• technische Hilfsinformationen

Wenn plötzlich Dinge vorgelesen werden, die eigentlich gar nicht sichtbar oder relevant sind, sollte geprüft werden, ob sie wirklich für Hilfstechnologien erreichbar sein sollen.

41. Reihenfolge des Inhalts prüfen

Eine Website kann optisch aus mehreren Spalten bestehen.

Screenreader folgen dagegen der technischen Dokumentreihenfolge.

Das kann zu Überraschungen führen.

Optisch:

Überschrift.

Produkt.

Preis.

Button.

Technisch:

Überschrift.

Footer-Link.

Sidebar.

Button.

Preis.

Dann ist die Reihenfolge problematisch.

Höre deshalb eine Seite einmal tatsächlich von oben nach unten.

42. Nicht alles einzeln Wort für Wort anhören

Bei einem echten Test musst du nicht jede Seite komplett von Anfang bis Ende vorlesen lassen.

Screenreader-Nutzer verwenden Navigationstechniken.

Zum Beispiel:

• Überschriften
• Links
• Formulare
• Regionen

Für Anfänger reicht es zunächst, mehrere typische Wege auszuprobieren.

Du möchtest Probleme finden.

Keine 4.000 Wörter lange Seite als Hörbuch konsumieren.

43. Erst mit offenen Augen testen

Beim ersten Versuch kannst du ruhig sehen, was auf dem Bildschirm passiert.

Das hilft dir dabei, die Screenreader-Ausgabe mit dem sichtbaren Element zu verbinden.

Beispiel:

Du hörst:

„Schaltfläche ohne Namen.“

und siehst gleichzeitig:

Das ist unser Menü-Button.

So verstehst du schneller die Ursache.

44. Danach Bildschirm bewusst ignorieren

Wenn du etwas sicherer wirst, probiere einen Abschnitt, ohne ständig auf den Bildschirm zu schauen.

Du kannst den Monitor beispielsweise nicht direkt ansehen oder die Augen kurz schließen.

Dann merkst du schnell:

Reichen die ausgegebenen Informationen wirklich aus?

Das kann sehr aufschlussreich sein.

45. Nicht versuchen, einen blinden Nutzer zu imitieren

Das ist wichtig.

Ein zehnminütiger Screenreader-Test macht dich nicht zu einem Experten für die Nutzung durch blinde Menschen.

Formuliere deshalb Ergebnisse vorsichtig.

Besser:

„Beim Test mit NVDA war der Button nicht verständlich beschriftet.“

Nicht:

„Blinde Nutzer können diese Website problemlos verwenden.“

Die zweite Aussage wäre nach einem kurzen Selbsttest viel zu weitgehend.

46. Unterschiedliche Screenreader können unterschiedlich reagieren

Nicht jeder Screenreader und Browser interpretiert jede Website exakt gleich.

Deshalb kann eine Seite beispielsweise mit:

NVDA + Firefox

anders reagieren als mit:

VoiceOver + Safari.

Für einen ersten Test ist das kein Problem.

Später können wichtige Systeme mit mehreren Kombinationen überprüft werden.

47. Automatische Bildbeschreibung nicht mit Alt-Text verwechseln

Moderne Screenreader und Betriebssysteme können teilweise versuchen, Bilder automatisch zu erkennen.

Das ist hilfreich.

Es sollte aber keine Ausrede sein, Alt-Texte wegzulassen.

Eine automatisch erzeugte Bildbeschreibung weiß nicht immer:

• welchen Kontext das Bild hat,
• welches Detail für das Produkt wichtig ist,
• welche Information der Autor vermitteln möchte.

Die Website sollte wichtige Accessibility-Informationen selbst bereitstellen.

48. Screenreader-Test nach Änderungen wiederholen

Du hast ein Menü repariert.

Sehr gut.

Teste es erneut.

Gerade bei Accessibility kann eine Änderung ein Problem lösen und gleichzeitig ein neues erzeugen.

Zum Beispiel:

Button bekommt einen Namen.

Jetzt heißt er:

„Menü Menü öffnen Schaltfläche.“

Technisch mehr Informationen.

Praktisch unnötige Wiederholung.

Erst beim Anhören fällt das auf.

Was sollte ein Anfänger zuerst testen?

Du musst nicht sofort alles aus diesem Artikel durchführen.

Für den Anfang reichen fünf Bereiche:

1. Überschriften

Sind Aufbau und Reihenfolge verständlich?

2. Links und Buttons

Haben sie sinnvolle Namen?

3. Bilder

Sind Alt-Texte hilfreich?

4. Formulare

Werden Felder und Fehler verständlich vorgelesen?

5. Navigation

Kannst du dich sinnvoll durch die Website bewegen?

Damit findest du bereits viele typische Probleme.

Der 15-Minuten-Screenreader-Test

Für einen schnellen Einstieg kannst du diesen Ablauf verwenden.

Minute 1 bis 3

Screenreader aktivieren und Startseite öffnen.

Seitentitel und Hauptüberschrift anhören.

Minute 3 bis 5

Durch Überschriften navigieren.

Prüfen, ob die Struktur sinnvoll ist.

Minute 5 bis 7

Links und Buttons anhören.

Minute 7 bis 10

Kontaktformular testen.

Absichtlich einen Fehler erzeugen.

Minute 10 bis 12

Navigation und Dropdown-Menüs prüfen.

Minute 12 bis 15

Eine wichtige Aktion durchführen.

Zum Beispiel:

Kontaktformular absenden oder Produkt in Warenkorb legen.

Nach diesen 15 Minuten hast du häufig bereits eine Liste mit Verbesserungsmöglichkeiten.

30-Minuten-Test für einen Online-Shop

Bei einem Shop würde ich etwas mehr Zeit einplanen.

5 Minuten

Navigation und Kategorie.

5 Minuten

Produktseite und Bilder.

5 Minuten

Varianten und Warenkorb.

10 Minuten

Checkout und Fehlermeldungen.

5 Minuten

Zahlungsart und Bestätigung.

Wenn der komplette Ablauf verständlich funktioniert, ist das ein gutes Zeichen.

Typische Screenreader-Probleme

In der Praxis begegnen einem häufig dieselben Fehler.

„Button“

Keine verständliche Bezeichnung.

„Link“

Link ohne zugänglichen Namen.

Dateiname statt Bildbeschreibung

Alt-Text fehlt oder ist falsch.

Fünfmal derselbe Produktname

Galeriebilder besitzen identische Alt-Texte.

Formularfeld ohne Namen

Label fehlt oder ist technisch nicht verbunden.

Fehlermeldung wird nicht angekündigt

Dynamischer Fehler ist nur visuell sichtbar.

Unverständliche Überschriftenhierarchie

Struktur stimmt nicht.

Popup wird nicht angekündigt

Fokus bleibt auf der Seite dahinter.

Versteckte Inhalte werden vorgelesen

Ausgeblendete Elemente bleiben zugänglich.

Unklarer Zustand

Checkbox, Tab oder Akkordeon meldet nicht, ob es aktiviert oder geöffnet ist.

Screenreader-Test und WAVE kombinieren

WAVE zeigt beispielsweise:

Alt-Text vorhanden.

Dann hörst du ihn mit Screenreader an.

Das ist eine perfekte Kombination.

WAVE:

Technische Information vorhanden.

Screenreader:

Ist die Information auch sinnvoll?

Screenreader-Test und axe DevTools kombinieren

axe meldet:

Button ohne zugänglichen Namen.

Du reparierst den Button.

Danach mit Screenreader testen.

Hört sich der neue Name verständlich an?

So wird aus einem automatischen Fehler ein praktisch überprüftes Ergebnis.

Screenreader-Test und Lighthouse kombinieren

Lighthouse ist ein schneller erster Scan.

Danach sollte der Screenreader zeigen, was die große grüne Zahl nicht beantworten kann.

Ein Lighthouse Score von 100 sagt schließlich nicht, ob:

• Alt-Texte sinnvoll sind,
• Navigation logisch klingt,
• Fehlermeldungen verständlich sind,
• ein kompletter Checkout benutzbar ist.

Muss ich jede Seite mit Screenreader testen?

Bei einer Website mit hunderten Seiten wäre das kaum sinnvoll.

Beginne mit repräsentativen Seitentypen.

Unternehmenswebsite

• Startseite
• Leistungsseite
• Kontakt
• Formular
• Blogartikel

Online-Shop

• Startseite
• Kategorie
• Produktseite
• Warenkorb
• Checkout
• Kundenkonto

Buchungswebsite

• Angebotsseite
• Terminwahl
• Formular
• Bestätigung

Wiederkehrende Templates produzieren häufig dieselben Probleme.

Fehler dokumentieren

Beim Testen solltest du Probleme sofort notieren.

Beispiel:

Seite	Problem	Auswirkung
Startseite	Suchbutton ohne Namen	Funktion unklar
Kontakt	E-Mail-Feld wird nur als Eingabefeld vorgelesen	Feldzweck unklar
Produkt	alle Bilder gleicher Alt-Text	Bildinformationen fehlen
Checkout	Fehler wird nicht angekündigt	Bestellung kann blockieren

Damit kannst du später gezielt arbeiten.

Prioritäten richtig setzen

Nicht jeder Fehler ist gleich dringend.

Priorität 1: Nutzer kommt nicht weiter

Zum Beispiel:

• Navigation nicht bedienbar
• Formular nicht ausfüllbar
• Zahlungsart nicht auswählbar
• Popup nicht schließbar

Priorität 2: wichtige Information fehlt

Zum Beispiel:

• Formularlabel fehlt
• relevantes Produktbild ohne Alt-Text
• Preis schlecht zuordenbar

Priorität 3: Orientierung ist schwierig

Zum Beispiel:

• Überschriftenstruktur
• unklare Links
• fehlende Zustandsinformationen

Priorität 4: unnötige oder störende Ausgabe

Zum Beispiel:

• dekorative Bilder
• doppelte Texte
• redundante Icons

Kurze Checkliste für deinen Screenreader-Test

Prüfe:

• Wird der Seitentitel sinnvoll vorgelesen?
• Gibt es eine verständliche Hauptüberschrift?
• Sind Überschriften logisch aufgebaut?
• Kann ich über Überschriften navigieren?
• Haben Links verständliche Namen?
• Haben Buttons verständliche Namen?
• Werden wichtige Bilder sinnvoll beschrieben?
• Werden dekorative Bilder übersprungen?
• Ist die Hauptnavigation verständlich?
• Funktionieren Untermenüs?
• Haben Formularfelder eindeutige Beschriftungen?
• Werden Pflichtfelder erkannt?
• Sind Checkboxen verständlich?
• Werden Fehlermeldungen angekündigt?
• Wird erklärt, wie ein Fehler behoben werden kann?
• Funktionieren Akkordeons und Tabs?
• Werden deren Zustände erkannt?
• Funktionieren Popups und Dialoge?
• Wird der Fokus sinnvoll gesteuert?
• Funktioniert ein kompletter Nutzerweg?
• Ist der Checkout verständlich?
• Ist nach einer Zahlung oder Aktion klar, was passiert ist?

Was ein Screenreader-Test nicht beweist

Auch wenn alles gut funktioniert:

Ein eigener Test beweist nicht automatisch vollständige Barrierefreiheit.

Dafür gibt es mehrere Gründe.

Du kennst die Website bereits.

Du weißt, wo sich Dinge befinden.

Du siehst während des Tests möglicherweise trotzdem den Bildschirm.

Du verwendest vielleicht nur einen Screenreader und einen Browser.

Ein echter Nutzer hat einen anderen Erfahrungshintergrund.

Deshalb sollte der Selbsttest als wichtiger Bestandteil einer größeren Prüfung verstanden werden.

Trotzdem: Screenreader-Tests verändern den Blick auf Webseiten

Nach dem ersten richtigen Screenreader-Test passiert häufig etwas Interessantes.

Du schaust Websites danach anders an.

Ein Icon-Button?

Du fragst dich:

Wie heißt der eigentlich technisch?

Ein Produktbild?

Was würde davon vorgelesen?

Eine Fehlermeldung?

Bekommt ein Screenreader überhaupt mit, dass sie erschienen ist?

Ein Popup?

Wo landet der Fokus?

Genau dieses Denken ist extrem wertvoll.

Barrierefreiheit wird dadurch weniger zu einer Liste abstrakter WCAG-Regeln und mehr zu einer Frage der tatsächlichen Nutzung.

Fazit: Einfach einschalten und zuhören

Viele Websitebetreiber haben Respekt vor dem ersten Screenreader-Test.

Das ist verständlich.

Die Bedienung ist zunächst ungewohnt und die Sprachausgabe kann am Anfang überwältigend wirken.

Aber du musst nicht sofort alle Tastenkombinationen beherrschen.

Beginne klein.

Öffne eine wichtige Seite.

Hör dir den Seitentitel an.

Springe durch die Überschriften.

Prüfe Links und Buttons.

Öffne ein Formular.

Erzeuge absichtlich einen Fehler.

Und bei einem Online-Shop:

Versuche eine echte Bestellung bis zum letzten Schritt durchzuführen.

Schon dabei wirst du Dinge hören, die dir vorher wahrscheinlich nie aufgefallen sind.

Genau deshalb ist der Screenreader-Test eine so wertvolle Ergänzung zu Lighthouse, WAVE und axe DevTools.

Automatische Tools zeigen dir:

Was technisch auffällig ist.

Der Screenreader zeigt dir:

Was davon tatsächlich beim Nutzer ankommt.

Und am Ende ist genau das die entscheidende Frage.

Nicht:

„Hat mein Tool 100 Punkte angezeigt?“

Sondern:

„Kann ein Mensch die Website verstehen und benutzen, auch wenn er den Bildschirm nicht sieht?“

Wenn du diese Frage regelmäßig praktisch testest, bist du beim Thema Barrierefreiheit bereits einen großen Schritt weiter.

Hinweis: Ein eigener Screenreader-Test bietet eine wertvolle praktische Orientierung, ersetzt aber keine vollständige fachliche Accessibility-Prüfung und keine Tests mit Menschen, die Screenreader im Alltag verwenden.