Unter den Experten im Arbeitskreis Barrierefreiheit sind automatisierte Accessibility-Tests von Websites umstritten. Das Hauptargument der Gegner: Automatisierte Tests können nicht alle Fehler erkennen. Das Hauptargument der Befürworter: Ohne automatisierte Tests lässt sich die Qualität von großen Webprojekten nicht langfristig sicherstellen. Wir haben uns vor diesem Hintergrund entschlossen, eine „echte“ Website (www.bayern.de) sowohl manuell als auch automatisiert auf Barrierefreiheit zu testen, um anschließend insbesondere die Qualität bzw. den Umfang des automatisierten Tests bewerten zu können. Den Expertentest hat Jörg Morsbach durchgeführt; für die automatisierten Tests habe ich das aXe-Browser-Plugin von Deque und den Online-Check von Tenon.io eingesetzt. Wir haben uns auf die Startseite von bayern.de beschränkt.
Grenzen und Möglichkeiten der Automatisierung
Um die drei Tests vergleichen zu können, habe ich eine tabellarische Gegenüberstellung von Expertentest und automatischen Tests gemacht. Nicht in die Liste aufgenommen habe ich einige Best Practice Fehler von aXe, die keiner WCAG-Richtlinie zugeordnet waren.
Welche Fehler wurden zuverlässig von die automatisierten Tools erkannt und wo sind die Grenzen?
Sowohl aXe als auch Tenon.io erkennen die mangelnden Farbkontraste der Seite, die fehlenden Textalternativen für diverse Links und die doppelt vergebenen IDs von einigen Elementen. Auch die problematischen Tabindex-Werte, die zwar theoretisch erlaubt sind, die aber in der Praxis fast immer zu Problemen mit der Tastaturbedienung führen, werden von beiden Tools angemerkt (bei aXe allerdings im Rahmen der Best Practice Regeln).
Erwartungsgemäß sind es vor allem die semantischen Bewertungen, die von den automatisierten Tools nicht geleistet werden: Insbesondere die (mangelnde) Sinnhaftigkeit der Überschriften und der Überschriftenstruktur wurde vom Tool nicht erfasst. Auch die Unterscheidung, ob es sich um eine Layout- oder Inhaltsgrafik handelt und ob der jeweilige Alternativtext sinnvoll ist oder nicht, konnte nicht vom Algorithmus getroffen werden. Zwar kann das Tool Bedienelemente ohne Textinhalt erkennen; aber ob das Bedienelement einen sinnvollen Text enthält, ist naturgemäß nicht ermittelbar (so lautet die Textalternative für einen Pause-Button immer „Presseticker pausieren“, egal ob das Element gerade auf Pause oder Start steht).
Wenn man die Best-Practice-Meldungen außer acht lässt und für jeden Fehler den vollen Punktabzug annimmt, würde man bei dem automatisierten Test mit aXe (übertragen auf den BIK BITV Test) auf 92 Punkte kommen. Der Expertentest kam auf weniger als 80 Punkte; es ist nahezu ausgeschlossen, dass ein anderer Tester auf mehr als 90 Punkte gekommen wäre.
False Positives
Haben die automatisierten Tools Fehler gemeldet, die gar keine sind (False Positives)?
Der Vergleich des Expertentests mit Tenon.io ergibt ein etwas anderes Bild als bei aXe. Indem Tenon.io zum Beispiel Javascript Eventhandler an nicht mit der Tastatur bedienbaren Elementen erkennt, werden Probleme in der Tastatursteuerung erkannt. Auch die Redunanz bei den Textalternativen, die der Experte bemängelt hatte, wird erkannt. Allerdings fangen an dieser Stelle auch die Probleme an: Die Redunanz schränkt zwar die Usability ein, die Bedienung wird weniger effizient; effektiv kann der Nutzer aber noch zum Ziel kommen. Auch bei einigen anderen Fehlern könnte man diskutieren, ob es wirklich eine Blockade ist, die zu einer Abwertung führen muss – oder eher eine Best Practice Empfehlung oder ein Hinweis, der nochmal manuell kontrolliert werden muss.
Verifikation vs. Falsifikation
Wie soll man vor diesem Hintergrund den automatisierten Test einordnen? Ist es überhaupt sinnvoll, automatisierte Tests einzusetzen – oder wiegt man sich dadurch vielleicht in falscher Sicherheit?
Jörg Morsbach schreibt in seinem Fazit zum Test, „dass kein automatisiertes Tool Ergebnisse liefern kann, die zukünftig eine WCAG Konformität […] bestätigen können.“ Das ist sicherlich korrekt. Aber ein automatisiertes Tool kann Ergebnisse liefern, die bestätigen, dass eine Seite definitiv nicht WCAG konform ist. Die Voraussetzung dafür ist, dass die Fehler vom Tool sehr konservativ gemeldet werden, d.h.: Lieber einige potentielle Fehler nicht melden, als einen Fehler zu melden, der keiner ist. Da die Aussage „Diese Seite ist barrierefrei“ vom Tool keinesfalls zuverlässig getroffen werden kann, muss die Aussage „Diese Seite ist nicht barrierefrei“ absolut zuverlässig sein. aXe geht hier in meinen Augen den richtigen Weg, zumal sich Best Practice Fehler von WCAG Fehlern gut trennen lassen.
Tenon.io eignet sich in meinen Augen eher als Basis für einen Expertentest, da mehr Fehler gemeldet werden – aber entsprechend die Wahrscheinlichkeit für False Positives steigt.
Best of both worlds
Bleiben wir bei www.bayern.de als Beispiel. Die Website besteht nicht nur aus der von uns exemplarisch getesteten Startseite, sondern aus über 60.000 Einzelseiten. Technisch ist einerseits eine vollautomatische Bestätigung der Barrierefreiheit einer Website nicht möglich. Praktisch ist andererseits eine vollständige und dauerhafte Bestätigung der Barrierefreiheit aller Einzelseiten durch einen Experten nicht möglich.
Aus diesem Grund müssen bei größeren Projekten beide Testarten kombiniert werden, wenn die Qualität dauerhaft und in größtmöglicher Breite sichergestellt werden soll. Der Experte geht bei klug ausgewählten Einzelseiten oder Komponenten in die Tiefe, kontrolliert die Semantik und extrapoliert auf dieser Basis Empfehlungen für die Technik und die Redaktion. Die automatisierten Tests gehen in die Breite (sowohl hinsichtlich der Menge der Seiten als auch hinsichtlich der Testfrequenz – nicht aber hinsichtlich der gemeldeten Fehler). Was automatisiert getestet werden kann, wird kontinuierlich getestet; die automatisierten Tests können in den Entwicklungsprozess integriert werden (z.B. im Rahmen eines Continouus Integration Prozesses) und im Rahmen eines Monitorings die Live-Websites überwachen (und so z.B. auch redaktionelle Fehler melden). Melden die Testtools neue Fehler oder Best-Practice-Verstöße (z.B. weil eine neue Komponente im Projekt eingesetzt wird), sollte das ein Anlass für ein Experten-Review sein.
Thomas Heilmann beschäftigt sich als Gründer und Geschäftsführer der Münchner Internet-Agentur mindscreen mit Fragen des Content Managements und der Barrierefreiheit.
Seine erste Website war 1996 online. Inzwischen konzipiert und entwickelt er anspruchsvolle Webapplikationen, E-Commerce- und CMS-Projekte mit einem Fokus auf zugänglichen User Interfaces. Zudem engagiert er sich für die Weiterentwicklung von Open Source Projekten wie Neos CMS.
Zwei Projekten, an denen er maßgeblich beteiligt war, wurde von der Aktion Mensch und der Stiftung Digitale Chancen ein BIENE Award für herausragende Barrierefreiheit verliehen.