|
Kürzlich erhielt ich von einem meiner Leser, der in einer
Regierungsbehörde arbeitet, die folgende Anfrage:
| Ich untersuche derzeit die
Accessibility der Portaltechnologie von FooCorp XYZ.
Die einzigen Leute, die von dem Produkt behaupten,
dass es allgemein zugänglich, also "accessible"
sei, sind die verantwortlichen Designer bei FooCorp.
Ich muss wissen, ob diese Technologie für Personen
mit Bildschirmlesegeräten (sogenannten "Screen
Readern") zugänglich ist. |
Das fragliche Produkt (hier XYZ genannt) wurde in unserem
letzten Projekt zur Intranet-Portal-Usability
nicht untersucht, weshalb ich nichts über dessen potentielle
Probleme aussagen kann. Wir hatten aber herausgefunden, dass
die wenigsten Portallösungen fixfertig mit guter Usability
ausgeliefert werden. So gesehen kann man sicherlich mit dem
Schlimmsten rechnen. Es ist sowieso dringend davon abzuraten,
sich in Sachen Benutzererfahrung und Usability nur auf die
Aussagen der Verkäufer zu verlassen. Ich kann Ihnen nur
raten, sich immer persönlich ein Bild zu machen. So eine
Überprüfung ist ziemlich einfach: Bitten Sie einfach 5 Ihrer
behinderten Angestellten, sich eine Stunde an das Produkt zu
setzen und ein paar beispielhafte Aufgaben zu lösen, die mit
der Demo-Version möglich sind. Es ist dabei äusserst
wichtig, dass die Testpersonen ihre eigenen
Bildschirmlesegeräte, Bildvergrösserungssoftware, Keyguards
und technologischen Hilfen und Eingabegeräte verwenden, die
sie auch sonst in ihrem Alltag einsetzen. Obwohl es noch
eine ganze Reihe zusätzlicher Richtlinien
für Intranet-Nutzertests mit behinderten Nutzern gibt, so
kommen diese in einem solchen Fall nicht zum Tragen. Sie
führen ja nicht eine formelle Usability-Evaluation durch, um
anschliessend ein Redesign zu machen, sondern beurteilen
lediglich, ob das Produkt Ihren Angestellten bei der
Erledigung ihrer Aufgaben hilft. Nach einer Stunde werden Sie
die Antwort kennen. Accessibility-Trugschluss
Der grösste Trugschluss im Zusammenhang mit Accessibility
besteht im Glauben, Accessibility lasse sich isoliert
betrachten und ohne Anwender und deren Aufgaben umsetzen.
Sicher gibt es technische Kriterien, anhand derer man eine
Website zugänglicher gestalten kann. Allerdings kann es schon
vorkommen, dass behinderte Nutzer mit einer Website überhaupt
nichts anfangen können, selbst wenn sämtliche Kriterien der
1. Priorität abgehakt sind (vgl. die Kriterienliste
der WAI (engl.)). Jeder weiss, dass die erste Accessibility-Regel lautet,
Bilder mit Alt-Text zu versehen, damit Personen, die sich die
Bilder nicht ansehen können, sich die Beschreibung anhören
können. Die Accessibility-Checklisten sagen einem aber nicht,
wie man Alt-Text schreiben muss, d.h. was man
kommunizieren muss, um Blinden eine Hilfestellung zu bieten. Das
Geschäftsziel von Accessibility kann nicht einfach nur sein,
besonders viel Punkte auf der Liste der gesetzlichen
Anforderungen zu erreichen. Was Sie sich für Ihre Website wirklich
wünschen, ist, dass behinderte Nutzer mehr Produkte kaufen. Auf einem Intranet wollen Sie die
Produktivität ihrer behinderten Angestellten erhöhen. Dies
tönt nach den Zielen eines Usability-Projekts - und das sind
sie auch. Natürlich sind die Usability-Probleme für
Nutzer mit Behinderung nicht ganz dieselben wie für Nutzer
ohne Behinderung. Aber es gibt erstaunlich viele
Überschneidungen. Es ist ohnehin eine
Vereinfachung, von behinderten und nichtbehinderten Nutzern zu
sprechen, so als wären das zwei Paar Schuhe. In der Praxis gibt
es ein Kontinuum von Menschen mit mehr oder weniger schweren
Behinderungen. So haben z.B. die meisten Leute über 45 ein
reduziertes Sehvermögen und benötigen variable
Schriftgrössen - obwohl sie deswegen ja noch nicht in die Statistik
der "Sehbehinderten" fallen. Usability-Probleme
für ältere Menschen sind nicht dieselben wie jene von
jungen Menschen mit Behinderung. Aber es gibt viele
Gemeinsamkeiten zwischen den beiden Gruppen. Einfache
Benutzbarkeit ist zentral
Eine Analogie: Wenn Sie an der Handy-Strategie Ihrer Firma
arbeiten, dann reicht es nicht, einfach nur dafür zu sorgen,
dass die Webseiten auf der Anzeige des Handys erscheinen.
Solche technische Zugänglichkeit bringt nicht viel mehr
Handy-Nutzer auf IhreWebsite. Aus unserer Studie von
frühen WAP-Handys (engl.) wissen wir, dass die Anwender einen Bogen um
Inhalte und Dienstleistungen machen, wenn diese auf dem
kleinen Bildschirm nicht über optimale Usability verfügen.
Wenn Sie nicht dafür sorgen, dass die Nutzer die
Handy-Version Ihrer Website einfach verwenden können,
arbeiten Sie völlig für die Katze. Wenn die Nutzer ewig lang
auf die Inhalte warten müssen oder sich ständig auf der
Website verlieren, dann erscheinen Sie bald nicht mehr auf
deren Telefon. Ähnlich wie für sehbehinderte Anwender
können tragbare Geräte nur immer eine limitierte
Informationsmenge gleichzeitig abbilden. Und auch wenn die
einzelnen Designrichtlinien voneinander abweichen, so ist die
Reaktion des Nutzers doch in beiden Fällen dieselbe: Es ist zu mühsam, durch
die Seite zu navigieren und den Inhalt zu verstehen, und daher
verlassen die Nutzer die Site. Die simple Tatsache, dass die
Website sich auf dem Bildvergrösserer darstellen lässt,
reicht bei weitem noch nicht aus, um Leute tatsächlich auf
der Website und bei den Informationen zu halten. Wenn Sie
Ihre Website für Menschen mit Behinderung zugänglicher
machen wollen, dann behalten Sie das Ziel im Auge:
Unterstützen Sie die Nutzer bei der Verwendung der Site. Accessibility ist
dabei ein wichtiges Ziel, das aber in sich noch nicht
ausreicht. Der
Hauptfokus sollte auf der Usability für behinderte Nutzer
liegen, wobei man besonders acht geben muss, dass die
Nutzer bei typischen Aufgaben unterstützt werden.
|