Barrierefreiheit testen: manuell oder automatisiert?

Kurz gesagt: Es gibt drei Möglichkeiten, die digitale Barrierefreiheit zu testen.

• Automatisierte Scans

• Manuelle Tests.

• Hybrider Ansatz

Automatisierte Tests haben 57,38 % der Barrierefreiheitsprobleme gefunden, gemessen im Automated Accessibility Coverage Report von Deque über mehr als 13.000 Seiten und rund 300.000 Befunde. Der Rest braucht menschliches Urteil.

Manuelle vs. automatisierte Barrierefreiheitstests: der direkte Vergleich

• Manuelle Tests rechnen sich dort, wo Automatisierung nicht hinkommt: Qualität von Alternativtexten, Fokusreihenfolge, Fehlermeldungen, und ob jemand mit einem Screenreader die Aufgabe tatsächlich abschließen kann. Manuelle Tests passen zu neuen Features, zur User Experience (UX), zu komplexen Abläufen, zu explorativem Testen und zu einmaligen Testfällen.

• Automatisierung kostet vorne mehr und pro Durchlauf deutlich weniger. Die Rechnung dreht sich, sobald Tests sich wiederholen. Genau deshalb gehört sie in Continuous-Integration- und Continuous-Delivery-Pipelines (CI/CD) und in Regressionssuiten.

• Ein hybrides Setup folgt der Testpyramide: automatisierte Prüfungen an der Basis für die Menge, manuelle Tests und Tests mit assistiven Technologien an der Spitze für das Urteil.

Worum es bei beiden Testarten geht

Manuelles Testen der Barrierefreiheit bedeutet, dass eine Person die Oberfläche Schritt für Schritt durchgeht, oft mit assistiver Technologie, und beurteilt, ob die Nutzung tatsächlich funktioniert.

Die testende Person beobachtet das Verhalten, bewertet das Ergebnis anhand der Web Content Accessibility Guidelines (WCAG) und stößt unterwegs auf Barrieren, die niemand erwartet hat. Perspektive, Intuition und Erfahrung tragen den größten Teil.

Automatisiertes Testen der Barrierefreiheit bedeutet, dass die Prüfungen einmal als Skript oder Code hinterlegt sind und danach wiederholt gegen das Produkt laufen.

Teams hängen diese Tests meist in ihre Build- und Deployment-Prozesse. Das Ziel: schnell und verlässlich feststellen, ob bestehende Funktionen nach einer Änderung noch korrekt arbeiten.

Beide Ansätze bewerten dasselbe Produkt. Sie unterscheiden sich in Ablauf, Aufwand, Tempo und Wartbarkeit.

Wann welcher Ansatz sinnvoll ist

Automatisiertes Testen

• Am besten für: Tempo, Regressionstests in großer Menge, Integration in die CI/CD-Pipeline und Skalierung über jedes Release.

• Was es findet: fehlende Labels, unzureichende Kontrastwerte, fehlende Alt-Attribute sowie strukturelle WCAG-Verstöße auf Komponentenebene.

• Grenzen: Es kann nicht beurteilen, ob ein Alternativtext sinnvoll ist, ob eine Fehlermeldung verständlich bleibt oder ob ein komplexer Ablauf in der Praxis nutzbar ist.

Manuelles Testen

• Am besten für: Nutzbarkeit im Alltag, menschliche Wahrnehmung, komplexe Nutzungswege und exploratives Testen.

• Was es findet: Barrieren bei der Tastaturbedienung, die logische Fokusreihenfolge, das Verhalten im Screenreader, verständliche Fehlerbehebung und kontextabhängige Barrieren.

• Grenzen: langsamere Ausführung, höhere Personalkosten pro Durchlauf und schwer skalierbar für Nightly Builds oder große Regressionssuiten.

Eine gute Teststrategie nutzt die Stärken von beidem und streicht dabei Doppelarbeit und unnötige Kosten.

Was manuelle Barrierefreiheitstests ausmacht

Der Ablauf

Manuelles Testen umfasst jede Testaktivität, bei der Menschen Testfälle ohne technische Automatisierung ausführen.

Ein typischer Ablauf:

Schritt 1: Den Umfang festlegen Die Produktgrenze, die WCAG-Version und Konformitätsstufe (meist 2.1 AA oder 2.2 AA) sowie die Kombinationen aus Browser und Screenreader. Dieselbe Seite verhält sich in NVDA mit Firefox anders als in VoiceOver mit Safari, deshalb gehört die Kombination in den Umfang.

Schritt 2: Das Produkt erkunden Erfasse die Templates, die geteilten Komponenten und die vollständigen Prozesse wie Registrierung und Checkout. Geteilte Komponenten wiegen am schwersten: Ein defektes Navigationsmuster wiederholt sich auf jeder Seite, die es nutzt.

Schritt 3: Eine repräsentative Stichprobe wählen Niemand testet jede Seite. Nimm eine Instanz jedes Templates, jeden Schritt jedes Prozesses und obendrauf eine Zufallsauswahl.

Schritt 4: Die Stichprobe bewerten Mehrere Durchgänge über denselben Screen:

• Nur Tastatur: Alles erreichen, sehen, wo du gerade bist, aus jeder Komponente wieder herauskommen, die Aufgabe abschließen.

• Screenreader: Hören, was die Seite ansagt, in jeder Kombination im Umfang.

• Zoom und Reflow. Text auf 200 %, Layout auf 320 CSS-Pixel Breite.

• Formulare: Sagt die Fehlermeldung, was schiefging und wie es weitergeht, und landet der Fokus an einer sinnvollen Stelle?

• Kontrast und Bewegung: Die tatsächlich gerenderten Farben messen, danach mit reduzierter Bewegung erneut prüfen.

Schritt 5: Berichten Jeder Befund trägt ein Erfolgskriterium, eine Konformitätsstufe und seine Auswirkung auf die Nutzung. Genau das macht die Dokumentation später für eine Barrierefreiheitserklärung verwendbar, und es sagt dem Team, welche Korrektur zuerst dran ist.

Neben skriptbasierten manuellen Tests spielt exploratives Testen eine große Rolle. Tester:innen bewegen sich frei durch das Produkt und finden Barrieren aus Sicht der Nutzung.

Typische Einsatzfälle

Manuelles Testen ist überall dort am stärksten, wo menschliche Wahrnehmung entscheidet:

• UX- und Usability-Tests: Wie fühlt sich der Ablauf an? Sind Beschriftungen und Fehlermeldungen verständlich?

• Exploratives Testen: In frühen Entwicklungsphasen oder nach einer größeren Änderung.

• Abnahmetests: Gemeinsam mit Fachbereichen oder Product Ownern.

• Ad-hoc-Tests: Nach einer dringenden Korrektur oder einem Hotfix.

• Komplexe End-to-End-Prozesse: Systeme mit vielen Komponenten, die sich noch häufig ändern.

• Tests mit Menschen mit Behinderungen: Die einzige Methode, die zeigt, ob ein Ablauf in der Praxis nutzbar ist und nicht nur auf dem Papier konform.

Stärken und Grenzen

Stärken manueller Tests:

• Hohe Flexibilität, wenn Anforderungen unklar sind oder sich bewegen.

• Berücksichtigt subjektive Eindrücke und die gelebte Erfahrung der Menschen, die das Produkt nutzen.

• Niedrige Einstiegshürde, sodass auch Fachbereiche mittesten können.

• Ideal für einmalige oder stark variable Testfälle.

Grenzen manueller Tests:

• Langsame Ausführung bei großen Testsuiten.

• Hoher Personalaufwand, der die Kosten treibt.

• Risiko menschlicher Fehler und uneinheitlicher Ausführung.

• Selten praktikabel für häufige Regressionstests oder Nightly Builds.

Was automatisierte Barrierefreiheitstests ausmacht

Der Ablauf

Automatisiertes Testen der Barrierefreiheit kombiniert UI-Engines wie Playwright oder Cypress mit Regel-Engines wie axe-core. Weil die Regeln bereits in der Engine stecken, liegt die Arbeit in Konfiguration, Zustandsabdeckung und Triage statt im Schreiben eigener Assertions.

Ein typischer Ablauf:

Schritt 1: Das Regelwerk konfigurieren Lege WCAG-Version und Konformitätsstufe fest und entscheide, welche optionalen Best-Practice-Regeln mitlaufen. Standardkonfigurationen melden Dinge, die keine Konformitäts Verstöße sind, und das ist der schnellste Weg, das Vertrauen des Teams in die Ergebnisse zu verlieren.

Schritt 2: Entscheiden, wo die Prüfungen laufen, Auf Komponentenebene ist es am günstigsten: Ein einmal geprüfter Button deckt jede Seite ab, die man nutzt. Auf Seitenebene zeigt sich, was erst im Zusammenspiel entsteht, etwa Überschriftenhierarchie und Landmark-Struktur. Die meisten Teams brauchen beides.

Schritt 3: Das Produkt vor dem Scan in jeden Zustand bringen Der Schritt, den allgemeine Automatisierungsratgeber auslassen, und der darüber entscheidet, ob die Suite etwas taugt. Ein Scanner liest das Dokument so, wie er es vorfindet. Ein nicht geöffnetes Modal, ein nicht abgeschicktes Formular und ein eingeklapptes Menü sind für ihn unsichtbar. Das Skript muss vorher öffnen, absenden und ausklappen.

Schritt 4: Baseline setzen, dann auf neue Befunde prüfen Der erste Durchlauf gegen ein bestehendes Produkt liefert eine große Zahl. Halte sie als Baseline fest und lass den Build nur bei dem fehlschlagen, was danach dazukommt. Teams, die jeden Merge am vollständigen Ergebnis blockieren, schalten die Prüfung innerhalb eines Monats ab.

Schritt 5: Die „needs review"-Ergebnisse an einen Menschen geben axe-core liefert vier Kategorien: passes, violations, inapplicable und incomplete. Incomplete heißt, dass die Prüfung allein zu keinem Urteil kam. Diese Ergebnisse fallen häufiger unter den Tisch als alles andere, und ein spürbarer Teil der Befunde steckt genau dort.

Der Anfangsaufwand ist höher. Er zahlt sich aus, sobald die Tests häufig laufen.

Typische Einsatzfälle

Automatisierte Tests leisten das Beste bei:

• Regressionstests. Nach jedem Merge oder Release.

• Smoke- und Sanity-Tests. Um die grundlegende Funktionsfähigkeit schnell zu prüfen.

• API- und Integrationstests. Für stabile Schnittstellen.

• Performance- und Lasttests. Ohne Automatisierung praktisch nicht machbar.

• Qualitätssicherung in CI/CD. Automatische Prüfungen bei jedem Commit.

• Barrierefreiheits-Regressionen. Ein fehlendes Label oder ein gebrochener Kontrastwert fällt auf, sobald er in die Codebasis kommt.

Stärken und Grenzen

Stärken automatisierter Tests:

• Sehr schnelle Ausführung großer Testsuiten.

• Wiederholbarkeit und Konsistenz ohne Ermüdung.

• Skaliert mit wachsendem Produkt und häufigeren Releases.

• Über die Zeit kosteneffizient, wenn die Tests oft laufen.

Grenzen automatisierter Tests:

• Hoher Anfangsaufwand für Setup, Umsetzung und Infrastruktur.

• Laufende Wartungskosten, besonders bei einer sich schnell ändernden Oberfläche.

• Schlecht geeignet für visuelle, gestalterische oder subjektive Bewertung.

• Risiko eines grünen Builds, während kritische Szenarien ungeprüft bleiben.

Bei der Toolauswahl sollten Entwicklungs- und QA-Teams den Tech-Stack des Produkts abwägen, die Integration in die bestehende CI/CD-Umgebung, die Wartbarkeit der Testfälle, den Community-Support und die Fähigkeiten, die im Team schon vorhanden sind.

12 kostenlose Tools für Barrierefreiheits- und QA-Tests

Du brauchst kein Budget, um anzufangen. Diese Tools sind kostenlos, und die meisten Teams schaffen einen ersten Durchgang an einem Nachmittag.

Kostenlose automatisierte Barrierefreiheits-Scanner

• axe DevTools Browser-Erweiterung. Führt axe-core im Browser aus und weist jeden Befund dem passenden WCAG-Kriterium zu.

• WAVE. Die Erweiterung von WebAIM, mit einer visuellen Überlagerung, die zeigt, wo auf der Seite eine Barriere sitzt.

• Lighthouse. In den Chrome DevTools eingebaut, es gibt also nichts zu installieren.

• Accessibility Insights for Web. Microsofts Erweiterung, die zusätzlich zum automatischen Scan eine geführte manuelle Bewertung mitbringt.

• Der kostenlose Scan von Accessiway. Eine schnelle Ausgangsprüfung für jede öffentliche URL.

Kostenlose Tools für manuelle Prüfungen

• NVDA. Ein kostenloser Open-Source-Screenreader für Windows, und der schnellste Weg zu hören, was deine Oberfläche tatsächlich ansagt.

• ANDI. Ein kostenloses Bookmarklet, das Labels, Überschriften und Rollen Element für Element untersucht.

• Colour Contrast Analyser. Die kostenlose Desktop-App von TPGi, die jede Farbe auf dem Bildschirm misst und offline funktioniert.

Kostenlose QA-Automatisierungs-Frameworks

• Playwright. Open Source, browserübergreifend, mit gepflegter axe-core-Integration.

• Selenium. Die etablierte Open-Source-Option mit der breitesten Sprachunterstützung.

• Cypress. Open-Source-Kern, verbreitet für Frontend-End-to-End-Tests.

• axe-core. Die Open-Source-Engine unter den meisten der genannten Scanner. Einmal in eines der drei Frameworks eingebunden, laufen Barrierefreiheitsprüfungen mit dem Rest deiner Suite mit.

Ein Punkt, der klar gesagt gehört: Diese Tools finden Probleme, sie beheben sie nicht. Und kein Scanner, unserer eingeschlossen, ersetzt eine menschliche Prüfung bei Fragen wie der, ob ein Alternativtext das Richtige beschreibt.

Manuell vs. automatisiert: die Unterschiede auf einen Blick

Geschwindigkeit

Beim Tempo gewinnt die Automatisierung klar. Eine große Regressionssuite mit hunderten Testfällen läuft in Minuten, manuell würde dasselbe Stunden oder Tage dauern.

Kosten

Bei den Kosten ist das Bild differenzierter:

• Manuelle Tests haben niedrige Anfangskosten und hohe laufende Kosten pro Durchlauf.

• Automatisierte Tests haben hohe Anfangskosten (Automatisierung, Infrastruktur, Schulung) und niedrige Grenzkosten pro Wiederholung.

Ob sich Testautomatisierung rechnet, hängt daran, wie oft die Tests danach laufen. Bei häufigen Regressionstests, Continuous Integration und langfristig stabilen Anforderungen zahlt sie sich in der Regel aus.

Wartung

Die Wartung manueller Tests ist vor allem organisatorisch: Die Testfalldokumentation muss aktuell bleiben.

Bei automatisierten Tests brauchen Skripte, Testdaten und Umgebungen Pflege, und Änderungen an der Oberfläche machen das aufwendiger, als Teams erwarten.

Flexibilität

Manuelle Tests bieten die größte Flexibilität. Tester:innen wechseln spontan den Weg, probieren eine neue Idee und reagieren auf Unerwartetes.

Automatisierte Tests sind starrer und decken eng definierte Szenarien in hoher Struktur ab.

Abdeckung

Bei der Abdeckung liegen automatisierte Tests vorn, sobald viele Kombinationen und Regressionsszenarien im Spiel sind. Skripte gehen Eingabe- und Konfigurationsvarianten systematisch durch, was von Hand nicht realistisch ist.

Genauigkeit

Bei der Genauigkeit liefern automatisierte Skripte eine gleichbleibende Ausführung ohne Konzentrationsverlust.

Manuelles Testen bringt kontextabhängige Barrieren ans Licht, die niemand in einer technischen Prüfregel abgebildet hat.

Vergleichstabelle der wichtigsten Kriterien

Welche Teststrategie zu welchem Fall passt

Kleine Projekte und frühe Entwicklungsphasen: manuelles Testen

In einem kleinen Projekt oder in den ersten Sprints lohnt sich aufwendige Automatisierung meist noch nicht. Anforderungen bewegen sich schnell, die Oberfläche ist instabil, und viele Testfälle laufen nur einmal.

Was hier funktioniert:

• Exploratives manuelles Testen.

• Kurze Checklisten.

• Enge Zusammenarbeit zwischen Entwicklung, QA und Fachbereichen.

Starte die Automatisierung mit Unit-Tests und stabilen Kernfunktionen. Sobald sich die Anforderungen setzen, erhöhe den Automatisierungsgrad Schritt für Schritt.

Regression, CI/CD und große Testsuiten: automatisiertes Testen

Je größer das Produkt und je häufiger die Deployments, desto mehr zählt Automatisierung:

• Wiederkehrende Regressionstests nach jedem Release oder Feature-Branch.

• Qualitätssicherung in CI/CD-Pipelines, damit Probleme früh auffallen.

• Große, wiederverwendbare Testsuiten, die nachts oder bei jedem Commit laufen.

In dieser Größenordnung ist Automatisierung eine wirtschaftliche Notwendigkeit. Ohne sie steigen die Kosten wiederholter manueller Tests steil an oder Releases verschieben sich.

Eine praktikable Strategie umfasst:

• Eine breite Basis aus Unit- und API-Tests automatisieren.

• Kerngeschäftsprozesse mit robusten automatisierten End-to-End-Tests absichern.

• Die kritischen manuellen Tests für UX, seltene Randfälle und Abnahme behalten.

Hybrider Ansatz und die Testpyramide

Der hybride Ansatz verbindet manuelles und automatisiertes Testen entlang der Testpyramide:

Basis Viele schnelle, stabile Unit-Tests, fast vollständig automatisiert.

Mitte Eine moderate Anzahl automatisierter Integrations- und API-Tests.

Spitze Wenige, gezielte UI- und End-to-End-Tests, teils automatisiert, teils manuell.

Automatisierte Tests gehen dorthin, wo sie hohe Abdeckung zu geringen Kosten liefern. Manuelle Tests gehen dorthin, wo menschliches Urteil, Kreativität und Fachwissen gefragt sind.

Eine praktikable Aufgabenteilung:

• Entwickler:innen schreiben Unit- und Integrationstests, während sie neue Features bauen.

• QA automatisiert die kritischen End-to-End-Szenarien und Regressionssuiten.

• Fachbereiche übernehmen manuelle Abnahme- und UX-Tests.

• Menschen mit Behinderungen testen die wichtigsten Abläufe, über strukturierte Nutzertests.

Für Barrierefreiheit gilt genau diese Logik: WCAG 2.1 AA ist die technische Grundlage für die Konformität nach dem European Accessibility Act (EAA), nach dem deutschen Barrierefreiheitsstärkungsgesetz (BFSG) und nach dem österreichischen Barrierefreiheitsgesetz (BaFG), und sie steht ebenso hinter der harmonisierten Norm EN 301 549. Manche Erfolgskriterien sind maschinell prüfbar. Die meisten stellen eine Frage, die nur ein Mensch beantworten kann.

Häufige Fragen zu manuellen und automatisierten Barrierefreiheitstests

Wir haben keine QA-Rolle im Team. Wo fangen wir an?

Starte mit zwei Schritten, die keine Infrastruktur brauchen: Lass einen kostenlosen automatisierten Scanner über deine fünf wichtigsten Seiten laufen, und navigiere dieselben Seiten danach nur mit der Tastatur, also mit Tab, Enter und Escape.

Der Tastaturdurchgang findet die kritischen Barrieren, die Automatisierung strukturell nicht sehen kann, etwa eine Fokusfalle oder ein unsichtbares Menü. Trag die Befunde in das Ticketsystem ein, das dein Team ohnehin nutzt. Automatisierung lohnt sich erst, wenn dieselben Probleme nach Releases immer wiederkommen.

Ersetzt ein Barrierefreiheits-Widget oder Overlay die Notwendigkeit zu testen?

Nein. Widgets bieten hilfreiche Bedienelemente für Nutzer:innen, etwa zur Textvergrößerung, aber sie korrigieren nicht den zugrundeliegenden Code, stellen keine regulatorische Konformität her und ersetzen weder Tests noch Remediation.

Wie es weitergeht

Wenn du manuelles und automatisiertes Testen ehrlich vergleichst, die Wirtschaftlichkeit der Automatisierung einrechnest und eine klare Strategie festlegst, hebt dein Team die Qualität, ohne Kosten aufzubauen, die sich nicht rechtfertigen lassen.

Für ein erstes Bild vom Stand deiner Website kannst du einen kostenlosen Barrierefreiheits-Scan starten. Von dort verbindet unser barrierefreiheits audit automatisierte Abdeckung mit fachlicher manueller Prüfung und Tests durch Menschen mit Behinderungen, und die Plattform für digitale Barrierefreiheit hält die Ergebnisse für dein Team dauerhaft sichtbar.