Website auf Barrierefreiheit testen: Automatischer Check und manuelle Prüfung

Wenn man sich mit digitaler Barrierefreiheit beschäftigt, kommt man an automatisierten Tools kaum vorbei. Aber was bringen diese Tools eigentlich? Und können sie den manuellen Testaufwand wirklich verringern?

Dieser Beitrag ist kein vollständiger WCAG-Audit und keine Rechtsberatung. Er zeigt, wie man automatisierte Tests sinnvoll einsetzt, wo ihre Grenzen liegen und warum eine manuelle Prüfung trotzdem notwendig bleibt.

Kurz gesagt

Automatisierte Tests sind der niederschwelligste Einstieg in das Thema. Sie decken aber nur einen Teil möglicher Barrieren ab. Manuelle Prüfungen bleiben immer erforderlich.

Automatisierte Tests sind gut für:

• eine erste Einschätzung des Zustands
• konkrete Hinweise zu technisch erkennbaren Problemen
• einen schnellen Überblick über mehrere Seiten
• wiederholbare Prüfungen nach Änderungen

Ihre Grenzen liegen vor allem dort, wo Kontext, Sprache, Nutzungslogik oder visuelle Wahrnehmung eine Rolle spielen.

Automatisierte Tests können zum Beispiel nicht sicher beurteilen:

• Ist die Seite in Inhalt und Struktur verständlich?
• Sind sichtbare Elemente auch technisch zugänglich?
• Gibt es Elemente, die visuell versteckt sind, aber trotzdem vorgelesen oder fokussiert werden?
• Werden Animationen verwendet, die Nutzer:innen vom Inhalt ablenken?
• Ist die Seitennavigation mit Tastatur, Screenreader und assistiven Technologien wirklich sinnvoll möglich?
• Funktionieren wichtige Nutzerflüsse wie Kontaktformular, Checkout, Login oder Buchung in der Praxis?

Deshalb ist eine manuelle Prüfung in der Regel sinnvoll und in manchen Fällen, je nach Website und rechtlichen Anforderungen, auch klar notwendig.

Schritt 1: Automatischen Check starten

Zu Beginn kann man mit automatisierten Tools viele Ergebnisse in kurzer Zeit finden. Dabei helfen Tools wie Google Lighthouse direkt in den Browser-Entwicklertools, die Axe Platform oder mein hauseigenes Tool barrieretest.at.

Der angebotene Funktionsumfang unterscheidet sich von Anbieter zu Anbieter. Für den ersten Einstieg reichen kostenlose Testergebnisse aber meist aus. Für einen bezahlten automatisierten Prüfbericht lohnt es sich vor allem dann, wenn mehrere Seiten und Nutzerflüsse gleichzeitig analysiert werden können oder wenn das Ergebnis deutlich bessere Handlungsempfehlungen liefert.

Für den ersten Eindruck genügt häufig ein kostenloses Angebot wie barrieretest.at.

Sobald die wichtigsten Seiten automatisch getestet wurden, beginnt die eigentliche Arbeit: die Ergebnisse verstehen, priorisieren und durch manuelle Tests ergänzen.

Schritt 2: Ergebnisse verstehen

Die meisten automatisierten Tools stellen nach dem Test eine Liste von Problemen dar. Diese Probleme sind oft nach Schweregrad oder nach ihrer Position auf der Seite sortiert. Häufig wird auch ein sogenannter Selektor angezeigt, mit dem das betroffene Element im Code gefunden werden kann.

Üblicherweise wird außerdem ein Kriterium auf Basis der Web Content Accessibility Guidelines (WCAG) angegeben, das beim betroffenen Element verletzt wurde. Da viele Tools auf der kostenlosen axe-core-Bibliothek von Deque basieren, verlinken sie häufig auch auf die Detailbeschreibungen von Axe.

Zum besseren Verständnis der Kriterien gibt es zahlreiche Ressourcen in einfacherer Sprache, zum Beispiel das Nachschlagewerk von Gehirngerecht Digital, das WCAG-Kartendeck von Johannes Lehner oder das englische WCAG in Plain English von Aaardvark.

Wenn die automatisiert gefundenen Probleme grob verstanden sind, geht es mit den einfachsten und schnellsten manuellen Tests weiter. Für diese Punkte habe ich bereits einen konkreten Leitfaden zum Testen von Barrierefreiheit für Unternehmen geschrieben und fasse sie hier nur kurz zusammen.

Schritt 3: Tastatur-Navigation testen

Bedienelemente sollten nicht nur per Maus funktionieren. Navigation, Menüs, Buttons, Formulare, Modals, Cookie-Banner, Checkout-Prozesse, Buchungsportale und Kontaktformulare sollten auch mit der Tastatur bedienbar sein.

Der einfachste Test: Maus weglegen und nur mit der Tastatur durch die Seite navigieren.

Tab springt von Element zu Element.
Shift + Tab springt zurück.
Enter oder Leertaste aktiviert Elemente.

Der Fokus muss dabei immer sichtbar bleiben. Man darf sich auf der Seite nicht verlieren, nicht in einem Element stecken bleiben und nicht an eine Stelle springen, die visuell oder logisch keinen Sinn ergibt.

Schritt 4: Screenreader-Test durchführen

Hier geht es um den Teil der Seite, der nicht über das visuelle Layout vermittelt wird. Also zum Beispiel: Werden Überschriften auch technisch als Überschriften erkannt? Haben relevante Bilder sinnvolle Alternativtexte? Werden Buttons, Links und Formularfelder verständlich vorgelesen?

Wie man das konkret am eigenen Rechner ohne viel Aufwand überprüfen kann, beschreibe ich in Screenreader-Test selbst durchführen: So klingt deine Website.

Schritt 5: Formulare und kritische Nutzerflüsse prüfen

Die meisten Websites verfolgen ein Ziel. Nutzer:innen sollen Informationen finden, etwas kaufen, etwas buchen, ein Formular ausfüllen oder eine Kombination aus mehreren Dingen erledigen. Diese Workflows sollten zuerst definiert und anschließend gezielt getestet werden.

Für ein klassisches E-Commerce-Unternehmen bedeutet das unter anderem:

• Startseite: Kommen Nutzer:innen zur Suche oder zur Auswahl von Kategorien?
• Filter: Kann man Ergebnisse sinnvoll filtern oder nach einzelnen Produkten suchen?
• Login: Ist der gesamte Login-Bereich auch mit Tastatur bedienbar?
• Warenkorb: Können Produkte hinzugefügt, entfernt und geändert werden?
• Checkout: Kann der Kauf vollständig abgeschlossen werden?
• Fehlermeldungen: Verstehen Nutzer:innen, was passiert ist und wie sie den Fehler beheben können?

Diese Komplexität zeigt, warum automatisiertes Testen hier nur begrenzt hilft. Ein Tool kennt das konkrete Ziel des Unternehmens und den erwarteten Nutzerfluss meistens nicht. Es kann einzelne technische Probleme finden, aber nicht zuverlässig beurteilen, ob ein echter Prozess für echte Nutzer:innen funktioniert.

Was ein Tool gut findet

Automatisierte Tools sind mittlerweile sehr gut darin, fehlende Alternativattribute aufzudecken, bestimmte Kontraste zu prüfen und Teile der semantischen Struktur einer Seite zu analysieren.

Sie finden zum Beispiel häufig:

• Bilder ohne alt-Attribut
• Formularfelder ohne Label
• Buttons ohne zugänglichen Namen
• Links ohne verständlichen Text
• bestimmte Kontrastprobleme
• problematische ARIA-Verwendung
• fehlende Dokument-Sprache
• strukturelle HTML-Probleme

Hier kann viel Zeit eingespart werden, wenn man mit einem automatisierten Test startet, der die Ergebnisse gleich als Liste darstellt.

KI-gestützte Tests wie der optionale KI-Test von barrieretest.at können zusätzlich Hinweise liefern, etwa ob ein Seitentitel zum Inhalt passt oder welcher Alternativtext zu einem Bild passen könnte.

Trotzdem bleibt auch hier menschliche Bewertung wichtig. KI kann Vorschläge liefern, aber nicht sicher wissen, welche Information im konkreten Kontext wirklich relevant ist.

Was kein Tool sicher beurteilen kann

Ein automatisiertes Tool kann nur das prüfen, was technisch eindeutig erkennbar ist. Viele Barrieren entstehen aber nicht nur durch falschen Code, sondern durch fehlenden Kontext, unklare Sprache, schlechte Abläufe oder visuelle Entscheidungen.

Ein Tool kann erkennen, ob ein Bild ein alt-Attribut hat. Es kann aber nicht zuverlässig beurteilen, ob der vorhandene Alt-Text im konkreten Zusammenhang hilfreich ist.

Ein Tool kann erkennen, ob ein Button einen zugänglichen Namen hat. Es kann aber nicht sicher beurteilen, ob dieser Name für Nutzer:innen verständlich genug ist.

Ein Tool kann prüfen, ob ein Formularfeld technisch mit einem Label verbunden ist. Es kann aber nicht vollständig bewerten, ob das Formular in einem echten Nutzerfluss logisch, verständlich und fehlertolerant ist.

Beispiele

Automatisch prüfbar:

Ein Bild hat kein alt-Attribut.

Manuell zu bewerten:

Ist der vorhandene Alternativtext im Kontext sinnvoll, oder ist er nur formal vorhanden?

Automatisch prüfbar:

Ein Formularfeld hat kein Label.

Manuell zu bewerten:

Versteht eine Person, was sie eingeben soll, welche Felder verpflichtend sind und wie sie einen Fehler beheben kann?

Automatisch prüfbar:

Ein Button hat keinen zugänglichen Namen.

Manuell zu bewerten:

Ist der Buttontext im jeweiligen Kontext eindeutig genug?

Automatisch prüfbar:

Ein Kontrastwert zwischen Text und Hintergrund ist zu niedrig.

Manuell zu bewerten:

Sind auch Zustände wie Fokus, Hover, Fehler, deaktivierte Buttons oder Hinweise ausreichend erkennbar?

Automatisch prüfbar:

Eine Seite enthält Überschriften.

Manuell zu bewerten:

Ergibt die Überschriftenstruktur inhaltlich Sinn, oder wurde sie nur optisch beziehungsweise technisch irgendwie gesetzt?

Bei komplexeren Komponenten erkennt ein Tool oft nur Symptome. Ein Modal kann formal korrekt ausgezeichnet sein, aber der Tastaturfokus landet trotzdem an der falschen Stelle. Ein Cookie-Banner kann sichtbar sein, aber mit Tastatur nicht zuverlässig geschlossen werden. Ein Formular kann technisch aus Labels und Feldern bestehen, aber nach einem Fehler keine verständliche Orientierung geben.

Deshalb sollte man automatisierte Testergebnisse nicht als endgültiges Urteil lesen, sondern als Startpunkt für die eigentliche Prüfung.

Ergebnisse richtig priorisieren

Der häufigste Fehler nach einem automatisierten Test ist, die Ergebnisliste einfach von oben nach unten abzuarbeiten. Das wirkt strukturiert, ist aber nicht immer sinnvoll.

Besser ist es, zuerst die Auswirkungen auf Nutzer:innen und auf das Ziel der Website zu bewerten.

Wichtige Fragen sind:

• Blockiert das Problem einen zentralen Nutzerfluss?
• Betrifft es viele Seiten oder nur eine einzelne Stelle?
• Betrifft es Navigation, Formulare, Checkout, Login oder Kontaktaufnahme?
• Ist das Problem für Tastatur- oder Screenreader-Nutzer:innen ein echter Blocker?
• Ist die Behebung technisch einfach und schnell möglich?
• Entsteht das Problem in einer wiederverwendeten Komponente?

Ein Beispiel: Dreißig fehlende Alternativtexte auf rein dekorativen Bildern sind meist weniger dringend als ein unsichtbarer Tastaturfokus im Hauptmenü.

Ein anderes Beispiel: Ein einzelnes fehlerhaftes Formularfeld auf einer selten besuchten Unterseite kann relevant sein. Ein Cookie-Banner, der per Tastatur nicht geschlossen werden kann, ist aber deutlich kritischer, weil er potenziell die gesamte Website blockiert.

Ich würde Probleme daher grob in diese Reihenfolge bringen:

1. Blocker in zentralen Nutzerflüssen
   Alles, was Navigation, Kontakt, Kauf, Buchung, Login oder Formularabschluss verhindert.

2. Globale Komponenten
   Header, Navigation, Footer, Cookie-Banner, Modals, Suchfunktion, wiederverwendete Formulare und Design-System-Komponenten.

3. Technisch einfache Fehler mit großer Wirkung
   Fehlende Labels, leere Buttons, fehlende Dokument-Sprache, grobe Kontrastprobleme oder kaputte Überschriftenstruktur.

4. Redaktionelle und inhaltliche Verbesserungen
   Bessere Linktexte, sinnvollere Alternativtexte, klarere Fehlermeldungen und verständlichere Struktur.

5. Feinschliff und laufende Optimierung
   Details, die nicht blockieren, aber die Nutzung angenehmer, verständlicher oder robuster machen.

Wie oft sollte man testen?

Barrierefreiheit ist kein einmaliger Zustand. Websites ändern sich laufend: neue Inhalte, neue Plugins, neue Formulare, neue Komponenten, neue Kampagnen, neue Cookie-Banner oder neue Tracking-Skripte.

Deshalb lohnt es sich, nicht nur einmal vor dem Launch zu testen.

Sinnvoll sind Tests besonders:

• vor einem Relaunch
• nach größeren Designänderungen
• wenn neue Formulare oder Buchungsstrecken eingeführt werden
• wenn ein neues Cookie-Banner oder Tracking-Tool eingebaut wird
• wenn neue Templates oder Komponenten entstehen
• wenn ein automatisierter Test plötzlich viele neue Probleme zeigt
• regelmäßig bei geschäftskritischen Websites, Shops oder Portalen

Ein automatisierter Test eignet sich gut als wiederholbarer Schnellcheck. Er zeigt, ob neue technische Probleme entstanden sind. Die manuelle Prüfung zeigt danach, ob die wichtigsten Abläufe wirklich funktionieren.

Fazit

Automatisierte Barrierefreiheitstests sind sinnvoll, aber sie sind kein Ersatz für eine manuelle Prüfung.

Sie helfen dabei, technische Probleme schnell sichtbar zu machen, erste Hinweise zu sammeln und die Arbeit zu strukturieren. Genau dafür sollte man sie nutzen.

Die entscheidende Frage bleibt aber immer:

Können echte Nutzer:innen die wichtigsten Inhalte und Funktionen tatsächlich verwenden?

Diese Frage lässt sich nicht vollständig automatisieren. Dafür braucht es Tastaturtests, Screenreader-Tests, manuelle Bewertung, Verständnis für Nutzerflüsse und manchmal auch professionelle Unterstützung.

Wer mit einem Tool startet, macht also nichts falsch. Wichtig ist nur, danach nicht aufzuhören.

Nächster Schritt

Wenn du einen ersten Überblick möchtest, starte mit einem automatisierten Check:

Kostenlosen Barrierefreiheits-Check auf barrieretest.at starten

Wenn du wissen möchtest, welche Probleme wirklich kritisch sind und wie du sie sinnvoll behebst, ist eine manuelle Prüfung der nächste Schritt:

WCAG-Audit und Barrierefreiheitsprüfung bei Solasit ansehen