Barrierefreiheit von Websites testen: automatisch vs. manuell

Die Barrierefreiheit einer Website testest du in zwei Ebenen: ein automatischer Scan, der schnell die messbaren Fehler findet, und eine manuelle Prüfung für alles, was ein Mensch beurteilen muss. Automatische Tools wie axe-core, Lighthouse und WAVE finden fehlende Beschriftungen, leere Links und fehlerhaftes ARIA. Ob ein Alt-Text stimmt, ob dein Checkout nur mit der Tastatur funktioniert und ob ein Screenreader dein Formular logisch vorliest, sieht kein einziges Tool.

Dieser Artikel gehört zu unserem vollständigen Leitfaden zur Barrierefreiheit von Websites. Hier bekommst du ein ehrliches Bild davon, was automatische Tools können und was nicht, eine manuelle Testroutine in Schritten, die offizielle Evaluationsmethode des W3C und eine Empfehlung, wie oft du testen solltest.

Der Maßstab, gegen den du testest, ist WCAG, die Web Content Accessibility Guidelines des W3C. In Europa gilt meist Stufe AA als Ziel. Welche Anforderungen genau darunter fallen, liest du in WCAG 2.2 erklärt.

#Was können automatische Tools?

Automatische Barrierefreiheitstools prüfen Regeln, die sich objektiv aus dem Code ableiten lassen, etwa ob ein Bild ein alt-Attribut hat oder ein Eingabefeld eine Beschriftung. Sie sind schnell, wiederholbar und eignen sich dafür, bei jedem Release zu laufen. Drei Tools begegnen dir am häufigsten.

axe-core ist die Open-Source-Testbibliothek von Deque. Laut der README auf GitHub hat axe-core Regeln für WCAG 2.0, 2.1 und 2.2 auf Stufe A, AA und AAA, dazu Regeln für Best Practices. Deque strebt null Fehlalarme an: Ein Fehler, den axe-core meldet, ist grundsätzlich auch wirklich ein Fehler. Zweifelsfälle markiert axe-core als "incomplete", mit dem Hinweis, dass eine manuelle Beurteilung nötig ist.

Lighthouse ist in die Chrome DevTools eingebaut. Laut der Dokumentation zur Score-Berechnung ist der Barrierefreiheits-Score ein gewichteter Durchschnitt automatischer Audits, mit Gewichtungen auf Basis der Auswirkungseinschätzung von axe. Jedes Audit verweist auf eine axe-core-Regel. Manuelle Prüfungen nennt Lighthouse separat, aber sie fließen nicht in den Score ein.

WAVE von WebAIM zeigt Fehler und Hinweise als Symbole auf deiner Seite. Die Browsererweiterung testet die Seite so, wie sie in deinem Browser dargestellt wird, also auch nach dem Ausführen von JavaScript. Die Hilfeseite von WAVE sagt es selbst deutlich: WAVE kann dir nicht sagen, ob deine Inhalte barrierefrei sind, das kann nur ein Mensch entscheiden.

Wie viele Probleme findet ein automatisches Tool? Deque veröffentlichte 2021 eine eigene Untersuchung auf Basis von gut 2.000 Audits. Laut Deque deckte automatisches Testen mit axe im Schnitt 57 Prozent der Anzahl gefundener Probleme ab. Zwei Einschränkungen: Es ist eine Untersuchung des Anbieters selbst, und sie zählt Probleme nach Menge, nicht nach Erfolgskriterien. Häufige Fehler fallen also stark ins Gewicht. Für deine Website kann der Anteil höher oder niedriger ausfallen.

#Was können automatische Tools nicht?

Automatische Tools können nicht beurteilen, ob etwas verständlich, logisch oder benutzbar ist, und genau dort liegen viele der größten Barrieren. Ein paar Beispiele, die kein Scanner zuverlässig erfasst:

• Qualität des Alt-Texts. Ein Tool sieht, dass ein Alt-Text vorhanden ist, aber nicht, ob "IMG_4032.jpg" oder "Bild" das Foto beschreibt.
• Tastaturbedienung eigener Komponenten. Ein Aufklappmenü, das nur auf einen Mausklick reagiert, oder ein Pop-up, in dem der Fokus stecken bleibt, bemerkst du erst, wenn du es selbst ausprobierst.
• Logische Fokus- und Lesereihenfolge. Der Code kann gültig sein, während der Fokus vom Header zum Footer springt.
• Sinnvolle Fehlermeldungen. Ein Tool sieht nicht, ob "Ungültige Eingabe" dem Besucher hilft, das Problem zu lösen.
• Verhalten beim Zoomen und Reflow. Überlappender Text oder abgeschnittene Buttons bei 400 Prozent Zoom siehst du nur auf dem Bildschirm.
• Inhalte, die erst per JavaScript erscheinen, wenn das Tool nur das rohe HTML liest.

Der Farbkontrast liegt dazwischen. axe-core hat eine Kontrastregel, aber die funktioniert nur auf einer tatsächlich dargestellten Seite. Text auf einem Hintergrundbild oder Verlauf ergibt oft ein "incomplete". Miss den Kontrast deshalb auch manuell mit einem Kontrastmesser.

#Automatisch oder manuell: nach Art der Prüfung

Je nach Art der Prüfung unterscheidet sich stark, wie viel ein automatisches Tool feststellen kann. Diese Tabelle gibt einen praktischen Überblick über die häufigsten Prüfungen.

Das Fazit aus der Tabelle: Automatisches Testen ist ein guter erster Filter, aber ein großer Teil der Kriterien verlangt menschliches Urteil. Eine Übersicht der Fehler, die wir in beiden Ebenen am häufigsten sehen, findest du unter häufigste Barrierefreiheitsfehler.

#Eine manuelle Testroutine in Schritten

Ein manueller Basistest braucht keine Spezialsoftware und findet genau die Probleme, die Scanner übersehen. Geh diese Schritte für jeden Seitentyp durch: Startseite, Kategorie, Produkt, Formular und Checkout.

1. Leg die Maus weg. Navigiere mit Tab, Umschalt+Tab, Enter, Leertaste und den Pfeiltasten. Erreichst du jeden Link, jeden Button und jedes Feld? Ist der Fokus immer sichtbar? Kannst du Menüs, Pop-ups und das Cookie-Banner öffnen und wieder schließen, ohne festzustecken?
2. Prüfe die Reihenfolge. Folgt der Fokus der visuellen Lesereihenfolge? Beginnt die Seite mit einem Skiplink zum Hauptinhalt?
3. Zoome auf 200 Prozent. Nutze den Zoom deines Browsers. Laut WCAG 2.2 (Kriterium 1.4.4) muss sich Text bis auf 200 Prozent vergrößern lassen, ohne dass Inhalt oder Funktion verloren gehen.
4. Teste Reflow bei 400 Prozent. Zoome in einem 1280 Pixel breiten Fenster auf 400 Prozent; das entspricht 320 CSS-Pixeln. Kriterium 1.4.10 verlangt, dass der Inhalt dann ohne horizontales Scrollen lesbar bleibt, außer bei Inhalten wie Tabellen oder Karten.
5. Miss den Kontrast. Nutze einen Kontrastmesser oder den Farbwähler in den DevTools. Normaler Text braucht mindestens 4,5:1, großer Text 3:1 (Kriterium 1.4.3).
6. Hör mit einem Screenreader zu. Nutze NVDA unter Windows oder VoiceOver auf Mac oder iPhone. Geh die Überschriften durch, öffne ein Formular und schick es mit einem Fehler ab. Werden Beschriftungen, Pflichtfelder und Fehlermeldungen vorgelesen?
7. Prüfe Formulare separat. Haben Felder sichtbare Beschriftungen, stimmen die Autocomplete-Werte und erscheint eine Fehlermeldung als Text beim richtigen Feld? Mehr dazu in barrierefreie Formulare und Checkout.
8. Notiere, was du findest. Schreib für jedes Problem die Seite, das Kriterium, die Schritte zum Reproduzieren und den Schweregrad auf. Diese Liste nutzt du auch, wenn du deine Barrierefreiheitserklärung erstellen willst.

Als ersten Einstieg kannst du auch den Easy Checks des W3C folgen. Die warnen selbst, dass eine Seite diese schnellen Checks bestehen und trotzdem noch große Barrieren haben kann.

#Die WCAG-EM-Methode des W3C

WCAG-EM ist die Evaluationsmethode des W3C, um festzustellen, inwieweit eine Website oder ein digitales Produkt WCAG erfüllt. Laut der Übersichtsseite des W3C wurde WCAG-EM 2 am 23. Juli 2026 als W3C Group Note veröffentlicht. Die Methode fügt WCAG keine neuen Anforderungen hinzu, sondern beschreibt, wie du eine Bewertung aufbaust. Version 2 erweitert den Ansatz von Websites auf Apps und andere digitale Produkte.

Die Methode hat fünf Schritte:

1. Umfang festlegen: Was fällt unter die Bewertung, was ist das Ziel und welche Stufe (A, AA oder AAA)?
2. Produkt erkunden: Welche wichtigen Ansichten, Funktionen, Inhaltsarten und Technologien gibt es?
3. Repräsentative Stichprobe wählen: eine strukturierte Auswahl, ergänzt um zufällige Seiten, wenn du nicht alles testen kannst.
4. Stichprobe evaluieren: Prüfe jede Seite gegen die Erfolgskriterien und halte fest, wie du getestet hast.
5. Ergebnisse berichten: Fass die Ergebnisse zusammen und formuliere deine Schlussfolgerungen.

Das W3C bietet dafür ein kostenloses WCAG-EM Report Tool an. Für einen Onlineshop ist Schritt 3 der wichtigste: Nimm auf jeden Fall den vollständigen Bestellprozess auf, von der Produktseite bis zur Bestätigung.

#Testen mit Menschen mit Behinderung

Nutzertests mit Menschen mit Behinderung finden Usability-Probleme, die eine Konformitätsprüfung nach WCAG nicht ans Licht bringt. Das W3C gibt in Involving Users in Evaluating Web Accessibility ein paar klare Empfehlungen.

• Behebe zuerst die offensichtlichen Fehler, damit Tester nicht an etwas hängen bleiben, das du selbst hättest finden können.
• Bezieh Nutzer schon während der Entwicklung ein, nicht erst am Ende.
• Geh nicht davon aus, dass eine Person für alle mit derselben Behinderung spricht.
• Kombiniere Nutzertests immer mit einer Bewertung nach WCAG, denn Nutzertests allein bestimmen nicht, ob deine Website die Anforderungen erfüllt.

Für einen Onlineshop im Mittelstand muss das keine große Studie sein. Drei oder vier Sitzungen, in denen jemand mit Screenreader, Vergrößerungssoftware oder nur mit Tastatur ein Produkt bestellt, liefern oft schon konkrete Verbesserungspunkte.

#Wie oft testest du?

Wie oft du testest, hängt davon ab, wie oft sich deine Website ändert, aber ein fester Zyklus in drei Ebenen funktioniert für die meisten Unternehmen.

Achte vor allem auf Änderungen, die an deinem Entwicklungsteam vorbeigehen. Ein neues Chat-Widget, ein anderes Cookie-Banner oder ein Bezahlschritt eines externen Anbieters kann eine barrierefreie Website auf einen Schlag weniger barrierefrei machen.

#Wo Flowproof in diesen Prozess passt

Flowproof ist die automatische erste Ebene, kein Ersatz für manuelles Testen. Die Barrierefreiheitsprüfung führt axe-core auf dem HTML deiner Seite aus und prüft gegen WCAG 2.0, 2.1 und 2.2 auf Stufe A und AA. Für jede gefundene Regel siehst du das Erfolgskriterium, die Stufe und den Schweregrad.

Was der Scan bewusst nicht macht: Farbkontrast automatisch messen. Dafür ist eine echte Darstellung im Browser nötig, deshalb meldet Flowproof Kontrast als manuell zu prüfen. Baut deine Seite den Inhalt erst per JavaScript auf, warnt der Scan, dass nur das Basis-HTML getestet wurde. Außerdem prüft Flowproof, ob du einen Link zu einer Barrierefreiheitserklärung hast, ob es einen Skiplink gibt und ob Audio automatisch abgespielt wird. Der Barrierefreiheits-Score ist unabhängig vom GEO-Score.

#So prüfst du das auf deiner eigenen Website

1. Lass einen automatischen Scan laufen auf deiner Startseite, einer Kategorieseite, einer Produktseite, deinem Kontaktformular und jedem Schritt des Checkouts.
2. Behebe zuerst die Fehler mit dem höchsten Schweregrad, etwa fehlende Beschriftungen und Buttons ohne Namen.
3. Geh die manuelle Routine aus diesem Artikel auf denselben Seiten durch: Tastatur, Zoom 200 Prozent, Reflow 400 Prozent, Kontrast und ein Screenreader.
4. Halte deine Ergebnisse fest mit Seite, Kriterium und Schweregrad, und nimm bekannte Probleme in deine Barrierefreiheitserklärung auf.
5. Plane die nächste Runde: automatisch bei jedem Release, manuell bei neuen Bestandteilen und einmal im Jahr eine vollständige Bewertung nach WCAG-EM.

Die Barrierefreiheitsprüfung von Flowproof ist in den kostenpflichtigen Tarifen Pro und Business enthalten. Du kannst kostenlos starten und die Tarife auf der Preisseite vergleichen.