Warum automatisierte Barrierefreiheits-Scanner nur 30 % der Probleme erkennen (und was Sie dagegen tun können)

Sie führen einen automatisierten Accessibility-Scan durch, das Dashboard ist grün, und Sie atmen erleichtert auf. Aber hier ist eine unbequeme Wahrheit: Dieser saubere Bericht kann den Großteil der tatsächlichen Barrieren auf Ihrer Website verbergen. Forschung und unabhängige Studien zeigen konsistent, dass automatisierte Scanner nur zwischen 30% und 57% der tatsächlichen WCAG-Verstöße erkennen – was bedeutet, dass irgendwo zwischen der Hälfte und zwei Dritteln der Probleme, denen Ihre behinderten Nutzer täglich begegnen, für die Tools, auf die sich die meisten Teams verlassen, völlig unsichtbar bleiben.

Der Stand des automatisierten Accessibility-Testings

Automatisiertes Accessibility-Testing hat enorm an Popularität gewonnen – und das aus gutem Grund. Immer mehr Teams setzen auf Automatisierung, um nach Accessibility-Problemen zu suchen: 50% der Befragten in einer Umfrage von 2024 gaben an, automatisierte Accessibility-Tools zu nutzen, um potenzielle Probleme zu identifizieren, gegenüber 40% im Jahr 2023. Die Attraktivität liegt auf der Hand – Scanner sind schnell, relativ günstig und lassen sich direkt in CI/CD-Pipelines integrieren. Sie erkennen offensichtliche, wiederkehrende, regelbasierte Verstöße in großem Umfang: das fehlende alt-Attribut, das Formulareingabefeld ohne Label, der Button mit leerem Accessible Name.

Aber die Abdeckungsgrenze ist ein hartnäckiges Problem, das kein Scanner-Anbieter durchbrechen konnte. Laut Deque „kann man im Durchschnitt 57% der WCAG-Probleme automatisch finden“, und selbst dann geben Tools Komponenten als unvollständig zurück, bei denen eine manuelle Überprüfung erforderlich ist. Diese Zahl von 57% stellt das optimistische Ende des Spektrums dar, erreicht von einer der ausgereiftesten und vertrauenswürdigsten Accessibility-Engines auf dem Markt, die eine pragmatische, praxisnahe Messmethodik verwendet. Andere Schätzungen liegen deutlich niedriger. Automatisierte Tools erfassen ungefähr 30–40% der WCAG-Verstöße, während die verbleibenden 60–70% manuelle Tests erfordern.

Die Diskrepanz zwischen 30% und 57% hängt davon ab, wie man den Nenner definiert. Deque kam auf die 57%-Zahl, indem ein pragmatischer, praxisnaher Ansatz statt eines theoretischen gewählt wurde – es wurden viele Websites stichprobenartig untersucht und gemessen, wie viele der tatsächlich dokumentierten Accessibility-Defekte mit axe-core hätten erkannt werden können. Wenn Forschende die Abdeckung stattdessen gegen alle WCAG-Erfolgskriterien als theoretische Menge messen, fallen die Zahlen drastisch. Zum Zeitpunkt dieses Textes zeigt das Filtern nach WCAG 2.2 Level A und AA, um nur genehmigte automatisierte Testregeln anzuzeigen, eine teilweise oder vollständige Abdeckung für nur 17 von 55 Erfolgskriterien. Wie man es auch dreht: Automatisiertes Testing hinterlässt eine erhebliche – und rechtlich gefährliche – Lücke.

Das Problem wird dadurch verschärft, wie schwer diese Lücke von außen zu erkennen ist. Ein bestandener Scan signalisiert aktiv Sicherheit – genau dann hören Teams am ehesten auf, weiter hinzuschauen. Das Dashboard ist grün. Es wird ausgeliefert. Echte Nutzer mit Behinderungen stoßen auf echte Barrieren.

Worin Scanner tatsächlich gut sind

Bevor wir in die Abdeckungslücke eintauchen, lohnt es sich klarzustellen, was automatisierte Tools wirklich gut können. Sie sind schnell, konsistent und unermüdlich beim Prüfen von Dingen, die sich allein durch das Auslesen des DOM bestimmen lassen. Accessibility-Automatisierung kann gängige WCAG-Verstöße wie fehlenden Alt-Text, leere Links, fehlerhafte Formularlabels und zu geringe Farbkontrastverhältnisse zuverlässig erkennen. Das sind strukturelle, binäre Checks – entweder das Attribut existiert oder nicht, entweder das Kontrastverhältnis besteht 4,5:1 oder es fällt durch.

Der WebAIM Million Report, der jährlich die eine Million meistbesuchten Startseiten analysiert, vermittelt ein eindrückliches Bild davon, wie verbreitet diese erkennbaren Fehler weiterhin sind. 95,9% der Startseiten wiesen erkannte WCAG-2-Fehler auf. Die sechs häufigsten Kategorien – Text mit zu geringem Kontrast, fehlender Alt-Text, fehlende Formularlabels, leere Links, leere Buttons und fehlende Dokumentensprache – machen 96% aller erkannten Fehler aus, und diese häufigsten Fehler sind seit sieben Jahren dieselben. Automatisierte Tools sind tatsächlich hilfreich, um diese hochfrequenten, wenig komplexen Verstöße in großem Umfang sichtbar zu machen. Das Problem ist, dass das Beheben nur dieser Probleme eine Website mit den meisten ihrer tatsächlichen Barrieren zurücklässt.

Warum die Lücke existiert: Was Scanner nicht bewerten können

Die Abdeckungsgrenze ist kein Versagen der Ingenieurskunst – sie ist eine grundlegende Einschränkung dessen, was eine Maschine ohne menschliches Urteil bewerten kann. Die Lücke existiert, weil Maschinen keinen Kontext, keine Nutzerintention oder subjektive Aspekte verstehen können, etwa ob die Überschriftenhierarchie sinnvoll ist oder ob Alt-Text korrekt ist. Ein Scanner kann bestätigen, dass ein Bild ein alt-Attribut hat. Er kann Ihnen nicht sagen, ob dieses Attribut „photo-123-final-v2.jpg“ oder eine wirklich hilfreiche Beschreibung enthält. Tools können markieren, dass ein Bild Alt-Text hat, aber nur eine Person kann beurteilen, ob dieser Text das Bild tatsächlich gut beschreibt.

Hier sind die wichtigsten Kategorien von Problemen, die automatisierter Erkennung konsequent entgehen:

• Screenreader-Erlebnis: Automatisierte Tools können nicht „zuhören“, wie ein Screenreader Inhalte ansagt. Sie können die Gültigkeit von ARIA-Attributen prüfen, aber nicht feststellen, ob die resultierenden Ansagen für Nutzer sinnvoll sind. Ein Formularfeld kann ein technisch gültiges aria-label haben, das für einen echten NVDA- oder JAWS-Nutzer als verwirrende Zeichenfolge vorgelesen wird.
• Logische Lese- und Fokusreihenfolge: In der Praxis ergibt die Lesereihenfolge oft keinen Sinn, wenn Screenreader-Nutzer auf Informationen zugreifen, die visuell völlig in Ordnung erscheinen. In einem Spaltenlayout liest ein Screenreader die erste Zeile von Spalte 1, dann Spalte 2, was zu Verwirrung führt. Scanner analysieren die DOM-Reihenfolge isoliert, ohne den Kontext, wie das visuelle Layout diese Reihenfolge für sehende Nutzer verändert.
• Aussagekräftige Link- und Buttontexte im Kontext: Automatisierte Tools können prüfen, ob ein Link existiert und ob er Text enthält, aber sie können nicht immer beurteilen, ob der Zweck dieses Links klar ist. Fünf „Mehr erfahren“-Links auf derselben Seite bestehen alle automatisierten Checks und fallen alle bei echten Nutzern durch, die verstehen müssen, wohin jeder einzelne führt.
• Dynamische Inhalte und Live Regions: Automatisierte Tools können Probleme mit dynamisch geladenen Inhalten nicht erfassen. Man muss den Test erneut ausführen, nachdem das dynamische Update hinzugefügt wurde – aber selbst dann kann das Tool nicht sagen, ob ein Screenreader es vorlesen wird oder nicht.
• Kognitive Accessibility und einfache Sprache: Automatisierung kann strukturelle Probleme wie Überschriftenreihenfolge oder das Vorhandensein von Labels erkennen, aber nicht Lesbarkeit, Klarheit oder ob Anweisungen leicht zu befolgen sind. Ein komplexer mehrstufiger Checkout mit verwirrenden Fehlermeldungen kann strukturell „sauber“ sein und gleichzeitig für Nutzer mit kognitiven Beeinträchtigungen hochgradig unzugänglich.
• Tastaturnavigation in komplexen Interaktionen: Automatisierung kann grundlegenden Tastaturfokus und -bedienbarkeit testen, aber keine komplexen mehrstufigen Interaktionen, benutzerdefinierten Gesten oder alternativen Eingabegeräte vollständig validieren. Ein benutzerdefiniertes Datepicker-Widget kann in der Theorie vollständig per Tastatur bedienbar sein und in der Praxis eine komplette Falle.
• Überlappende visuelle Elemente und Farbverläufe beim Kontrast: Automatisierte Tools können Kontrastverhältnisse bewerten, berücksichtigen aber nicht immer überlappende Elemente, Bilder hinter Text oder dynamisch wechselnde Inhalte, die die Lesbarkeit beeinträchtigen.

Ein sauberer automatisierter Scan bedeutet, dass Sie die 30–40% der Probleme adressiert haben, die Automatisierung erfassen kann. Die verbleibenden 60–70% sind ungetestet. Beanspruchen Sie niemals WCAG-Konformität ausschließlich auf Basis automatisierter Tests.

Ein besonders eindrücklicher Beleg: In einer Studie erstellten staatliche Accessibility-Verfechter im Vereinigten Königreich absichtlich eine Webseite mit 142 Accessibility-Barrieren und analysierten die Seite anschließend mit 13 automatisierten Accessibility-Tools. Das am besten abschneidende Tool konnte nur 40% der Barrieren identifizieren. Das schlechteste Tool fand lediglich 13%. Selbst als die Bedingungen zugunsten der Tools gestaltet waren – eine kontrollierte Seite mit bekannten, dokumentierten Problemen – waren die Ergebnisse ernüchternd. Und die Kombination von Tools löst das Problem nicht vollständig: Selbst beim Einsatz von sechs Tools parallel werden die Hälfte aller WCAG-2-Erfolgskriterien nicht abgedeckt und 6 von 10 Verstößen übersehen.

Das rechtliche Risiko einer Überabhängigkeit von Automatisierung

Dies ist nicht nur eine theoretische Frage der User Experience. Die rechtlichen Risiken bei Accessibility-Nichtkonformität steigen stark, und ein bestandener automatisierter Scan bietet in einem Gerichtsverfahren nahezu keinen Schutz. Im Jahr 2024 wurden in US-Gerichten mehr als 4.000 Klagen wegen Barrieren bei der Website- oder mobilen Accessibility eingereicht. Allein in der ersten Hälfte des Jahres 2025 gab es 2.014 ADA-Website-Klagen – ein Anstieg um 37% gegenüber 2024.

Außergerichtliche Einigungen liegen im Durchschnitt bei 30.000 $, während gerichtliche Urteile im Durchschnitt 85.000 $ betragen. Hinzu kommen in allen Fällen Verteidigungskosten von 30.000–175.000 $. Noch schlimmer: Eine einmalige Einigung ist keine Sicherheitsgarantie: 45–46% der bundesweiten digitalen Accessibility-Klagen von 2025 richteten sich gegen Unternehmen, die bereits zuvor verklagt worden waren. Verklagt zu werden und nur das zu flicken, was automatisierte Tools markieren, ohne die breiteren strukturellen Lücken zu schließen, macht Sie lediglich zur Zielscheibe für den nächsten Kläger.

Es lohnt sich auch, ein verbreitetes Missverständnis über Accessibility-Widgets und Overlays als Abkürzung zur Konformität anzusprechen. Daten aus dem Jahr 2025 zeigen, dass 456 ADA-Klagen gegen Websites eingereicht wurden, auf denen Accessibility-Widgets installiert waren, was 22,64% aller Klagen ausmacht – ein deutlicher Hinweis darauf, dass das bloße Hinzufügen eines Accessibility-Widgets keine umfassende Lösung ist. Automatisierte Tools können nur 30% der WCAG-Probleme erkennen, was bedeutet, dass jedes Tool oder Widget, das sich ausschließlich auf automatisierte Erkennung stützt, per Definition den Großteil der Probleme unadressiert lässt. Was ein wirklich wertvolles Accessibility-SDK – wie Accsible – von den Overlay-Produkten unterscheidet, die rechtlichen und regulatorischen Gegenwind erfahren haben, ist die Kombination aus automatisierter Behebung und dem Bekenntnis zu einer ehrlichen, gestuften Compliance-Strategie statt falscher Garantien.

Eine gestufte Teststrategie, die tatsächlich funktioniert

Die Antwort auf die Abdeckungslücke besteht nicht darin, automatisierte Scanner aufzugeben – sondern sie richtig zu nutzen: als erste Schicht in einer umfassenden Strategie, nicht als letzte. Von den 86 WCAG-2.2-Erfolgskriterien erfordern siebzig Prozent eine menschliche Überprüfung, um die Kriterien korrekt zu interpretieren und auf die Grauzonen außerhalb des Geltungsbereichs automatisierter Accessibility-Technologie anzuwenden. Das bedeutet, menschliches Urteil ist nicht optional – es ist strukturell durch den Standard selbst gefordert.

Ein robustes Accessibility-Testprogramm funktioniert typischerweise in drei Schichten:

1. Automatisiertes Scanning (kontinuierlich): Integrieren Sie Scanner wie axe-core in Ihre CI/CD-Pipeline und führen Sie sie bei jedem Build aus. Fangen Sie strukturelle, binäre Verstöße ab, bevor sie in die Produktion gelangen. Setzen Sie Schwellenwerte und lassen Sie Builds bei neuen kritischen Verstößen fehlschlagen. Das ist Ihr Sicherheitsnetz für die offensichtlichen Dinge – schnell, skalierbar und günstig. Führen Sie automatisierte Tools früh und häufig während der Entwicklung aus. Integrieren Sie axe oder WAVE in Ihre CI/CD-Pipeline, damit Probleme erkannt werden, bevor der Code die QA erreicht. So wird Accessibility-Testing nach links verlagert und Probleme werden erkannt, wenn sie am günstigsten zu beheben sind.
2. Manueller Experten-Audit (periodisch): Führen Sie strukturierte manuelle Audits anhand der vollständigen WCAG-Checkliste durch, durchgeführt von Personen mit tiefem Accessibility-Wissen. Manuelle Accessibility-Tests werden von geschulten Expertinnen und Experten durchgeführt, die Websites aktiv mit unterstützenden Technologien wie Screenreadern, Tastaturnavigation oder Vergrößerungssoftware nutzen. Sie bewerten Kontext und Nutzererlebnis – die logische Fokusreihenfolge und das intuitive Navigationsgefühl, die Klarheit von Formularen und Fehlermeldungen, die Lesbarkeit in komplexen Inhalten. Manuelle Audits finden typischerweise vierteljährlich oder bei der Auslieferung größerer Features statt und sollten Ihre meistfrequentierten User Journeys Ende-zu-Ende abdecken. Geführte manuelle Accessibility-Audits liegen zwischen vollständig manuellen und vollständig automatisierten Tests, verringern die Abdeckungslücke, und einige Schätzungen sehen die Abdeckung mit diesem Ansatz bei bis zu 80%.
3. Tests mit assistiven Technologien und Nutzertests (fortlaufend): Sie können sich nicht ausschließlich auf automatisierte Tools verlassen, um Accessibility-Probleme auf Ihrer Website zu bestimmen. Jedes Website-Projekt braucht eine User-Testing-Strategie, und es wird dringend empfohlen, Accessibility-Nutzergruppen einzubeziehen – Screenreader-Nutzer, reine Tastaturnutzer, Nutzer ohne Hörvermögen, Nutzer mit motorischen Beeinträchtigungen. Echte Nutzer mit Behinderungen finden Probleme, die keine Checkliste vorhersieht. Testen Sie mit NVDA und JAWS unter Windows, VoiceOver unter macOS und iOS sowie TalkBack unter Android. Navigieren Sie Ihren gesamten Checkout- oder Anmelde-Flow ausschließlich mit der Tastatur. Hören Sie sich tatsächlich an, wie Ihre Inhalte vorgelesen klingen.

Wenn Teams alle drei Schichten implementieren, kann die kombinierte Abdeckung 80–90% der realen Probleme erreichen – eine dramatische Verbesserung gegenüber der 30–57%-Grenze der reinen Automatisierung. Das Ziel ist nicht Perfektion am ersten Tag; es ist ein systematischer, dokumentierter Prozess, der ernsthaftes Bemühen zeigt und die Lücke kontinuierlich schließt.

Accessibility in Ihren Entwicklungs-Workflow integrieren

Die wichtigste kulturelle Veränderung besteht darin, Accessibility von einer Pre-Launch-Checkliste zu einer kontinuierlichen Praxis zu machen. Viele Organisationen machen den Fehler, sie als einmaligen Audit zu behandeln, den sie beauftragen, wenn sie eine Klage befürchten, statt als Qualitätsstandard, der in jeden Sprint eingebettet ist. Wenn ein Audit Probleme in einem produktiven System aufdeckt, sind die Kosten für deren Behebung fünf- bis zehnmal höher, als sie es in der Designphase gewesen wären.

Beginnen Sie damit, Accessibility-Kriterien zu einem Teil Ihrer Definition of Done zu machen. Wenn ein Entwickler eine neue Komponente ausliefert, sollte automatisch ein schneller automatisierter Check laufen. Wenn eine Designerin ein neues Pattern erstellt, sollten Farbkontrast und Fokuszustände überprüft werden, bevor das Design überhaupt übergeben wird. Wenn eine Content-Redakteurin ein neues Bild hinzufügt, sollte sie genau wissen, wie aussagekräftiger Alt-Text aussieht – nicht nur, dass Alt-Text erforderlich ist.

Für Compliance-Manager ist die praktische Konsequenz Dokumentation. Einige Teams führen automatisierte Tests durch, gehen aber nie auf die Ergebnisse ein. Das bringt keinen Mehrwert und erzeugt Dokumentation, die zeigt, dass Sie von Problemen wussten, sie aber nicht behoben haben – problematisch in rechtlichen Situationen. Ein Accessibility-Programm ist nur dann verteidigungsfähig, wenn Sie einen angemessenen, ernsthaften Prozess kontinuierlicher Verbesserung nachweisen können: regelmäßige Scans, dokumentierte Ergebnisse, ein Fahrplan zur Behebung und Belege dafür, dass Sie auf das Gelernte reagieren. WCAG-Konformität ist kein binärer Zustand, den man einmal erreicht – sie ist eine Haltung, die man aufrechterhält.

Tools wie Accsible existieren, um diesen gestuften Ansatz zu unterstützen – indem sie ein SDK bereitstellen, das Accessibility-Verbesserungen direkt in das Nutzererlebnis einbettet, Probleme in Echtzeit sichtbar macht und den manuellen Audit-Prozess ergänzt, statt zu versuchen, ihn zu ersetzen. Das richtige Overlay oder SDK ist kein magischer Schutzschild gegen Klagen; es ist eine Komponente eines durchdachten Programms, das anerkennt, was Automatisierung leisten kann und was nicht.

Wesentliche Erkenntnisse

• Automatisierte Scanner sind ein Startpunkt, keine Ziellinie. Selbst die besten Tools erkennen nur zwischen 30% und 57% der tatsächlichen WCAG-Verstöße. Ein sauberer Scanbericht bedeutet nicht, dass Ihre Website barrierefrei ist – er bedeutet, dass die erkennbare Teilmenge der Probleme adressiert wurde.
• Die Mehrheit der WCAG-Erfolgskriterien erfordert menschliches Urteil. Screenreader-Erlebnis, logische Lesereihenfolge, aussagekräftige Linktexte im Kontext, kognitive Klarheit und komplexe Tastaturinteraktionen sind alles Bereiche, in denen Automatisierung strukturell nicht in der Lage ist, eine verlässliche Antwort zu geben.
• Das rechtliche Umfeld ist feindlich gegenüber Selbstzufriedenheit. Über 5.100 bundesweite ADA-Website-Klagen wurden 2025 eingereicht, Einigungen kosten routinemäßig 30.000–85.000 $ plus Verteidigungskosten, und fast die Hälfte der Beklagten war bereits zuvor verklagt worden – was darauf hindeutet, dass oberflächliche Korrekturen nicht ausreichen.
• Eine Drei-Schichten-Strategie – automatisiertes Scanning, manuelle Experten-Audits und echte Tests mit assistiven Technologien – kann die Abdeckung auf 80–90% erhöhen und verschafft Ihnen die dokumentierte, ernsthafte Compliance-Haltung, die Gerichte und Aufsichtsbehörden erwarten.
• Verlagern Sie Accessibility nach links. Probleme in der Design- und Entwicklungsphase zu erkennen, kostet nur einen Bruchteil dessen, was die Behebung nach dem Launch kostet. Integrieren Sie automatisierte Checks in CI/CD, machen Sie Accessibility zu einem Teil Ihrer Definition of Done und führen Sie regelmäßige manuelle Audits für Ihre meistfrequentierten User Journeys durch.