Wer Barrierefreiheit ernsthaft testen will, kommt um eine Erkenntnis nicht herum: Es gibt nicht den einen Test. Was tatsächlich funktioniert, ist die Kombination aus drei Ebenen – jede deckt einen Teil der Realität ab, den die anderen nicht erreichen. Wer nur eine Ebene wählt, bekommt nur einen Ausschnitt – und glaubt manchmal, das ganze Bild zu sehen. In diesem Ratgeber zur strukturierten Durchführung eines Barrierefreiheits-Tests zeige ich Ihnen, wie diese drei Ebenen zusammenspielen, welche Tools heute praktisch nutzbar sind und welche zehn Punkte Sie selbst in einer Stunde abhaken können, um eine erste ehrliche Standortbestimmung Ihrer Website zu machen.

Was ein Barrierefreiheits-Test ist und wozu er dient

Ein Barrierefreiheits-Test prüft, ob eine Website, App oder ein Dokument die Anforderungen anerkannter Standards erfüllt – im DACH-Raum sind das vor allem die WCAG 2.2 auf Konformitätsstufe AA und die ergänzenden Vorgaben der EN 301 549. Das Ziel ist doppelter Natur: Auf der einen Seite die rechtliche Absicherung gegenüber BFSG, BITV und EAA, auf der anderen Seite die tatsächliche Nutzbarkeit für alle Zielgruppen. Ein guter Test bewertet beides, sieht also nicht nur den Code, sondern auch die Bedienerfahrung. Genau deshalb funktioniert keine einzelne Methode allein – jede hat ihren spezifischen Blick und ihre Grenzen.

Die drei Test-Ebenen im Überblick

Stellen Sie sich die drei Ebenen wie konzentrische Kreise vor: Der Scanner deckt den breitesten, oberflächlichsten Bereich ab, die Expertenprüfung geht in die strukturelle Tiefe, der Test mit echten AT-Nutzern erreicht das, was Code allein nie zeigt.

Ebene 1: Automatisierte Scanner

Scanner prüfen den Code Ihrer Seite gegen Hunderte technischer Regeln in Sekunden. Sie finden fehlende Alt-Attribute, offensichtliche Kontrast-Verstöße bei Standard-Text, ungelabelte Formularfelder, kaputte Überschriftenhierarchien, fehlende Sprach-Attribute, ARIA-Syntax-Probleme. Sie machen das schnell, breit und reproduzierbar – ihre Stärke. Was sie nicht leisten: inhaltliche Beurteilung. Ein Scanner sieht, dass ein Alt-Text existiert, aber nicht, ob er das Bild sinnvoll beschreibt. Er sieht eine Live-Region im Code, aber nicht, ob sie zum richtigen Zeitpunkt ausgelöst wird. Realistisch erfassen Scanner etwa 30 bis 40 Prozent der WCAG-Kriterien. Das ist viel – und es ist deutlich weniger als „die ganze Wahrheit“.

Ebene 2: Manuelle Expertenprüfung

Hier kommt der menschliche Sachverstand ins Spiel. Eine Expertenprüfung geht strukturiert durch die WCAG-Kriterien, die ein Scanner nicht abdecken kann – inhaltliche Qualität von Alt-Texten und Linktexten, logische Lesereihenfolge bei komplexen Layouts, Sinnhaftigkeit von Fehlermeldungen, korrekte Tabellen-Header-Zuordnung, Verständlichkeit der Sprache. Geprüft wird mit Browser-Werkzeugen, Headings-Navigation, manuellen Tastatur-Walkthroughs und gezieltem Code-Review. Eine erfahrene Person erreicht damit die maschinell nicht prüfbaren 60 bis 70 Prozent der Kriterien – und zwar nicht oberflächlich, sondern in der Tiefe, in der WCAG-Konformität wirklich liegt. Die Grenze: Auch ein Experte simuliert oft nur, was ein Screenreader-Nutzer tatsächlich erlebt.

Ebene 3: Test mit echten AT-Nutzern

Die dritte Ebene ist die Ebene, die alles Vorhergehende durch die Realität prüft. Eine Person, die täglich mit JAWS, NVDA oder VoiceOver arbeitet, bedient Ihre Website wie ein echter Nutzer – mit dem trainierten Gefühl für Bedienfluss, mit der Geduld oder Ungeduld, mit der Erwartungshaltung eines tatsächlich Betroffenen. Diese Tests finden Dinge, die weder Scanner noch Experte sehen würden: Eine komplexe Komponente, die in der manuellen Prüfung „sauber“ aussah, aber im realen Bedienfluss verwirrt. Eine Reihenfolge, die logisch wirkte, aber in der praktischen Nutzung irritiert. Eine Tabelle, die formal korrekt ist, aber zu lang vorgelesen wird. Welche Unterschiede zwischen den Screenreadern dabei eine Rolle spielen, habe ich in JAWS, NVDA und VoiceOver: Wie echte Nutzer Ihre Website wirklich erleben ausführlich beschrieben.

Warum die Kombination zählt

Die drei Ebenen sind keine Alternativen, sondern Ergänzungen. Jede findet, was die anderen nicht finden können. Wer nur Ebene 1 fährt, bekommt eine grüne Ampel mit verstecktem Restrisiko. Wer auf Ebene 1 und 2 setzt, hat ein technisch fundiertes Bild – aber keine Aussage darüber, ob die Seite real bedienbar ist. Erst alle drei Ebenen zusammen liefern eine belastbare Bewertung. In der Audit-Praxis bedeutet das eine konkrete Reihenfolge: Zuerst der Scanner als breite Erstprüfung, dann die manuelle Expertenebene, schließlich der Test mit AT-Nutzern für die kritischen Pfade. Diese Reihenfolge spart Geld – Sie lassen die teure dritte Ebene nicht über Verstöße laufen, die schon in der ersten gefunden und behoben sind.

Tools im Überblick: Was Sie heute nutzen können

Die Werkzeuglandschaft ist überschaubar und gut etabliert. Diese Übersicht zeigt die für die Praxis wichtigsten Tools:

Wichtig zu verstehen: Diese Werkzeuge ergänzen sich. Axe DevTools und WAVE finden überlappende, aber nicht identische Mängel – wer beide nutzt, fängt mehr ab. Lighthouse ist ein netter Schnellcheck, aber zu oberflächlich für ernsthafte Prüfungen. NVDA als Selbsterprobung gibt Entwicklern ein Gefühl, ersetzt aber den echten Nutzertest nicht.

Die Schnell-Checkliste für den Einstieg

Wenn Sie heute eine Stunde Zeit haben und Ihre Website grob einschätzen wollen, gehen Sie diese zehn Punkte durch. Sie ersetzen keinen vollständigen Test, finden aber zuverlässig die häufigsten kritischen Mängel.

1. Maus weglegen. Tabben Sie zehn Minuten durch die Seite. Ist der Tastaturfokus immer sichtbar? Erreichen Sie jeden Button, jedes Formularfeld? Bleiben Sie irgendwo stecken?
2. Browser-Extension scannen. Installieren Sie axe DevTools oder WAVE, scannen Sie die wichtigsten Seiten Ihrer Site und notieren Sie die kritischen Mängel.
3. Auf 200 Prozent zoomen. Vergrößern Sie die Anzeige im Browser. Bleibt alles lesbar und nutzbar, oder zerfällt das Layout?
4. Auf 320 Pixel Breite verkleinern. Ziehen Sie das Browserfenster auf Smartphone-Breite. Funktioniert der Inhalt ohne horizontales Scrollen?
5. Mit Screenreader durchgehen. Aktivieren Sie NVDA oder VoiceOver und navigieren Sie zehn Minuten durch die Seite. Klingt sie verständlich?
6. Alt-Texte durchsehen. Klicken Sie sich durch und prüfen Sie, ob die Bildbeschreibungen aussagekräftig sind – oder ob Dateinamen, „Bild“ oder leere Werte stehen.
7. Linktexte durchsehen. Zählen Sie die „Mehr erfahren“- und „Hier klicken“-Links. Jeder davon ist ein Verstoß gegen WCAG 2.4.4.
8. Überschriften-Struktur prüfen. Nutzen Sie HeadingsMap, um die H1-H6-Hierarchie sichtbar zu machen. Gibt es Sprünge? Mehrere H1?
9. Formulare prüfen. Klicken Sie auf jedes Label – springt der Cursor ins Feld? Lösen Sie absichtlich einen Fehler aus – wird er sichtbar und für Screenreader hörbar gemeldet?
10. Cookie-Banner und Live-Chat testen. Diese Elemente sind die häufigsten Tastatur-Fallen. Können Sie sie per Tastatur bedienen und wieder verlassen?

Wenn Sie diese Liste ehrlich durchgehen, finden Sie auf den meisten Websites Mängel – oft mehr, als Sie erwartet hätten. Das ist normal. Es ist der Startpunkt, nicht das Versagen.

Was Sie als Selbst-Tester finden können – und was nicht

Die Schnell-Checkliste ist nützlich, hat aber Grenzen. Sie finden damit die offensichtlichen Strukturprobleme, fehlende Beschriftungen, kaputte Layouts und einen Teil der Tastaturfallen. Was Sie nicht zuverlässig finden: feinere ARIA-Probleme, die korrekte Header-Zuordnung in komplexen Tabellen, die zeitliche Korrektheit von Live-Region-Ankündigungen, Probleme, die nur in bestimmten Screenreader-Browser-Kombinationen auftreten, und die feinen Unterschiede zwischen JAWS, NVDA und VoiceOver. Auch Inhalte, die nur unter bestimmten Bedingungen erscheinen – Fehlermeldungen, dynamische Filter, eingeloggte Bereiche –, übersehen Selbst-Tests gerne, weil Tester nicht systematisch jeden Pfad abklappern. Ehrliche Selbst-Prüfungen sind wertvoll, sie sind aber kein Ersatz für einen vollständigen Test, der gerichtsfest dokumentiert.

Wann ein professionelles Audit nötig wird

Spätestens dann, wenn Ihre Website unter das BFSG fällt und Sie eine belastbare Erklärung zur Barrierefreiheit veröffentlichen müssen, reicht der Selbst-Test nicht mehr. Auch wenn das Risiko eines Verfahrens steigt – etwa nach einer Beschwerde, im Vorfeld eines Relaunch oder bei einem öffentlichen Ausschreibungs-Auftritt –, brauchen Sie eine professionelle Prüfung mit dokumentiertem Ergebnis. Das gilt genauso, wenn Sie sich gegen den Reflex absichern müssen, eine Ein-Klick-Lösung zu kaufen, die das Problem angeblich „lösen“ soll – warum solche Overlays das BFSG-Risiko gerade nicht beseitigen, habe ich in Overlays und 1-Klick-Lösungen: Warum sie das BFSG-Risiko nicht lösen ausführlich beschrieben.

Wie Sie heute mit einem kostenlosen Erstcheck starten

Wenn Sie die hier beschriebene erste Test-Ebene praktisch nutzen wollen, ohne selbst eine Browser-Extension einzurichten, ist unser Access Score der direkte Einstieg. Er führt automatisiert ein WCAG-2.2-Audit Ihrer Website durch, prüft die wichtigsten Unterseiten und liefert Ihnen eine verständliche Übersicht der gefundenen technischen Mängel – mit Erklärung, was sie bedeuten und welche Konsequenzen sich daraus ergeben. Das ist die kostenlose erste Ebene des Drei-Ebenen-Modells.

Was der Access Score nicht ersetzt: die manuelle Expertenprüfung und den Test mit echten Nutzern. Beides bekommen Sie in unserem Tiefen-Audit Access Ready, das alle drei Ebenen kombiniert und ein im Verfahren belastbares Zertifikat liefert. Aber für die schnelle erste Standortbestimmung – und um zu entscheiden, wie tief Sie überhaupt einsteigen müssen – ist der Access Score der ehrlichste Einstieg, den ich Ihnen empfehlen kann.