Barrierefreiheit der Website testen: Tools + 7 manuelle Checks

Sie haben das BFSG auf dem Schirm, Chrome DevTools ist offen - und jetzt fragen Sie sich: Wie finde ich heraus, ob meine Website wirklich barrierefrei ist? Die ehrliche Antwort: Es gibt drei Wege, und keiner reicht allein. Automatisierte Tools wie WAVE oder Lighthouse liefern einen schnellen Einstieg. Manuelle Checks decken auf, was kein Scanner sieht. Und ein professionelles Barrierefreiheitsaudit bringt die strukturierte Bewertung nach EN 301 549 und WCAG 2.1 AA, die Sie für echte Rechtskonformität brauchen.

Das BFSG ist seit Juni 2025 in Kraft. Wer sich für die rechtlichen Details interessiert (wer betroffen ist, welche Bußgelder drohen, wo die Kleinstunternehmen-Ausnahme greift) findet alles in unserem ausführlichen BFSG-Artikel. Dieser Artikel hier konzentriert sich auf das Testen.

Schnelltest mit kostenlosen Tools

Die folgenden Tools sind kostenlos, sofort einsetzbar und zusammen ein solider erster Schritt, um die Barrierefreiheit Ihrer Website zu testen. Jedes hat einen anderen Schwerpunkt.

WAVE

Wave ist eine Browser-Extension von WebAIM. Sie legt farbige Icons direkt über Ihre Seite: rote für Fehler, gelbe für Warnungen, grüne für erkannte Strukturelemente. Ideal als Einstieg, weil Sie kein DevTools-Fenster öffnen müssen und die Probleme dort sehen, wo sie auftreten.

Weiter zu WAVE

Lighthouse

Lighthouse steckt in Chrome DevTools (F12, Tab „Lighthouse"). Es liefert einen Accessibility-Score von 0 bis 100 und nutzt intern die axe-core-Engine. Praktisch für Entwickler, die ohnehin in DevTools arbeiten. Aber der Score verführt zu einem gefährlichen Fehlschluss, auf den wir gleich mehr eingehen.

axe DevTools

axe DevTools ist ebenfalls eine Browser-Extension. Sie bietet höhere Präzision als WAVE, weniger False Positives und liefert zu jedem Fund einen konkreten Fix-Vorschlag mit WCAG-Referenz. Für strukturierte Entwickler-Diagnosen die beste Wahl.

Weiter zu axe DevTools

‍

Womit anfangen? Öffnen Sie WAVE auf Ihrer Startseite für den ersten visuellen Überblick. Dann axe DevTools für die detaillierte Diagnose. Soweit, so gut.

Bevor jedoch Euphorie ausbricht, hier direkt die wichtigste Erkenntnis dieses Artikels: Der britische Government Digital Service (GDS) hat 142 bekannte Barrierefreiheits-Probleme gezielt in eine Testseite eingebaut und durch 13 automatisierte Tools laufen lassen. Das beste Tool fand 40 % der Probleme. Unabhängige Untersuchungen von Deque, WebAIM und TPGi bestätigen diesen Wert seit über einem Jahrzehnt: Automatisierte Tools decken rund 30 bis 40 % der WCAG-Erfolgskriterien ab.

Ein Lighthouse-Score von 100 bedeutet: keine automatisch erkennbaren Fehler. Über die verbleibenden 60 bis 70 % sagt er nichts.

Manuelle Prüfung: die 7 wichtigsten Checks

Diese sieben Tests brauchen keine Spezialsoftware und sind in unter einer Stunde machbar. Sie decken genau die häufigsten und schwerwiegendsten Barrieren ab, an denen automatisierte Tools scheitern.

‍

1. Tastatur-Navigation: Legen Sie die Maus beiseite. Navigieren Sie die Seite nur mit Tab, Shift+Tab, Enter und den Pfeiltasten. Funktioniert jeder Button, jeder Link, jedes Dropdown? Bleiben Sie irgendwo hängen, ist das ein kritischer WCAG-Verstoß.
2. Fokus-Sichtbarkeit: Während Sie per Tastatur navigieren: Sehen Sie jederzeit, welches Element gerade aktiv ist? Der Fokusrahmen muss deutlich sichtbar sein - auch wenn Ihr CSS die Standardstile überschreibt. Viele Teams entfernen outline: none aus ästhetischen Gründen und merken nicht, dass sie damit eine Barriere schaffen.
3. Zoom auf 200 %:  Zoomen Sie im Browser auf 200 % (Strg/Cmd + Plus). Bricht das Layout? Werden Texte abgeschnitten? Überlappen Elemente? Alle Funktionen müssen bedienbar bleiben. WCAG 2.1 AA verlangt das.
4. Kontrast-Check: Textkontrast mindestens 4,5:1 für Normaltext, 3:1 für großen Text (ab 18pt oder 14pt fett). Nutzen Sie den Contrast Checker von WebAIM oder den integrierten WAVE-Check. Besonders kritisch: heller Text auf Bildern und Placeholder-Texte in Formularfeldern.
5. Alt-Texte stichprobenartig: Rechtsklick auf Bilder und „Element untersuchen" oder WAVE nutzen. Fehlende Alt-Texte sind WCAG-Verstöße. Generische Texte wie „Bild", „image.jpg" oder „DSC_0042" sind es auch - denn sie transportieren keinen Inhalt.
6. Formular-Fehlermeldungen: Füllen Sie ein Formular absichtlich falsch aus. Erscheinen die Fehlermeldungen verständlich? Sind sie visuell und programmatisch mit dem richtigen Eingabefeld verknüpft? Eine Fehlermeldung am Seitenende, die nicht zum Feld scrollt, hilft niemandem.
7. Video-Untertitel: Haben alle Videos Untertitel oder zumindest ein Transkript? Startet ein Video automatisch mit Ton, ohne dass Nutzer es stummschalten können? Beides sind Verstöße, die viele Teams übersehen.

Screenreader-Test für Einsteiger

Ein Screenreader liest Ihre Seite so vor, wie blinde Nutzer sie erleben. Zwei Optionen stehen kostenlos bereit: NVDA für Windows (Download erforderlich) und VoiceOver auf dem Mac (bereits eingebaut - Cmd+F5 aktiviert es).

‍

Die ehrliche Einordnung: Ohne Übung ist es schwer zu beurteilen, ob das Vorleseergebnis tatsächlich korrekt ist. Screenreader haben eigene Navigationslogiken, Tastenkombinationen und Ansagemuster. Sie werden beim ersten Versuch mehr Fragen haben als Antworten. Das ist normal.

‍

Zwei konkrete Einstiegspunkte helfen trotzdem:

‍

• Überschriften-Navigation: Drücken Sie in NVDA die H-Taste, um von Überschrift zu Überschrift zu springen. Ergibt die Reihenfolge Sinn? Fehlen Ebenen (z. B. H2 direkt nach H4)?
• Formular-Modus: Navigieren Sie in ein Formular und prüfen Sie, ob der Screenreader die Labels korrekt vorliest. „Editierfeld" ohne Beschriftung ist ein klassisches Warnsignal.

Was ein professionelles Barrierefreiheitsaudit zusätzlich prüft

Ein Barrierefreiheitsaudit ist eine strukturierte, normkonforme Prüfung Ihrer Website nach EN 301 549 bzw. WCAG 2.1 AA. Es kombiniert automatisierte Scans, manuelle Tests und die Bewertung durch erfahrene Prüfer.

‍

Die drei Prüfebenen im Überblick:

‍

• Automatisiert (Tools) - Deckt rund 30 bis 40 % der WCAG-Kriterien ab. Schnell, wiederholbar, gut für Regressionstests.
• Manuell-selbst (die 7 Checks) - Fängt die offensichtlichsten Probleme ein, die Tools übersehen. Abhängig von Ihrer Erfahrung.
• Experten-Audit - Findet, was beide anderen Ebenen nicht können.

‍

Was nur ein Audit findet - und das ist der entscheidende Punkt:

• Semantische Strukturfehler: Eine Heading-Hierarchie kann im Code formal korrekt sein und trotzdem im Kontext der Seite keinen Sinn ergeben. Tools sehen Code. Experten sehen Bedeutung.
• ARIA-Fehlanwendungen: Schlecht implementiertes ARIA ist häufig schlimmer als gar kein ARIA. Ein role="button" auf einem div, das keine Tastatur-Events hat, erzeugt eine Barriere, wo vorher keine war. Tools melden keine „falsch verwendeten" ARIA-Rollen, sondern sehen nur, dass welche vorhanden sind.
• Logische Lesereihenfolgen: Visuell kann ein Layout perfekt wirken und für Screenreader trotzdem chaotisch sein, weil die DOM-Reihenfolge von der visuellen Darstellung abweicht.
• Kognitive Barrieren: Unklare Sprache, zu komplexe Formulare, fehlende Orientierungshilfen. Kein Scanner misst kognitive Last.
• PDF-Dokumente: Tagged PDFs sind ein eigenes Prüffeld. Die meisten Accessibility-Tools ignorieren PDFs komplett, weshalb genau dort bei vielen Unternehmen die gravierendsten Verstöße stecken.
• ‍

Wer die Grenzen der Selbsttests erkannt hat und BFSG-Konformität sicherstellen muss, braucht diese dritte Ebene. In einem professionellen Barrierefreiheitsaudit bewerten wir systematisch alle drei Ebenen und liefern einen priorisierten Maßnahmenplan.

Overlay-Widgets: Was sie können und was nicht

Anbieter wie AccessiBe oder UserWay versprechen „1-Klick-Barrierefreiheit" per JavaScript-Widget. Die Idee: Ein Script auf der Seite einbinden, und die Compliance-Frage ist erledigt.

‍

Die Realität sieht anders aus. Die Europäische Kommission hat klargestellt, dass Overlays keine akzeptable Lösung für Barrierefreiheitsprobleme darstellen: "Overlays, or any other tools which do not ensure the website itself meets the detailed criteria of the standard, are not an appropriate solution. It is best to fix accessibility issues at their source."

‍

Der Grund ist logisch: Kein automatisiertes Tool deckt alle WCAG 2.1 Level A und AA Kriterien ab. Ein Widget, das über dem Code liegt, kann den Code selbst nicht reparieren. Wenn Ihre Tastatur-Navigation nicht funktioniert, ändert ein Overlay daran nichts.

‍

Hinzu kommt: Die EU-Kommission hat festgestellt, dass einige Overlay-Tools mit den Assistive Technologies von Nutzern mit Behinderungen in Konflikt geraten können - und die Website damit weniger zugänglich machen. Nutzer, die NVDA oder VoiceOver verwenden, haben ihre Tools über Jahre konfiguriert. Ein Widget, das ungefragt ARIA-Labels injiziert oder Steuerelemente umbenennt, stört diese eingespielte Konfiguration.

‍

Falls Sie bereits ein Overlay einsetzen: Entfernen Sie es und starten Sie stattdessen einen echten Test mit den Tools und Checks aus diesem Artikel.

Befunde priorisieren: kritisch vs. kosmetisch

Nach dem Testen haben Sie eine Liste von Befunden. Und dann die Frage: Wo anfangen? Die Antwort liegt in der Unterscheidung zwischen Befunden, die Nutzung blockieren, und solchen, die Best-Practice-Abweichungen darstellen.

‍

Die Logik dahinter: Kritische Befunde sind WCAG-Verstöße der Stufe A oder AA, die eine Nutzung komplett verhindern. Mittlere behindern, blockieren aber nicht. Kosmetische sind Abweichungen von Best Practices ohne direkte Compliance-Relevanz.

‍

Ein Beispiel aus unserer Audit-Praxis: In einem E-Commerce-Audit fanden wir 3 kritische Befunde - darunter ein nicht-fokussierbarer Kaufen-Button und fehlende Formular-Labels im Checkout - die innerhalb eines Tages behoben waren. Daneben standen 40 kosmetische Befunde, die keinerlei BFSG-Relevanz hatten. Die Priorität war sofort klar.

‍

BFSG-Kontext in drei Sätzen

Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt seit dem 28. Juni 2025. Der technische Maßstab ist WCAG 2.1 Stufe AA gemäß EN 301 549 - und genau das prüfen die Tools und Checks in diesem Artikel. Bei Verstößen drohen Bußgelder bis zu 100.000 Euro sowie Abmahnungen durch Wettbewerber und Verbände.

‍

Wer im Detail wissen möchte, ob das BFSG auf das eigene Unternehmen zutrifft, welche Ausnahmen gelten und wie die Durchsetzung 2026 aussieht, findet alles in unserem Artikel Barrierefreie Website: Wer 2026 unter die BFSG-Pflicht fällt.

‍

Fazit

Selbsttests mit kostenlosen Tools sind ein guter Start - aber kein Ersatz für eine vollständige Prüfung. Zwei konkrete nächste Schritte: Installieren Sie jetzt WAVE und prüfen Sie Ihre Startseite. Dann gehen Sie die 7 manuellen Checks durch.

‍

Wer danach weiß, dass der WAVE-Bericht sauber aussieht und die Tastatur-Navigation funktioniert, hat eine solide Ausgangsbasis. Aber der Weg zur Rechtskonformität beginnt danach, denn die verbleibenden 60 bis 70 % der WCAG-Kriterien prüfen sich nicht von selbst.

‍