Automatisierte Accessibility-Prüfung im Web: Möglichkeiten und Grenzen
Tools können dabei helfen, die Barrierefreiheit von Webanwendungen zu prüfen – doch an zahlreichen Stellen bleibt menschliches Verständnis gefragt.
(Bild: Dilok Klaisataporn/Shutterstock.com)
- Maria Korneeva
Mit dem European Accessibility Act (EAA) und seiner nationalen Umsetzung durch das Barrierefreiheitsstärkungsgesetz (BFSG) gelten seit Juni 2025 in Deutschland verbindliche Anforderungen für zahlreiche digitale Produkte und Dienstleistungen. Parallel dazu wurden die organisatorischen Voraussetzungen geschaffen: Die zuständige Marktüberwachungsbehörde ist eingerichtet und nimmt schrittweise ihre Arbeit auf. Damit rückt Barrierefreiheit für viele Unternehmen erstmals in den konkreten Fokus von Compliance, Risikoabwägung und Produktverantwortung.
Und es wächst der Wunsch nach effizienten, skalierbaren Lösungen. Viele Organisationen hoffen auf automatisierte Accessibility-Checks als schnellen und möglichst vollständigen Weg zur Konformität. Entsprechend populär sind Linter, Browser-Extensions, CI/CD-Integrationen und KI-gestützte Prüfwerkzeuge. Automatisierung ist dabei ein wichtiges und sinnvolles Werkzeug – doch sie hat klare technische Grenzen.
Denn zahlreiche Barrieren lassen sich nicht maschinell erkennen. Sie entstehen durch fehlenden Kontext, unklare Bedeutung, komplexe Interaktionen oder mangelnde Verständlichkeit – Aspekte, die menschliches Urteilsvermögen erfordern. Dieser Artikel zeigt, welche Arten von Accessibility-Tools es gibt, welche Aufgaben sie sinnvoll übernehmen können und warum ein erheblicher Teil der Barrieren auch mit modernster Automatisierung unsichtbar bleibt.
Videos by heise
Testwerkzeuge und ihre Grenzen
Um die Möglichkeiten und Grenzen automatisierter Barrierefreiheitsprüfungen zu verstehen, lohnt sich zunächst ein Blick auf die unterschiedlichen Werkzeugtypen und darauf, welche Aspekte von Accessibility sie jeweils erfassen können.
Linter sind statische Analysetools für Quellcode. Sie erkennen syntaktische oder strukturelle Fehler, etwa ob ein alt-Attribut fehlt oder ein Button kein Label besitzt. Allerdings haben sie keine Kenntnis darüber, wie sich Seiten im Browser verhalten, wie Fokusabläufe funktionieren oder ob interaktive Komponenten korrekt reagieren. Statische Tools sehen nur Code – nicht Nutzung.
Browser-Extensions analysieren hingegen das Document Object Model (DOM) im gerenderten Zustand und können so mehr erkennen als statische Analyzer. Dennoch bleiben sie „Snapshot-Tools“: Sie bewerten einen Zustand, aber nicht die Interaktion über mehrere Schritte hinweg. Komplexe Fokusänderungen, Tastaturfallen oder dynamisch aktualisierte Inhalte bleiben typischerweise unsichtbar.
Unit-Test-Plug-ins sind nützlich, um bestimmte einzelne Komponenten auf Barrieren zu prüfen. Allerdings decken Unit-Tests die Funktionalität (zum Beispiel Tastaturbedienbarkeit) nur einer Komponente ab und bilden typischerweise keine vollständigen Nutzerflows ab.
End-to-End-Testtools bieten eine größere Abdeckung. Sie können komplexere Interaktionen simulieren, etwa die Fokussteuerung beim Öffnen und Schließen eines Modals, also eines Dialogs, der sich über die Inhalte der Seite legt und oft eine zusätzliche Aktion beinhaltet. An solche Testszenarien müssen Entwicklerinnen und Entwickler jedoch selbst denken. Werden Accessibility-Plug-ins integriert, lassen sich einige Aspekte automatisiert prüfen. Das umfangreichste Ergebnis erhält man, indem man Testfälle für wichtige Prozesse selbst schreibt und zusätzlich verschiedene Zustände seiner Website über automatisierte Plug-ins prüfen lässt. Doch auch dann bleibt ein grundsätzliches Problem: End-to-End-Tests wissen nicht, ob ein Bedienablauf „logisch“ oder „verständlich“ ist. Sie führen Befehle aus – aber sie „erleben“ die Nutzung nicht so, wie es ein Mensch tut.
CI/CD-Scanner automatisieren Prüfungen im Build- oder Deployment-Prozess. Sie eignen sich besonders gut dafür, typische fehlerhafte Muster frühzeitig aufzudecken und Regressionen zu vermeiden. Ihre Grenzen sind jedoch die gleichen wie die der zugrunde liegenden Tools. Ob man Linter, Browsererweiterungen, Unit-Tests oder End-to-End-Tests einbindet: Sie prüfen Code, Struktur und einfache Interaktionen – aber keine komplexen Navigationsabläufe oder inhaltlichen Bedeutungen.
Alle diese Werkzeuge leisten wertvolle Beiträge im Entwicklungsprozess. Doch wie viel Testaufwand lassen sie noch übrig?
(Bild: jaboy/123rf.com)
Mehr über Accessibility im Web erfährst du auf der enterJS 2026 am 16. und 17. Juni in Mannheim. Die Konferenz dreht sich rund um die JavaScript/TypeScript-Entwicklung im Enterprise-Bereich. Vergünstigte Frühbuchertickets sind im Online-Ticketshop erhältlich.
Wie viel Automatisierung wirklich leisten kann: Erkenntnisse aus Studien und Praxis
Mehrere Studien haben untersucht, wie hoch der Anteil der Barrieren ist, den automatisierte Tools tatsächlich erkennen können. Eine umfassende Analyse des Accessibility-Software-Anbieters Deque Systems ergab 2024, dass dessen automatisierte Tests etwa 57 Prozent aller Accessibility-Probleme in realen Audits identifizieren konnten. Mit KI-Unterstützung will das Unternehmen sogar gut 80 Prozent erreicht haben.
Accessibility-Praktikerinnen und -Praktiker sehen die Wirksamkeit der automatisierten Tools deutlich eingeschränkter und schätzen, dass sich nur 20 bis 40 Prozent der potenziellen Barrieren technisch erkennen lassen. Mehrere Expertinnen und Experten, darunter Adrian Roselli und Steven Faulkner, berichten aus umfangreichen Feldtests, dass automatisierte Checks sogar nur 4 bis 10 Prozent der wirklichen Probleme erkennen.
Womit lässt sich diese Diskrepanz in den Schätzungen erklären? Natürlich unterscheiden sich die Zahlen der Marketing-Abteilung und der unabhängigen Accessibility-Beratung, weil sie damit unterschiedliche Ziele verfolgen. Auch die absichtlich eingefügten Bugs, die die Testseiten enthalten, unterscheiden sich, und somit auch die Testergebnisse. WCAG-Versionen (Web Content Accessibility Guidelines), genutzte Tools – all das sorgt für eine hohe Varianz in Schätzungen.
Trotz der Unterschiede zeigen diese Zahlen eindeutig, dass die existierenden Tools noch nicht hundertprozentig beurteilen können, ob eine Website barrierefrei ist. Selbst die formelle Prüfung der WCAG-Kriterien ist noch nicht zu 100 Prozent automatisiert möglich.
Typische Limitierungen und Fallbeispiele
Auch wenn Barrierefreiheit deutlich mehr als stupide Einhaltung der WCAG-Erfolgskriterien erfordert, stellen diese Richtlinien eine fundierte Checkliste zum Einstieg dar. Die darin enthaltenen Anforderungen betreffen sowohl die technische als auch die semantische Seite der Inhalte, das heißt, wie sie programmatisch zur Verfügung gestellt werden und wie verständlich sie formuliert sind.
Automatisierte Accessibility-Tools können in erster Linie Strukturen, Muster und technische Eigenschaften prüfen. Sie erkennen fehlende Attribute, inkorrekte Rollen oder syntaktische Fehler – aber sie verstehen nicht, was Inhalte bedeuten, wie Nutzerinnen und Nutzer mit einer Anwendung interagieren oder wie logisch ein Interface aufgebaut ist.
Deswegen lohnt sich der Blick auf die WCAG-Kriterien aus folgender Perspektive: Welche Anforderungen betreffen nicht nur Strukturen und formelles Vorhandensein von bestimmten Elementen, sondern auch Aspekte wie intuitive Nutzung, Interpretation, Kontext und Relevanz? Dabei stehen die Kriterien der Konformitätsstufen A und AA (siehe Infokasten) im Fokus, da sie von sämtlichen Barrierefreiheitsgesetzen als rechtliche Anforderung genannt werden. Die WCAG-Richtlinien basieren auf den Grundprinzipien der Barrierefreiheit für Webinhalte – Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit. Rund um diese Prinzipien sind auch die Beispiele in diesem Artikel gruppiert.
Die Web Content Accessibility Guidelines (WCAG) sind ein internationaler Standard des World Wide Web Consortium (W3C) zur barrierefreien Gestaltung von Webinhalten. Sie definieren prüfbare Erfolgskriterien, die sich an vier Grundprinzipien orientieren: wahrnehmbar, bedienbar, verständlich und robust.
Die WCAG unterscheiden drei Konformitätsstufen, die unterschiedliche Ebenen von Wirkung, Aufwand und fachlicher Komplexität der Anforderungen beschreiben:
- Stufe A
Anforderungen mit grundlegender Wirkung auf die Barrierefreiheit und vergleichsweise geringem Umsetzungsaufwand. Ohne ihre Erfüllung ist eine Nutzung für viele Menschen mit Behinderungen kaum oder gar nicht möglich (z. B. Alternativtexte für Bilder, Tastaturbedienbarkeit). - Stufe AA
Anforderungen mit hoher Wirkung für eine breite Nutzer:innengruppe, die zentrale Barrieren im Nutzungskontext abbauen, aber bereits ein höheres Maß an gestalterischem, redaktionellem und technischem Barrierefreiheits-Know-how erfordern (z. B. ausreichende Farbkontraste, verständliche Beschriftungen, konsistente Navigation).
Diese Stufe gilt in der Praxis als maßgeblicher rechtlicher Standard und wird von nahezu allen Barrierefreiheitsgesetzen gefordert. - Stufe AAA
Anforderungen mit sehr spezifischer Wirkung für einzelne Nutzergruppen, die mit hohem konzeptionellem, technischem oder organisatorischem Aufwand verbunden sind und daher nicht für alle Inhalte realistisch umsetzbar sind (z. B. Gebärdensprachversionen).
