Auch wenn man alles richtig gemacht hat kann es beim praktischen Einsatz noch einige Probleme geben, so auch bei der Barrierefreiheit. Deswegen ist es immer sinnvoll, die fertige Anwendung zu testen.
Dabei sollte man nach Möglichkeit externe Tester zu Rate ziehen. Die eigenen Mitarbeiter und die Web-Agentur sind fast immer betriebsblind, das gilt im Übrigen auch für die Mitarbeiter mit einer Behinderung. Nur weil jemand behindert ist muss er nicht unbedingt etwas von Barrierefreiheit verstehen. Eine minimale Voraussetzung muss sein, dass er die Probleme anderer Behinderter antizipieren kann und das kann er nicht, wenn er sich nur mit der eigenen Technik beschäftigt hat.
Es gibt verschiedene Testmöglichkeiten. Es gibt automatische Testtools, die die Barrierefreiheit prüfen sollen. Das ist ganz nützlich, damit Fehler auf der Webseite wie schlechte Kontraste, fehlende Alternativtexte und so weiter entdeckt werden können. Für die erste Phase vor allem für die Prüfung von Prototypen ist das ausreichend. Echte Probleme kann man damit nicht aufdecken. Man kann zum Beispiel das Redaktionssystem so einstellen, dass es automatisch einen Text wie „Lorem ipsum dolor“ für Grafikbeschreibungen vergibt. Das Testtool kann nicht zwischen echten und belanglosen Alternativtexten unterscheiden. Es kann auch nicht bestimmen, ob eine Auszeichnung semantisch korrekt ist, ob ich zum Beispiel eine Zwischenüberschrift korrekt formatiert habe oder ob sie nur als fetter Absatz markiert wurde.
Nach wie vor verwechseln viele Menschen Barrierefreiheit mit Validität. Das W3C stellt Anwendungen zur Verfügung, mit denen sich HTML und CSS auf Korrektheit prüfen lassen. Das ist nicht unwichtig, aber valide Webseiten sind nicht unbedingt barrierefrei und nichtvalider Code wirkt sich nicht unbedingt negativ auf die Barrierefreiheit aus. Es reicht schon, wenn ein einziges Zeichen im Head der Datei falsch codiert wurde und schon wirft der Validator für jede Seite mit diesem Head Unmengen an Fehlern aus, ohne dass das den Screenreader-Nutzer oder jemand anderen interessieren muss.

Expertentests

Mit ein wenig Erfahrung können systematische Tests durchgeführt werden. Für die gängigen Browser gibt es Erweiterungen, mit denen sich gängige Probleme analysieren lassen. Einige Werkzeuge zeigen die Webseite so, wie sie von Screenreader-Nutzern gesehen würde. Das ist zwar nützlich, aber vor allem ist es provisorisch. Es gibt einen Unterschied darin, ob man eine Seite als Screenreader sieht oder ob man sie tatsächlich benutzen muss. Im praktischen Einsatz können ganz andere Probleme auftreten, als das, was der Webentwickler antizipieren kann. Dennoch ist der Test durch einen Experten die beste Lösung, was das Preis-Leistungsverhältnis angeht. Ein Experte ist übrigens jemand, der sich mit Webdesign, Entwicklung und Barrierefreiheit auskennt. Ein Mensch mit einer Behinderung kann bestenfalls herausfinden, ob er selber mit der Seite zurecht kommt. Das ist nicht schlecht, reicht aber nicht aus. Es gibt sehr unterschiedliche Nutzertypen, die eine Einzelperson nicht abdecken kann, es sei denn, sie kann diese unterschiedlichen Nutzertypen antizipieren – oder sie ist ein Experte für Barrierefreiheit.
Beim Expertentest lassen sich zwei Varianten unterscheiden: die heuristische Analyse und der Cognitive Walkthrough.
Der Usability-Guru Jakob Nielsen meint, es ließe sich ein Großteil der Fehler via Cognitive Walkthrugh auffinden. Das mag richtig sein, aber am Ende kommt es eher darauf an, die hoffentlich wenigen schwerwiegenden Fehler aufzuspüren als die zahllosen kleinen, die in der Praxis kaum relevant sind. Ein Usability-Experte, der wenige Fehler findet wird weniger ernst genommen als jemand, der zahllose Fehler findet. Folgen wir dem Pareto-Prinzip sind 20 Prozent der Fehler für 80 Prozent der Probleme verantwortlich.
Die Priorität liegt darauf, die schwerwiegenden Fehler zu reparieren, die kleinen Fehler sollten repariert werden, wenn es der Aufwand rechtfertigt.

Praxistests

Am sinnvollsten erscheint eine Mischung unterschiedlicher Testverfahren. Würde man eine Matrix aus allen möglichen Hilfstechniken, allen möglichen Versionen und allen möglichen Browsern bilden, erhielte man eine unendliche Tabelle. Zöge man dann noch alle möglichen Sehbehinderungen in Betracht und würde man dazu noch alle UNTERSCHIEDLICHEN TECHNISCHEN Fähigkeiten addieren, käme man mit dem Testen zu keinem Ende. Und würde vermutlich dennoch einige Probleme übersehen.
Bei den Praxistests versucht man einen Querschnitt der Nutzer bei der praktischen Nutzung des Webangebots zu beobachten. Die Nutzer sollen bestimmte Aufgaben erledigen, wobei mit Eyetracking beobachtet wird, wo sie hinschauen. Sie sprechen laut über das, was sie sehen, was sie vorhaben und worüber sie gerade – im Kontext mit der Webseite – nachdenken. Solche Tests lassen sich auch mit Menschen mit Behinderung umsetzen, in diesem Falle sprechen wir auch von Praxistests. Wie gesagt ist es schwierig, alle Behinderungsformen abzubilden. Es sollte zunächst reichen, wenn man aus jeder Gruppe ein bis zwei Personen heranzieht und ansonsten auf Qualitätssicherung setzt. Es ist am sinnvollsten, Menschen mit geringer Technikerfahrung an diese Tests zu setzen. Wenn diese Menschen zurecht kommen, dann werden die technikaffinen auch keine größeren Probleme haben. Ganz unbedarfte Nutzer taugen hingegen nicht als Testpersonen, weil sie kein realistisches Bild der Anwendung geben. Sie kämpfen mehr mit der Technik als mit der Anwendung.
Auch hier sollte man die Laborsituation nicht unterschätzen. Meine Kritik an solchen Tests besteht darin, dass die Nutzer sich gezwungen sehen, einen Prozess zu Ende zu führen, weil sie ein Scheitern auf die eigene Unfähigkeit zurückführen und nicht auf die Website. Zuhause ist es leicht, jemand anderem die Schuld zu geben, im Labor werden wir aber beobachtet und kämpfen weiter bis zum bitteren Ende, wo wir zuhause schon längst hingeschmissen hätten.
Egal, für welches Testverfahren ihr euch entscheidet, das Verfahren sollte strukturiert und nach einem Schema ablaufen. Es bringt relativ wenig, intuitiv mal hier, mal dort etwas zu testen oder sich irgendwie durch die Seite zu klicken. Im Internet gibt es verschiedene Anleitungen, die ihr als Hilfe nehmen könnt.

BITV-Test

Die Barrierefreie-Informationstechnik-Verordnung verpflichtet die Einrichtungen des Bundes zur barrierefreien Gestaltung ihrer Webseiten. Aufbauend auf der Verordnung wurde der BITV-Test entwickelt. Er prüft genau genommen nicht die Barrierefreiheit einer Webseite, sondern die Einhaltung der BITV. Daran erkennt man auch die Grenzen solcher Tests. Man testet nur auf vorgegebene Kriterien. Ein gewitzter Programmierer könnte sich einfach vornehmen, auf diese Testkriterien hin zu optimieren. Eine formal barrierefreie Webseite kann dennoch für Menschen mit Behinderung schwierig zu nutzen sein. Viele Ministerien setzen übermäßig auf gut gemeinte Hilfen wie Shortcuts, Überschriften für Blöcke oder Listen. Sparsam eingesetzt sind sie eine Hilfe vor allem für Screenreader-Nutzer, im Übermaß machen sie die Seite unübersichtlich.
Ein alternatives Konzept zu Labortests wären Tests mit echten Nutzern, die aber nicht im Labor sitzen. Ich hatte das anhand von Web Analytics schon an anderer Stelle beschrieben. Hier wäre es hilfreich, wenn die Browser selbst oder eine Dritt-Anwendung aufzeichnen könnten, wie die Nutzer von Hilfstechnik mit der Website interagieren. Der Firefox kann bereits Daten von Screenreader-Nutzern sammeln. Um eine nennenswerte Zahl von Nutzern zu bekommen müssten sie in diesem Fall explizit eingeladen werden, für ihre Teilnahme könnten sie eine Aufwandsentschädigung bekommen. Der Vorteil bestünde darin, dass sie kein Weiße-Kittel-Syndrom entwickeln, nicht künstlich unter Zeitdruck gesetzt werden und sich auch nicht gezwungen sehen müssen, das Szenario komplett durchzuspielen, auch wenn sie es ansonsten abgebrochen hätten.

Neue Testmethoden braucht das Land

Es gibt noch zu wenige Tests auf Barrierefreiheit, vor allem mit behinderten Nutzern. Früher waren Websites eine Anordnung von Texten, Bildern und Links. Heute handelt es sich häufig um komplexe Anwendungen oder puzzleartige Zusammenstellungen von Inhalten aus verschiedensten Quellen. Diese Anwendungen brauchen ausgefeiltere Testverfahren, vor allem sollten Methoden der Qualitätssicherung eingesetzt werden.