• Facebook
  • Google+
  • Twitter
  • XING
20.11.2005

Accessibility allein reicht nicht

Indem man sich bei der Planung stark auf Accessibility fixiert, hilft man behinderten Nutzern nicht zwangsweise. Wirkliche Unterstützung leisten Sie dagegen, wenn Sie eine Usability-Perspektive einnehmen.

 

by Jakob Nielsen (deutsche Übersetzung) - 21.11.2005

 

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 Nutzererfahrung 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 Nutzbarkeit 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 achtgeben muss, dass die Nutzer bei typischen Aufgaben unterstützt werden.

 

© Deutsche Version von Jakob Nielsens Alertbox. Institut für Software-Ergonomie und Usability AG. Alle Rechte vorbehalten.

Kommentare auf diesen Beitrag

    Keine Kommentare

Kommentar hinzufügen

Die mit * gekenzeichneten Felder sind zwingend auszufüllen