Accessibility Testing: Methoden und Prüfansätze

Automatisierte Prüfwerkzeuge analysieren den DOM einer Webseite und prüfen gegen eine Regelbasis. Sie können erkennen, ob Bilder Alt-Texte haben, ob Formularfelder Labels besitzen, ob Farbkontraste den Schwellenwert erreichen und ob die Heading-Hierarchie korrekt ist. Was sie nicht prüfen können: Ob der Alt-Text den Bildinhalt korrekt beschreibt, ob die Fokusreihenfolge logisch ist, ob dynamische Inhalte für Screenreader zugänglich sind und ob die Seite kognitiv verständlich ist.

Laut Untersuchungen des W3C/WAI finden automatisierte Prüfwerkzeuge im Durchschnitt 57% (WebAIM, 2025) der auf einer Seite vorhandenen Barrierefreiheitsprobleme. Die übrigen Probleme betreffen Aspekte, die menschliches Urteilsvermögen erfordern: Ist der Linktext aussagekräftig? Ist die Tab-Reihenfolge sinnvoll? Funktioniert das Fokusmanagement bei Modalfenstern? Wird dynamischer Inhalt korrekt angekündigt? Diese Fragen kann nur ein manueller Tester beantworten.

Automatisierte Tests sind dennoch unverzichtbar als erste Prüfschicht und für die kontinuierliche Überwachung. Sie identifizieren schnell die offensichtlichen Probleme: fehlende Alt-Texte, Kontrastverstöße, fehlende Labels und ARIA-Fehler. Diese Low-Hanging-Fruits sollten behoben werden, bevor die aufwendigere manuelle Prüfung beginnt. In CI/CD-Pipelines verhindern automatisierte Tests, dass neue Barrieren in den Code gelangen.

Automatisierte Prüfwerkzeuge gibt es als Browser-Erweiterungen, als in die Browser-Entwicklertools integrierte Module und als Kommandozeilen-Werkzeuge für die Pipeline. Gemeinsam ist ihnen, dass sie die aktuelle Seite gegen eine WCAG-Regelbasis prüfen. Die Ergebnisse werden in der Regel nach Schweregrad gruppiert (kritisch, schwer, moderat, gering) und enthalten Beschreibungen des Problems, des betroffenen Elements und einen Lösungshinweis. Für eine fundierte Einordnung bündeln wir diese Erkenntnisse in unserem WCAG-Audit.

Viele dieser Prüf-Engines liegen als Open-Source-Bibliotheken vor und lassen sich in automatisierte Test-Pipelines integrieren. In Kombination mit Testing-Frameworks können die Prüfungen bei jedem Build oder Pull Request ausgeführt werden. Das stellt sicher, dass keine neuen Barrierefreiheitsprobleme in den Produktivcode gelangen. Für bestehende Projekte empfehlen wir einen Baseline-Scan, der den aktuellen Stand dokumentiert, gefolgt von einer schrittweisen Reduktion der Fehler.

Manche Werkzeuge erweitern den reinen Automatik-Scan um geführte manuelle Tests, die den Prüfer durch Kriterien leiten, die nicht automatisiert prüfbar sind. Solche geführten Tests kombinieren automatisierte Erkennung mit manueller Bestätigung und decken so einen größeren Teil der WCAG-Kriterien ab als ein rein automatisierter Lauf -- ersetzen jedoch nicht die vollständige Experten-Prüfung.

Viele Browser-Entwicklertools und Online-Prüfdienste geben die Barrierefreiheit als Punktwert von 0 bis 100 aus, oft zusammen mit Performance, SEO und Best Practices. Dieser Wert basiert auf einer gewichteten Bewertung der automatisch gefundenen Probleme. Ein Score von 100 bedeutet nicht, dass die Seite barrierefrei ist, sondern nur, dass keine automatisch erkennbaren Probleme gefunden wurden.

Solche Scores nutzen häufig dieselben Open-Source-Prüf-Engines wie die spezialisierten Werkzeuge, ergänzen aber eigene Checks. Die Ergebnisse sind weniger detailliert als bei einer dedizierten Prüfung, bieten aber einen schnellen Überblick und sind besonders nützlich für Entwickler, die Barrierefreiheit als Teil ihres regulären Development-Workflows prüfen möchten.

Wichtig ist das Verständnis der Limitierungen: Ein Accessibility-Score von 100 bedeutet lediglich, dass die automatisiert prüfbaren Kriterien erfüllt sind. Die Seite kann dennoch schwerwiegende Barrieren aufweisen, die nur manuell erkennbar sind. Wir empfehlen, den Score als Hygienefaktor zu behandeln: Ein niedriger Wert zeigt definitiv Probleme an, ein hoher Wert beweist aber nicht die Barrierefreiheit.

Automatisierte Barrierefreiheitstests entfalten ihren größten Nutzen, wenn sie in die CI/CD-Pipeline integriert werden. Bei jedem Code-Commit prüft eine automatisierte Prüf-Engine alle gerenderten Seiten auf WCAG-Verstöße. Neue Barrieren werden erkannt, bevor sie in die Produktionsumgebung gelangen. Solche Prüfwerkzeuge lassen sich nahtlos in Build-Prozesse einbinden und blockieren Deployments, wenn kritische Barrierefreiheitsfehler gefunden werden.

Laut einer Erhebung von WebAIM (2025) reduzieren Unternehmen mit CI/CD-integriertem Accessibility Testing die Anzahl der Barrierefreiheits-Regressionen um 78 Prozent (Projekterfahrung) im Vergleich zu manuellen Prüfzyklen. Der Aufwand für die Einrichtung ist überschaubar -- in den meisten Fällen genügt die Konfiguration einer automatisierten Prüf-Engine als Testschritt in der bestehenden Pipeline. Die professionelle Einrichtung stellt sicher, dass die Tests korrekt konfiguriert sind und aussagekräftige Ergebnisse liefern.

Der manuelle Tastatur-Test ist der wichtigste Einzeltest für die Barrierefreiheit. Er erfordert keine Tools, nur die Tastatur: Mit Tab und Shift+Tab durch die Seite navigieren, mit Enter und Space Elemente aktivieren, mit Escape Modals schließen und mit Pfeiltasten in Widgets navigieren. Dabei wird systematisch geprüft: Ist jedes interaktive Element erreichbar? Ist die Reihenfolge logisch? Ist der Fokus immer sichtbar? Gibt es Keyboard-Traps?

Der Tastatur-Test deckt mehrere WCAG-Kriterien gleichzeitig ab: 2.1.1 (Keyboard), 2.1.2 (No Keyboard Trap), 2.4.3 (Focus Order), 2.4.7 (Focus Visible) und 2.4.11 (Focus Not Obscured). Diese Kriterien können nicht automatisiert geprüft werden, da sie das Verhalten der Seite bei Interaktion betreffen. Ein erfahrener Tester kann einen vollständigen Tastatur-Test der wichtigsten Seitentypen in einer bis zwei Stunden durchführen.

Screenreader-Tests simulieren die Nutzung der Website durch blinde und sehbehinderte Menschen. Der Tester navigiert mit dem in Windows oder macOS verfügbaren Screenreader durch die Seite und prüft, ob alle Inhalte zugänglich sind. Werden Landmarks korrekt erkannt? Sind die Überschriften hierarchisch korrekt? Haben alle Bilder Alt-Texte? Sind Formulare korrekt beschriftet? Werden dynamische Inhalte über Live Regions angekündigt?

Der Screenreader-Test deckt Probleme auf, die weder automatisierte Tools noch der Tastatur-Test erkennen: Sinnlose Alt-Texte, die zwar vorhanden sind aber den Bildinhalt nicht beschreiben, ARIA-Attribute, die zwar gesetzt sind aber falsche Werte haben, Live Regions, die nicht funktionieren, und semantische Strukturen, die für Screenreader verwirrend sind.

Wir empfehlen Tests mit mindestens zwei verschiedenen Screenreadern, da jeder Screenreader ARIA-Attribute und HTML-Semantik leicht unterschiedlich interpretiert. Die Kombination aus dem Windows-Screenreader und dem macOS-Screenreader deckt den Großteil der Nutzer ab. Für mobile Optimierung ergänzen wir Tests mit den in iOS und Android integrierten Screenreadern.

Die Prüfung der kognitiven Barrierefreiheit ist der am schwierigsten zu standardisierende Bereich. WCAG 2.2 enthält mehrere Kriterien, die kognitive Zugänglichkeit adressieren: 3.3.7 (Redundant Entry), 3.2.6 (Consistent Help), 3.3.8 (Accessible Authentication) und die grundlegenden Verständlichkeitskriterien der Guideline 3.1. Die Prüfung erfordert die Bewertung, ob Texte verständlich formuliert sind, ob Fehlermeldungen hilfreich sind und ob der Seitenaufbau vorhersagbar ist.

Ein strukturierter kognitiver Walkthrough hilft, diese Kriterien systematisch zu prüfen: Der Tester durchläuft die wichtigsten Nutzungspfade der Website und bewertet an jedem Schritt, ob die Handlungsanweisung klar ist, ob der Nutzer erkennen kann, welche Aktion nötig ist, ob Feedback verständlich und zeitnah erfolgt und ob der Nutzer sich orientieren kann. Diese Methode identifiziert Barrieren, die für alle Nutzer relevant sind, besonders aber für Menschen mit kognitiven Einschränkungen.

Farbkontraste gehören zu den häufigsten Barrierefreiheits-Problemen: 86 Prozent (WebAIM Million Analysis, 2025) der meistbesuchten Websites verstoßen gegen die WCAG-Kontrastanforderungen. Die Prüfung ist dabei vergleichsweise einfach: Das WCAG-Kontrastminimum beträgt 4,5:1 für normalen Text und 3:1 für großen Text (ab 18pt oder 14pt fett). Automatisierte Kontrast-Prüfwerkzeuge berechnen das Kontrastverhältnis für beliebige Farbkombinationen und zeigen sofort, ob die Anforderung erfüllt ist.

Über das reine Kontrastverhältnis hinaus prüfen spezialisierte Tools die Lesbarkeit unter verschiedenen Sehbedingungen: Simulationen für Farbenblindheit (Protanopie, Deuteranopie, Tritanopie), Sehschärfereduktion und Katarakt zeigen, wie Inhalte für betroffene Nutzer erscheinen. Diese Simulationen decken Probleme auf, die bei reiner Kontrastmessung nicht sichtbar werden -- etwa zwei Farben mit ausreichendem Kontrast, die bei Rot-Grün-Schwäche nicht mehr unterscheidbar sind. Eine professionelle Barrierefreiheitsprüfung kombiniert automatisierte Kontrastprüfung mit visuellen Simulationen für ein vollständiges Bild.

Die Schriftprüfung ergänzt die Farbprüfung: Neben dem Kontrast beeinflussen Schriftgröße, Zeilenabstand und Zeichenabstand die Lesbarkeit maßgeblich. WCAG 2.2 fordert, dass Nutzer Text auf bis zu 200 Prozent vergrößern können, ohne dass Inhalte abgeschnitten werden oder die Funktionalität leidet. Responsive Designs, die ausschließlich mit Viewport-Einheiten arbeiten, erfüllen diese Anforderung oft nicht, weil die Schriftgröße an die Bildschirmbreite statt an die Nutzereinstellungen gekoppelt ist.

User Testing mit Menschen mit Behinderungen ist die aussagekräftigste Form der Barrierefreiheitsprüfung. Kein automatisiertes Tool und kein Experten-Test kann die reale Nutzungserfahrung ersetzen. Nutzer mit verschiedenen Behinderungen verwenden ihre assistiven Technologien auf individuelle Weise und stoßen auf Barrieren, die Tester nicht vorhersehen können.

Für ein aussagekräftiges User Testing empfehlen wir die Einbeziehung von mindestens fünf Nutzern mit verschiedenen Behinderungsarten: Screenreader-Nutzer (blinde Nutzer), Nutzer mit Sehbeeinträchtigung (Zoom, hoher Kontrast), Tastaturnutzer (motorische Einschränkung), Nutzer mit kognitiven Einschränkungen und Nutzer mit Hörbeeinträchtigung. Die Tests werden als moderierte Usability-Tests durchgeführt, bei denen die Nutzer typische Aufgaben auf der Website erledigen.

Die Erkenntnisse aus User Tests fließen direkt in den Maßnahmenplan ein und haben die höchste Priorität, da sie reale Nutzungsbarrieren dokumentieren. User Testing sollte nicht einmalig durchgeführt werden, sondern regelmäßig wiederholt werden, insbesondere nach größeren Redesigns oder Feature-Updates. Die Schulungsangebote vermitteln Methoden zur Organisation und Durchführung von barrierefreiem User Testing.

Ein professionelles WCAG-Audit kombiniert alle beschriebenen Testmethoden zu einer umfassenden Prüfung. Der typische Ablauf beginnt mit der Auswahl repräsentativer Seiten: Startseite, Kategorieseite, Produktdetailseite, Checkout-Prozess, Kontaktformular, Login-Bereich und mindestens eine Inhaltsseite. Diese Stichprobe deckt die wichtigsten Seitentypen und Interaktionsmuster ab.

Jede ausgewählte Seite wird gegen alle relevanten WCAG 2.2 AA-Kriterien geprüft. Automatisierte Scans identifizieren die offensichtlichen Probleme. Manuelle Tests prüfen Tastaturnavigation, Screenreader-Kompatibilität und kognitive Verständlichkeit. Die Ergebnisse werden in einem priorisierten Maßnahmenplan zusammengefasst: Kritische Probleme (blockieren den Zugang), schwere Probleme (erhebliche Beeinträchtigung), moderate Probleme (störend, aber umgehbar) und leichte Probleme (Verbesserungspotenzial).

Der Maßnahmenplan enthält für jedes Problem eine Beschreibung, die betroffene Seite und das betroffene Element, das verletzte WCAG-Kriterium, die Priorität und einen konkreten Lösungsvorschlag. Auf Basis des Plans kann die Umsetzung systematisch erfolgen und der Fortschritt nachverfolgt werden. Ein Re-Audit nach der Umsetzung validiert die Korrekturen und identifiziert gegebenenfalls neue Probleme.

Die Dokumentation des Audits ist ebenso wichtig wie die Durchführung: Ein professioneller WCAG-Audit-Bericht listet nicht nur die gefundenen Probleme auf, sondern priorisiert sie nach Schweregrad, betroffener Nutzergruppe und Aufwand der Behebung. Kritische Barrieren, die den Zugang vollständig blockieren (z.B. nicht bedienbare Formulare, fehlende Alternativtexte für zentrale Inhalte), stehen ganz oben. Mittlere Probleme beeinträchtigen die Nutzererfahrung, verhindern aber nicht den Zugang. Niedrige Prioritäten sind Optimierungsmöglichkeiten, die die Barrierefreiheit verbessern, aber keine Pflichtanforderung verletzen. Diese Priorisierung ermöglicht eine schrittweise Barrierefreiheits-Umsetzung mit dem größten Nutzen zuerst.