Die Praxis zeigt, dass Formulare häufig weder benutzerfreundlich noch barrierefrei sind. In unserer Formularserie hatten wir das Testen von Formularen bereits ausführlich behandelt. An dieser Stelle wollen wir aufzeigen, welche Probleme in der Praxis entstehen können, wenn Formulare nicht ausreichend getestet wurden. Wir nehmen hier ein Beispiel, das es so gegeben hat. Es handelt sich dabei um eine einfache Umfrage, die mittlerweile nicht mehr online steht.
Weiterlesen …
Bei dem Formular handelt es sich um eine Umfrage mit vielen Checkboxen, ein paar Radio-Buttons, zwei Eingabefeldern, einem Auswahlfeld und einem
Absendebutton. In einem kurzen Einleitungstext wird der Inhalt und Zweck der Umfrage zusammengefasst. Die Umfrage selbst besteht aus mehreren Blöcken, pro Block kann zwischen etwa zehn Optionen per Checkbox ausgewählt werden.
Das Formular wird nicht clientseitig validiert, das heißt, Fehler bei der Eingabe werden erst nach dem Absenden des Formulars und dem Neuladen der Seite angezeigt.
Fehler 1: Ungeschickte Auswahl von Formularelementen
Das Formular umfasst mehrere Blöcke mit Checkboxen. Man kann alle Checkboxen auswählen, wobei jede Checkbox eine Option darstellt. Außerdem gibt es eine Checkbox für ›alles‹, man kann also alle Optionen des Blocks auswählen.
Falsch: Man darf aus irgendeinem Grund nur drei Checkboxen pro Bereich auswählen, kann aber beliebig viele aktivieren. Hat man die Checkbox ›alles‹ ausgewählt, darf keine der anderen zu diesem Block gehörenden Checkboxen ausgewählt sein.
Mit anderen Worten: ein blinder Nutzer muss mit seinem Screenreader nach dem Ausfüllen und Versenden des Formulars alle Checkboxen des fehlerhaften Blocks noch einmal durchgehen und an- bzw. abwählen, bis er auf maximal drei aktive Checkboxen oder die Checkbox ›alles‹ kommt. Er muss sich außerdem merken, wie viele Checkboxen er schon aktiviert hat, denn sehen kann er das natürlich nicht.
Dazu kommt noch ein Fehler in der Logik des Formulars: man darf entweder eine begrenzte Zahl von Optionen auswählen oder alle Optionen. Es leuchtet nicht ein, warum man sich entscheiden soll zwischen drei Optionen oder ›alles‹.
Checkboxen sollten deshalb nur eingesetzt werden, wenn die Zahl der wählbaren Optionen unbegrenzt ist.
Fehler 2: Mangelnde Ausfüllhilfe
Wenige Formulare sind wirklich selbsterklärend. Es ist daher sinnvoll, den Nutzern Ausfüllhilfen anzubieten. Die Zahl auswählbarer Optionen sollte unmittelbar nach der zugehörigen Frage genannt werden.
Bei dem genannten Formular gab es diese Ausfüllhilfen nicht. Es fehlte eine generelle Anleitung, wie das Formular auszufüllen ist. Erst in den Fehlermeldungen tauchen die Hinweise auf, wie viele Optionen ausgewählt werden dürfen.
Fehler 3: Schlechte Formulararchitektur
Bei umfangreichen Formularen ist eine Aufteilung der Blöcke auf mehrere Seiten sinnvoll. Bei diesem Formular hätte sich das angeboten, weil die Fehlerkorrektur für Blinde schlicht unzumutbar ist. Der Blinde muss jeden einzelnen Block darauf hin prüfen, ob dort eine Fehlermeldung vorhanden ist und im schlimmsten Fall jeden Block einzeln korrigieren. Das ist so mühsam und langwierig, dass es kaum jemand auf sich nehmen wird. Bei der Aufteilung auf mehrere Blöcke würde die Fehlermeldung nach dem Ausfüllen des ersten Blockes auftreten. Es müsste also nur dieser Block korrigiert werden. Außerdem würde ein Lerneffekt eintreten: der Benutzer lernt nach der ersten Fehlermeldung, dass er nur drei Checkboxen pro Block auswählen darf.
Um die Probleme mit diesem Formular zu beheben hätte bereits ein formloser Test mit einigen unbeteiligten Personen ausgereicht. Da dieses Formular ausdrücklich an Menschen mit Behinderung gerichtet war, wäre auch ein Test auf Barrierefreiheit angemessen gewesen. Wir können nur dazu raten, Formulare dieser Art ausgiebig zu testen, um unnötige Abbrüche zu vermeiden. Ein schlecht gestaltetes Formular fällt letztlich auch negativ auf den Anbieter der Webseite zurück.
Digitale Texte stellen andere Herausforderungen an die Redakteure als gedruckte Texte. Die Leser erwarten im Internet, dass passende Informationen oder Quellen verlinkt werden.
Auch Links wollen richtig gesetzt werden. Es ist zwar möglich, am Ende eines digitalen Textes alle erwähnten Inhalte zu verlinken, aber dieses Verfahren stammt noch aus den Zeiten des Papiers. Ellenlange Listen mit Fußnoten oder Literaturlisten mögen auf Papier angemessen sein, im Internet sind sie unübersichtlich, siehe dazu auch unseren Artikel zur Nutzerführung durch Links. Es ist übersichtlicher, Inhalte im Kontext zu verlinken, also den Link dort zu setzen, wo der entsprechende Inhalt erwähnt wurde.
Weiterlesen …
Linktext und Kontext
Worauf ein Link verweist sollte immer aus dem Link- oder Ankertext und dem umgebenden Text – dem Linkkontext – erkennbar sein. Der Linkkontext macht deutlich, wohin der verweisende Link führt, am Ankertext lässt sich erkennen, welche Information dort gefunden wird.
Umgang mit Verlinkungen
Im Internet lassen sich generell vier Umgangsarten mit Links beobachten.
- Viele Webseiten verlinken gar nicht, häufig herrscht die Angst vor, die Nutzer würden die Seite verlassen, wenn Links angeboten werden.
- Viele Webseiten setzen die Links an das Ende des Textes. Die Autoren befürchten oft, der Leser würde den Text nicht zu Ende lesen, wenn ihm zwischendurch ein Link angeboten wird.
- Viele Nachrichtenportale setzen Links in Blöcken zwischen die Texte. Dabei werden praktisch immer nur Inhalte der gleichen Webseite verlinkt.
- Andere Seiten verlinken im Fließtext, das macht zum Beispiel Heise durchgängig in seinen Publikationen, aber auch viele Weblogs.
Eine Mischform ist die Verlinkung verwandter Inhalte oder Quellen im Fließtext und das Angebot weiterführender Links am Ende der Artikel, das machen viele Weblogs wie auch ›Einfach für Alle‹. Die Wikipedia verlinkt im Fließtext nur intern und setzt alle externen Links an das Ende der Artikel.
Generell lässt sich beobachten, dass Webseiten mit einer web- oder technikaffinen Zielgruppe stärker im Fließtext verlinken. Häufig wird argumentiert, Links im Fließtext würden den Leser ablenken oder vor zu viele Optionen stellen.
Die Rolle der Links in der Barrierefreiheit
Für den Nutzer von Screenreadern sind einzelne Links im Text nicht störend. Viele Blinde nutzen die Möglichkeit, sich alle Links einer Seite anzeigen zu lassen. Deshalb ist für sie ein sprechender Link wichtig, »Erfahren Sie mehr« ist deshalb kein guter Ankertext.
Für Sehbehinderte muss deutlich erkennbar sein, dass es sich um einen Link handelt. Links werden häufig nicht mehr standardkonform – unterstrichen und blau -angeboten. Andersfarbiger Text im Fließtext wird in Usability-Tests häufig als störend empfunden, weil er die Aufmerksamkeit ablenkt. Dennoch muss ein Mittelweg gefunden werden, damit deutlich erkennbar ist, dass es sich um einen Link handelt.
Es gibt in CSS fünf Zustände für Links, für die jeweils ein anderes Aussehen definiert werden sollte:
a:link: ein noch nicht besuchter Linka:focus: ein angetabbter Linka:hover: ein Link, der mit dem Mauscursor angesteuert wurdea:visited: ein besuchter Linka:active: ein gerader angeklickter Link
focus ist vor allem für Tastaturnutzer wichtig und wird häufig vergessen. Eine Änderung sollte nicht nur durch Farbe, sondern auch durch Unterstreichung oder Rahmen deutlich werden.
Generell ist es nicht sinnvoll, Links in einem neuen Fenster oder Tab öffnen zu lassen. Die Nutzer wissen selbst, ob sie ein neues Fenster öffnen möchten oder nicht. Für alle Nutzer muss immer deutlich sein, wenn der Link nicht auf eine Webseite, sondern auf ein PDF oder einen multimedialen Inhalt verweist. Überraschungen dieser Art sind nicht besonders beliebt. Wenn es aus irgendeinem Grund nötig ist, Links in neuen Fenstern zu öffnen oder andere Inhalte als Webseiten zu verlinken, kann es sinnvoll sein, dem Link eine Grafik voranzustellen. Alternativtext und Titel können dann angeben, welcher Inhalt sich hinter dem Link verbirgt oder das ein neues Fenster bzw. ein neuer Tab geöffnet wird.
Benutzerfreundlichkeit durch Verlinkung
Aus Usability-Sicht ist die Verlinkung im Text vorzuziehen. Zum einen lässt sich hier eher kontextsensitiv verlinken. Zum anderen ist eine Häufung von Links in Blöcken mitten im Text oder am Fuß des Textes ebenfalls eine kognitive Herausforderung. Nehmen wir an, wir hätten fünf Links auf deren Inhalt im Text verwiesen wird: Wir suchen aber eine bestimmte Information, die uns im Text aufgefallen ist und die wir gerne weiter verfolgen möchten. Im schlimmsten Fall müssen wir alle Links einmal durchklicken, um die gewünschte Information zu finden.
Logisch verlinken
Wo man von technik- oder webaffinen Lesern ausgehen kann, sind Links im Fließtext sinnvoll. Ob das noch übersichtlich ist oder nicht hängt weniger von der Zahl der angebotenen Links ab als von der Schlüssigkeit des Linkkontextes, des Ankertextes und des verlinkten Inhalts. Wenn der verlinkte Inhalt keinen starken Bezug zu der jeweiligen Textstelle hat, kann er ebenso gut an das Ende des Textes gestellt werden.
Eine Linkhäufung am Fuß des Textes ist nicht nur abschreckend, sie zeigt auch, dass der Autor sich keine Gedanken dazu gemacht hat, wie Informationen strukturiert präsentiert werden, Informationen und Verknüpfungen machen immer nur im größeren Zusammenhang einen Sinn.
Eine Ausnahme ist die Druckversion einer Seite. Wenn die Seite ausgedruckt wird, ist es sinnvoll, die Links am Ende des Artikels als normale URL anzubieten, anstatt sie komplett zu unterschlagen. So macht es etwa das Online-Magazin Telepolis.
Textlastige Seiten gelten allgemein als barrierefrei. Doch es gibt einige Möglichkeiten, Texte für Menschen mit unterschiedlichen Behinderungen zugänglicher zu machen. Im folgenden möchten wir uns vor allem mit der technischen Strukturierung von Texten beschäftigen. Verständlichkeit und Textgestaltung (Typographie) sind ebenfalls wichtige Themen, sollen hier aber nicht behandelt werden.
Blinde benötigen Zwischenüberschriften und Absätze, um Textabschnitte wenn nötig überspringen zu können. Außerdem gibt es im Screenreader verschiedene Möglichkeiten, Texte zu überfliegen: Blinde können sich zum Beispiel alle Überschriften oder Links einer Seite anzeigen lassen.
Alle aktuellen Browser bieten die Möglichkeit, eigene Stylesheets anzulegen, um etwa die Lesbarkeit von Texten zu verbessern. Stylesheets erlauben es, die Größe von Text, den Textfluss und andere Faktoren der Lesbarkeit anzupassen. Das kann zum Beispiel Sehbehinderten helfen, aber auch Menschen mit Leseschwäche, die Probleme mit dem Blocksatz oder mit bestimmten Schriftfamilien haben können.
Sie funktionieren am besten, wenn für die Struktur der Seite semantisch korrektes HTML eingesetzt wird. HTML hat einen ganzen Satz von Tags, die ihren Inhalt beschreiben: zum Beispiel h1 bis h6 für Überschriften, ul für nichtnummerierte Listen oder blockquote für Zitate. Diese Tags werden von Screenreadern ausgewertet, um Blinden Informationen über das aktuelle Element weiterzugeben.
Weiterlesen …
Auszeichnungssprachen versus WYSIWYG
Jedes aktuelle Redaktionssystem hat zumindest rudimentäre Möglichkeiten zur Textformatierung. Puristen arbeiten mit einfachem HTML, was einige Vorteile mit sich bringt. Beliebter sind jedoch die What-You-See-is-what-you-get oder kurz WYSIWYG-Editoren. In WordPress ist zum Beispiel der TinyMCE integriert, der an gängige Textverarbeitungen erinnert.
Abb.: TinyMCE in der erweiterten Ansicht
Weniger stark verbreitet sind Mischformen von WYSIWYG und Auszeichnungssprachen. Eine der bekannteren Formen der Textformatierung ist die Wiki-Syntax, wie sie in MediaWiki eingesetzt wird. Wiki- oder Rich-Text-Editoren bieten an, die Formatierung über Schaltflächen vorzunehmen, blenden jedoch die Formatierungsanweisungen im Text ein. Puristen können die Anweisungen direkt über die Tastatur eingeben, visuell orientierte Menschen können die Formatierung über die Schaltflächen vornehmen.
Viele Autoren stören sich daran, wenn die Formatierungsanweisungen im Text sichtbar sind. Es bringt jedoch auch einige Vorteile mit sich:
- Zum einen können so auch Blinde den Text formatieren. TinyMCE ist zwar prinzipiell mit Tastatur bedienbar, die Bedienung ist aber nicht sehr komfortabel.
- Zum anderen hat man mehr Kontrolle über die Formatierung. Bei WordPress kommt es recht häufig zu seltsamen Umbrüchen, Formatierungs- und Darstellungsproblemen, die man mühsam nachbearbeiten muss. Das passiert vor allem, wenn Texte aus der Textverarbeitung in den WYSIWYG-Editor hineinkopiert werden.
Die Redakteure lernen durch die Formatierungsanweisungen, dass die Textstrukturierung im Web anders als in der Textverarbeitung funktioniert. Ein Nachteil besteht darin, dass die verwendete Auszeichnungssprache gelernt werden muss.
Strukturierung statt Aufhübschung
Ein sehr häufiger Fehler bei der Formatierung von Texten ist der Einsatz von nichtsemantischem HTML oder CSS. Man kann zum Beispiel eine Überschrift mit HTML als Überschrift kenntlich machen. Man kann aber auch ein DIV-Element verwenden und das ein wenig fetter und größer gestalten.
Das ist übrigens die Regel, nicht die Ausnahme. Die meisten Tageszeitungen verfahren so. Fast immer ist die eigentliche Artikelüberschrift als Überschrift gekennzeichnet, die Zwischenüberschriften hingegen nicht. Auch TinyMCE bietet in der WordPress-Standardkonfiguration keine Formatierungen für Zwischenüberschriften an. Hinzu kommt, dass Redakteure keinen Einfluss darauf haben, wie ihre Formatierungen im Redaktionssystem verarbeitet werden, schließlich soll das Layout einheitlich sein. Die Verarbeitungsregeln müssen im Redaktionssystem festgelegt werden.
Es kommt auch sehr häufig vor, dass Listen nicht korrekt formatiert werden. Die meisten Leute verfahren wie in der Textverarbeitung, schreiben einen Bindestrich, ihren Text und drücken dann auf Return. Die Textverarbeitung bietet in der Standardeinstellung per AutoFormat eine Auflistung an. Im Web klappt das aber nicht. Eine Einrückung wird dann über Leerzeichen, Tabulator oder ein Zitateelement umgesetzt, was sehr unprofessionell aussieht.
Ein häufiger Fehler, der nur bei WYSIWYG-Editoren auftreten kann ist die falsche Formatierung von Listen. Eine Liste mit drei Listenpunkten wird zu drei Listen mit jeweils einem Listenpunkt. Das geschieht, wenn jeder Punkt einzeln als Liste formatiert wird, anstatt die gesamte Liste einmal zu formatieren. Rein optisch fällt dieser Fehler allerdings in der Regel nicht auf, stört aber den blinden Screenreadernutzer.
Grenzen der Formatierung
Wesentlich mehr Formatierungsoptionen bieten die meisten Redaktionssysteme nicht an. Abkürzungen und Kennzeichnung von Sprachwechseln gehören nicht zum Standardumfang von WYSIWYG-Editoren. Einfache Tabellen lassen sich vielleicht noch einfügen, aber schon bei komplexeren Formatierungen dürfte Schluss sein, weil sie von den Redaktionssystemen nicht unterstützt werden. Ob HTML oder Wiki-Syntax, fast alle Redaktionssysteme filtern aus Sicherheitsgründen Formatierungsanweisungen heraus, die sie nicht kennen. Den Texteditor um solche Funktionen zu ergänzen ist allerdings keine technisch aufwendige Aufgabe.
Mehr Verständnis
Es gibt also kurz zusammengefasst zwei Kernprobleme bei der Strukturierung von Texten:
- Die Programmierer von Redaktionssystemen setzen nur Standardanforderungen um oder arbeiten gar mit Layout statt Struktur, setzen also CSS statt HTML ein. Sie setzen nur die grafischen Anforderungen um, weil sie sich selbst nicht um die Formatierung von Texten kümmern müssen.
- Die Redakteure ihrerseits sind mit den Grundlagen der Strukturierung von Texten im Web nicht vertraut. Entweder kommen sie aus dem Printbereich, wo andere für das Layout zuständig sind. Oder sie sind gelernte Online-Redakteure, in deren Kursen HTML und CSS stiefmütterlich behandelt wird. In der Regel wissen sie auch nicht, was unter semantischem HTML zu verstehen ist und können entsprechend auch ihre Anforderungen an das Redaktionssystem nicht sauber formulieren.
Die Anforderungen an strukturierte Texte müssen also schon im Redaktionssystem umgesetzt werden. Die Redakteure ihrerseits müssen dazu angehalten und geschult werden, Texte korrekt zu strukturieren.
Im ersten Teil sind wir auf die Navigation und die Kategorisierung über Tags und Rubriken als Formen der Nutzerführung eingegangen. Im zweiten Teil wird es um die Nutzerführung über verschiedene Verlinkungsformen gehen.
Hin und zurück – der Brotkrumenpfad
Der Brotkrumenpfad oder der sog. Breadcrumb-Trail gehört bei vielen Seiten zu einer unauffälligen, aber wichtigen Funktion. Er verrät kurz und anschaulich, wo man sich gerade befindet und was die übergeordnete Ebene der aktuellen Seite ist. Damit ist eine wichtige Regel der Usability erfüllt: Die Breadcrumbs verraten jederzeit, wo man ist, was die nächst höhere Ebene ist und wie man auf diese Ebene gelangt. Wenn die Navigation schlüssig aufgebaut ist, lässt der Brotkrumenpfad auch die Zuordnung eines Objekts innerhalb einer Hierarchie zu. Ich befinde mich auf Seite X, X ist ein Unterelement von Y, Y ist ein Unterelement von Z und so weiter. Je tiefer eine Ebene in der Navigation liegt, desto spezifischer wird die Information. Folgerichtig sollte die Information allgemeiner werden, wenn man eine Ebene höher steigt. Ein Brotkrumenpfad wird deshalb um so wichtiger, je mehr Ebenen eine Navigation hat.
Eine ähnliche Funktion kann im übrigen auch der URL erfüllen, wenn er lesbar ist. Bei einem Dateimanager ist das ein wenig augenfälliger: hier können wir anhand des Pfades erkennen, welche Ordner und Unterordner zu einer Datei führen und bekommen ein Gefühl dafür, wie Strukturen in diesem Ordnungssystem aufgebaut sind. Weil die meisten Webseiten heute auf Redaktionssystemen basieren, spielt die klassische Ordnerstruktur im Web keine große Rolle mehr.
Weiterlesen …
Inhaltliche Links
Natürlich gehören auch die Links im Inhaltsbereich zur Benutzerführung – ein Punkt, der häufig vernachlässigt wird. Bei Wikipedia spielen zum Beispiel die Links neben der Suche die eigentliche Hauptrolle. Bei längeren Artikeln folgt nach einem einleitenden Absatz ein Inhaltsverzeichnis, welches einen schnellen Überblick über Inhalt und Aufbau des Artikels liefert und einzelne Abschnitte des Artikels anspringbar macht. Innerhalb der Artikel werden Stichworte verlinkt, zu denen Artikel in der Wikipedia existieren. Außerdem gibt es in Form von Sprungankern die Möglichkeit, zur Quellenangabe der jeweiligen Information zu springen und anschließend wieder zur Ursprungsstelle zurückzukehren. Man kann also durch die Wikipedia navigieren, ohne die Hauptnavigation zu benutzen – die eigentliche Idee hinter dem Konzept »Hypertext«.
Online-Publikationen und Online-Bücher verwenden gerne eine Blätterfunktion. Online-Publikationen wollen vor allem die Klickrate steigern, weil bestimmte Werbeformen nach der Zahl der Seitenaufrufe bezahlt werden (sog. Ad Impressions). Oder sie glauben an die irrige Annahme, dass Nutzer auf längeren Webseiten nicht scrollen.
Bei Büchern hingegen macht es Sinn, die Texte abschnittsweise bereit zu stellen, weil sich die Kapitel als natürliche Abschnitte anbieten. Ein schönes Beispiel dafür sind die kostenlos zugänglichen EDV-Bücher des Galileo-Verlages. Ein ganzes Buch samt Grafiken auf einer Seite darzustellen würde die Ladezeit unnötig verlängern und brächte nur wenige Vorteile.
Am Ende eines Artikels sollte dem Nutzer immer eine Möglichkeit angeboten werden, weiterzuklicken: das kann ein verwandter Artikel sein, ein Verweis auf Quellen oder auf interessante Artikel zum behandelten Thema auf anderen Webseiten. Viele Nutzer werden nicht wieder hoch scrollen, um nachzuschauen, ob es oben noch was Spannendes gibt. Es bietet sich immer an, einen Link zu allgemeineren und einen zu spezifischeren Informationen anzubieten, um unterschiedliche Zielgruppen zu erreichen. Ein gutes Beispiel ist die HTML-Referenz selfHTML, wo etwa im Abschnitt über Verlinkung jeweils Links zu Grundlagenwissen und tiefer gehenden Informationen angeboten werden.
Blinde Nutzer verwenden gerne die Funktion, sich alle Links einer Seite anzeigen zu lassen. Das erlaubt einen sehr schnellen Überblick über den Inhalt des Dokuments. Wenn sie die Webseite gut genug kennen und die Links schlüssig benannt sind können Blinde unwahrscheinlich schnell durch die Webseite navigieren. Das ist übrigens der Grund, warum »weiter« oder »hier klicken« kein guter Ankertext für einen Link ist.
Anzeige der Links von ›Einfach für Alle‹ durch einen Screenreader
Sitemaps und Indizes
Sitemaps und Indizes spielen bisher in der Nutzerführung eine untergeordnete Rolle. Dabei sind Sitemaps eine interessante Alternative zu Navigationen, denn sie zeigen alle Ober- und Unternavigationspunkte, ohne dass man die einzelnen Navigationspunkte aufklappen muss. Wenn die Navigationspunkte auch verständlich benannt sind, kann man das Gesuchte sehr viel schneller finden, als wenn man die klassische Navigation verwenden würde. Wenn Sie eine grafische Sitemap anbieten, sollten Sie auch eine HTML-Version für Blinde und Sehbehinderte bereit stellen.
An der Sitemap sieht man auch, wie schon im ersten Beitrag geschrieben, dass es weniger wichtig ist, wie viele Haupt- und Unternavigationspunkte man unterbringt – entscheidend ist, dass die Links schlüssig dargestellt, gruppiert und benannt sind.
Eine Alternative zur Sitemap wäre ein Index oder Inhaltsverzeichnis. Ein Index basiert meistens auf einer alphabetischen Sortierung wichtiger Begriffe. Jedem Buchstaben sind bestimmte Begriffe zugeordnet, wodurch Nutzer sehr schnell die Gruppierung durchschauen können. Solche Indizes kennen wir aus Sachbüchern, sie können aber auch im Web sinnvoll sein: Viele Leute wissen, dass sie etwas bestimmtes auf einer Webseite finden können, haben aber keine Idee davon, wie es heißt oder es ist ihnen gerade entfallen. Oder sie wissen, dass sich eine bestimmte Information auf der Website befindet, aber nicht wo. In diesem Fall ist es einfacher, über Sitemaps oder Indizes zu gehen als über Suchmaschinen. Indizes bieten sich vor allem für komplexe Webseiten mit vielen unterschiedlichen Themen an. Sie sind allerdings nur dann sinnvoll, wenn sie bei Aktualisierungen und Änderungen auf der Webseite regelmäßig gepflegt werden.
Besser statt mehr verlinken
Die Rolle der Links als Elemente der Nutzerführung wird kaum berücksichtigt. Bereiche, die zueinander in Verbindung stehen oder sich aufeinander beziehen, werden kaum miteinander verbunden. Der Hypertext ist ein hervorragendes Medium, um aufeinander aufbauende Informationen so miteinander zu verknüpfen, dass sie leichter aufgefunden werden können. Viele Webseiten sind aber eher wie Bücher aufgebaut. Wer auf einer speziellen Seite gelandet ist und nach allgemeineren Informationen sucht, darf sich erst einmal selber umschauen. Auf Behördenseiten wird sehr häufig gesagt, welches Formular man ausfüllen muss und wo es zu finden ist – wohlgemerkt anstatt es direkt zu verlinken. Wenn der entsprechende Bereich oder das Formular umbenannt wurde, hat der Nutzer keine Chance, es zu finden. Es geht also nicht darum, beliebig viele Links auf eine Webseite zu stellen. Der Anbieter muss vielmehr überlegen, welche Informationen für den Nutzer hilfreich sind. Der Autor muss also mehr nachdenken, damit der Besucher weniger nachdenken muss.
Die erste Lektion in der Mensch-Maschine-Interaktion dürfte sein, dass die Systeme selten genauso verwendet werden, wie sie gedacht waren. Das gilt vor allem für Software und Webseiten. Die Konzepter geben sich besondere Mühe, den Benutzer auf bestimmten Wegen durch die Webseite zu leiten. Es schadet aber selten, von diesen Wegen abzuweichen – im Gegenteil: unterschiedliche Nutzungsweisen erleichtern die Nutzung des Produkts. Dem Nutzer sollten daher möglichst viele Optionen angeboten werden, denn je näher das Produkt an seinen Nutzungsgewohnheiten liegt, desto eher wird er es auch weiterhin benutzen.
Webseiten werden immer komplexer, multimedialer und vielseitiger. Dennoch bleibt die Navigation das Rückgrat der Webseite. Im folgenden werden wir uns mit einigen Navigationskonzepten und ihren Vor- und Nachteilen beschäftigen.
Weiterlesen …
Die Monohierarchie – klassische Navigation
Die meisten Webseiten basieren heute auf einer einfachen Hierarchie: Ober- und Unterkategorien. Die Kategorisierung ist ein eleganter Weg, um auch sehr große Mengen an Informationen zu organisieren. Man spricht von starker Hierarchie oder Monohierarchie, wenn jedes Objekt nur einer Ebene zugeordnet ist. Dazu ein Zitat aus Henrik Arndts Buch zur Informationsarchitektur:
»Die Strukturierung von Informationen mittels Hierarchien ist sehr effektiv. Jeder einzelnen Sektion sind nur die Eigenschaften zugewiesen, die sie von der ihr übergeordneten Kategorie unterscheidet. Alle anderen Eigenschaften ergeben sich aus der Position innerhalb der Struktur.«
(Henrik Arndt. Integrierte Informationsarchitektur. Springer 2006, Seite 135f.)
Jeder, der schon mal ein Kategorisierungssystem aufgebaut hat, ist sich der Schwäche dieses Systems bewusst. Denken wir an die Bibliothek, wo sich jedesBuch fast immer mehreren Sachgebieten zuordnen lässt und die Entscheidung, wo es schließlich eingeordnet wird, auf banalen Faktoren bis hin zur Größe des Einbands basieren kann.
Bei Webseiten haben wir im Großen und Ganzen das gleiche Problem im verschärftem Maße. Einerseits sollen zu viele Navigationspunkte auf der ersten Ebene vermieden werden, andererseits soll die Navigation nicht zu viele Unternavigationspunkte oder Unterebenen haben. Praktisch ist es kein Problem, eine einzelne Seite mehreren Navigationspunkten zuzuordnen, das widerspricht aber jeder Konzeptionspraxis.
Eine simple Regel besagt, dass die Nutzer mit maximal drei Klicks das finden sollten, was sie gesucht haben, die Regel gilt allerdings als veraltet. Es geht weniger darum, die Zahl der nötigen Klicks zu minimieren als eher darum dem Nutzer klar zu zeigen, dass er auf dem richtigen Weg ist. Zum einen werden die Nutzer das Navigationskonzept nicht auf Anhieb verstehen. Zum anderen werden sie – auch wenn sich der Webmaster das wünscht – nicht jeden Navigationspunkt einmal auf Verdacht aufklappen, um zu sehen, ob das Gesuchte dort ist. Hier gilt die Faustregel: mit jeder weiteren Hierarchie-Ebene verliert man weitere Nutzer. Wer sich hoffnungslos in der dritten Ebene verlaufen hat, macht das, was die meisten erfahrenen Internet-Nutzer von Anfang an getan hätten: Sie rufen eine Suchmaschine auf, geben den Namen der Website und den Suchbegriff ein und werden wahrscheinlich schneller das Gesuchte finden. Der weniger versierte Nutzer wird der Site auf Dauer den Rücken kehren.
Das Problem bei den Hierarchien besteht darin, dass wir nur das sehen, was in der gerade geöffneten Ebene vorhanden ist. Öffnen wir eine Ebene, schließt sich eine andere. Aber kaum ein Mensch wird es auf sich nehmen, sich durch sämtliche Ebenen zu hangeln. Frei nach Murphys Gesetz ist das Gesuchte immer dort, wo man gerade nicht sucht.
Für Blinde ergibt sich das spezielle Problem, dass sie sich linear durch die Website bewegen. Wenn sie eine ihnen unbekannte Website öffnen, müssen sie mit dem Screenreader sämtliche Navigationspunkte durchgehen, um das Gesuchte zu finden. Und das machen sie nicht einmal, sondern sie müssen das bei jedem Neuladen der Seite wiederholen, nur kommen natürlich weitere Ebenen dazu, der Prozess verlängert sich also. Das ist ein generelles Problem für Tastaturnutzer, denn sie können die Navigationspunkte nicht mit dem Mauscursor direkt anspringen, sondern müssen mit der Tastatur durchtabben, was je nach Komplexität der Webseite sehr aufwendig sein kann.
Menschen mit kognitiver Behinderung haben oft Schwierigkeiten, sich in komplexen Strukturen zu orientieren. Verschärfend kommt hinzu, dass die Anbieter möglichst originell sein wollen oder jargonlastig sind und branchentypische Sprachregister bedienen. Auch Nutzer ohne kognitive Behinderung wissen meistens nicht, was der Texter mit Brokerage oder Investor Relations meint. Die Struktur der Seite orientiert sich oft nicht an den Bedürfnissen des Nutzers sondern am Organigramm des Unternehmens oder dem Corporate Wording. Beides ist für komplett Außenstehende – und das sind nun mal die meisten Nutzer eines öffentlichen Angebots – unverständlich und undurchschaubar.
Flache versus tiefe Navigationen
Navigationen sind entweder flach oder tief. Flache Navigationen haben viele Navigationspunkte auf der ersten Ebene, haben dafür aber wenige Ebenen. Tiefe Navigationen wiederum haben eher wenige Navigationspunkte auf der ersten Ebene, haben dafür aber mehr Ebenen. Ob man dem Nutzer eher 6 oder bis zu 9 Navigationspunkte zumuten kann, wird stark diskutiert. Tatsächlich scheint aber die Schlüssigkeit des Navigationskonzeptes entscheidender zu sein als die Zahl der Navigationspunkte. Online-Shops oder -Medien zum Beispiel haben oft deutlich mehr als zehn Navigationspunkte, und allein der Erfolg großer e-Commerce-Anbieter zeigt, dass Nutzer damit in der Regel zurecht kommen.
Grafische Darstellung einiger weniger Seiten im
World Wide Web um en.wikipedia.org (Quelle:
Wikimedia Commons)
Die Polyhierarchie
Die Polyhierarchie oder schwache Hierarchie ist die Zuordnung von Objekten zu mehreren Rubriken. Bekanntestes Beispiel bei Webseiten ist die Kategorisierung in Weblogs. Die Kategorie legt die generelle Einordnung eines Beitrags fest, während die Tags oder Labels eine präzisere Einordnung des Beitrags zulassen. Eine Tagcloud erlaubt durch die unterschiedliche Gewichtung der Worte eine schnelle Orientierung darüber, worüber der Autor hauptsächlich schreibt und gibt nebenbei auch die Möglichkeit, gezielter nach Beiträgen zu einem bestimmten Thema zu suchen, ohne sich den Kopf über den korrekten Suchbegriff zu zerbrechen. Soll man jetzt nach Barrierefreiheit oder Zugänglichkeit suchen, nach Internet oder eher nach Web? Die Verschlagwortung hilft bei der Entscheidung, denn der Autor kann echte und vermeintliche Synonyme für seine Beiträge vergeben. Ein Beitrag kann beliebig vielen Kategorien und Schlagworten zugeordnet werden.
Generell ist das Prinzip schwacher Hierarchien eine gute Lösung für Websites mit vielen Beiträgen zu unterschiedlichen Themen. Leider übertreiben es viele Blogger mit den Kategorien und Tags. Schlagworte werden eher großzügig und unsystematisch vergeben, viele Schlagworte sind so allgemein gehalten, dass sie eigentlich nicht zum Beitrag passen und dem Nutzer auch nicht weiter helfen. Das freie Redaktionssystem Drupal bietet einen systematischeren Ansatz, hier können ganze Vokabularien über ein eingebautes Taxonomie-System angelegt werden.
Auch für Menschen mit Behinderung kann eine Polyhierarchie durchaus Vorteile haben. Eine Schlagwortwolke erlaubt eine flachere Hierarchie als die Navigation. Wenn die Schlagworte präzise gewählt wurden, können die Beiträge zu einem bestimmten Thema wesentlich schneller gefunden werden als in einer verschachtelten Monohierarchie. Die allzu großzügige Vergabe von Kategorien und Schlagworten wiederum ist schwerer zu durchschauen als eine klassische Navigation.
- Man ist sehr viel schneller dabei, eine neue Kategorie anzulegen als einen neuen Punkt in der Hauptnavigation.
- Die Kategorien wachsen eher »wild«, Navigationen sind häufig schlüssiger aufgebaut als Kategorien.
- Wordpress erlaubt auch das Verschachteln von Kategorien, womit das Kategoriensystem die gleichen Probleme aufwirft wie eine klassische Navigation.
Letzten Endes müssen auch bei Polyhierarchien die gleichen Regeln wie beim Aufbau einer Navigation beachtet werden: die Zahl der Elemente spielt erst dann eine Rolle, wenn das gesamte Ordnungssystem unübersichtlich, unverständlich oder ungenau wird. Wer für jeden Beitrag eine neue Kategorie eröffnet und 30 Schlagwörter vergibt, hilft dem Nutzer nicht.
Barrierefreiheit allein reicht heute nicht mehr. Auch die Ansprüche von Menschen mit Behinderung an Webseiten und Anwendungen steigt. Obwohl es einige Berührungspunkte zwischen Barrierefreiheit (Accessibility) und Benutzerfreundlichkeit (Usability) gibt, handelt es sich doch um zwei Arbeitsgebiete mit unterschiedlichen Methoden und Anforderungen. Dennoch lässt sich die Usability speziell für Menschen mit Behinderung verbessern, so dass am Ende auch die Bedienbarkeit – und damit die Barrierefreiheit – verbessert wird. In diesem Artikel wollen wir zeigen, wie die Usability von Webseiten mit Menschen mit Behinderung getestet werden kann.
Man kann zwischen den drei Bereichen Barrierefreiheit, Benutzbarkeit und Benutzerfreundlichkeit unterscheiden. Eine Seite kann im unstrukturierten HTML daher kommen und dennoch für Menschen mit Behinderung benutzbar sein, das ist aber weder barrierefrei noch benutzerfreundlich. Eine andere Seite kann alle Kriterien der Barrierefreiheit erfüllen, aber dennoch so kompliziert in der Bedienung sein, dass kein Nutzer mit Behinderung sie freiwillig besuchen würde.
Die Barrierefreiheit legt den Schwerpunkt auf die Verbesserung der Benutzbarkeit und weniger auf die Benutzerfreundlichkeit. Alle Testverfahren, ob automatisch oder durch menschliche Tester durchgeführt, prüfen in erster Linie nach formalen Kriterien. Wenn diese Kriterien erfüllt sind, kann man den Grad der Barrierefreiheit bewerten. Aspekte der Benutzerfreundlichkeit ließen sich auch in diese Tests aufnehmen, sie spielen aber bisher eine untergeordnete Rolle.
Weiterlesen …
Typische Usability-Probleme
Schauen wir uns zunächst mal einige Usability-Probleme an, die speziell für Menschen mit Behinderung entstehen können.
- Ein Formular kann zum Beispiel neben dem Label auch eine Vorbelegung haben. Es kann dem Screenreader-Nutzer passieren, dass er drei Mal vorgelesen bekommt, was in das Formular einzutragen ist, einmal der Text vor dem Feld, einmal das Label und einmal die Vorbelegung. Das ist keine Barriere, aber vor allem bei längeren Formularen anstrengend.
- Sprunganker sollen wichtige Bereiche der Website leichter erreichbar machen. Mancher Anbieter übertreibt es aber mit der Zahl dieser Sprunganker, so dass die Sprunganker selbst übersprungen werden müssen.
- Ähnlich sieht es aus, wenn wichtige Bereiche der Webseite durch Überschriften leichter ansteuerbar gemacht werden sollen. Mancher meint es zu gut und vergibt so viele Überschriften, dass der Blinde Probleme hat, den eigentlichen Inhalt der Website aufzuspüren, insbesondere wenn die Seite schlecht strukturiert ist.
- Menschen mit motorischer Behinderung verwenden oft besondere Eingabegeräte wie die Augensteuerung. Sie ziehen es vor, möglichst wenige Schritte auf einer Webseite zu machen und möglichst wenig Text einzugeben. Auch mit einiger Übung ist es anstrengend, längere Texte über eine Bildschirmtastatur einzugeben. Diese Nutzergruppe wird durch unnötig lange oder aufwendige Prozesse abgeschreckt.
- Ein sehr häufiges Problem sind aufklappende Navigationsmenüs oder Layer: Sehbehinderte achten oft nicht genau darauf, wo sie den Mauscursor positionieren. Deshalb passiert es recht häufig, dass die Menüs unbeabsichtigt aufgeklappt werden und sich über den Inhalt legen.
Auswahl der Testpersonen
Im Prinzip spricht nichts dagegen, mit Menschen mit Behinderungen Usability-Tests durchzuführen. Testpersonen werden nach unterschiedlichen Kriterien wie den technischen Fähigkeiten ausgewählt. Dazu kommt bei Menschen mit Behinderungen die sehr unterschiedliche Kenntnis der Hilfsmittel und deren Möglichkeiten. Es müssen also zwei Dimensionen von Problembereichen bei der Auswahl von Testpersonen bedacht werden:
- Die Fähigkeiten im Umgang mit Programmen wie dem Browser und
- die Kenntnisse über die eingesetzte Hilfstechnik.
Wir empfehlen Personen mit geringer oder mittlerer technischer Kompetenz für einen Test zu gewinnen. Wenn diese Personen zurecht kommen bzw. ihre Anforderungen umgesetzt werden, dann werden sehr wahrscheinlich auch Menschen mit mehr technischer Erfahrung zurecht kommen.
Die gesamte Spannbreite verschiedener Behinderungen, Hilfstechniken und technischen Fähigkeiten wird man wohl nicht in einer Testgruppe abbilden können. Allein die Zahl der unterschiedlichen Sehbehinderungen lässt sich kaum mit annehmbaren Aufwand abbilden. Sie sollten dennoch versuchen, die unterschiedlichen Behinderungen Sehbehinderung, Lernbehinderung, motorische Behinderung und Hörbehinderung abzubilden.
Im Rahmen eines Usability-Tests sollen typischerweise bestimmte Aufgaben wie der Kauf eines Artikels bewältigt werden. Diese Aufgaben müssen nicht speziell für Menschen mit Behinderung angepasst werden.
Der Testleiter ist gefordert
Allerdings sind vom Testleiter erweiterte Fähigkeiten gefordert. Er muss zum einen natürlich mit den Leuten kommunizieren können, also auch mit Gehörlosen oder Menschen mit Lernbehinderung. Zum anderen muss er aber auch ihre speziellen Arbeitsweisen mit dem Computer kennen, damit er Probleme erkennen kann, ohne nachzufragen oder einzugreifen. Schwierig ist es zum Beispiel einem Sehbehinderten mit starker Vergrößerung bei seiner Arbeit am Computer zu folgen. Vor allem Blinden und Sehbehinderten muss genügend Zeit zur Orientierung auf der Seite gelassen werden. Natürlich kann auch hier die Methode des lauten Denkens angewendet werden, das heißt die Testperson berichtet, was sie gerade tut und was sie damit erreichen möchte.
Methoden des Usability-Tests wie Eyetracking oder Maustracking müssen auf die Nutzungsstrategien von Menschen mit Behinderung angepasst werden. Ein Sehbehinderter verwendet die Maus auch zum Verschieben des sichtbaren Bildschirmausschnitts, so dass seine Mausbewegungen im Vergleich zum Normalsehenden ungewöhnlich aussehen. Er wird auch ein wenig mehr Zeit benötigen, um ein Objekt zu identifizieren als ein Sehender.
Fazit
Praxistests von Barrierefreiheit und Benutzerfreundlichkeit sind noch nicht so verbreitet, wie es wünschenswert wäre. Allerdings sollte die steigende Komplexität von Webseiten nicht mit dazu führen, dass ihre Bedienung immer komplizierter wird. Anspruchsvolle Angebote wie im eGoverment-Bereich werden sich mittelfristig nur durchsetzen können, wenn sie den Nutzern insgesamt ein positives Nutzererlebnis anbieten.
Vor allem bei großen Webprojekten und bei der Entwicklung komplexer Programme werden häufig sogenannte Personas eingesetzt. Personas sind idealtypisch entworfene Personen mit realistischer Biographie, denen bestimmte technische Fähigkeiten und Vorgehensweisen am Computer zugeschrieben werden. Jede Nutzergruppe hat besondere Erwartungen daran, wie eine Website gestaltet sein und wie sie funktionieren sollte und diese Erwartungen sollten sich in den Personas widerspiegeln.
Zusammen mit Personas werden Szenarien eingesetzt. Szenarien definieren typische Aktionen auf der Website: der Kauf eines Produktes auf einer Shopping-Seite, eine Überweisung im Online-Banking und so weiter. Eine Persona bildet zusammen mit einem Szenario die Möglichkeit, spezifische Anforderungen an die Website zu definieren, die schon im Entwurfsprozess berücksichtigt werden können.
Weiterlesen …
Personas mit Behinderung
Auch Personas mit unterschiedlichen Behinderungen lassen sich in die Planung einer Website oder Anwendung einbauen. Dabei ist wichtig, dass Hilfstechnologien und behindertenspezifische Anforderungen bei diesen Personas untergebracht werden. Idealerweise sind folgende Gruppen bei den Personas vertreten:
- Blinde mit Screenreader und Braillezeile
- Sehbehinderte mit Vergrößerungssoftware
- Menschen mit motorischen Einschränkungen – Eye-Tracking oder Sprachsteuerung
- Gehörlose und schwerhörige Menschen
- Menschen mit Lernbehinderungen
Gehörlose und Menschen mit Lernbehinderungen benutzen normalerweise keine Hilfstechnik, dennoch haben sie besondere Anforderungen wie Texte in Leichter Sprache oder Gebärdenvideos. Bei dem Entwurf sehbehinderter Personas sollten zudem Farbfehlsichtigkeiten berücksichtigt werden.
Im Grunde müssen diese Personas nur einmal entworfen werden und das ist die meiste Arbeit. Schließlich müssen neben den Biographien auch die typischen Handlungsweisen auf Websites ermittelt werden, die durch die Behinderung und die Hilfsmittel bestimmt sind. Sind die Personas einmal erstellt, spricht nichts dagegen, sie projektübergreifend einzusetzen und gegebenenfalls anzupassen.
Sind die Personas mit ihren typischen Eigenschaften und Handlungsweisen entworfen, müssen projektbasierte Szenarien entwickelt werden. Eine Online-Banking-Anwendung erfordert andere Vorgehensweisen als eine Shopping-Plattform. Erst in Kombination mit projektspezifischen Szenarien sind Personas wirklich sinnvoll.
Beispiel: Verhaltensmuster im Shopping
Eine typische Shopping-Anwendung bietet unterschiedliche Vorgehensweisen. Viele Leute werden sich erst einmal die Sonderangebote auf der Startseite anschauen. Die nächste Gruppe sucht ein bestimmtes Produkt und benutzt dafür die vorhandenen Kategorien, um sich durch die Produktgruppen zu bewegen. Andere wiederum suchen nach einem bestimmten Produkt direkt über die Shop-Suchmaschine.
Auch beim Bezahlen gibt es ganz unterschiedliche Vorgehensweisen. Blinde werden vielleicht versuchen, sich alle Formularelemente einer Seite anzeigen zu lassen. Sie suchen nach den typischen Eingabefeldern für die Versandadresse oder nach einer Log-In-Möglichkeit. Menschen mit anderen Behinderungen suchen vielleicht eher nach bestimmten Symbolen wie Einkaufskörben oder Registrierkassen, wie sie von Shopping-Sites allgemein bekannt sind. Blinde suchen nach der Maske, wo sie ihre Adresse oder ihre Kontodaten eingeben können, während andere Gruppen vielleicht nach den typischen Kreditkarten-Symbolen Ausschau halten. So kann man den kompletten Prozess von der Auswahl der Waren bis zum Abschluss des Einkaufs für unterschiedliche Zielgruppen und Verhaltensmuster durchdeklinieren und optimieren.
Im Rahmen von Personas können auch Gründe erfasst werden, die zum Abbruch eines Kaufprozesses führen. Die einen bezahlen vielleicht lieber per Abbuchung, die anderen wollen das Geld überweisen und wiederum andere nehmen einen Payment-Dienstleister in Anspruch. Viele werden den Bestellprozess abbrechen, wenn sie die Versandbedingungen, Allgemeinen Geschäftsbedingungen oder Richtlinien zum Datenschutz nicht dort finden, wo sie diese erwarten. Gehörlose werden häufig den Einkauf abbrechen, wenn es neben einer Telefonnummer keine funktionierende Kontaktmöglichkeit per Fax oder E-Mail gibt. Blinde werden ihre Bankverbindung nicht eingeben, wenn sie nicht feststellen können, ob die Daten sicher übertragen werden.
Daneben können auch rein technische Gründe zum Abbruch des Einkaufs führen. Dazu gehören etwa die schlechte Platzierung oder Benennung von Bedienelementen oder eine mangelhafte Tastaturbedienbarkeit.
Vorteile von Personas
Ein Vorteil von Personas besteht darin, dass viele typische Probleme durch sie anschaulicher werden. Es macht emotional einen Unterschied, ob man sagt, Hans kann nicht mit CAPTCHAs umgehen, weil er blind ist als wenn man sagt, Blinde können nicht mit CAPTCHAs umgehen. Das Problem wird sehr viel greifbarer, weil man einen Namen und einen Menschen mit nachvollziehbaren Problemen vor sich hat statt einer anonymen Gruppe. Wenn über den Entwurf einer Website diskutiert wird, können die Entwickler einfach die Frage stellen: »Würde Hans damit zurecht kommen?«. Ein Problem wird wesentlich anschaulicher, wenn man es an einer konkreten Person mit einem Namen und einer Biographie festmachen kann. Es ist leichter, sich in die Rolle einer Person zu versetzen als in die Rolle einer Gruppe.
Ein weiterer Vorteil besteht darin, dass die Anforderungen der Nutzer schon sehr früh im Entwurfsprozess erfasst und berücksichtigt werden können. Eine Anwendung nachträglich barrierefrei zu machen ist sehr viel teurer und aufwendiger, als die Anforderungen von vorneherein umzusetzen.
Vorteil gegenüber Nutzertests
Personas werden vor allem bei der Definition von Anforderungen und im Entwurfsprozess verwendet. Viele Probleme, die ansonsten erst bei Nutzertests herauskommen würden, dürften so schon im Entwurfsprozess gelöst werden. Personas sind aber kein Ersatz für Tests mit echten Nutzern.
Eintippen, Knopf drücken, fertig: Diskussionen in Foren und Kommentare in Blogs, soziale Interaktion in Communities, das Hochladen eigener Inhalte in Videoportalen, Jobangebote und -gesuche in Stellenbörsen, Fahrplanauskünfte und Tickets bei der Bahn oder Bestellungen und Bezahlung in Online-Shops, ja sogar das Einstellen von Inhalten in Redaktionssystemen und Weblogs – all das funktioniert nur mit Formularen. In Zeiten des Mitmach-Webs werden Formulare immer wichtiger. Formulare sind die technische Basis interaktiver Angebote und die Grundlage der Kommunikation zwischen Anbietern und Nutzern einer Webseite.
Weiterlesen …
Gerade bei Formularen gelten die POUR-Prinzipien der WCAG 2.0 in Reinform: Formulare müssen wahrnehmbar (im Englischen: perceivable), bedienbar (engl. operable), verständlich (understandable) und robust (robust) sein. In den Richtlinien finden sich nur wenige direkte Vorgaben zu Formularen, aber fast alle Punkte der WCAG sind anwendbar – von HTML über CSS und WAI-ARIA bis zu JavaScript und der serverseitigen Verarbeitung der eingegebenen Daten. Obwohl HTML seit Jahren viele Elemente für barrierefreie und damit bedienerfreundliche Formulare enthält, setzen Webdesigner sie zu wenig ein.
Die technischen Grundfunktionen eines Formulars – erfassen, ausfüllen und abschicken – müssen mit allen möglichen Mitteln der Ein- und Ausgabe gelingen. Konkret heisst das, Anbieter von Webseiten müssen assistierende Techniken wie z.B. Screenreader, Sprachsteuerung oder Spezialtastaturen berücksichtigen. Für öffentliche Anbieter, die den Vorgaben der Barrierefreie Informationstechnik-Verordnung (BITV) unterliegen, ist der Einsatz dieser Mittel klar geregelt: die Verordnung verlangt die Verwendung der korrekten HTML-Elemente und den Einsatz von CSS für die Gestaltung, das gilt auch für Formulare. Alle anderen Anbieter profitieren ebenfalls von einer einfachen und barrierefreien Nutzbarkeit ihrer Formulare.
Die Konzeption der Formulare oder der Anwendung steht vor der technischen Umsetzung. Der Webentwickler Timo Wirth hat die Perspektive der Nutzer in einer Präsentation einmal so formuliert: »Ein Formular ist kein Datenbankprozess, es ist der Anfang eines Gesprächs«
. Damit ein gelungener Dialog entsteht, gibt diese Serie Hinweise zur barrierefreien Umsetzung von Formularen.
Die Serie ist in fünf Teile gegliedert:
Im ersten Teil »Toleranz und Rücksicht« geht es um Grundlagen und Konzeption von Formularen. Der zweite Teil – »Formulardesign: der wichtige erste Eindruck« – dreht sich um die Gestaltung, Nutzerführung und Usability. Das technische Grundgerüst und damit die Markup-Grundlage von Formularen und das Layout per CSS ist Inhalt des dritten Teils »HTML & CSS für Formulare«.
Neben den für die Struktur benötigten HTML-Elementen und CSS für die Gestaltung kommt in vielen Formularen JavaScript für das Verhalten zum Einsatz. In Teil 4 geht es um »Dynamik in Formularen – JavaScript & AJAX«.
Im letzten Teil zeigen wir, wie Sie eine erste Qualitätssicherung vornehmen können und geben Tipps für Tests mit echten Nutzern: »Testen von Formularen und web-basierten Anwendungen«.
Barrierefreiheit geht insbesondere in Formular-Anwendungen weit über technische und gestalterische Details hinaus und schließt im Grunde genommen den gesamten Prozess bis zum erfolgreichen Abschluss einer Transaktion mit ein – ein Umstand der in den letzten Jahren auch verstärkt im Prüfverfahren des BIENE-Wettbewerbs berücksichtigt wurde. Wie Sie Ihre Nutzer bei der Bewältigung möglicher Hürden unterstützen steht in den folgenden WCAG-Techniken:
Weiterlesen …
Allgemeine Techniken
Ihr Formulardesign kann noch so ausgefeilt und gut getestet sein – Nutzer machen trotzdem Fehler. Die Frage ist nur wie Sie als Anbieter mit diesen Fehlern umgehen: unterstützen Sie den Nutzer bei der Korrektur oder lassen Sie ihn im Dunklen? Was es bei Fehlermeldungen zu beachten gibt wird in den folgenden WCAG-Techniken erklärt:
Weiterlesen …
Allgemeine Techniken
Client-seitige Scripting-Techniken
Neben dem technischen Aufbau gehören auch konzeptionelle und gestalterische Aspekte zur Umsetzung einer barrierefreien Formular-Anwendung. Welche das sind zeigen die folgenden WCAG-Techniken:
Weiterlesen …
Allgemeine Techniken
HTML-Techniken
Typische Fehler
ARIA-Techniken
Falls Sie bereits den kommenden WAI-ARIA-Standard einsetzen sollten Sie neben den passenden Techniken auch die WAI-ARIA Technik-Anmerkungen zu Rate ziehen.
Die neu erschienene Broschüre »Barrierefreiheit - Universelles Design« erläutert, wie Usability Professionals die Barrierefreiheit in ihren Designs berücksichtigen können, indem sie den Gestaltungsprinzipien des Universellen Designs folgen.
Barrierefreiheit – Universelles Design
Die Broschüre zeigt unter dem Motto ›Gut für Alle‹, dass sich Barrierefreiheit lohnt. Außerdem enthalten sind zahlreiche Beispiele und praktische Tipps ebenso wie eine Zusammenfassung der aktuellen Richtlinien und weiterführende Literatur.
Sie wurde von Mitgliedern und Experten des Arbeitskreises Barrierefreiheit der Usability Professionals' Association (UPA) erstellt. Der Verband ist ein Netzwerk von und für Usability-Experten, die sich der Wissensvermittlung und Meinungsbildung rund um das Thema Usability und User Experience verpflichtet fühlen.
Die Mitglieder des Arbeitskreis Barrierefreiheit vertreten innerhalb der UPA die Schnittstelle zwischen Usability und Barrierefreiheit. Neben der Öffentlichkeitsarbeit findet ein reger Wissens- und Erfahrungsaustausch statt. Neue Mitglieder sind jederzeit willkommen; nähere Informationen finden Sie auf der Webseite der German UPA.
[Update 28.10.10: Die Broschüre »Barrierefreiheit - Universelles Design« ist nun auch als barrierefreies PDF (684 kB) erhältlich.]
Die Qualität einer Website entscheidet über den Erfolg im Internet – auch beim E-Government. Zugänglichkeit für Menschen mit Behinderungen und Benutzerfreundlichkeit sind wichtige Kriterien für die Besucher von Webauftritten der öffentlichen Hand. Die zentralen Kriterien für die Bewertung einer Website sind dabei die Benutzerfreundlichkeit, die Barrierefreiheit, die Suchmaschinentauglichkeit und die technische Qualität. Die Qualidator-Studie der schweizerischen seven49.net brachte folgendes Ergebnis an den Tag: 1. Platz für Österreich mit 81.57 %, 2. Platz für Deutschland mit 79.03 % und 3. Platz für die Schweiz mit 77.87 % Gesamtqualität der E-Government-Angebote.
Städte im direkten Vergleich
Bei den österreichischen Städten liegt Bludenz vor Wien und Linz auf den Top-Plätzen. Die Stadt Bludenz hat ein Gesamtscore von 92,76 %, aufgegliedert in die Bereiche Barrierefreiheit (95,29 %), Benutzerfreundlichkeit (94,81 %) und der Suchmaschinentauglichkeit (87,95 %) und führt damit vor Wien mit 87,25 % und dem 2008 mit einer silbernen BIENE ausgezeichneten Linz mit 83,84 %. Fügt man sämtliche Städte der drei Länder Österreich, Schweiz und Deutschland in einem Ranking zusammen, so führt die Webseite von Bludenz (92,76 %) vor den Web-Auftritten der deutschen Städte Bonn (88,98 %) und Bochum (88,92 %).
Weiterlesen …
Websites auf Bundesländerebene im Vergleich
Vergleicht man alle Web-Auftritte der schweizerischen Kantone und deutschen sowie österreichischen Bundesländer, ergibt sich ein Ranking, das vom Kanton Graubünden mit 90,79 % angeführt wird, vor den Bundesländern Wien mit 87,25 %, Sachsen mit 86,9 % und Nordrhein-Westfalen mit 86,87 %.
Bei den Web-Auftritten der österreichischen Bundesländer liegt die Stadt Wien mit einer Gesamtbewertung von 87,25 % vor dem Burgenland mit 86,28 % und der Steiermark mit 85,5 % in Führung. Die Bewertung von Wien mit 87,25 % setzt sich aus den Bereichen Barrierefreiheit (87,34 %), Benutzerfreundlichkeit (85,97 %) und der Suchmaschinen (85,58 %) zusammen.
»Qualität und Service sind oberste Priorität beim Internet-Auftritt der Stadt Wien. Dabei spielen die Barrierefreiheit und Benutzerfreundlichkeit eine maßgebende Rolle. Die Platzierung von wien.gv.at beim Länder- und Städtevergleich ist ein zusätzlicher Ansporn, den Bedürfnissen der User noch mehr gerecht zu werden. Ein wichtiges Ziel dabei ist es, den Bürgern und Wirtschaftstreibenden nicht nur Informationen zur Verfügung zu stellen, sondern auch den Amtsweg zu erleichtern oder gar zu ersparen.«
, so der Wiener Obersenatsrat Johannes Mittheisz, verantwortlich für die IKT-Strategie im Magistrat der Stadt.
Folgende Anfrage einer Doktorandin an der Technischen Universität Dresden hat uns erreicht, die wir hiermit gerne weiterreichen. Die Arbeit beschäftigt sich mit dem Thema Usability-Methoden für Nutzer mit Behinderungen, speziell blinden Nutzern. Ziel der Dissertation ist, neue Methoden für Evaluationen mit blinden Nutzern zu entwickeln:
Liebe Accessibility- und Usability-Experten,
mein Name ist Mei Miao. Ich bin Doktorandin an der TU Dresden. In meiner Arbeit geht es um das Thema Usability-Methoden für Nutzer mit Behinderungen, speziell für blinde Nutzer. Da ich keine ausreichende praktische Erfahrung habe, möchte ich Sie um Ihre Unterstützung bitten.
Mit dieser Umfrage möchte ich erfahren, welche Usability-Methoden in der Praxis für Nutzer mit Behinderungen, speziell blinde Nutzer, häufig verwendet werden und welche Erfahrungen Sie damit gemacht haben. Es wäre für mich sehr hilfreich, wenn Sie sich die Zeit nehmen könnten, den Fragebogen, den Sie unter http://141.76.84.200:8080/Fragebogen/ finden, auszufüllen.
Für Fragen stehe ich Ihnen unter mm33@inf.tu-dresden.de gern zur Verfügung.
Ich bedanke mich für Ihre Mühe im Voraus!
Mei Miao
Heute nochmal so ganz pauschal zu unserem Kernthema Accessibility:
Grundlegende konzeptionelle & gestalterische Erwägungen, um dies hier zu verhindern:
Heute mal was mit Usability und wie man auf dem Nutzer auf die Spur kommt:
Den Bad Usability Calendar hatten wir in den Vorjahren schon öfters verlinkt, jetzt gibt es die neueste Version für das aktuelle Jahr in verschiedenen Größen und Sprachen: Bad usability calendar – wie immer zum Brüllen.
Auch neu: der EfA-Kalender 2008
Ausser der Jahreszahl hat sich eigentlich nicht viel geändert beim ›Einfach für Alle‹-Wandkalender für das Jahr 2008:
EfA-Kalender2008.pdf (4,8 MB, DIN A3, CMYK).
Wir wünschen viel Spaß damit. Für eventuell auftretende Fehlfunktionen des Kalenders übernehmen wir keinerlei Haftung und auch keinen Support. Weitere Goodies zum Mitnehmen bei Downloads.
