Ergonomische Softwaregestaltung und Barrierefreiheit

Transkript

1 Ergonomische Softwaregestaltung und Barrierefreiheit Ausarbeitung zum Vortrag im Software Engineering Projekt WS07/08 Steffen Lutter Matrikelnummer: Technische Universität Berlin Institut für Softwaretechnik und Theoretische Informatik Software Engineering Projekt

2 Kurzfassung Durch den großflächigen Einsatz von Rechnersystemen in Büros und anderen Arbeitsumgebungen hat die Softwareergonomie in der heutigen Welt einen sehr hohen Stellenwert erlangt. Während eine gute softwaretechnische Qualität von Programmen als Voraussetzung für ein erfolgreiches Produkt bekannt ist, wurde noch vor einiger Zeit für die Aspekte Gebrauchstauglichkeit (Usability) und Zugänglichkeit (Accessibility) wenig Entwicklungszeit investiert. Problematisch ist aber zunächst das fehlende Wissen über die ergonomische Gestaltung bei den Softwareentwicklern. Diese Ausarbeitung befasst sich mit den Grundlagen ergonomischer Softwaregestaltung und bietet einen Einstieg in die Themen Gebrauchstauglichkeit und Zugänglichkeit. Dank intensiver Forschung in den Gebieten Wahrnehmungspsychologie und Arbeitswissenschaften gibt es zu diesem Thema bereits viele Erkenntnisse. Zunächst werden die Grundsätze der Dialoggestaltung vorgestellt, die die Grundlage für ergonomische Systeme sind. Um die Aspekte verständlicher zu machen, werden zwei Verfahren zur Überprüfung von Gebrauchstauglichkeit vorgestellt. Gerade weil diese Prüfverfahren auch von den Kunden bzw. deren Betriebsräten angewandt werden können, muss der Softwareentwickler wissen, an welchen Kriterien er gemessen wird. Zusätzlich lassen sich diese Prüfverfahren auch als Hilfsmittel in der Softwareentwicklung einsetzen. Barrierefreiheit ist ein anzustrebendes Ziel, da sich der Kreis potenzieller Kunden beachtlich vergrößert. Insbesondere die Informationsbeschaffung aus dem World Wide Web steht im Vordergrund, da hier die meisten Barrieren zu erwarten sind auf der einen Seite die große Nachfrage, auf der anderen Seite multimediale und nicht linearisierte Inhalte. Das Anstreben der Barrierefreiheit führt den Gedanken der Usability weiter, so dass auch hier alle Nutzer von einer besseren Gebrauchstauglichkeit profitieren können. Seite 2

3 Inhalt Kurzfassung... 2 Vorwort... 4 Usability die ISO-Norm Bedeutung... 4 Zielsetzung... 5 Gesundheitliche Aspekte... 5 Wirtschaftliche Aspekte... 5 Der Benutzer... 6 Die sieben Grundsätze der Dialoggestaltung... 6 Aufgabenangemessenheit... 7 Selbstbeschreibungsfähigkeit... 7 Steuerbarkeit... 8 Erwartungskonformität... 8 Fehlertoleranz... 9 Individualisierbarkeit... 9 Lernförderlichkeit Prüfbarkeit von Softwareergonomie KO-Kriterien IsoMetrics IsoMetricsS IsoMetricsL Barrierefreiheit / Zugänglichkeit Grundlagen Web accessibility Beispiele Textalternativen Farben und Kontraste Sprache Navigation und Orientierung Geräteunabhängigkeit und Abwärtskompabilität Fazit Quellen Seite 3

4 Vorwort Ergonomische Softwaregestaltung und Barrierefreiheit haben aufgrund der enormen Verbreitung von rechnergestützten Arbeitssystemen eine große Bedeutung erlangt. Ergonomische Grundsätze für die Arbeit an Bürosystemen wurden erstmals verbindlich in der Bildschirmarbeitsverordnung (BildscharbV) niedergeschrieben [08]. Auf Grundlage dieses deutschen Gesetzes wurde die internationale Norm 9241 entwickelt, die ergonomische Anforderungen an die Mensch-Maschine- Interaktion definiert. Im Mittelpunkt steht hier der Abschnitt zu den Grundsätzen der Dialoggestaltung, der aber nur einen Teil der Anforderungen an die Softwareergonomie darstellt. Da die Grundsätze unabhängig von der eingesetzten Dialogtechnik anwendbar sind, bilden sie das Fundament eines benutzerfreundlichen Systems. Die im zweiten Kapitel vorgestellten Prüfverfahren helfen dem Entwickler die Grundsätze umzusetzen und zu überprüfen. Im Anschluss bietet das Kapitel über Zugänglichkeit eine Vertiefung der ergonomischen Softwaregestaltung. Usability die ISO-Norm 9241 Bedeutung Die ISO-Norm 9241 (DIN EN ISO 9241) [02] der International Organization for Standardization (ISO) definiert ergonomische Grundsätze für Bürotätigkeiten mit Bildschirmgeräten. Sie wurde 1995 vom europäischen Institut für Normung (CEN) angenommen. In der überarbeiteten Fassung aus dem Jahr 2006 wurde der zunehmenden Verwendung von Software außerhalb von Büroumgebungen Rechnung getragen und die Einschränkung auf Bürotätigkeiten aufgehoben. Die Formulierung der ergonomischen Grundsätze wurde für die Mensch-System-Interaktion angepasst. Die Normreihe gilt auf europäischer, nationaler wie internationaler Ebene: Auf der Grundlage der internationalen Norm der ISO wurde die europäische Norm (EN) erarbeitet, die wiederum vom deutschen Institut für Normung (DIN) als DIN-Norm übernommen wurde. In dem deutschen Recht existiert die Bildschirmarbeitsverordnung (BildscharbV), zu der bei Unklarheiten in der Rechtssprechung die ISO-Norm 9241 zur Hilfe genommen wird. Die ISO- Norm hat aus diesem Grund einen rechtlichen Charakter und sollte deshalb sowohl den Softwareentwicklern bekannt sein als auch den Geschäftsführern und Betriebsräten von Unternehmen, die Software in ihren Betrieben einsetzen. Seite 4

5 Zielsetzung Die in der ursprünglichen Fassung aus 17 Teilen bestehende Normreihe befasst sich mit Anforderungen an die Arbeitsumgebung, Hardware und Software. Ziel ist es, den Benutzer vor gesundheitlichen Schäden beim Arbeiten an Rechnersystemen zu bewahren und ihm die Ausführung seiner Arbeitsaufgaben zu erleichtern. Abbildung : Einordnung der Usability nach DATech [06] Hier sollen die Anforderungen an die Softwareergonomie betrachtet werden. Der Begriff Softwareergonomie besteht aus zwei Teilen: Während Software die Gesamtheit der auf einem Rechnersystem laufenden Programme umfasst, bedeutet Ergonomie die Anpassung an den Menschen Es wird hier also von der menschengerechten Gestaltung von rechnergestützen Informations- und Arbeitssystemen gesprochen. Aufgrund der Nutzungsdauer und häufigkeit sollen hier Bürosysteme im Vordergrund stehen. Prinzipiell lassen sich aber natürlich alle Grundsätze auf beliebige Mensch-System-Interaktionen übertragen. Gesundheitliche Aspekte Studien belegen, dass schlecht gestaltete Softwaresysteme der Gesundheit erhebliche Schäden zufügen können [17]. Dabei sind Erkrankungen sehr häufig, die durch Stress verursacht werden: Neben Kopfschmerzen sind Erscheinungen wie Müdigkeit, Lustlosigkeit, Erschöpfung und Reizbarkeit möglich. Des Weiteren können auch Magenbeschwerden, Schlafstörungen und innere Unruhe auftreten. Problematisch ist, dass diese Erkrankungen nicht kurzfristig sind, sondern langfristige Schäden verursachen, deren Auswirkungen auch Jahre nach Erkennen bzw. Beseitigen der Ursache Auswirkungen zeigen. Ziel ist es also, unnötige körperliche sowie psychische Belastungen zu vermeiden. Wirtschaftliche Aspekte Auch aus der wirtschaftlichen Sicht lohnt es, sich mit Softwareergonomie zu beschäftigen. Aus der Perspektive des Kunden ist das größte Problem beim Einsatz von Software in Unternehmen der Einarbeitungsaufwand der Mitarbeiter in neue Softwaresysteme. Die Schwierigkeit wird noch dadurch erhöht, dass Softwaresysteme gemessen an anderen Werkzeugen relativ kurzlebig sind. Ziel von ergonomisch gestalteter Software ist es, den Einarbeitungsaufwand für den Benutzer unabhängig von dessen Erfahrungsgrad möglichst gering zu halten. Dadurch wird nicht nur der Benutzer entlastet, sondern es kann auch der Kostenaufwand für Einarbeitungszeit und Schulungen für Arbeitgeber gespart werden. Die menschliche Denkfähigkeit soll dafür aufgewendet werden Arbeitsaufgaben zu lösen und nicht um komplexe Softwaresysteme zu bedienen. Seite 5

6 Auf der anderen Seite kann auch der Softwareentwickler profitieren: Erkenntnisse über die Umsetzung ergonomischer Grundsätze und deren Prioritäten können in Richtlinien gefasst werden, um vom Anfang einer Softwareentwicklung an eine konsistentere Gestaltung des Produkts zu gewährleisten. Der einzelne Programmierer wird dabei durch die einfache Anwendung der Richtlinie um eine Aufgabe erleichtert und kann sich so besser um andere Probleme kümmern. Die Richtlinie kann zudem sofern vorhanden mit dem Auftraggeber besprochen werden, so dass mögliche Risiken bei der Produktabnahme minimiert werden. Neben der Minimierung des Entwicklungsaufwandes können Richtlinien auch für die Marketingstrategie des Unternehmens benutzt werden: Durch Einbringen eines firmentypisches look & feel in das Erscheinungsbild der grafischen Oberfläche kann sich Corporate Identity (CI) auch in der Software selbst ausdrücken. Benutzer erwarten häufig, dass sich verschiedene Softwareprodukte aus dem gleichen Haus ähnlich bedienen lassen. Ist ein Produkt besonders ergonomisch und gebrauchstauglich, so wirbt dies auch für andere Produkte dieses Herstellers. Der Benutzer Um Software an den Benutzer anpassen zu können, müssen dessen Merkmalen betrachtet werden. Nach dem Abschnitt 10 der ISO-Norm [02] sind folgende Merkmale zu nennen: Aufmerksamkeitspanne Grenzen des Kurzeitgedächtnisses Lerngewohnheiten Grad an Erfahrung * + Das mentale Modell * + Der Grad der Erfahrung bezieht sich auf die Arbeit und den Umgang mit dem Dialogsystem. Im Abschnitt Die sieben Grundsätze der Dialoggestaltung wird allerdings deutlich, dass bei Einhaltung dieser Grundsätze auch der Erfahrungsgrad mit dem Umgang ähnlicher Dialogsysteme wichtig ist. Das mentale Modell des Benutzers von der zugrunde liegenden Struktur des Dialogsystems muss ergründet werden, da es sich durch die Verwendung von Metaphern und Bedienungsstrukturen in der Software von dem tatsächlichen Modell unterscheiden kann. Ein Beispiel wäre die Arbeitsaufgabe Löschen von vertraulichen Informationen : Während der Benutzer denkt, dass Dateien beim Löschen tatsächlich entfernt werden, gibt das System den Speicherplatz aber nur wieder zum Schreiben frei. Auf Grundlage dieser Benutzermerkmale wurden in der ISO-Norm 9241 sieben Grundsätze der Dialoggestaltung als wichtig anerkannt. Die sieben Grundsätze der Dialoggestaltung Jeder der folgenden Grundsätze ist als allgemeine Leitlinie zu verstehen, die durch Empfehlungen und Beispiele versucht unabhängig von einer bestimmten Dialogtechnik bei der Gestaltung von Dialogsystemen zu unterstützen. Als Dialog wird eine Interaktion zwischen einem Benutzer und dem Dialogsystem für die Erreichung eines bestimmten Zieles bezeichnet. Seite 6

7 Aufgabenangemessenheit Nach ISO-Norm wird ein Dialog als aufgabenangemessen bezeichnet, wenn er den Benutzer unterstützt, seine Arbeitsaufgabe effektiv und effizient zu erledigen. Es gibt einige Kriterien, an denen sich die Aufgabenangemessenheit messen lässt: Der Dialog sollte nur Informationen und Hilfsangebote anzeigen, die in den aktuellen Aufgabenkontext passen. Beispielsweise wird die Hilfe für den Wikisyntax nur dann angezeigt, wenn ein Artikel erstellt oder geändert wird. Es müssen keine systembedingten Tätigkeiten von dem Benutzer zu erledigen sein. Wird beispielsweise eine neue Datei erstellt, darf der Benutzer nicht mit Problemen wie der Zeichensatzkodierung belastet werden. Werden für die Erfüllung der Aufgabe Eingaben gefordert, müssen die Felder sofern möglich mit Standardwerten (Defaults) gefüllt werden. Bei wiederkehrenden Aufgaben muss das System unterstützen. Denkbar sind hier definierbare Templates oder die Speicherung vorheriger Eingaben für die Wiederverwendung. Unnötige Arbeitsschritte sollen vermieden werden (Abb. 1). Abbildung : Speichern und Schließen als eine Aktion Selbstbeschreibungsfähigkeit Ist ein Dialog selbstbeschreibungsfähig, ist dem Benutzer jeder Schritt des Dialogsystems verständlich oder eine Erklärung kann auf Nachfrage erfolgen. Die Selbstbeschreibungsfähigkeit hilft dem Benutzer sich ohne Anleitung zurechtzufinden und so den Einarbeitungsaufwand zu verringern. Ein gutes selbstbeschreibendes System kann je nach Komplexität auch ohne externe Dokumentation bedienbar sein. Vor der Ausführung von Operationen mit schwerwiegenden Folgen muss entsprechend informiert werden und gegebenenfalls eine Warnung vor unumkehrbaren Arbeitsschritten ausgegeben werden. Die Meldungen müssen die Terminologie des Nutzers verwenden, die sich aus dem Arbeitsgebiet, z.b. Finanzdienstleistungen oder Automobilbau, ableiten lassen. Die Rückmeldungen sollen an den Kenntnisgrad angepasst werden, der zu erwarten ist. (vgl. Der Benutzer ). Die Beschreibungen der Meldungen ergänzen das Wissen des Benutzers über das zugrunde liegende Dialogsystem. Die Meldung Bitte warten ist nicht ausreichend, stattdessen sollen sinnvolle Informationen über den Systemzustand angezeigt werden: Bitte warten, die Datei wird gespeichert. Seite 7

8 Steuerbarkeit Ein steuerbarer Dialog zeichnet sich dadurch aus, dass der Benutzer bis zur Erreichung des Ziels die Richtung und die Geschwindigkeit des Dialogs bestimmen kann. Das Dialogsystem sollte daher nicht eigenständig Aktionen vornehmen, bis der Benutzer die Vollständigkeit einer Eingabe bestätigt, z.b. durch Drücken der Eingabetaste. Es sollte selbstverständlich sein, dass der Benutzer auswählt in welcher Reihenfolge er welche Elemente bearbeitet, d.h. der Benutzer hat die Kontrolle über die Richtung des Dialogs. Dialogschritte müssen auch reversibel sein, d.h. man sollte zumindest den letzten Dialogschritt rückgängig machen können. Dialogsysteme sollten bei dem Abbrechen und Wiederaufnehmen von Arbeitsaufgaben Unterstützung anbieten. Insbesondere durch Unterbrechungen außerhalb des Bürosystems wie Anrufe oder Anfragen von Kollegen kann es notwendig sein, eine aktuelle Aufgabe abzubrechen und diese später fortzusetzten. In der Arbeitswirklichkeit zeigt sich, dass durch diese Problematik viel Arbeitszeit verloren geht. Ein steuerbares System bietet Wiederaufnahmepunkte, bei dem der Dialog fortgesetzt werden kann, sofern dies zweckmäßig ist. Zu guter letzt sei noch erwähnt, dass sich der Benutzer entscheiden können muss, auf welche Art der Eingabe-/Ausgabegeräte er zurückgreifen möchte. Das System sollte neben der Steuerung über die Maus beispielsweise auch komplett über die Tastatur bedienbar sein. Erwartungskonformität Laut Norm ist ein Dialog erwartungskonform, wenn er konsistent ist und den Merkmalen des Benutzers entspricht, z.b. den Kenntnissen aus dem Arbeitsgebiet, der Ausbildung und der Erfahrung des Benutzers sowie den allgemein anerkannten Konventionen. Hierbei ist das Prinzip der Ortskodierung wichtig: Menschen merken sich die Position von Komponenten und verknüpfen diese dann mit einer Funktion. Dieses Prinzip sollte genutzt werden, um Erwartungskonformität zu erreichen: Komponenten mit ähnlicher oder gleicher Funktion sollten immer an der gleichen Position der Software stehen, d.h. es ist eine einheitliche Position von Komponenten anzustreben. So wie ein Benutzer von Windows / Linux Systemen weis, dass das Programmmenu in fast jeder Software in der linken oberen Ecke zu finden ist, wird ein Benutzer von Macintosh Systemen am oberen Bildschirmrand suchen. Wie schon bei der Selbstbeschreibungsfähigkeit erwähnt, sollte der Wortschatz verwendet werden, mit dem der Benutzer bereits vertraut ist. Einige andere wichtige Merkmale der Erwartungskonformität sollen nicht ungenannt bleiben: Shortcuts sollten konsistent verwendet werden, nach Möglichkeit auch über die Grenze des eigenen Produkts hinweg. Es gibt allgemein bekannte Kürzel, die nicht für eine andere Funktion verwendet werden sollten, wie die Taste F1, die immer das Hilfesystem starten sollte. Für ähnliche Aufgaben sollten die Dialoge ähnlich gestaltet sein, so dass der Benutzer einen Lernprozess nur einmal durchschreiten muss und bei der nächsten Aufgabe analog zu der bekannten vorgehen kann. Seite 8

9 Sollte die Antwortzeit des Dialogsystems zu hoch sein (i.d.r. sei ein Richtwert von 15ms genannt), so muss dem Benutzer der aktuelle Bearbeitungsstatus visualisiert werden. Bei längeren Prozessen eigenen sich Fortschrittsbalken, bei kürzeren genügt oft auch eine Aktivitätsanzeige oder eine textuelle Information. Fehlertoleranz Eine wichtige Eigenschaft ergonomischer Systeme ist die Fehlertoleranz, da diese maßgebend für das Verhalten des Nutzers ist. Merkt ein Benutzer, dass ein System instabil ist, leicht in undefinierte Zustände kommt und Fehler zulässt, wird er wenig experimentierfreudig sein. Verhält sich ein System hingegen stabil, hilft bei dem Entdecken von Eingabefehlern, unterstützt bei der Lokalisation dieser Fehler (Abb. 3) und stellt dieses mit einer angemessenen Aufmerksamkeitserregung dar, wird der Benutzer sich eher entdeckungsfreudig verhalten und kann so stressfrei und ohne Lektüre der Betriebsanleitung das System erkunden. In der ISO-Norm wird davon gesprochen, dass das Arbeitsergebnis durch den Benutzer bei Fehlern entweder mit keinem oder mit minimalen Korrekturaufwand erreicht werden kann. Es sollte immer versucht werden, Fehlerwerte von vornherein nicht zuzulassen, um frühzeitig auf den Fehler aufmerksam zu machen. Stellt man sich ein System vor, in Abbildung : angemessener Hinweis auf einen Eingabefehler dem eine Matrikelnummer in ein Formular eingetragen werden soll, wäre es also richtig bereits beim Verlassen des Feldes durch den Cursor im Fehlerfall darauf hinzuweisen, dass die Matrikelnummer ein sechsstelliger numerischer Wert sein muss. Wird die Validierung erst beim Abschicken des Formulars durchgeführt, ist der Korrekturaufwand ein wenig höher. Eine noch spätere Überprüfung, beispielsweise bei mehrseiteigen Formularen ist auszuschließen, sofern eine frühere Validierung möglich wäre. Des Weiteren müssen Fehler erläutert werden. Zudem ist es wünschenswert, gegebenenfalls eine erweiterte Hilfe anzubieten. Sofern möglich, sollte das System Fehler automatisch korrigieren. Ein berühmtes Beispiel hierfür sind Textverarbeitungssysteme, die kleine Fehler wie klein geschriebene Wörter am Satzanfang automatisch korrigieren. Individualisierbarkeit Ein Dialog ist individualisierbar, wenn das Dialogsystem Anpassungen an die Erfordernisse der Arbeitsaufgabe, individuelle Vorlieben des Benutzers und Benutzerfähigkeiten zulässt. ISO Seite 9

10 Vorweg sei erwähnt, dass die Individualisierbarkeit immer nur in einem gewissen Rahmen möglich sein darf, um den Benutzer vor bestimmten Beeinträchtigungen zu bewahren. Es dürfen z.b. unannehmbare Lautstärken, die das Hörvermögen beeinträchtigen können, nicht möglich sein. Bei der Individualisierung werden im Wesentlichen die Gegenstände der Anpassung und die Wirkungsdauer betrachtet. Es sind verschiedenste Anpassungen möglich, unter anderem Anpassungen an kulturelle Gegebenheiten, Anpassungen an den Kenntnisgrad, den Arbeitsstil und dem Verständnis des Benutzers und auch an dessen Wahrnehmungsvermögen sowie seinen sensomotorischen Fähigkeiten. Wie schon bei dem Grundsatz Selbstbeschreibungsfähigkeit genannt, ist es erforderlich den Umfang von Erläuterungen und Hilfen einstellen zu können. Die Definition eines eigenen Vokabulars für Objekte und Funktionen, z.b. durch die Nutzung von Synonymen, sollte möglich sein. Des Weiteren kann es für Arbeitsaufgaben sinnvoll sein, eigene Kommandos durch die Definition von Makros hinzuzufügen und so neue Funktionalität durch die Komposition von Einzelfunktionen zu ergänzen, die dann durch neue Buttons oder Shortcuts ansprechbar sind. Für das Erstellen dieser Makros gibt es je nach Kenntnisgrad des Benutzers und der Arbeitsaufgabe die Möglichkeit eine Makrosprache einzusetzen oder Kommandofolgen bei Vorführung des Benutzers aufzuzeichnen. Die ISO-Norm geht dabei nicht näher auf die Anwendungsdauer der Anpassungen ein. Es ist dennoch interessant zu wissen, dass die Individualisierungen situativ also einmalig sein können, an ein Dokument gebunden, für eine Sitzungsperiode gelten können oder permanent sind. Die Definition eigener Wege heißt nicht, dass die zuvor vorhandenen verloren gehen, sondern dass zu den ohnehin existierenden Dialogfolgen weitere hinzukommen und die in einem guten System existierende Lösungsvielfalt ergänzt wird. Zusammenfassend lässt sich sagen, dass die Produktivität durch Individualisierung dann steigt, wenn den Grundsätzen der Aufgabenangemessenheit und der Steuerbarkeit beigetragen wird. Wie anfangs bereits genannt kann eine schlechte Individualisierung aber auch Unübersichtlichkeit verursachen und ist deshalb mit Bedacht zu handhaben. Lernförderlichkeit Auch die Lernförderlichkeit hängt von anderen Grundsätzen ab: Eine gute Steuerbarkeit und Selbstbeschreibungsfähigkeit fördern den Lernprozess des Benutzers im Umgang mit der Software. Es liegt auf der Hand, dass Anleitungen und Hilfssysteme weniger genutzt werden müssen, wenn die Software den Fähigkeiten des Benutzers entsprechend Hinweise erteilt und das Arbeitsergebnis leicht erreichbar und ersichtlich ist zum Beispiel über das Prinzip What you see is what you get (WYSIWYG). Von der Software angebotene Lernstrategien unterstützen den Benutzer bei der Einarbeitung in das System. Dabei ist Learning by doing mit Sicherheit eine der besten Strategien, ein tieferes Verständnis zu erlangen. Damit dies funktionieren kann, muss die Software in der Lage sein eine Vorschau für Ergebnisse nach anwendbaren Operationen anzuzeigen oder es müssen alle Arbeitsschritte reversibel sein, so dass keine Gefahr besteht bisher erreichte Ergebnisse zu Seite 10

11 verlieren. Es ist auch ein interaktiver Online-Unterricht denkbar, wie er inzwischen in vielen Produkten zu finden ist. Neben Benutzern, die sich das erste Mal in ein System einarbeiten müssen, sind auch die Benutzer zu beachten, die die Software nur selten benutzen und so ihr Wissen wieder auffrischen müssen. Dazu sollten weniger benutzte Kommandos selbstbeschreibender gestaltet werden, d.h. mit mehr Hinweisinformationen versehen werden, und häufig benutzte Kommandos mit Abkürzungen und Vorbelegungen angeboten werden. Prüfbarkeit von Softwareergonomie Es ist neben der allgemeinen Kenntnis der relevanten Teile der ISO-Norm 9241 wissenswert, mit welchen Verfahren die Benutzerfreundlichkeit prüfbar ist. Im folgendem werden die Prüfverfahren KO-Kriterien und IsoMetrics vorgestellt, die nicht nur von Softwareentwicklern angewendet werden. Als Beispiel wäre ein Unternehmen denkbar, dass eine neue Software für seine Angestellten einführen will. Betriebsräte sind dann durchaus in der Lage, anhand der genannten Prüfverfahren die Einführung dieser Software zu verhindern, beziehungsweise bei konkurrierenden Systemen das benutzerfreundlichste zu wählen. Nicht nur deshalb ist es auch für den Softwareentwickler wichtig, die Prüfverfahren zu kennen: Bei richtigem Einsatz unterstützen die Prüfverfahren den Entwicklungsprozess, da die Kriterien ob nun gewichtet oder nicht als Ziele in Entwicklungsabschnitte mit einfließen können. Betrachtet man die möglichen Vorteile, ist der mit Sicherheit entstehende Zeitaufwand gerechtfertigt, wobei sowohl die KO-Kriterien als auch IsoMetrics im Vergleich zu anderen Prüfverfahren noch relativ zeitschonend sind. Eine Einarbeitungszeit in das Prüfverfahren und in die Software ist natürlich unumgänglich, wobei unter Umständen noch eine Auswertungsphase hinzukommt. KO-Kriterien Bei den KO-Kriterien handelt es sich um Ausschlusskriterien zur ergonomischen Prüfung von Bürosoftware, die auf Grundlage der EG-Richtlinie zur Softwareergonomie und der ISO-Norm 9241 entwickelt wurden. Es handelt sich hierbei um eine Broschüre [04], mit der der Autor Betriebs- und Personalräten/-rätinnen sowie interessierten Arbeitnehmern/Arbeitnehmerinnen ein Instrument an die Hand geben [will], mit dem sie Anwendungssoftware auf ihre ergonomische Tauglichkeit hin prüfen können. Gerade aus diesem Grund ist es auch für den Softwareentwickler interessant, an welchen Maßstab die Kunden den Softwareentwickler messen. Dabei wird anhand von 29 Ausschlusskriterien festgestellt, ob der Einsatz einer Software verantwortbar ist. Für jedes Ausschlusskriterium wird das Kriterium selbst, die nötige Prüfaktion, die Ausschlussmerkmale, der Bezug und optional Anmerkungen und Beispiele angegeben. Der Autor weist aber auch auf Schwierigkeiten hin, die bei Anwendung des Verfahrens auftreten können. Unter Umständen kann ein Kriterium durch den Prüfenden nicht bewertbar sein, weil Seite 11

12 Informationen über den Sachverhalt fehlen, sich die Prüfenden Personen über einen Sachverhalt uneinig sind, es an Sachverstand oder Expertenwissen fehlt oder zum Beispiel Datenbestände nicht verfügbar sind, so dass eine realitätsnahe Prüfumgebung nicht gegeben ist. Abbildung : Beispiel für ein Ausschlusskriterium [04] Betrachtet man das Beispiel (Abb. 4), lassen sich die genannten Schwierigkeiten schon erahnen: Lässt sich in der Dokumentation ein Hinweis über den verwendeten Standard finden? Ist ein herstellereigener Standard genannt, lässt sich in angemessener Zeit ermitteln, ob sich dieser auf einen der genannten Standards beruft? Ist es realistisch ein System abzulehnen, nur weil sich nicht herausfinden lässt, auf welchen Standard es basiert? Doch obwohl es einige Spielräume zu geben scheint, in denen Unklarheiten auftauchen mögen, kann man bei sachlicher und realitätsnaher Betrachtung Systeme fair bewerten. Zuletzt zeigt es auch dem Softwareentwickler, welche Fehler zu vermeiden sind. IsoMetrics Das Prüfverfahren IsoMetrics [09] bezieht sich auf den Abschnitt 10 der ISO-Norm 9241 und enthält 75 Fragen zu den Grundsätzen der Dialoggestaltung. Es gibt eine Kurzversion und eine Langversion, die sich grundsätzlich unterscheiden: Die Variante IsoMetricsS ist die Kurzversion (S steht dabei für short) und ist summativ, d.h. als Ergebnis des Verfahrens ergibt sich ein Wert, der als Maßzahl benutzt werden kann und sich so zum Vergleich verschiedener Softwaresysteme eignet. Die Langversion IsoMetricsL (l für long) ist formativ und eignet sich deshalb für die Verbesserung eines einzelnen Softwaresystems. Seite 12

13 IsoMetricsS Da sich als Ergebnis der Kurzversion ein vergleichbarer Wert ergibt, scheint dieses Verfahren natürlich nur sinnvoll anwendbar, wenn ein zweites vergleichbares System vorliegt. Als weiteres Anwendungsgebiet kann es jedoch schon während des Entwicklungsprozesses zum Einsatz kommen: Durch die sich ergebende Maßzahl nach Durchführung des Prüfverfahrens lassen sich Prototypen vergleichen. Somit ist es möglich, schon vor der Hauptimplementierungsphase den besten Weg zu einer benutzerfreundlichen Software zu wählen und so auch Kosten zu sparen, da größere Änderungen in der späten Entwicklungsphase unwahrscheinlicher werden. Außerdem kann dieses Verfahren auch bei einer iterativen Entwicklung ein entsprechend großes Projekt vorausgesetzt - eingesetzt werden. Damit ist es möglich an fest definierten Punkten, z.b. Milestones die Software neu zu bewerten und so den Entwicklungsfortschritt aus Sicht der Usability zu bewerten. IsoMetricsL Im Gegensatz zu der Kurzversion wird bei der Langversion auch die Wichtigkeit eines Aspektes abgefragt, wodurch es möglich ist die einzelnen Prüffragen mit einer Priorität zu versehen. Zudem wird Raum für Anmerkungen geboten, in dem protokolliert wird an welchem Ort die Software noch Verbesserungspotential hat. Diese Variante ist somit formativ, d.h. sie eignet sich um Benutzerschnittstellen zu designen bzw. die Planung für die Verbesserung bestehender Schnittstellen zu unterstützen. Barrierefreiheit / Zugänglichkeit Schon der Titel dieses Kapitels zeigt ein Problem: Das Erreichen von Barrierefreiheit ist das Ziel der aktuellen Entwicklungen, doch leider gibt es einige Probleme, mit denen sich der Softwareentwickler beschäftigen muss: Projekte haben in sehr vielen Fällen einen engen Zeit- und Kostenrahmen, in dem das Produkt realisiert werden muss. Erschwerend können noch spezielle Kundenwünsche hinzukommen, die manchmal sogar einzelnen Grundsätzen der Usability widersprechen. Zudem muss sich der Entwickler noch über rechtliche Rahmenbedingungen wie z.b. der BildscharbV oder dem Barrierefreie Informationstechnologie Verordnung (BITV) im Klaren sein. Ziel kann es also nur sein einen guten Kompromiss zu finden, den Kunden zu beraten um so Barrieren abbauen zu können und Hilfsmittel die über die normalen Grundsätze der Dialoggestaltung hinausgehen anzubieten. Aus diesem Grund wird häufiger über Zugänglichkeit gesprochen. Zu guter letzt ist natürlich nicht zu vernachlässigen, dass bei allen Bemühungen bei der Übersetzung von einer visuellen Form in die textuelle Form immer Verluste auftreten werden. Grundlagen Wie im Kapitel über Usability hilft es auch hier sich den Benutzer mit seinen speziellen Merkmalen anzusehen, um ein besseres Verständnis dafür zu erlangen, weshalb eigentlich spezielle Maßnahmen für diese Nutzergruppe zu treffen sind. Neben den Merkmalen des Benutzers der ISO-Norm 9241 sind jetzt noch die Merkmale Seite 13

14 Sehfähigkeit Hörfähigkeit motorische Fähigkeit Lernbehinderungen zu betrachten. Man darf dabei nicht denken, dass diese Zielgruppe klein ist: Bereits ab dem vierzigsten Lebensjahr lässt im Allgemeinen die Sehfähigkeit nach, ab dem sechzigsten Lebensjahr kann es Einbußen bei der Feinmotorik geben. Im weiteren Verlauf ist auch häufig mit Einschränkungen bei der Gedächtnisleistung und der Konzentrationsfähigkeit zu rechnen. Erhöhte Zugänglichkeit Abbildung : Einordnung der Zugänglichkeit [06], erweitert kommt neben Menschen mit Behinderungen auch älteren Menschen zugute. Nicht zuletzt kann selbst der normale Benutzer von der Zugänglichkeit profitieren, da die Zugänglichkeit den Gedanken der Usability weiter führt. Betrachtet man den Markt aus dieser Perspektive, ist die Nachfrage von Menschen mit eingeschränkten Fähigkeiten im Bereich der Informationsbeschaffung und Kommunikation über das World Wide Web besonders hoch. Gerade hier gibt es aber die meisten Barrieren. Während in der Zeit von MS-DOS und Unix zeilenorientiere Terminalprogramme keine Barrieren für Braillezeilen darstellten und auch übliche Software durch die Vielfältigkeit der Bedienungsmöglichkeiten eher geringe Hindernisse darstellen, sind die Probleme bei Internetauftritten und angeboten wesentlich größer: Die hohe Komplexität des Webdesigns, fehlende Standardkonformität und fehlendes Problembewusstsein bei den Webentwicklern führt oftmals zu schwer zugänglichen Dokumenten. Aus diesem Grund wurde in diesem Gebiet viel geforscht, so dass es bereits umfangreiche Forschungsergebnisse und auch Literatur zu diesem Thema gibt im folgenden Abschnitt sei darüber ein Überblick gegeben. Web accessibility Für die barrierefreie Gestaltung von Internetseiten haben die Web Content Accessibility Guidelines (WCAG) und die Barrierefreie Informationstechnologie Verordnung (BITV) Bedeutung. Die Web Content Accessibility Guidelines wurden von der Web Accessibility Initiative (WAI) entwickelt und liegen seit 1999 in der ersten Fassung vor. Neben den Regeln [15] gibt es eine Checkliste [16], die dem Entwickler helfen soll, Internetangebote zugänglicher zu gestalten. Während die WCAG empfehlenden Charakter haben, ist die BITV in Deutschland für Behörden der Bundesverwaltung gesetzlich bindend [07]. Einige Länder sind dem Beispiel des Bundes gefolgt und gestalten ihre Internetangebote nach der BITV. Seit der Veröffentlichung der noch nicht vollkommenen WCAG 1.0 wurde allerdings die zweite Version, die 2001 fertiggestellt werden sollte bis heute nur als Working Draft zur Verfügung gestellt die finale Fassung lässt auf sich warten. Auch die BITV, die bis Mai 2005 hätte überprüft werden müssen, wurde seit der Publikation im Jahr 2002 nicht verändert. Letztendlich ist die Erkenntnis wichtig, dass auf den Seite 14

15 Einsatz verschiedener Techniken im Web mehr eingegangen werden muss, als noch in den Anfangszeiten. Die Probleme liegen im großen Teil darin, dass in der Anfangszeit des Hypertextes Tabellen für das Layout benutzt wurden, so dass die lineare Struktur der Informationen gestört wird und Braillezeilen und Screenreader keine Informationen über den tatsächlichen Zusammenhang des Inhalts finden können. Erstaunlich ist, dass sich solche Layouts noch heutzutage finden lassen, obwohl selbst der erste Browser von Tim Berners-Lee schon CSS unterstützte. Dies lässt sich aber nicht nur auf mangelnde Kenntnisse von Webentwicklern zurückführen, sondern auch mangelhafte Codegeneratoren von WYSIWYG Editoren. Bei richtigem Einsatz bekommen Browser, die kein CSS interpretieren können neben Screenreadern und Braillezeilen übrigens auch Suchroboter nur den Inhaltstext ohne Layoutinformationen. Eine weitere Problematik ergibt sich durch den Einsatz verschiedenster Technologien, die sich in heutigen Webangeboten wiederfinden. Ein populäres Beispiel ist hierbei der Einsatz von Flash: Trotz einiger Bemühungen von Adobe, Flashinhalte über die Microsoft Active Accessibility (MSAA) [19] Schnittstelle zugänglicher zu machen, ist dies in nur wenigen Fällen erfolgreich gewesen. Die MSAA Schnittstelle stellt Funktionalität für Hilfswerkzeuge wie Screenreader oder Hervorhebungstools auf die jeweilige Software bereit. Nachteilig ist jedoch, dass jede Software ihre eigene Implementierung der Schnittstelle bietet und somit das Hilfswerkzeug an jedes Produkt angepasst werden muss. Hinzu kommt, dass bis jetzt wenige Softwareprodukte diese Unterstützung bieten. Bei den WCAG gibt es eine Muss eine Soll und eine Darf Stufe, während die BITV etwas strenger ist und Muss und Soll Kriterien in der ersten Stufe zusammenfasst. Internetangebote, die die Richtlinien einhalten dürfen mit den abgebildeten Icons auf die Konformitätsstufe aufmerksam machen. Priorität WCAG1 Priorität BITV Konformität 1 - «Muss» Kriterien «Soll» Kriterien I «Muss» und «Soll» 3 - «Darf» Kriterien II «Darf» Seite 15

16 Beispiele Einige Beispiele sollen helfen, einen Eindruck zu vermitteln, welche Probleme auftreten können. Ist man sich der Probleme bewusst, erhöht sich die Entwicklungszeit für einige Problemlösungen nicht, während für andere Aspekte zusätzlicher Arbeitsaufwand entsteht. Dass die HTML und CSS Quellen standardkonform sein sollten, versteht sich beinahe von selbst (BITV, Anforderung 3 / WCAG Guideline 11). Textalternativen Es ist schon sehr bekannt, dass für alle nicht textuellen Elemente eines Dokumentes Alternativtexte vergeben werden müssen. Dabei ist es nun interessant zu wissen, nach welchen Regeln dies geschehen soll. Während bei sich der Autor des Internetangebots bei Soundfiles und Videos selber Gedanken machen muss, wie er die Inhalte zugänglich macht, gibt es bei Bildern definierte Regeln, auch wenn es hier Schwierigkeiten geben kann. Äquivalente für Landkarten, Karikaturen oder Diagramme sind nur schwer vorstellbar. Man unterscheidet im Allgemeinen zwischen Informationsgrafiken, Darstellungsbildern und Layoutgrafiken. Informationsgrafiken enthalten üblicherweise einen grafischen Text, ein eindeutiges Symbol oder ein Logo. Diese Informationen lassen sich in den meisten Fällen leicht in Textform fassen. Ein Beispiel wäre ein Knopf mit einem Druckersymbol, der auf die Druckversion des Dokumentes verweist. Darstellungsbilder, wie zum Beispiel Diagramme, Karten und Fotos erfordern einen Text, in dem das abgebildete Objekt im Vordergrund steht und nicht die Funktion. Es fällt unter Umständen leichter einen Alternativtext zu finden, wenn man sich fragt: Was wird abgebildet? Wie wird es abgebildet? Im Gegensatz hierzu muss man bei Layoutgrafiken anders vorgehen: Hat eine Grafik ausschließlich den Zweck, das Layout zu stützen ohne dabei eine andere Funktion zu übernehmen, so ist ein leerer Alternativtext anzugeben, damit beispielsweise Screenreader diese Elemente beim Vorlesen auslassen. Hat die Grafik den Zweck eine bestimmte Stimmung zu vermitteln, ist es durchaus legitim diese in der Layoutgrafik zu beschreiben. In allen anderen Fällen sollten Layoutgrafiken aber da stehen wo sie nach dem Standard hingehören nämlich in das zugehörige Cascading Style Sheet (CSS). Farben und Kontraste Farben haben einen großen Einfluss auf menschliche Stimmungen und werden deshalb gerne gezielt in Designs eingesetzt. In Hinblick auf das Layout wurde jedoch in Studien festgestellt, dass Farben in schlechten Abbildung : Informationsverlust durch fehlenden Kontrast Layouts die Übersichtlichkeit erheblich senken können, während Farben in guten Layouts die Übersichtlichkeit nur wenig verbessern können. Grundsätzlich verbessert man hier also nicht nur die Zugänglichkeit, sondern auch die Gebrauchstauglichkeit. Es kommt Seite 16

17 Abbildung : Toolunterstützung für den Layoutentwurf nun hinzu, dass einige Menschen Sehschwächen in Bezug auf Farben haben. Neben der relativ seltenen Farbenblindheit ist die Rot-Grün-Blindheit sehr verbreitet. Es empfiehlt sich deshalb, Layouts zunächst in einer Graustufenansicht (Abb. 7) zu entwickeln und danach mit Farbinformationen anzureichern. Dabei ist auf das Prinzip der Farbneutralität (BITV, Anforderung 2 / WCAG1.0, Guideline 2) zu achten: Fallen die Farben wegen einer Graustufendarstellung des Anzeigegerätes oder Farbfehlsichtigkeit des Benutzers weg, dürfen keine Informationen, wie zum Beispiel die Unterstreichung in Abbildung 6, verschwinden. Es ist ratsam vorab Farbschemata zu entwickeln, die weder zu schwache Kontraste aufweisen und langweilige und verwaschene Erscheinungsbilder erzeugen, noch zu starke Kontraste enthalten und so das Design unruhig und chaotisch wirken lassen. Sprache Werden in einem Dokument mehrere Sprachen benutzt oder treten sprachliche Besonderheiten auf, so ist dies erkennbar zu machen (BITV, Anforderung 4). Screenreader bzw. Sprachsynthetisierer sind auf die Kenntnis der Sprache angewiesen, damit sie wissen wie die Wörter ausgesprochen werden sollen. Sprachwechsel: <span lang="en" xml:lang="en">coffee</span> Abkürzung: <akronym lang="en" title="cascading Style Sheet"> CSS </akronym> Natürlich sollten für alle Sonderzeichen die im HTML Standard spezifizierten Character Entities benutzt werden z.b. <quot> für Zitate. Navigation und Orientierung Im Gegensatz zu klassischen Medien wie Büchern, Tonbändern oder Videos erhält man Informationen nicht sequenziell oder hierarchisch, sondern in beliebigen Reihenfolgen und Ordnungen. Aus diesem Grund ist eine gute Navigation das Herzstück einer jeden Webpräsenz. Ein gut navigierbares System beantwortet stets folgende Fragen: Wo bin ich? Wie kam ich hierher? Wo kann ich von hier aus hin? Da die Navigation dem Benutzer den Zugang zu den Inhalten des Angebots gewährt, ist es an dieser Stelle besonders bedeutend Barrieren zu vermeiden. Es gibt einige Regeln, die eine gute Navigation ausmachen: Die Navigation muss zum einen selbstverständlich ein übersichtliches Aussehen haben (siehe Abschnitt Abbildung : Bread-Crumb-Trial zur Orientierung Farben und Kontraste ). Zusätzlich sollte sie geräteunabhängig sein und ohne nutzerseitige Plug-ins und Skripte funktionieren. Es gilt insbesondere für die Navigation der Grundsatz Seite 17

18 Selbst-beschreibungs-fähigkeit der Dialoggestaltung. Die Hyperlinks müssen verständlich beschriftet sein. Eine Beschriftung wie hier klicken wäre beispielsweise nicht akzeptabel. Eine Pfadangabe hilft oft, sich in einem Webangebot zurechtzufinden (Abbildung 7). Wichtig ist immer, dass die Navigationsmechanismen schlüssig und nachvollziehbar eingesetzt werden. Geräteunabhängigkeit und Abwärtskompabilität Kurz gesprochen geht es darum zu verhindern, dass durch den Einsatz spezieller Technologien der Benutzer auf Inhalte nicht mehr zugreifen kann. Dies kann verschiedene Gründe haben. Als Neue Technologien wird durch die BITV mehr oder weniger alles Bezeichnet, was über herkömmliches HTML hinausgeht. Hierzu gehören Java Applets, JavaScripte, Flashanwendungen, Dokumente im PDF Format und Multimediaformate. Der Einsatz dieser Technologien wird durch die Verordnung nicht verboten, nur muss wie im Kapitel Textalternativen erläutert ein entsprechender Ersatz bereit stehen. Um geräteunabhängig zu sein (BITV, Anforderung 9 / WCAG1.0 Guideline 9), sollte auch auf Handler wie onmouseover oder onkeypress verzichtet werden, weil hier die Verwendung eines bestimmten Eingabeinstrumentes gefordert wird. Es wird daher empfohlen, logische Handler wie onchange oder onfocus zu verwenden. Nach Anforderung 10 der BITV müssen Dokumente auch von nicht mehr [dem] jeweils aktuellen Stand entsprechenden Technik kurz veralteter Software darstellbar sein. Da ohnehin die Verwendung offener Standards gefordert wird, läuft das Ganze auf die Standards XHTML und CSS hinaus, die von den gängigen Clients unterstützt werden. Diese Anforderung steht jedoch auch teilweise im Konflikt mit der Entwicklung neuer Standards, denn wie soll sich beispielsweise CSS3 durchsetzten, wenn alte Software nicht vernachlässigt werden darf. Die Komplexität dieser Problematik scheint somit eher zu steigen als zu sinken. Seite 18

19 Fazit Es gibt zahlreiche Gründe sich mit der Gebrauchstauglichkeit und der Zugänglichkeit von Software zu beschäftigen, doch es zeigt sich auch, dass es nicht immer einfach ist alle Anforderungen zu erfüllen. Es liegt auf der Hand, dass Fachwissen bei den Entwicklern hilft die Qualität von Software zu verbessern. Wenn man nur die wichtigsten Aspekte betrachtet erhöht sich die Entwicklungszeit nicht wesentlich, wenn das Produkt aber bis in das Detail abgestimmt werden soll, ist es ratsam Experten einzusetzen, die in der Projektplanung und Qualitätssicherung alle Entwicklungen im Blick behalten und von den ersten Entwürfen an mitarbeiten. Insbesondere im Bereich Zugänglichkeit ist viel Wissen erforderlich, um ein gutes Internetangebot entwickeln zu können. Zumindest Grundkenntnisse sind aber für alle Softwareentwickler sinnvoll und auch in akzeptabler Zeit anzueignen. Sind alle Projektbeteiligten für diese Themen sensibilisiert werden von Anfang an weniger Probleme entstehen und so auch weniger nachträgliche Korrekturen nötig sein. Man muss immer im Hinterkopf behalten, dass die wenigsten Aspekte statisch überprüfbar sind und man deshalb in der Projektplanung Zeit für die Prüfung der Software kalkulieren muss. Über die genaue Priorität der Aspekte sollte man sich nach einer detaillierten Zielgruppenanalyse Gedanken machen, denn nicht immer ist es nötig die höchste Konformitätsstufe für Zugänglichkeit zu erreichen. Da aber die Gebrauchstauglichkeit und Zugänglichkeit eine immer größere Rolle im Wettbewerb spielt, werden sich Investitionen in diesem Gebiet mit hoher Wahrscheinlichkeit auszahlen. Seite 19

20 Quellen ISO-Norm 9241 / Usability Gesetze [01] Überblick über die ISO Norm 9241, [02] Die ISO-Norm 9241 Abschnitt 10, [03] Methoden der Bewertung von Software, D. Bauer, D. Röckmann, Wirtschaftsverlag NW, 1999 [04] Software auf dem Prüfstand, Ausschlusskriterien zur ergonomischen Prüfung von Büro- Software, Wolfgang Hampe-Neteler, Bund-Verlag [05] ISO : Dialogknigge, , Fraunhofer Institut (FIT) [06] Leitfaden Usability: Modell der DATech, Deutsche Akkreditierungsstelle Technik GmbH [07] Barrierefreie Informationstechnologie Verordnung, , BGBl. I S [08] Bildschirmarbeitsverordnung BildscharbV, , BGBl. I S Prüfverfahren IsoMetrics *09+ IsoMetrics - Development of a software usability instrument, [10] Institut für wissenschaftspsychologische Forschung und Beratung GmbH, Prüfverfahren KO-Kriterien [11] Ausschlusskriterien zur ergonomischen Prüfung von Büro-Software, Wolfgang Hampe-Neteler, Bund-Verlag, 1994 Barrierefreies Webdesign [12] Barrierefreies Webdesign, Jan Eric Hellbusch, dpunkt.verlag, 2005 [13] Barrierefreies Webdesign, Angie Radtke und Dr. Michael Charlier, Addison-Wesley 2006 Web Content Accessibility Guidelines (WCAG) [14] Web Content Accessibility Guidelines, Überblick, [15] Web Content Accessibility Guidelines 1.0, W3C, [16] Web Content Accessibility Guidelines Checklist, W3C, Weitere Quellen [17] Gesundheit am Bildschirmarbeitsplatz, Junghanns und Ullsperger, 1998 [18] [19] MSAA: Seite 20