Komponenten- statt Seiten-Tests – warum der BITV-Test nicht mehr ausreicht

Webseiten können heute aus tausenden von Unterseiten bestehen. Bislang ist der BITV-Test das bevorzugte Testverfahren in Deutschland. In Zukunft wird er in der jetzigen Form nicht mehr ausreichen.
Websites bestehen im Prinzip aus wenigen Modulen: Navigationen, Content, Seiten-Bereiche, die Suche und eventuell noch eingebette Inhalte. Dafür reicht der BITV-Test heute aus. Man nimmt sich die Navigation in verschiedenen Zuständen vor, die paar wichtigsten Templates, eventuell noch ein Formular – das wars. Mehr schafft man im Prinzip auch nicht. Auch wenn ein Großteil der 91 Prüfschritte ohnehin nicht anwendbar sind, so ist der Test doch sehr zeitaufwendig.
Die große Herausforderung besteht aber in komplexen Websites, die eventuell sogar aus unterschiedlichen Redaktionssystemen gespeist werden oder auf denen mehrere Module ähnliche Aufgaben erfüllen. Bei großen Körperschaften kann man sich etwa gut vorstellen, dass einzelne Abteilungen ihr persönliches Lieblings-Modul haben, um Formulare zu erstellen.
Und dann sind da natürlich noch komplexe Web-Anwendungen. Single Page Applikationen wie Google Docs erfordern meines Erachtens eine andere Herangehensweise als statische, auf Information ausgelegte Websites.
Für große Websites scheint ein Remmediationsservice wie Siteimprove am sinnvollsten zu sein. Niemand ist in der Lage oder hat die Ressourcen, für so viele Websites die Qualitätssicherung zu machen. Hier kann man mit einer Mischung aus automatischer Remediation und Nutzer:Innen-Feedback arbeiten.
Was den Test durch Menschen angeht, müssen wir hingegen priorisieren. Mein Vorschlag ist, sich zum Einen, die Anwendung in Komponenten zu zerleegen. Die einzelnen Komponenten werden dann auf Barrierefreiheit geprüft und die Verantwortlichen müssen sicherstellen, dass nur noch geprüfte Komponenten verwendet werden dürfen.
Zum Anderen sollte man aber auch einen exemplarischen Use Case von Anfang bis Ende durchtesten. Dabei sollten natürlich auch Falsch-Eingaben geprüft werden. Das heißt, wir testen nur den Teil, der vollständig zum Use Case gehört, nicht den „Rahmen“ der Website, den wir oben bereits geprüft haben.
Vorstellbar ist, dass die verantwortliche Einrichtung eine spezielle Evaluations-Anwendung erstellt, in welcher alle exemplarischen Module vorhanden sind. Besser ist es aber, wenn man Komponenten prüft, wie sie tatsächlich erstellt wurden. Das hat de Vorteil, dass man nicht auf Komponenten trifft, die extra für den Test optimiert wurden.