Praxis

Die besten Barrierefreiheits-Tools 2026: Kostenlose und kostenpflichtige Scanner im Vergleich

Von Joshua Kantner · April 2026 · bf-check.de

Warum automatische Tools nur der Anfang sind

Kein automatisches Tool findet alle Barrierefreiheits-Probleme. Studien zeigen, dass selbst die besten Scanner nur etwa 30-40 % der WCAG 2.2 Success Criteria automatisch erkennen. Das liegt daran, dass viele Kriterien eine kontextuelle oder inhaltliche Bewertung erfordern, die Maschinen nicht leisten können.

Trotzdem sind automatische Scanner unverzichtbar: Sie finden die häufigsten und technisch prüfbaren Fehler schnell und zuverlässig. Fehlende Alt-Texte (SC 1.1.1), unzureichende Kontraste (SC 1.4.3), fehlende Formular-Labels (SC 1.3.1) oder ungültige ARIA-Attribute (SC 4.1.2) werden von guten Tools in Sekunden erkannt.

Das Barrierefreiheitsstärkungsgesetz (BFSG) verlangt nach § 3 die Einhaltung der EN 301 549, die sich an den WCAG 2.1 Level AA orientiert. Automatische Tools helfen dir dabei, die technisch prüfbaren Anforderungen abzudecken. Für die vollständige Konformität brauchst du allerdings immer auch manuelle Tests und idealerweise Tests mit echten Nutzern assistiver Technologien.

Automatisches vs. manuelles Testen

Der wichtigste Unterschied: Automatische Tools prüfen den Code, manuelle Tests prüfen die Nutzererfahrung. Beide Ansätze ergänzen sich und sind für eine vollständige BFSG-Prüfung notwendig.

Was automatische Tests gut können

Automatische Scanner sind besonders stark bei rein technischen Kriterien: Ist ein Alt-Attribut vorhanden? Erfüllt der Farbkontrast das Verhältnis 4,5:1 (SC 1.4.3)? Haben Formularfelder ein verknüpftes Label? Sind ARIA-Rollen korrekt gesetzt? Diese Prüfungen lassen sich zuverlässig automatisieren und liefern innerhalb von Sekunden Ergebnisse.

Was nur manuell geht

Ein Scanner kann feststellen, dass ein Alt-Text existiert, aber nicht, ob er sinnvoll ist. Ebenso kann kein Tool prüfen, ob eine Seite logisch aufgebaut ist (SC 1.3.2), ob Inhalte verständlich formuliert sind (SC 3.1.5) oder ob die Tastaturbedienung intuitiv funktioniert (SC 2.1.1). Dafür brauchst du manuelle Prüfungen, bei denen ein Mensch die Seite tatsächlich bedient und bewertet.

Die empfohlene Kombination

Die beste Strategie für die Durchführung eines Barrierefreiheits-Audits ist ein dreistufiger Ansatz: Zuerst ein automatischer Scan, um die offensichtlichen Fehler zu finden. Dann manuelle Tests mit Tastatur und Screenreader. Und schließlich Tests mit echten Nutzern, die auf assistive Technologien angewiesen sind.

Kostenlose Tools im Detail

bf-check.de

Spezialisiert auf das BFSG und die deutsche Rechtslage. Der kostenlose BFSG-Scanner liefert in ca. 30 Sekunden eine klare Bewertung, ob deine Webseite die wichtigsten Anforderungen erfüllt. Besonders geeignet für Einsteiger und Unternehmen, die einen schnellen Überblick brauchen.

WAVE (WebAIM)

Die WAVE-Extension für Chrome und Firefox zeigt Fehler, Warnungen und Strukturinformationen direkt als visuelle Overlay-Icons auf der Webseite an. Das macht sie besonders intuitiv für Designer und Redakteure. WAVE prüft unter anderem Kontraste, fehlende Alt-Texte, Überschriftenstruktur und ARIA-Attribute.

axe DevTools (Deque)

Die Chrome-Extension von Deque ist der De-facto-Standard für Entwickler. axe basiert auf der Open-Source-Bibliothek axe-core, die auch von Google Lighthouse und vielen anderen Tools genutzt wird. Die Ergebnisse sind sehr technisch und detailliert, mit direkten Verweisen auf die betroffenen WCAG Success Criteria.

Google Lighthouse

Direkt in den Chrome DevTools verfügbar (Tab "Lighthouse"). Liefert einen Accessibility-Score von 0-100 und kombiniert Barrierefreiheit mit Performance-, SEO- und Best-Practices-Metriken. Lighthouse nutzt intern axe-core, prüft aber weniger Regeln als die vollständige axe-Extension. Mehr dazu in unserem Artikel Google Lighthouse für Barrierefreiheit nutzen.

Pa11y

Ein Open-Source-Kommandozeilen-Tool, das sich hervorragend für Entwickler und CI/CD-Pipelines eignet. Pa11y kann ganze Webseiten crawlen und in verschiedenen Formaten berichten. Es lässt sich in GitHub Actions, GitLab CI oder Jenkins integrieren.

Tool-Vergleichstabelle

Tool Typ Kosten Stärke CI/CD
bf-check.deWeb-ScannerKostenlos / ProBFSG-Fokus, einfachNein
WAVEBrowser-ExtensionKostenlosVisuelles OverlayAPI verfügbar
axe DevToolsExtension / LibraryKostenlos / ProTechnische TiefeJa (axe-core)
LighthouseDevTools / CLIKostenlosGesamt-ScoreJa (Lighthouse CI)
Pa11yCLI-ToolKostenlosAutomatisierungJa
SiteimproveSaaS-PlattformEnterpriseMonitoring + ReportsAPI verfügbar
axe MonitorSaaS-PlattformKostenpflichtigDashboard + TrendsJa
⚠️
Ist deine Webseite betroffen? Kostenloser BFSG-Schnellcheck – Ergebnis in 30 Sekunden.
Jetzt prüfen →

Kostenpflichtige Tools

Siteimprove ist eine Enterprise-Lösung mit umfassendem Monitoring, historischen Berichten und Team-Management. Ideal für große Organisationen mit vielen Webseiten und mehreren verantwortlichen Teams.

Deque axe Monitor baut auf der bewährten axe-core-Engine auf und bietet ein Dashboard mit Trend-Analysen. Du siehst auf einen Blick, ob sich die Barrierefreiheit deiner Seite über die Zeit verbessert oder verschlechtert.

Level Access kombiniert automatische Scans mit menschlicher Beratung. Das ist besonders wertvoll, wenn du nicht nur Probleme finden, sondern auch Lösungsvorschläge von Experten erhalten möchtest.

Hinweis zu Overlay-Tools (UserWay u. ä.): Widget-basierte Lösungen, die eine Barrierefreiheits-Toolbar über die Webseite legen, sind in der Fachcommunity stark umstritten. Behindertenverbände und Barrierefreiheits-Experten raten davon ab, weil sie die eigentlichen Probleme im Code nicht beheben und oft neue Barrieren schaffen.

Screenreader-Testing: Die manuelle Königsklasse

Screenreader wandeln den Seiteninhalt in Sprache oder Braille-Ausgabe um. Ein Test mit einem Screenreader deckt Probleme auf, die kein automatischer Scanner erkennen kann. Mehr dazu erfährst du in unserem Artikel So funktionieren Screenreader.

Kostenlose Screenreader zum Testen

NVDA (NonVisual Desktop Access) ist der meistgenutzte kostenlose Screenreader für Windows. VoiceOver ist auf macOS und iOS vorinstalliert. TalkBack ist auf Android-Geräten verfügbar. Für professionelle Tests auf Windows ist JAWS der Branchenstandard, allerdings kostenpflichtig.

Worauf du beim Screenreader-Test achten solltest

Navigiere die Seite nur mit dem Screenreader, ohne auf den Bildschirm zu schauen. Prüfe: Werden alle Inhalte vorgelesen? Ist die Lesereihenfolge logisch (SC 1.3.2)? Werden interaktive Elemente korrekt angekündigt (SC 4.1.2)? Sind Formulare verständlich beschrieben (SC 3.3.2)?

Tastatur-Testing: Grundlage für Motorik-Barrierefreiheit

Alle interaktiven Elemente müssen per Tastatur erreichbar und bedienbar sein (SC 2.1.1). Das betrifft nicht nur Menschen mit motorischen Einschränkungen, sondern auch Nutzer von Sprachsteuerung und anderen Eingabegeräten.

So testest du: Leg die Maus beiseite und navigiere die komplette Seite nur mit Tab, Shift+Tab, Enter, Space und Pfeiltasten. Achte darauf, dass der Fokus-Indikator immer sichtbar ist (SC 2.4.7) und die Tab-Reihenfolge logisch ist (SC 2.4.3). Kein Element darf den Tastaturfokus einfangen, sodass du nicht mehr weiternavigieren kannst (SC 2.1.2).

Schritt für Schritt: Dein Testing-Workflow

Ein strukturierter Workflow hilft dir, keine Prüfschritte zu vergessen. So gehst du vor:

Schritt 1: Automatischer Scan. Starte mit einem schnellen Scan über bf-check.de für einen BFSG-fokussierten Überblick. Ergänze mit axe DevTools oder WAVE für eine detailliertere technische Analyse.

Schritt 2: Ergebnisse priorisieren. Sortiere die gefundenen Fehler nach Schweregrad. Kritisch sind Probleme, die den Zugang komplett verhindern (fehlende Tastaturnavigation, fehlende Alt-Texte auf Funktionsbildern). Weniger kritisch, aber wichtig sind Kontrastprobleme oder fehlende Landmarks.

Schritt 3: Tastatur-Test. Navigiere jede Seite komplett per Tastatur. Prüfe alle interaktiven Elemente: Links, Buttons, Formulare, Menüs, Modale.

Schritt 4: Screenreader-Test. Teste die wichtigsten Seiten und User-Flows mit NVDA oder VoiceOver. Achte besonders auf Formulare, den Checkout-Prozess und die Navigation.

Schritt 5: Dokumentation. Halte alle gefundenen Probleme mit Screenshot, betroffener URL und WCAG-Referenz fest. Das ist die Grundlage für die Behebung und spätere Nachprüfung.

Schritt 6: Beheben und erneut testen. Nach der Korrektur immer einen erneuten Scan durchführen, um sicherzustellen, dass keine neuen Probleme entstanden sind.

CI/CD-Integration: Automatisch bei jedem Deployment testen

Wer Barrierefreiheit nachhaltig sicherstellen will, integriert die Prüfung in den Entwicklungsprozess. So werden neue Barrieren erkannt, bevor sie live gehen.

Mögliche Setups

axe-core + Jest/Cypress: Schreibe Unit- oder E2E-Tests, die axe-core auf gerenderte Komponenten anwenden. Jeder fehlschlagende Test blockiert das Deployment.

Pa11y CI: Pa11y lässt sich als GitHub Action oder GitLab-CI-Job konfigurieren. Es crawlt eine Liste von URLs und meldet Fehler als Failed Build.

Lighthouse CI: Google bietet mit Lighthouse CI ein Tool, das Lighthouse-Audits in die Pipeline integriert. Du definierst Schwellenwerte (z. B. Accessibility-Score ≥ 90) und der Build schlägt fehl, wenn diese unterschritten werden.

Häufige Fehler beim Testen

Nur ein Tool nutzen: Jedes Tool hat blinde Flecken. Kombiniere mindestens zwei automatische Tools und ergänze durch manuelle Prüfung.

Scanner-Ergebnis als Freibrief sehen: Ein Score von 100 bei Lighthouse bedeutet nicht, dass deine Seite barrierefrei ist. Es bedeutet nur, dass die automatisch prüfbaren Kriterien bestanden wurden.

Overlay-Tools als Lösung betrachten: Widgets, die sich über die Seite legen, beheben keine Barrieren im Quellcode. Sie können sogar neue Probleme schaffen und geben ein falsches Sicherheitsgefühl.

Einmalig testen und dann vergessen: Barrierefreiheit ist ein laufender Prozess. Jedes Content-Update, jedes Plugin-Update und jede Design-Änderung kann neue Barrieren einführen. Gemäß § 4 BFSG muss die Konformität dauerhaft eingehalten werden.

Mobile Tests vergessen: Viele Seiten sind am Desktop barrierefrei, aber auf dem Smartphone nicht. Teste immer auch die mobile Ansicht, insbesondere Touch-Zielgrößen (SC 2.5.8) und die mobile Navigation.

Welches Tool ist das richtige für dich?

Für den schnellen Überblick: bf-check.de – in 30 Sekunden weißt du, ob deine Seite die BFSG-Grundlagen erfüllt.

Für Entwickler: axe DevTools für die detaillierte technische Analyse direkt im Browser. Ergänzt durch axe-core in der CI/CD-Pipeline.

Für Designer und Redakteure: WAVE, weil die visuelle Darstellung intuitiver ist als technische Fehlerlisten.

Für laufendes Monitoring: Siteimprove, axe Monitor oder das bf-check.de Agentur-Paket für regelmäßige automatische Scans mit Reporting.

Für vollständige BFSG-Konformität: Die Kombination aus automatischem Scan + manuellem Tastatur- und Screenreader-Test + Nutzer-Test. Nur so deckst du alle Anforderungen ab.

Dieser Artikel ersetzt keine Rechtsberatung. Für verbindliche Aussagen zur BFSG-Konformität deiner Webseite wende dich an eine qualifizierte Beratungsstelle oder Kanzlei.

Häufig gestellte Fragen

Kann ein Tool meine Webseite automatisch reparieren?
Nein. Tools können Probleme finden, aber nicht automatisch beheben. Overlay-Tools, die das versprechen, sind in der Barrierefreiheits-Community stark umstritten und werden von Experten und Behindertenverbänden abgelehnt.
Wie viel Prozent der WCAG-Kriterien kann ein automatischer Scanner erkennen?
Automatische Scanner erkennen etwa 30-40 % der WCAG 2.2 Success Criteria zuverlässig. Kriterien wie Kontraste (SC 1.4.3), fehlende Alt-Texte (SC 1.1.1) oder fehlerhafte Formular-Labels (SC 1.3.1) lassen sich gut automatisieren. Kontextuelle Bewertungen wie Verständlichkeit oder Sinnhaftigkeit von Alternativtexten erfordern manuelle Prüfung.
Reicht ein einziger Scan für die BFSG-Konformität?
Nein. Ein einzelner Scan ist nur eine Momentaufnahme. Webseiten ändern sich laufend durch neue Inhalte, Updates oder Redesigns. Das BFSG verlangt nach § 4 eine dauerhafte Einhaltung. Empfohlen wird ein regelmäßiges Monitoring, etwa monatlich oder nach jedem größeren Content-Update.
Was ist der Unterschied zwischen axe, WAVE und Lighthouse?
axe DevTools liefert sehr technische, entwicklernahe Ergebnisse und lässt sich in CI/CD-Pipelines einbinden. WAVE zeigt Fehler visuell direkt auf der Seite, was für Redakteure und Designer intuitiver ist. Lighthouse liefert einen Gesamt-Score und kombiniert Barrierefreiheit mit Performance- und SEO-Metriken, prüft aber weniger Regeln als axe.
Brauche ich einen Screenreader zum Testen?
Für eine vollständige Prüfung nach WCAG 2.2 Level AA ja. Screenreader-Tests decken Probleme auf, die kein automatischer Scanner findet, etwa fehlende Kontextinformationen, falsche Lesereihenfolge oder schlecht benannte interaktive Elemente. NVDA (Windows) und VoiceOver (macOS/iOS) sind kostenlos verfügbar.
Sind kostenpflichtige Tools besser als kostenlose?
Nicht zwangsläufig. Die Erkennungsqualität von axe (kostenlos) ist branchenführend. Kostenpflichtige Tools wie Siteimprove oder axe Monitor bieten Mehrwert durch automatisiertes Monitoring, historische Berichte, Dashboards und Team-Management. Für einzelne Webseiten reichen kostenlose Tools in Kombination mit manuellen Tests oft aus.
Kann ich Barrierefreiheits-Tests in meine CI/CD-Pipeline integrieren?
Ja. Tools wie axe-core, Pa11y und Lighthouse CI lassen sich direkt in Build-Pipelines (GitHub Actions, GitLab CI, Jenkins) einbinden. So wird bei jedem Deployment automatisch geprüft und neue Barrieren werden erkannt, bevor sie live gehen.

Weiterlesen

Strategie
Barrierefreiheit beim Relaunch
Strategie
BFSG-Checkliste Kleinunternehmen
Leitfaden
BFSG 2025: Der komplette Leitfaden

Ist deine Webseite BFSG-konform?

Finde es in 30 Sekunden heraus – kostenloser Schnellcheck mit sofortigem Ergebnis.

Jetzt kostenlos prüfen →
BFSG-Pflicht seit Juni 2025 – Ist deine Seite konform? Kostenlos prüfen
Seit Juni 2025 Pflicht

Warte – deine Webseite könnte gegen das BFSG verstoßen

Abmahnungen bis 5.000 €, Bußgelder bis 100.000 €. Unser kostenloser Scan zeigt dir in 30 Sekunden ob du betroffen bist.

Jetzt kostenlos scannen →