Häufig ist die erste Frage, wie man den Umfang des Barrierefreiheits-Tests festlegt. Kunden und einige Dienstleister neigen dazu, den Scope möglichst groß anzusetzen. Die Kunden, weil sie nichts falsch machen wollen oder den Prüf-Aufwand und damit die Kosten falsch einschätzen. Dienstleister, weil sie möglichst viele anrechenbare Stunden generieren wollen.
Content-Website
Eine typische Content-Website besteht aus wenigen Templates bzw. Komponenten. Immer im Scrope sind die folgenden Seiten:
- Startseite
- eine einfache Contentseite
- eine komplexe Content-Seite z.B. mit einer Tabelle
- eine Formular-Seite, wenn vorhanden
Nach aller Erfahrung ist die Zahl der Komponenten so groß, dass sie nicht alle durchgeprüft werden können. Die meisten davon werden ohnehin selten oder gar nicht eingesetzt. Deshalb macht es Sinn, nicht alle Komponenten durchzuprüfen. Vielmehr sollten nur die Komponenten geprüft werden, die tatsächlich regelmäßig verwendet werden.
Prozess-basierte Websites
Prozess-basierte Websites nenne ich so, wenn ein Prozess in einer bestimmten Reihenfolge durchlaufen wird. Beispiele sind Onlineshops oder Banking. Hier wird in der Regel der gesamte Prozess durchgeprüft, also von der Login-Seite bis zum Checkout. Erfahrungsgemäß wiederholen sich die Fehler nach der dritten Seite nur noch. Für einen reduzierten Test-Case ist es daher sinnvoll, alle Komponenten wie Checkboxen, Dropdowns und so weiter einmal durchzuprüfen.
eLearning
Ein spezieller Website-Typ sind eLearning-Angebote. Sie können aus zahllosen Unterseiten bestehen. In diesem Fall würde ich empfehlen, einmal die Startseite und einmal eine Extra-Seite mit allen verwendeten Komponenten wie single Choice, Multiple Choice, Drag-and-Drop und so weiter zu bauen, die mit echtem Inhalt befüllt sein sollte.
Die Ausnahme: Inkonsistente Komponenten
Eine schwierige Herausforderung sind Seiten oder Screens, die nicht mit wiederkehrenden Komponenten gebaut wurde. So was sollte eigentlich nicht mehr vorkommen, passiert allerdings nach wie vor. Als Außenstehende weiß man so was überlicherweise nicht. In diesem Fall müssen die Devs heraussuchen, welche Screens oder Unterseiten solche Komponenten enthalten und geprüft werden müssen.
Das gilt auch, wenn Dritt-Anbieter-Komponenten wie Cookie-Banner verwendet wurden. Sie müssen extra geprüft werden, weil man als Dev meistens keinen Einfluß auf deren Code hat.
Fazit
Das Ziel sollte sein, den Test-Umfang repräsentativ, aber so knapp wie möglich zu halten. Der Kunde bzw. sein Dev-Team muss dann den Transfer leisten und erkennen, welche Fehler auf anderen Screens und Komponenten auftreten könnten, die sich aus dem Bericht ableiten.
Das Ziel eines Barrierefreiheits-Tests ist es nicht, jeden kleinen Fehler zu finden, das ist nicht produktiv. Vielmehr ist das Ziel, strukturelle, also wiederkehrende und schwerwiegende Fehler zu finden. Der Rest ist Qualitätssicherung, Ausbildung und Fehler-Prävention.