{"id":750296,"date":"2026-01-27T08:21:10","date_gmt":"2026-01-27T08:21:10","guid":{"rendered":"https:\/\/www.europesays.com\/de\/750296\/"},"modified":"2026-01-27T08:21:10","modified_gmt":"2026-01-27T08:21:10","slug":"automatisierte-accessibility-pruefung-im-web-moeglichkeiten-und-grenzen","status":"publish","type":"post","link":"https:\/\/www.europesays.com\/de\/750296\/","title":{"rendered":"Automatisierte Accessibility-Pr\u00fcfung im Web: M\u00f6glichkeiten und Grenzen"},"content":{"rendered":"

close notice<\/p>\n

\n This article is also available in
\n English<\/a>.<\/p>\n

It was translated with technical assistance and editorially reviewed before publication.\n <\/p>\n

\n Don\u2019t show this again.\n<\/p>\n

Mit dem European Accessibility Act (EAA) und seiner nationalen Umsetzung durch das Barrierefreiheitsst\u00e4rkungsgesetz (BFSG) gelten seit Juni 2025 in Deutschland verbindliche Anforderungen f\u00fcr zahlreiche digitale Produkte und Dienstleistungen. Parallel dazu wurden die organisatorischen Voraussetzungen geschaffen: Die zust\u00e4ndige Markt\u00fcberwachungsbeh\u00f6rde ist eingerichtet und nimmt schrittweise ihre Arbeit auf. Damit r\u00fcckt Barrierefreiheit f\u00fcr viele Unternehmen erstmals in den konkreten Fokus von Compliance, Risikoabw\u00e4gung und Produktverantwortung.<\/p>\n

Weiterlesen nach der Anzeige<\/p>\n

\"Maria<\/p>\n

\n Maria Korneeva ist Frontend Technology Lead und Google Developer Expert mit Fokus auf Angular und Barrierefreiheit. Sie arbeitet freiberuflich an Frontend-Anwendungen, leitet Workshops und teilt ihre Erfahrungen auf Konferenzen und Meetups sowie in ihrem Buch \u201eBarrierefreie Webentwicklung: von den Grundlagen bis zur praktischen Umsetzung\u201c.\n <\/p>\n

Und es w\u00e4chst der Wunsch nach effizienten, skalierbaren L\u00f6sungen. Viele Organisationen hoffen auf automatisierte Accessibility-Checks als schnellen und m\u00f6glichst vollst\u00e4ndigen Weg zur Konformit\u00e4t. Entsprechend popul\u00e4r sind Linter, Browser-Extensions, CI\/CD-Integrationen und KI-gest\u00fctzte Pr\u00fcfwerkzeuge. Automatisierung ist dabei ein wichtiges und sinnvolles Werkzeug \u2013 doch sie hat klare technische Grenzen.<\/p>\n

Denn zahlreiche Barrieren lassen sich nicht maschinell erkennen. Sie entstehen durch fehlenden Kontext, unklare Bedeutung, komplexe Interaktionen oder mangelnde Verst\u00e4ndlichkeit \u2013 Aspekte, die menschliches Urteilsverm\u00f6gen erfordern. Dieser Artikel zeigt, welche Arten von Accessibility-Tools es gibt, welche Aufgaben sie sinnvoll \u00fcbernehmen k\u00f6nnen und warum ein erheblicher Teil der Barrieren auch mit modernster Automatisierung unsichtbar bleibt.<\/p>\n

Testwerkzeuge und ihre Grenzen<\/p>\n

Um die M\u00f6glichkeiten und Grenzen automatisierter Barrierefreiheitspr\u00fcfungen zu verstehen, lohnt sich zun\u00e4chst ein Blick auf die unterschiedlichen Werkzeugtypen und darauf, welche Aspekte von Accessibility sie jeweils erfassen k\u00f6nnen.<\/p>\n

Linter<\/strong> sind statische Analysetools f\u00fcr 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\u00fcber, wie sich Seiten im Browser verhalten, wie Fokusabl\u00e4ufe funktionieren oder ob interaktive Komponenten korrekt reagieren. Statische Tools sehen nur Code \u2013 nicht Nutzung.<\/p>\n

Weiterlesen nach der Anzeige<\/p>\n

Browser-Extensions<\/strong> analysieren hingegen das Document Object Model (DOM) im gerenderten Zustand und k\u00f6nnen so mehr erkennen als statische Analyzer. Dennoch bleiben sie \u201eSnapshot-Tools\u201c: Sie bewerten einen Zustand, aber nicht die Interaktion \u00fcber mehrere Schritte hinweg. Komplexe Fokus\u00e4nderungen, Tastaturfallen oder dynamisch aktualisierte Inhalte bleiben typischerweise unsichtbar.<\/p>\n

Unit-Test-Plug-ins<\/strong> sind n\u00fctzlich, um bestimmte einzelne Komponenten auf Barrieren zu pr\u00fcfen. Allerdings decken Unit-Tests die Funktionalit\u00e4t (zum Beispiel Tastaturbedienbarkeit) nur einer Komponente ab und bilden typischerweise keine vollst\u00e4ndigen Nutzerflows ab.<\/p>\n

End-to-End-Testtools<\/strong> bieten eine gr\u00f6\u00dfere Abdeckung. Sie k\u00f6nnen komplexere Interaktionen simulieren, etwa die Fokussteuerung beim \u00d6ffnen und Schlie\u00dfen eines Modals, also eines Dialogs, der sich \u00fcber die Inhalte der Seite legt und oft eine zus\u00e4tzliche Aktion beinhaltet. An solche Testszenarien m\u00fcssen Entwicklerinnen und Entwickler jedoch selbst denken. Werden Accessibility-Plug-ins integriert, lassen sich einige Aspekte automatisiert pr\u00fcfen. Das umfangreichste Ergebnis erh\u00e4lt man, indem man Testf\u00e4lle f\u00fcr wichtige Prozesse selbst schreibt und zus\u00e4tzlich verschiedene Zust\u00e4nde seiner Website \u00fcber automatisierte Plug-ins pr\u00fcfen l\u00e4sst. Doch auch dann bleibt ein grunds\u00e4tzliches Problem: End-to-End-Tests wissen nicht, ob ein Bedienablauf \u201elogisch\u201c oder \u201everst\u00e4ndlich\u201c ist. Sie f\u00fchren Befehle aus \u2013 aber sie \u201eerleben\u201c die Nutzung nicht so, wie es ein Mensch tut.<\/p>\n

CI\/CD-Scanner<\/strong> automatisieren Pr\u00fcfungen im Build- oder Deployment-Prozess. Sie eignen sich besonders gut daf\u00fcr, typische fehlerhafte Muster fr\u00fchzeitig 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\u00fcfen Code, Struktur und einfache Interaktionen \u2013 aber keine komplexen Navigationsabl\u00e4ufe oder inhaltlichen Bedeutungen.<\/p>\n

Alle diese Werkzeuge leisten wertvolle Beitr\u00e4ge im Entwicklungsprozess. Doch wie viel Testaufwand lassen sie noch \u00fcbrig?<\/p>\n

\"enterJS<\/p>\n

\n (Bild:\u00a0jaboy\/123rf.com)\n <\/p>\n

Mehr \u00fcber Accessibility im Web<\/a> erf\u00e4hrst du auf der enterJS 2026<\/a> am 16. und 17. Juni in Mannheim. Die Konferenz dreht sich rund um die JavaScript\/TypeScript-Entwicklung im Enterprise-Bereich. Verg\u00fcnstigte Fr\u00fchbuchertickets<\/a> sind im Online-Ticketshop erh\u00e4ltlich.<\/p>\n

Wie viel Automatisierung wirklich leisten kann: Erkenntnisse aus Studien und Praxis<\/p>\n

Mehrere Studien haben untersucht, wie hoch der Anteil der Barrieren ist, den automatisierte Tools tats\u00e4chlich erkennen k\u00f6nnen. Eine umfassende Analyse<\/a> 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\u00fctzung will das Unternehmen sogar gut 80 Prozent erreicht haben<\/a>.<\/p>\n

Accessibility-Praktikerinnen und -Praktiker sehen die Wirksamkeit der automatisierten Tools deutlich eingeschr\u00e4nkter und sch\u00e4tzen, dass sich nur 20 bis 40 Prozent<\/a> der potenziellen Barrieren technisch erkennen lassen. Mehrere Expertinnen und Experten, darunter Adrian Roselli<\/a> und Steven Faulkner<\/a>, berichten aus umfangreichen Feldtests, dass automatisierte Checks sogar nur 4 bis 10 Prozent der wirklichen Probleme erkennen.<\/p>\n

Womit l\u00e4sst sich diese Diskrepanz in den Sch\u00e4tzungen erkl\u00e4ren? Nat\u00fcrlich unterscheiden sich die Zahlen der Marketing-Abteilung und der unabh\u00e4ngigen Accessibility-Beratung, weil sie damit unterschiedliche Ziele verfolgen. Auch die absichtlich eingef\u00fcgten Bugs, die die Testseiten enthalten, unterscheiden sich, und somit auch die Testergebnisse. WCAG-Versionen (Web Content Accessibility Guidelines), genutzte Tools \u2013 all das sorgt f\u00fcr eine hohe Varianz in Sch\u00e4tzungen.<\/p>\n

Trotz der Unterschiede zeigen diese Zahlen eindeutig, dass die existierenden Tools noch nicht hundertprozentig beurteilen k\u00f6nnen, ob eine Website barrierefrei ist. Selbst die formelle Pr\u00fcfung der WCAG-Kriterien ist noch nicht zu 100 Prozent automatisiert m\u00f6glich.<\/p>\n

Typische Limitierungen und Fallbeispiele<\/p>\n

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\u00dft, wie sie programmatisch zur Verf\u00fcgung gestellt werden und wie verst\u00e4ndlich sie formuliert sind.<\/p>\n

Automatisierte Accessibility-Tools k\u00f6nnen in erster Linie Strukturen, Muster und technische Eigenschaften pr\u00fcfen. Sie erkennen fehlende Attribute, inkorrekte Rollen oder syntaktische Fehler \u2013 aber sie verstehen nicht, was Inhalte bedeuten, wie Nutzerinnen und Nutzer mit einer Anwendung interagieren oder wie logisch ein Interface aufgebaut ist.<\/p>\n

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\u00e4tsstufen A und AA (siehe Infokasten) im Fokus, da sie von s\u00e4mtlichen Barrierefreiheitsgesetzen als rechtliche Anforderung genannt werden. Die WCAG-Richtlinien basieren auf den Grundprinzipien der Barrierefreiheit f\u00fcr Webinhalte \u2013 Wahrnehmbarkeit, Bedienbarkeit, Verst\u00e4ndlichkeit und Robustheit. Rund um diese Prinzipien sind auch die Beispiele in diesem Artikel gruppiert.<\/p>\n

Die Web Content Accessibility Guidelines (WCAG) sind ein internationaler Standard des World Wide Web Consortium (W3C) zur barrierefreien Gestaltung von Webinhalten. Sie definieren pr\u00fcfbare Erfolgskriterien, die sich an vier Grundprinzipien orientieren: wahrnehmbar, bedienbar, verst\u00e4ndlich und robust<\/strong>.<\/p>\n

Die WCAG unterscheiden drei Konformit\u00e4tsstufen<\/strong>, die unterschiedliche Ebenen von Wirkung, Aufwand und fachlicher Komplexit\u00e4t<\/strong> der Anforderungen beschreiben:<\/p>\n