Oft sind die Kosten für Barrierefreiheits-Tests recht hoch. Auch wenn das aus Dienstleister-Perspektive erst einmal positiv erscheint, kann es sich für beide Seiten negativ auswirken. Für den Kunden erhöhen sich die Kosten. Das kann zur Folge haben, dass er sich ganz gegen einen Test entscheidet oder halt einen anderen Dienstleister beauftragt, der Dumping-Preise anbietet. Zur Wortklärung: Website steht für das gesamte Angebot, eine Webseite ist eine Seite des Angebots.
Zunächst erscheint es logisch, dass möglichst viele Seiten geprüft werden sollen, um möglichst viele Probleme zu finden. Bislang noch üblich ist der Seiten-basierte Test. Kundin oder Dienstleister suchen bestimmte Seiten heraus, die geprüft werden sollen. Kosten werden pro zu prüfender Seite berechnet. Das hat auch Nachteile für die Qualität der Prüfung.
Probleme der Seiten-basierten Prüfung
Gefundene Fehler hängen oft von Zufällen ab. Zum Beispiel kann es passieren, dass eine Komponente durch die Redakteurin falsch eingesetzt wurde. Es kann etwa sein, dass eine Überschrift statt einer Absatzformatierung verwendet wurde. Das ist ein Fehler in der Barrierefreiheit, der aber nicht auf die Komponente zurückgeht, sondern auf deren einmaligen falschen Einsatz. Wenn dieser Fehler nur einmal passiert bzw. immer durch den gleichen Redakteur verursacht wird, macht es wenig Sinn, das zu dokumentieren. Da es aber defacto ein Fehler ist, muss man es als Testerin dokumentieren, auch wenn es für die Anwendung eigentlich nicht relevant ist. Ziel eines tests sollte es immer sein, strukturelle und nicht einmalige Fehler zu finden.
Es geht in einem sinnvollen Prüfverfahren nicht darum, einzelne Fehler zu finden. Oft sind Prüfberichte einfach die Anhäufung solcher einmaliger kleiner Fehler, ein Beispiel sind fehlende Sprach-Auszeichnungen, in einem bekannten deutschen Test-Verfahren hat man ein Faible dafür. Sie blähen den Prüf-Bericht künstlich auf, sind in der Praxis aber irrelevant. Vielmehr sollte das Ziel sein, systemische Probleme zu finden, also Probleme, die mit den eingesetzten Komponenten strukturell zu tun haben. Fehler, die von den Redakteurinnen gemacht werden, sind nicht irrelevant, sie sind aber eher ein Problem der QS. Man braucht keine Consultants für 150 € je Stunde, um sie zu finden und zu dokumentieren. Faule Consultants mögen diese seiten-basierten Tests, da man mit relativ geringem Aufwand viele Findings hat und somit seine Rechnung noch besser rechtfertigen kann.
Ein weiteres Problem besteht dann, wenn eine komplette Strecke getestet werden soll. Ein eLearning-Angebot kann aus vielen Unterseiten bestehen. In der Regel werden aber nur wenige Komponenten immer wieder verwendet: Fragebögen, Media-Player, bestimmte Lernformate wie Flip-Cards. Meistens gibt es nur wenige Content- und interaktive Komponenten. Ähnlich sieht es bei Shopping-Angeboten aus. Aus ökonomischer Sicht ist es nicht sinnvoll für den Kunden, die gesamte Strecke zu testen.
Ein weiteres Problem ist, dass seiten-basierte Test-Verfahren die Komponenten atomisieren. Die gleiche Komponente wird in 10 verschiedenen Prüfschritten geprüft und die Fehler jeweils beim Prüfschritt dokumentiert. Dabei wäre es für die Kundin viel sinnvoller, die Findings nach Komponenten gruppiert zu erhalten.
Komponenten statt Unterseiten
Moderne Websites basieren ebenso wie Apps häufig auf Komponenten, die von den Online-Redakteurinnen – wenn man sie so nennen möchte – kombiniert werden. Die klassische HTML-Website, die im Grunde nur mit Inhalt befüllt wird gibt es noch, ist aber nach meiner Beobachtung ein Auslauf-Modell auf komplexen Web-Auftritten.
Bei einem Test ausgewählter Unterseiten kann es also passieren, dass man eher unwichtige Komponenten testet und die wichtigen oder komplexen Komponenten durchrutschen, weil sie auf den ausgesuchten Seiten nicht vorhanden sind.
Ebenso wenig ist es sinnvoll, Seiten zu prüfen, die auf dem gleichen Template basieren. Es kommt sehr häufig vor, dass man zwei bis drei Seiten bekommt, die exakt die gleichen Komponenten in unterschiedlichen Konstellationen enthalten oder auf dem gleichen Seitentyp basieren. Finden wird man immer etwas, relevant ist das selten. Das muss keine böse Absicht sein: Als Consultant kann man nicht wissen, wie die Systeme der Kundin funktionieren. Auch wenn Seiten oberflächlich gleich aussehen können sie dennoch auf unterschiedlichen Vorlagen basieren. Die Kundin ihrerseits wird oft schlecht gebrieft, wenn es um die Auswahl von Samples geht.
Es kann allerdings auch vorkommen, dass Komponenten gleich aussehen, aber unterschiedlich programmiert sind. Das kann die Kundin zusammen mit ihrer Entwicklerin herausfinden. Für einen externen Consultant kann das schwierig bis nicht möglich sein.
Fake-Seiten als Lösung
Wie kann man komponenten-basiert prüfen? Man bittet den Kunden, eine oder mehrere Unterseiten mit allen vorhandenen Komponenten zusammenzubauen. Navigationen sind dabei als eigene Komponenten zu betrachten, die in der Regel nicht auf jeder Seite, aber in ihren verschiedenen Zuständen geprüft werden müssen.
Es ist korrekt, dass die Prüfung dieser einzelnen Fake-Seiten teurer sein kann als die Prüfung von tatsächlich publizierten Webseiten, weil sie komplexer sind als echte Seiten. Da aber insgesamt weniger Unterseiten geprüft werden müssen, sinken in der Regel die Kosten für die gesamte Prüfung. Folgende Komponenten könnten aus meiner Sicht für die Prüfung sinnvoll sein.
- Startseite
- Inhaltsseite mit allen Text-Bild-Komponenten und Tabellen-Typen
- Formular-Seite mit allen Formular-Elementen
- Navigation als eigene Komponente in den verschiedenen Zuständen wie aufgeklappt, zugeklappt und so weiter
Diese Maßnahme wird nicht immer zu einer Kostensenkung für die Prüfung führen. Schließlich kann es sein, dass eine Website sehr viele Komponenten hat oder das auch Komponenten geprüft werden, die selten oder gar nicht genutzt werden. Das sollte der Kunde vermeiden. Aus meiner Sicht ist aber eindeutig, dass dieses Vorgehen die strukturellen Probleme ermitteln kann.
Mögliche Probleme
Es besteht die realistische Gefahr, dass der Kunde sich bei solchen Fake-Seiten besonders viel Mühe gibt, sie barrierefrei zu gestalten. Schließlich möchte er sich in einem besonders guten Licht darstellen.
In der Regel kann man ihn aber von solchen Ambitionen abbringen. Es geht bei einem Test gerade darum, mögliche Probleme zu finden. Nicht der Kunde wird beurteilt, sondern sein Produkt. Der Accessibility Consultant sollte wie eine Ärztin betrachtet werden. Sie fangen auch nicht eine Woche vor dem Besuch Ihrer Zahnärztin damit an, sich die Zähne zu putzen. Der Kunde sollte einfache Inhalte erstellen, die entweder aus der Praxis kommen oder realistisch sind. Eine Fake-Tabelle oder ein Diagramm müssen trotzdem auf richtigen Daten basieren, da man sie sonst nicht sinnvoll prüfen kann.
Die Kundin muss allerdings hier eine Transfer-Leistung erbringen. Sie bzw. ihre technischen Mitarbeiterinnen müssen wissen, welche Komponenten von einem Problem ebenfalls betroffen sein könnten. Bei einer guten Dokumentation sollte das kein Problem sein.
Die Kundin ist dann dafür verantwortlich, die Fehler so zu reparieren, dass sie nicht mehr strukturell durch die Komponente verursacht werden. Der Rest ist wie gesagt QS: Die Redakteurinnen benötigen exakte Informationen, wie die Komponente korrekt eingesetzt und ggf. angepasst werden muss. Werden immer noch Fehler auftreten? Wahrscheinlich, aber das wäre auch bei einem seiten-basierten Test der Fall und lässt sich mit realistischen Ressourcen nicht verhindern, sondern nur verringern.