Automatisierte Tests können im Entwicklungsprozess fest verankert werden und bieten damit einen guten Einstieg in die digitale Barrierefreiheit sowie einen Überblick über den Verlauf eines Projekts. Manuelle Prüfungen ersetzen sie aber auch heute noch nicht.
Worum es bei digitaler Barrierefreiheit geht
Digitale Barrierefreiheit beschäftigt sich mit jenen Barrieren, die beim Nutzen von digitalen Produkten oder Dienstleistungen auftreten, sei es in einem Web-Portal zur Buchung eines Hotels, im Online-Shop eines Versandhandels oder auf einer Informationsseite der Stadt.
Für viele dieser Angebote ist Barrierefreiheit inzwischen auch rechtlich verpflichtend. Der European Accessibility Act (EAA, Richtlinie 2019/882) legt fest, dass bestimmte Produkte und Dienstleistungen – etwa E-Commerce, Bankdienstleistungen oder Buchungsplattformen – barrierefrei anzubieten sind. In Österreich setzt das Barrierefreiheitsgesetz (BaFG) diese Richtlinie um; seine Anforderungen gelten seit dem 28. Juni 2025 und regeln, welche Unternehmen in ihren digitalen Angeboten Konformität herstellen müssen. Für Websites und Apps öffentlicher Stellen, wie etwa die erwähnte Informationsseite der Stadt, gilt bereits seit Längerem das Web-Zugänglichkeits-Gesetz (WZG).
Digitale Barrierefreiheit wird in ihrer gängigsten Form anhand sogenannter Erfolgskriterien gemessen. Diese werden durch die Web Accessibility Initiative (WAI) des World Wide Web Consortiums (W3C) unter dem Namen Web Content Accessibility Guidelines (WCAG) veröffentlicht. Gruppiert werden die Kriterien nach den Prinzipien der Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit.
In erster Linie klingt die Prüfung von Barrierefreiheit im Web also nach einem rechtlichen Problem. Man prüft, um keine Strafe zu riskieren. Diese Mentalität ist leider in vielen Köpfen verankert.
Dabei geht digitale Barrierefreiheit uns alle etwas an. Einer der größten Risikofaktoren, um selbst von digitalen Barrieren betroffen zu sein, ist nämlich das Alter. Ältere Nutzer:innen brauchen häufig größeren, kontrastreicheren Text, klarere Seiten-Navigation und weniger komplexe Interaktionen, um sich gut auf Seiten zurechtzufinden.
Nun stellt sich natürlich die Frage, wie man seine Inhalte auf Barrierefreiheit testet.
Ein einfacher und günstiger Einstieg dafür sind automatisierte Barrierefreiheitstests. Das sind Webseiten oder Programme, in denen man Inhalte einfügt, um dann sofort einen Ergebnisbericht zu erhalten. Im Grunde genommen macht der Test dabei nichts anderes, als den angegebenen Inhalt unter Anwendung der WCAG-Kriterien regelbasiert zu überprüfen. Wichtig zur Einordnung ist, dass sich nur ein Teil der Kriterien überhaupt automatisiert prüfen lässt – wie groß dieser Anteil ist, hängt von Tool und Zählweise ab (siehe Quelle 1). Das Ergebnis ist daher immer nur ein Richtungsweiser: Selbst wenn keine Fehler gefunden werden, heißt das nicht, dass die Seite auch wirklich barrierefrei ist.
Für eine vollständige Analyse braucht es immer manuelle Tests von Expert:innen, in denen die Seite nicht nur technisch, sondern besonders auf die Leitfragen von Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit geprüft wird.
Warum automatisierte Tests so wertvoll sind
Automatisierte Tests sind schnell, wiederholbar und objektiver als das eigene Bauchgefühl. Bei großen Websites und komplexen Applikationen können durch automatisierte Tests viele Probleme zeitnah gefunden werden, noch bevor eine manuelle Prüfung stattfindet. Für Teams, die noch keine Expertise in der digitalen Barrierefreiheit haben, sind automatische Tests ein leichter Einstieg in die Thematik. Neben den fachlichen Problemen werden in den Berichten oft bereits für Entwickler:innen aufbereitete Problemstellen aufgelistet, die dann direkt priorisiert abgearbeitet werden können.
Verschiedene Werkzeuge in diesem Bereich gibt es seit vielen Jahren. Zu den bekanntesten zählen Tools wie axe, Lighthouse, WAVE und pa11y. Viele dieser Tools sind für Entwickler:innen gebaut, es gibt aber eine steigende Anzahl an benutzerfreundlichen Tools, die sich eher an Betreiber:innen von Webseiten oder Web-Apps richten, um einen ersten Überblick zu bekommen.
Automatisierte Tools – unverzichtbar oder Unsinn?
Automatisierte Tests können direkt in der Entwicklung genutzt werden, und für Entwickler:innen entsteht dadurch nur ein geringer Mehraufwand. Das hilft vor allem deshalb, weil digitale Barrierefreiheit sonst oft erst am Ende eines Projekts evaluiert wird. Wenn die Seite bereits fertig ist und kurz vor dem Release steht, wird digitale Barrierefreiheit plötzlich zum Thema und zu einem Aufwand am Ende eines Projekts. Mit laufenden automatisierten Tests kann zumindest ein Teil dieser Hürden entfernt werden.
Gerade bei größeren Projekten liefert das einen klaren Mehrwert. Speziell bei Web-Apps gibt es häufig unzählige Abhängigkeiten, Bibliotheken und Komponenten. Eine Änderung führt hier schnell zu einem Wasserfall-Effekt durch das gesamte Projekt. Wenn hier nicht regelmäßig geprüft wird, droht am Ende eine böse Überraschung.
Die W3C Web Accessibility Initiative empfiehlt, Barrierefreiheit früh und laufend während Design und Entwicklung zu prüfen. Sie sagt aber auch klar, dass kein Tool allein bestimmen kann, ob eine Website Accessibility-Standards erfüllt. Dafür braucht es menschliche Bewertung (siehe Quelle 2).
Die richtige Einordnung ist also für mich: Speziell in der Entwicklung sind automatisierte Tools ein Filter, um strukturierte Probleme bereits früh zu erkennen und direkt zu beheben, nicht erst kurz vor Projektende. Der manuelle Prüfbedarf am Ende bleibt zwar trotzdem, aber die einfachen Probleme sind davor schon gelöst.
Für Betreiber:innen von Web-Apps und Webseiten lassen sich diese Tools ähnlich nutzen: als Filter, um vor einer manuellen Prüfung einen Überblick zu bekommen, wo die Probleme liegen und was mit wenig Aufwand direkt behoben werden sollte.
Was ein Score aussagt
Viele Tools liefern am Ende eine Punktezahl, zum Beispiel 87 von 100 Punkten. Andere zeigen eine Liste mit Fehlern, Warnungen und Hinweisen. Beides hilft, weil Fortschritt sichtbar wird und eine Zahl intern oft leichter zu kommunizieren ist als eine lange Liste technischer Details.
Die Frage ist deshalb, was diese Zahl beschreibt: Ein Score ist kein Zertifikat und keine Aussage über alle Nutzungssituationen. Er beschreibt, was ein bestimmtes Tool zu einem bestimmten Zeitpunkt automatisch prüfen konnte.
Eine Website kann in einem automatisierten Test gut abschneiden und in der Bedienung schwer nutzbar sein. Die Tastatur-Reihenfolge kann unlogisch sein. Ein Cookie-Banner kann den Fokus blockieren. Ein Formular kann technisch gesehen Labels haben, während die Fehlermeldungen den Nutzer:innen nicht helfen. Ein Alternativtext kann vorhanden sein und am Inhalt vorbeigehen.
Die Punktezahl misst dabei nicht die Barrierefreiheit als Ganzes, sondern nur den Teil, der automatisiert überhaupt gemessen werden kann. Und darin liegt auch die Krux des Problems: Viele Seiten scheitern an den Grundlagen.
Was eigene Daten und aktuelle Studien zeigen
In einer ersten, nicht repräsentativen Auswertung von 230 automatisierten Tests auf barrieretest.at war das Ergebnis ernüchternd. Von 100 möglichen Punkten wurde im Durchschnitt ein Wert von 29,5 erreicht (siehe Quelle 3). Dieser Wert zeigt, dass hier noch viel Potenzial besteht, obwohl nicht alles automatisiert erkannt werden kann. Natürlich ist das keine repräsentative Studie, denn wer seine Website aktiv testet, vermutet vielleicht bereits Probleme. Weiters kann das Tool nur öffentlich erreichbare Seiten testen, also keine Logins, versteckte Zustände oder komplexe Checkout-Prozesse.
Zu den häufigsten Problemen in den Daten zählen zu geringer Kontrast, fehlende Alternativtexte, doppelte ID-Attribute, leere Links, leere Überschriften, Buttons ohne zugänglichen Namen und Formularfelder ohne Label (siehe Quelle 3). Solche Fehler entstehen in der Regel in schlecht gepflegten Komponenten. Oft reicht ein falsch gebautes Template für ein gängiges CMS-System, und derselbe Fehler taucht auf unzähligen Seiten wieder auf.
Internationale Daten zeigen ein ähnliches Bild. Der WebAIM Million Report 2026 untersuchte im Februar 2026 automatisiert die Startseiten der eine Million meistbesuchten Websites. 95,9 Prozent der untersuchten Startseiten hatten automatisch erkennbare WCAG-2-Konformitätsfehler – ein Anstieg gegenüber 94,8 Prozent im Jahr 2025, womit sich der Trend der leichten Verbesserungen der Vorjahre wieder umkehrte. Zu den häufigsten Problemen gehörten zu geringe Kontraste, fehlende Alternativtexte, fehlende Formularlabels, leere Links, leere Buttons und eine fehlende Dokument-Sprache (siehe Quelle 4).
In den Daten erkennt man klar, dass es bereits seit Jahren um dieselben Fehlerarten geht. Das Wissen ist online abrufbar, die Werkzeuge sind vorhanden, aber dieselben Barrieren werden trotzdem immer wieder erneut eingebaut.
Was automatisierte Tools gut können
Überall dort, wo es klar definierte Regeln ohne Interpretationsspielraum gibt, können automatische Tests helfen. Wenn ein Button oder ein Link keinen zugänglichen Namen hat oder der Kontrast einer Überschrift nicht stimmt – diese Fehler finden automatisierte Tools in Sekunden.
Besonders gut erkennbar sind automatisiert vor allem die folgenden Probleme:
- Bilder ohne alt-Attribut
- Formularfelder ohne Label
- Buttons ohne zugänglichen Namen
- Links ohne verständlichen Text
- bestimmte Kontrastprobleme
- problematische ARIA-Verwendung
- fehlende Dokument-Sprache
- strukturelle HTML-Probleme
Was automatische Tests nicht sehen
Manuelle Prüfung braucht es überall dort, wo menschliches Feingefühl notwendig ist. Wenn der Nutzerfluss uneindeutig ist, Inhalte schwer verständlich formuliert sind oder Buttons nicht erkennen lassen, was beim Klick passiert – überall dort braucht es fachliche Expertise und manuelle Tests.
Ähnlich ist es bei Buttons, Formularen und Fehlermeldungen. Die Fehlermeldung kann technisch korrekt verknüpft sein, aber wenn der Fehler nicht verständlich beschrieben ist, kann dadurch trotzdem eine Barriere entstehen.
Manuell geprüft werden sollte vor allem:
- Ist der vorhandene Alternativtext im Zusammenhang sinnvoll?
- Ist die Tastatur-Reihenfolge logisch?
- Ist der Fokus immer klar erkennbar?
- Funktionieren Navigationen, Menüs, Modals, Banner und Formulare auch ohne Maus?
- Sind Fehlermeldungen verständlich und richtig zugeordnet?
- Versteht ein Screenreader die Struktur auf der Seite?
- Bleibt die Seite auch nach dem Zoomen nutzbar?
Am allerwichtigsten ist aber die Frage, ob wichtige Aufgaben abgeschlossen werden können. Kann jemand Kontakt aufnehmen, ein Produkt kaufen, ein Formular abschicken oder einen Termin buchen? Dort merkt man, ob Barrierefreiheit auch im Alltag funktioniert.
Die Rolle von KI
KI kann automatisierte Tests sinnvoll ergänzen. Der größte Nutzen liegt hier aus meiner Sicht zwischen dem Testbericht und der Umsetzung. In diesem Artikel ist mit KI vor allem ein LLM (Large Language Model), also ein großes Sprachmodell, gemeint, um nicht unnötig zu verkomplizieren.
Ein klassisches Tool meldet zum Beispiel: „Element does not have an accessible name.“ Für Entwickler:innen ist das meist verständlich. Projektleitung, Redaktion oder Geschäftsführung brauchen oft eine andere Übersetzung: Dieser Button hat keinen Namen, der von einem Screenreader vorgelesen werden kann. Nutzer:innen hören dann möglicherweise nur „Button“ und wissen nicht, welche Aktion ausgelöst wird.
An dieser Stelle kann KI helfen, indem sie technische Meldungen erklärt, ähnliche Probleme gruppiert, mögliche Auswirkungen beschreibt und aus einem Testergebnis ein verständliches Ticket macht. Sie kann auch Vorschläge für Linktexte, Buttontexte oder Alternativtexte liefern, solange diese Vorschläge fachlich geprüft werden.
Auf barrieretest.at gibt es optional eine KI-gestützte Analyse. In der ersten Auswertung wurde diese Funktion bei 49 von 230 Audits aktiviert. In 92 Prozent dieser Fälle meldete die KI zusätzliche potenzielle Probleme, die der regelbasierte Test nicht erkannt hatte. Im Durchschnitt kamen damit 2,3 zusätzliche Hinweise pro Prüfung dazu (siehe Quelle 3).
Die KI-gestützte Analyse von barrieretest.at orientiert sich dabei an den Prompts der Studie „How an LLM Can Improve Automatic Web Accessibility Validation“ (siehe Quelle 5), in der die Forschenden darlegen, dass das LLM bei den definierten Prüffragen in 92,4 Prozent der Fälle Fehler korrekt gefunden hat. Zur Einordnung ist hier aber auch wichtig: Selbst in diesem systematischen Test wurde keine 100-prozentige Zuverlässigkeit erreicht. Auch für die Prüffragen des LLMs braucht es also abschließend eine menschliche Prüfung.
Für Projekte konkret bedeutet das: KI kann erklären, vorsortieren und Vorschläge vorbereiten. Die Bewertung muss aber bei den Menschen bleiben, die den Inhalt, die Zielgruppe und auch den Nutzungskontext kennen.
Ein sinnvoller Prüfprozess
Aus diesen Erkenntnissen lässt sich ein sinnvoller Prüfprozess ableiten, der zeitnah zu echten Ergebnissen führt:
Schritt 1: Automatischen Check früh starten
Der automatische Test sollte nicht kurz vor dem Launch zum ersten Mal laufen. Je früher offensichtliche Probleme gefunden werden, desto günstiger lassen sie sich beheben.
Starten Sie mit den wichtigsten Seitentypen: Startseite, Kontaktseite, Formularseiten, Produktseiten, Login, Checkout oder Buchungsstrecken. Prüfen Sie die Seiten, auf denen Nutzer:innen wirklich etwas erledigen müssen.
Schritt 2: Ergebnisse verstehen und gruppieren
Nach dem Test entsteht oft eine lange Liste mit Meldungen. Diese Liste sollte nicht blind abgearbeitet werden. Prüfen Sie zuerst, ob Muster erkennbar sind: Tritt derselbe Fehler auf vielen Seiten auf, kommt er aus einer Komponente, betrifft er ein CMS-Template, entsteht er durch redaktionelle Eingaben oder blockiert er eine wichtige Nutzeraufgabe?
So werden aus vielen Einzelfunden wenige sinnvolle Arbeitspakete.
Schritt 3: Offensichtliche technische Fehler beheben
Viele automatisch gefundene Probleme sollten direkt korrigiert werden. Dazu gehören fehlende Labels, leere Buttons, fehlende Dokument-Sprache, grobe Kontrastprobleme oder leere Links.
Diese Fehler müssen nicht erst in einer manuellen Prüfung diskutiert werden. Ein Formularfeld ohne Label, ein Button ohne zugänglichen Namen oder Text mit zu geringem Kontrast ist ein reales Problem.
Schritt 4: Tastaturtest durchführen
Legen Sie danach die Maus zur Seite und navigieren Sie mit Tab, Shift + Tab, Enter, Leertaste und Esc durch die Website. Achten Sie darauf, ob alle wichtigen Funktionen erreichbar sind und ob immer sichtbar bleibt, wo sich der Fokus befindet.
Besonders relevant sind Menüs, Dialoge, Cookie-Banner, Formulare und alles, was sich öffnen, schließen oder absenden lässt. Viele Probleme fallen erst auf, wenn die Maus weg ist.
Schritt 5: Screenreader-Stichprobe machen
Eine Screenreader-Stichprobe ersetzt keinen Test durch erfahrene Screenreader-Nutzer:innen; als erster Realitätscheck ist sie gut geeignet. Prüfen Sie zum Beispiel mit NVDA, VoiceOver oder TalkBack, ob Überschriften, Links, Buttons, Formularfelder und Fehlermeldungen verständlich ausgegeben werden.
Auch hier lohnt sich der Blick auf die wichtigen Abläufe: Suche, Navigation, Login, Checkout, Buchung, Kontaktformular. Mit der Startseite allein sieht man zu wenig.
Schritt 6: Kritische Nutzerflüsse prüfen
Barrierefreiheit zeigt sich im Ablauf. Ein Kontaktformular kann gut aussehen und beim Absenden scheitern. Ein Shop kann auf der Startseite solide Werte haben und im Checkout unbenutzbar werden. Eine Buchungsstrecke kann visuell klar wirken und mit Tastatur oder Screenreader unverständlich sein.
Prüfen Sie deshalb echte Aufgaben: Kontaktformular ausfüllen, Pflichtfeld leer lassen, Fehlermeldung korrigieren, Produkt suchen und kaufen, Termin buchen, Login durchführen, Passwort zurücksetzen, Dokument finden und herunterladen.
Der Idealfall reicht für diese Prüfung nicht aus. Gerade Fehlerzustände zeigen, ob eine Website Menschen gut unterstützt.
Schritt 7: Wiederkehrende Probleme an der Ursache beheben
Barrieren entstehen selten als einzelne Ausrutscher; meistens kommen sie aus Systemen. Wenn alle Buttons schlecht beschriftet sind, liegt das Problem wahrscheinlich in der Button-Komponente. Wenn alle Formulare ähnliche Fehler haben, sollte die Formularkomponente verbessert werden. Wenn Redakteur:innen regelmäßig schlechte Linktexte oder leere Überschriften erzeugen, braucht es bessere Vorgaben im CMS.
Nachhaltige Barrierefreiheit entsteht an diesen Ursachen: Farben im Designsystem verbessern, Fokuszustände klar definieren, Formulare mit Labels und Fehlermeldungen bauen, CMS-Felder verständlicher gestalten, Redakteur:innen zu Alternativtexten und Linktexten schulen und automatisierte Tests regelmäßig wiederholen.
Fazit
Automatisierte Barrierefreiheitstests sind ein guter Einstieg, weil sie typische technische Probleme schnell finden und Teams früher zum Handeln bringen können. Der Score hilft bei der Einordnung, aber als Urteil über eine gesamte Seite ist er nicht geeignet.
Wer seine Website prüfen möchte, sollte mit einem automatischen Test beginnen und danach kritische Stellen manuell prüfen oder von Expert:innen bewerten lassen. So entsteht aus einer Punktezahl am Ende ein brauchbarer Prüfprozess.
Über den Autor
DI Andreas Steinkellner ist Software-Entwickler und UX-Consultant aus Graz. Mit Solasit unterstützt er Unternehmen bei nutzerzentrierter Webentwicklung und digitaler Barrierefreiheit. Er betreibt außerdem barrieretest.at, ein kostenloses Tool für automatisierte Barrierefreiheitstests und ist Co-Founder der Acurion OG.
Quellen
- Deque Systems: The Automated Accessibility Coverage Report. Nach dieser Auswertung von rund 300.000 Fehlern aus Erst-Audits lassen sich nur etwa 16 von 50 WCAG-2.1-AA-Erfolgskriterien (ca. 20–30 Prozent) automatisiert prüfen; gemessen am Fehlervolumen wurden jedoch 57,38 Prozent der gefundenen Probleme automatisiert erkannt.
- W3C Web Accessibility Initiative (WAI): Evaluating Web Accessibility Overview. Die W3C WAI empfiehlt, Barrierefreiheit früh und laufend im Entwicklungsprozess zu evaluieren, und weist darauf hin, dass kein Tool allein bestimmen kann, ob eine Website Accessibility-Standards erfüllt.
- Andreas Steinkellner / Solasit: 230 Accessibility-Audits: Was die Daten zeigen, 12. Februar 2026. Die Zahlen im Beitrag beziehen sich auf diese erste Auswertung von barrieretest.at.
- WebAIM: The WebAIM Million – 2026 Report. WebAIM untersuchte im Februar 2026 die Startseiten der Top 1.000.000 Websites mit der WAVE-Engine.
- Fabio Paternò, Manuela Vinci, Marco Manca, Nicola Iannuzzi: How an LLM Can Improve Automatic Web Accessibility Validation.