Niedrigschwellige Barrierefreiheitsprüfung ohne technisches Vorwissen

Die Prüfung digitaler Lehrmaterialien auf Barrierefreiheit setzt in der Regel Fachwissen zu Standards wie WCAG sowie technische Kenntnisse (z. B. im Umgang mit Testtools) voraus – Wissen, das den meisten Lehrenden erfahrungsgemäß fehlt. Ohne eigenständige Prüfmöglichkeit bleibt Barrierefreiheit deshalb oft eine abstrakte Anforderung, die nicht konkret überprüft und nachgebessert wird.

Als Grundlage für die Prüfkriterien wurden WCAG/BITV herangezogen und daraus ein eigener Kriterienkatalog abgeleitet. Da nicht alle WCAG/BITV-Kriterien für Moodle- und ILIAS-Kurse zwingend erforderlich sind, wurden diese gezielt ausgewählt. Technisch basiert die automatisierte Prüfung auf der „OpenA11y Evaluation Library“, die wir für die Besonderheiten von Moodle und ILIAS erweitert und angepasst haben. Für Kriterien, die sich nicht automatisch erfassen lassen, führt eine programmgestützte, schrittweise Anleitung durch die manuelle Prüfung – verständlich formuliert, ohne dass Lehrende Testverfahren oder Regelwerke im Detail kennen müssen.

Die Testkomponente ist einer von vier Bereichen des DACHS-Portals. Neben des manuellen Uploads von LMS-Kursen zur Barrierefreiheitsprüfung können Moodle-Kurse über ein Plugin auch direkt automatisiert ins Portal exportiert werden.

Für dieses Vorgehen braucht es:

1. einen aus WCAG/BITV abgeleiteten, aber gezielt auf die eigene Zielumgebung zugeschnittenen Kriterienkatalog (nicht alle Standardkriterien sind überall relevant);

2. eine geeignete Ausgangsbasis für automatisierte Prüfungen, z. B. eine bestehende Open-Source-Bibliothek, die sich erweitern lässt, statt alles neu zu entwickeln;

3. eine verständliche, konsequent laiengerecht formulierte Führung durch die nicht automatisierbaren Prüfschritte.

Das Vorgehen eignet sich für Projekte, die

• eine Zielgruppe ohne technisches Fachwissen befähigen wollen, komplexe Qualitätskriterien in Bezug auf Barrierefreiheit selbst zu prüfen,

• einen Prüfgegenstand haben, der sich automatisiert und/oder manuell beziehungsweise geführt bewerten lässt, und

• bei Bedarf über eine technische Anbindung an die genutzten Systeme verfügen.

Weniger geeignet, wenn sich die Kriterien nicht sinnvoll in automatisierbare und geführte manuelle Schritte aufteilen lassen.

Erwartungsgemäß ermöglichte die automatisierte Prüfung eine schnelle erste Einschätzung ohne, dass technisches Vorwissen vorausgesetzt wird. Unerwartet zeigte sich in der Alpha-Testphase, dass die ursprünglich technisch formulierten Prüfkriterien und Anleitungen für Lehrende trotzdem zu unverständlich waren – ein Zeichen dafür, dass die Einschätzung der Texte als „ohne technisches Wissen verständlich“ fehlerhaft war.

Auch wenn „kein technisches Vorwissen nötig“ von Anfang an das Ziel war, waren die ersten Formulierungen der Prüfkriterien und Anleitungen zu technisch – das wurde erst durch das Feedback der Lehrenden in der Alpha-Testphase ersichtlich. Erst nach einer kompletten sprachlichen Überarbeitung aller Regeln bestätigte die Beta-Testphase, dass die Verständlichkeit nun passte. Laienverständlichkeit lässt sich im Entwickler*innenteam kaum zuverlässig selbst einschätzen und muss aktiv mit der Zielgruppe getestet werden.

Zunächst wurde im DACHS-Projekt die „axe-core-Bibliothek“ als Grundlage für die automatisierte Prüfung eingesetzt, sich dann aber bewusst für die „OpenA11y Evaluation Library“ entschieden, da diese aus Sicht der Entwickler*innen mehr und qualitativ bessere Prüfungen mitbrachte. Rückblickend wird empfohlen, verfügbare Bibliotheken frühzeitig anhand konkreter eigener Testfälle zu vergleichen, statt sich zu früh auf eine Lösung festzulegen.

Formulieren Sie Prüfkriterien und Anleitungen von Anfang an so einfach wie möglich – und verlassen Sie sich nicht auf die eigene Einschätzung, ob das verständlich genug ist, sondern testen Sie explizit mit fachfremden Personen. Prüfen Sie außerdem frühzeitig, welche WCAG/BITV-Kriterien für Ihre Zielumgebung überhaupt relevant sind, statt den vollständigen Katalog unreflektiert zu übernehmen. Nutzen Sie bestehende Open-Source-Bibliotheken als Ausgangsbasis, statt automatisierte Prüfungen komplett neu zu entwickeln.

Der Pflegeaufwand für die Prüfkriterien ist nicht zu unterschätzen: Beachten Sie, dass Prüfkriterien im Laufe der Zeit angepasst oder ergänzt werden müssen.