Selbst testen mit Tastatur und Screenreader

Automatische Prüfwerkzeuge sind ein guter Anfang. Sie finden fehlende Alternativtexte, zu schwache Kontraste und unbeschriftete Formularfelder in Sekunden. Aber sie finden nur einen Teil der Barrieren – Schätzungen zufolge zwischen einem Viertel und gut der Hälfte, je nach Werkzeug und Zählweise. Ob sich ein Menü mit der Tastatur bedienen lässt, ob der Fokus nach dem Öffnen eines Dialogs an der richtigen Stelle landet oder ob ein Alternativtext sinnvoll ist, kann keine Software zuverlässig beurteilen.

Die gute Nachricht: Für die wichtigsten manuellen Tests braucht es weder teure Software noch Expertenwissen. Eine Tastatur und ein kostenloser Screenreader genügen. Diese Lektion zeigt, wie Sie in einer halben Stunde einen aussagekräftigen Eindruck von Ihrer Website bekommen.

1. Automatisch prüfen – und die Grenzen kennen

Beginnen Sie mit einer automatischen Prüfung, etwa mit unserem Barrierefreiheits-Check, mit Lighthouse in den Entwicklerwerkzeugen von Chrome oder mit Browser-Erweiterungen wie axe DevTools oder WAVE. Diese Werkzeuge liefern eine Fehlerliste mit Hinweisen, wo das Problem im Quelltext liegt. Ein hoher Punktwert bedeutet aber nicht, dass eine Website barrierefrei ist – er bedeutet nur, dass die maschinell prüfbaren Fehler fehlen.

2. Der Tastaturtest

Viele Menschen können keine Maus benutzen: Menschen mit motorischen Einschränkungen, die mit Tastatur, Schaltern oder Sprachsteuerung arbeiten, und blinde Menschen, die mit dem Screenreader über die Tastatur navigieren. Wer seine Website ohne Maus bedienen kann, hat deshalb eine der wichtigsten Hürden genommen. Legen Sie die Maus zur Seite und nutzen Sie nur diese Tasten:

Achten Sie auf vier Dinge. Erstens: Sehen Sie jederzeit, wo Sie sind? Viele Designs entfernen den Fokusrahmen, weil er als unschön gilt – damit ist die Tastaturbedienung praktisch unmöglich. Zweitens: Ist die Reihenfolge logisch, also meist von oben links nach unten rechts? Drittens: Erreichen Sie alles, auch Untermenüs, Schieberegler und den Cookie-Banner? Viertens: Kommen Sie überall wieder heraus, oder bleiben Sie in einem Element gefangen, einer sogenannten Tastaturfalle?

3. Der Screenreader-Test

Den Screenreader haben Sie wahrscheinlich schon auf Ihrem Gerät. Auf dem Mac starten Sie VoiceOver mit Befehl + F5, unter Windows installieren Sie das kostenlose NVDA. Beim ersten Mal ist die Bedienung ungewohnt, und die Sprachausgabe klingt schnell – das ist normal. Konzentrieren Sie sich auf wenige Aufgaben: Rufen Sie die Liste der Überschriften auf (bei NVDA mit Einfügen + F7, bei VoiceOver über den Rotor mit Steuerung + Option + U) und prüfen Sie, ob sie die Seite sinnvoll gliedert. Springen Sie zu Bildern und Knöpfen und hören Sie, was vorgelesen wird. Füllen Sie ein Formular aus und achten Sie darauf, ob jedes Feld angesagt wird.

4. Testen Sie Ihre eigene Website

Öffnen Sie Ihre Website in einem zweiten Fenster und gehen Sie die Schritte durch. Notieren Sie bei jeder Barriere, auf welcher Seite sie auftritt und was genau passiert.

5. Befunde priorisieren

Am Ende steht eine Liste von Barrieren. Nicht alle sind gleich wichtig. Zuerst beheben Sie, was Nutzer vollständig blockiert: ein Bestellknopf, der sich nicht per Tastatur auslösen lässt, ein Formularfeld ohne Beschriftung im Bestellprozess, ein Cookie-Banner, der die ganze Seite sperrt und nicht schließbar ist. Danach kommt, was die Nutzung stark erschwert, etwa ein fehlender Fokusrahmen oder unlogische Überschriften. Kosmetische Probleme folgen zum Schluss. Wichtig ist außerdem, Barrierefreiheit in den Alltag zu bringen: Jede neue Seite und jede neue Funktion sollte vor der Veröffentlichung kurz per Tastatur getestet werden. Das kostet Minuten und verhindert, dass sich wieder neue Barrieren einschleichen.

6. Mobil testen und Befunde festhalten

Ein großer Teil der Nutzer ist mobil unterwegs, und auch Screenreader werden auf dem Smartphone intensiv genutzt. VoiceOver auf dem iPhone und TalkBack auf Android funktionieren mit Wischgesten: Ein Wisch nach rechts springt zum nächsten Element, ein Doppeltipp aktiviert es. Ein kurzer Test auf dem eigenen Handy zeigt oft Probleme, die am Computer nicht auffallen, etwa zu kleine Schaltflächen, Menüs, die sich nicht schließen lassen, oder Inhalte, die nur beim Überfahren mit der Maus erscheinen und auf dem Touchscreen gar nicht erreichbar sind. Die WCAG 2.2 verlangen für Bedienelemente eine Mindestgröße der Zielfläche von 24 mal 24 Pixeln oder ausreichend Abstand zu benachbarten Elementen.

Gefundene Barrieren sollten so festgehalten werden, dass jemand anderes sie nachvollziehen kann. Ein gutes Protokoll enthält die Adresse der Seite, das betroffene Element, eine kurze Beschreibung dessen, was passiert, das verwendete Hilfsmittel samt Browser und, wenn möglich, das betroffene Erfolgskriterium der WCAG. Ein Screenshot hilft zusätzlich. So kann die Entwicklung den Fehler reproduzieren, beheben und nach der Behebung erneut prüfen.

Für die interne Organisation bietet sich eine einfache Tabelle oder ein Ticketsystem an, in dem jeder Befund mit Priorität und Zuständigkeit versehen wird. Die Ergebnisse fließen später auch in die Erklärung zur Barrierefreiheit ein: Dort wird beschrieben, welche Bereiche noch nicht vollständig zugänglich sind und bis wann sie verbessert werden. Wer regelmäßig testet, etwa vierteljährlich oder bei jedem größeren Update, erkennt Rückschritte früh und kann nachweisen, dass Barrierefreiheit ernst genommen wird. Besonders wertvoll ist es, von Zeit zu Zeit Menschen einzubeziehen, die Hilfsmittel täglich nutzen. Sie finden Probleme, die selbst erfahrene Prüfer übersehen, und zeigen, wo eine formal korrekte Lösung im Alltag trotzdem hakt.

Ein typischer Ablauf in einem kleinen Team sieht so aus: Eine Person übernimmt die Rolle der Ansprechperson für Barrierefreiheit, führt einmal im Quartal den Tastaturtest und einen kurzen Screenreader-Test auf den wichtigsten Seiten durch und trägt die Befunde in eine gemeinsame Liste ein. Die Entwicklung arbeitet die Liste nach Priorität ab und meldet zurück, wenn ein Punkt erledigt ist. So entsteht ohne großen Aufwand ein fortlaufender Nachweis, dass Barrieren erkannt und beseitigt werden – genau das, was auch eine Behörde im Fall einer Beschwerde sehen möchte.

Stand: September 2026. Kursmaterial der Klarwerk Akademie – vermittelt Grundlagen und ersetzt keine Rechtsberatung oder vollständige Prüfung nach WCAG und EN 301 549.