Das Prüfverfahren sollte einheitlich sein. Um unterschiedlichen Einreichungen gerecht zu werden kann die Prüfung auch modular aufgebaut sein, wobei einzelne Module speziell für Webseiten oder Apps oder Konzepte gelten.
Der Test sollte eher qualitativ als quantitativ angelegt werden. Anstatt also ein relativ starres System aus Regeln zu verwenden, wird die praktische Nutzbarkeit abgefragt. Ausgangspunkt dafür ist die Überlegung, dass eine nicht oder schlecht benutzbare Anwendung auch nicht Barrierefrei ist. Bei Tests wie dem BITV-Test steht eher der technische Unterbau im Vordergrund, der Benutzer interessiert sich aber mehr für die Oberfläche und die Inhalte.
Die Evaluation hat zwei Phasen: In Teil 1 wertet die Redaktion die Einreichungen aus. Dazu müssen Ausschlusskriterien entwickelt werden. Es sollten zum Beispiel Inhalte ausgeschlossen werden, bei denen deutlich sichtbar ist, dass der Einreicher sich keine Mühe zur Barrierefreiheit gemacht hat, weil er zum Beispiel das ohnehin barrierefreie Standardlayout eines Redaktionssystems verwendet hat. Ebenfalls auszuschließen sind Inhalte, die offensichtlich seit langer Zeit nicht gepflegt wurden oder bei denen absehbar ist, dass sie nicht weiter entwickelt werden. Eine Mindestvoraussetzung für eine Einreichung ist ein testbarer Prototyp.
Berücksichtigt werden Einreichungen, die einen Bezug zu Behinderung oder Barrierefreiheit haben.
In der zweiten Phase werden die eingereichten Konzepte in der Praxis von Betroffenen geprüft.
Die Einreichungen sollten von einem kleinen redaktionsteam ausgewertet werden, eine Einzelperson würde zu subjektiv urteilen. Die Checkliste wird vorher festgelegt und ggf. angepasst, falls die Kriterien als zu streng empfunden werden.
Das Redaktionsteam kann positiv bewerten, wenn
• das Produkt sich an mehrere Zielgruppen richtet
• es auf mehreren Plattformen vorhanden ist (Android, iOS) oder als universelle Weblösung angelegt wurde
• das Produkt günstig oder kostenlos abgegeben wird (Kosten sollten nicht negativ gewertet werden, schließlich sollen die Leute auch Geld verdienen können und die Kosten von Apps sind normalerweise nicht unverhältnismäßig)
• Menschen mit Behinderung bei der Entwicklung beteiligt wurden, auch in Form von User-Evaluation
• die Lösung als OpenSource bereit gestellt wird
• innovative Ansätze eingesetzt werden (offene Daten, Gamification, Crowdsourcing
Negativ bewertet werden sollte hingegen
• eine Sonderlösung für Menschen mit Behinderung (Sonderlösungen sind unerwünscht, da die Wahrscheinlichkeit groß ist, das sie irgendwann nicht weiter entwickelt oder zugunsten der konventionellen Lösung vernachlässigt werden)
• eine App als Alternative für eine ansonsten unzugängliche Webseite (die App als Entschuldigung dafür, das die Webseite nicht zugänglich ist, man soll sich also ein Handy kaufen, um auf die Infos zugreifen zu können). Eine Ausnahme kann gemacht werden, wenn die Funktionen der Webseite nur schwer barrierefrei gemacht werden können (wie bei Facebook) oder die Anwendung zusätzliche Funktionen bereit stellt, die im Internet nicht ohne weiteres realisierbar sind.
Das Redaktionsteam setzt sich am Ende der ersten Phase zusammen und diskutiert darüber, welches Konzept in den praxistest geht und welche Gruppe die Einreichungen testet.
Zweite Phase: Praxistest durch Betroffene
Die zweite Phase ist der Praxistest. Im Praxistest werden die Einreichungen von mindestens zwei Personen aus der Zielgruppe geprüft. Wenn es keine konkrete Zielgruppe gibt, entscheidet das Redaktionsteam, wer und wie viele Menschen die Anwendung testen. Die hier beschriebene Methode orientiert sich an der heuristischen Evaluation, einer Methode aus dem Usability-Bereich.
Es gibt zwei denkbare Ansätze. Die Testperson wird nach dem Test nach einem festen Schema befragt oder sie wird während der Testphase beobachtet.
Im Usability-Check gibt es die Methode des lauten Denkens, der Benutzer spricht laut aus, was er gerade tun möchte, warum er das tut und welche Schwierigkeiten er gerade hat. Sinnvoll erscheint eine Mischung aus Fragebogen/Checkliste und Beobachtung des Probanden.
Der Prüfer protokolliert die Evaluation und notiert sich zum Beispiel, wie schnell sich der Proband zurecht gefunden hat oder wo er auf Probleme gestoßen ist.
Anschließend wird er zu seinen subjektiven Eindrücken befragt, wobei eine feste Checkliste/ein Fragebogen eingesetzt wird.
Szenario
Das Redaktionsteam bestimmt für jede Anwendung den hauptsächlichen Einsatzzweck. Anhand dieses Zweckes wird für diese Anwendung ein Szenario oder eine Aufgabe bestimmt, die im Rahmen der Evaluation bearbeitet werden soll. Ohne Szenario wird der Eindruck zu subjektiv, der Nutzer klickt sich durch die Anwendung, ohne sie konkret zu verwenden.
Mögliche Kriterien sind:
• Erlernbarkeit
• Bedienbarkeit
• Nutzbarkeit
• Robustheit (die Anwendung soll mit der eingesetzten Hilfssoftware funktionieren und z.B. nicht andauernd abstürzen)
Der Testleiter kann z.B. beobachten, wie gut der Benutzer mit der Anwendung zurecht kommt. Die Beobachtungen werden protokolliert und fließen in die Bewertung ein.
Mögliche Fragen an den Nutzer nach dem Test:
• Fanden Sie die Anwendung gut bedienbar?
• Sind Ihnen Probleme aufgefallen?
• Wird der anvisierte Zweck mit der Anwendung erreicht?
Die Testpersonen sollten keine technischen Experten sein, um realistische Ergebnisse zu erhalten. Sie sollten sich mit Computern, der Hilfssoftware oder den Hilfsmitteln auskennen, aber weder zu bewandert sein noch zu unerfahren. Dadurch wird sicher gestellt, dass sie für die Gruppe repräsentativ sind.
Die richtigen Anreize setzen
Wichtig ist, durch das Evaluationsverfahren die richtigen Anreize zu setzen. Einerseits sollte Barrierefreiheit als allgemeines Thema verankert werden. Möglicherweise ist der Entwickler bereit, Verbesserungsvorschläge aus der Community anzunehmen. Im Idealfall setzen sich Entwickler und Anwender am Ende zusammen, um die Anwendung gemeinsam weiter zu verbessern, es wird also ein stärkerer Impact erzeugt – eine Win-Win-Situation.
Grundlegende Annahmen
Oftmals wird Barrierefreiheit als das sture Abarbeiten von Regeln betrachtet. Die Leute sehen keinen Anlass, sich mit den konkreten Bedürfnissen oder Schwierigkeiten von Menschen mit Behinderung zu beschäftigen, sondern begnügen sich mit dem Abarbeiten von Forderungskatalogen. Diese Richtlinien sind von klugen Leuten mit großem Engagement erstellt worden, aber am Ende entscheiden immer die Benutzer aktiv oder passiv, ob eine Anwendung genutzt wird oder nicht. Das wiederum hängt nicht unbedingt davon ab, ob die konkrete Anwendung die Richtlinien zur Barrierefreiheit erfüllt, teilweise erfüllt oder gar nicht erfüllt. Vor allem Webseiten öffentlicher Einrichtungen erfüllen die Richtlinien zur Barrierefreiheit, gelten aber als schlecht benutzbar für Menschen mit Behinderung. Deshalb sollte von einem strengen Kriterienkatalog zugunsten eines nutzerbasierten Evaluationsverfahren verzichtet werden.
Oft genug wird darauf verwiesen, eine Anwendung sei nicht barrierefrei, da Kriterium XY nicht erfüllt sei, wobei es egal zu sein scheint, ob dieses Kriterium im konkreten Zusammenhang von Bedeutung ist. Eine Anwendung, die sich nur an Lernbehinderte wendet, muss nicht primär für Blinde zugänglich sein.
Die diversen Richtlinien wie BITV, WCAG und so weiter sind als Leitlinien zu verstehen, sie sind ein Weg, nicht das Ziel. Entscheidend ist die Frage, ob die Zielgruppe mit dem Produkt zurecht kommt.
Entscheidend ist an dieser Stelle, dass die Zielgruppe mit einem Produkt zurecht kommt, nicht die Frage, ob bestimmte WCAG-Kriterien erfüllt wurden. Der Fokus wird damit von den Kriterien genommen und auf die User-Evaluation und die Usability gesetzt. Dadurch erhöht sich der Anreiz bei den Entwicklern, behinderte Nutzer einzubinden.
Evaluating concepts for digital Accessibility