Das Testen von Webprojekten und mobilen Apps ist eine neue Herausforderung im täglichen Arbeitsalltag eines jeden Entwicklers. Die große Vielfalt der Geräte und Betriebssysteme, die in den letzten Jahren erschienen sind, macht dies noch schwieriger. Weil man kein Vermögen für zahlreiche unterschiedliche Testgeräte ausgeben möchte, eröffnen seit einiger Zeit immer mehr »Open Device Labs« ihre Pforten.
Sven Wolfermann erläutert, was das bedeutet und welche Vorteile dies vor allem auch für diejenigen bringt, die sich mit App- und Webentwicklung beschäftigen.
Hinter der Idee für das erste »Open Device Lab« steht der Gedanke eines »offenen Testlabors« für mobile Geräte. Sie entstand vor ca. einem Jahr in den Agenturräumen von Clearleft in Brighton (UK). Jeremy Keith, der Gründer von Clearleft, wollte die Geräte, die sich in seiner Agentur befanden, nicht nur für die eigene Mitarbeiterschaft, sondern auch für andere Entwickler zum Testen von Webanwendungen und Apps offen zugänglich machen. Was Jeremy Keith anfangs nicht gedacht hätte war, wie viele Entwickler dieser Idee folgten und ihm aus eigenen älteren Beständen Geräte spendeten, so dass die Geräteanzahl schnell wuchs und eine Bandbreite an unterschiedlichsten Herstellermarken und Versionen zur Verfügung stand.
Warum ist das Testen auf echten Geräten überhaupt notwendig?
Für jedes mobile Betriebssystem gibt es sogenannte Emulatoren, um die Entwicklung und Programmierung einer Anwendung zu testen. Um die responsive Website oder mobile Webapp im Desktop-Browser zu testen, gibt es für die Webentwicklung mittlerweile sehr gute Entwicklertools. Allerdings lassen sich Eigenschaften wie Multi-Touch-Gesten, hohe Pixeldichten (Retina-Displays von Apple), oder Prozessorleistung nicht simulieren und müssen zwingend auf echten Geräten getestet werden, um Fehler erkennen zu können. Viele Besonderheiten von Browser/Betriebssystemkombinationen, gerade auf Android-Betriebssystemen, lassen sich ebenfalls nicht zweifelsfrei simulieren und müssen unter realen Bedingungen ausprobiert werden. Dabei sollten speziell auch Größen von Buttons oder Links überprüfen, da die Bedienbarkeit und Performance auf mobilen Geräten eine große Rolle spielt. Außerdem können die Apps oder Websites dann auch mit den Eingabehilfen für Menschen mit Behinderung getestet werden. Dazu gehören etwa die Sprachausgabe, Sprachsteuerung oder Bildschirmvergrößerung.
Weiterhin sollte man unbedingt die Lesbarkeit der Texte überprüfen. Das iPad mini beispielsweise stellt die gleiche Anzahl an Pixeln viel kleiner dar als sein großer 10-Zoll-Bruder. Leider ist es auch durch die Abfrage der Geräteparameter nicht möglich, das iPad mini zu identifizieren, so dass man auch für diese »klein gezoomte« Ansicht eine gute Lesbarkeit vorhalten sollte. Dies kann man nicht am Desktop-Browser simulieren.
Speziell bei der Vielzahl der Smartphones gibt es teilweise große Unterschiede. Hier reicht die Pixeldichte mittlerweile von 0.75 bis 3.0 (Full HD). Gerade bei der Verwendung von Medien (Bilder, Videos) stellt das ein Problem dar, und eine akzeptable Lösung für das Projekt und die Zielgruppe muss gefunden werden.
Am Ende kommt man aber an Tests auf den einzelnen Geräten nicht vorbei, die meisten Emulatoren sind für diesen Zweck nicht ausreichend.
Der Mehrwert eines »Open Device Labs« liegt insofern auf der Hand. In einer Zeit steigender Verbreitung mobiler Endgeräte und wachsender Zugriffe über Smartphones und Tablets ist es enorm wichtig, seine Projekte auf unterschiedlichen Geräten sorgfältig zu testen. Dass der Bedarf da ist, zeigt die Nachfrage nach solchen Angeboten. Der Idee des »Open Device Labs« folgen seither schon über 50 andere Labs weltweit.
Wo finde ich Open Device Labs?
Ob es in der Nähe schon ein Open Device Lab gibt, kann man auf der Webseite opendevicelab.com überprüfen. Deutsche Open Device Labs gibt es mittlerweile in Berlin, Frankfurt, München, Hamburg, Düsseldorf, Köln, Dortmund und Nürnberg.
Ist die eigene Stadt noch nicht vertreten und möchte man ein eigenes ODL anbieten, sollte man sich zuerst Gedanken über den Standort machen. Er sollte für alle frei zugänglich sein, möglichst an einem zentralen Ort liegen und genug Platz für die Testgeräte bereithalten. Ein unbenutzter Büroraum oder eine Bürogemeinschaften sind dafür ideal. Durch eine Initiative von Andre Jay Meissner und Bruce Bowman gibt es zudem eine Anlaufstelle für begeisterte Firmen, um ein eigenes ODL zu starten. Auf der Webseite lab-up.org kann man sich informieren, welche Schritte notwendig und sinnvoll sind, um ein Open Device Lab anzubieten. Zudem kann Lab-Up auch Kontakte zu Herstellern knüpfen, die manchmal auch Geräte sponsern.
Da es für einige Firmen aus vielen Gründen nicht möglich ist, Ihre Projekte außer Haus zu testen, gibt es jetzt auch ein mobiles ODL, bei dem man einen Gerätepark mieten kann. Informationen dazu findet man unter odl.maddesigns.de.
Für das Prüfen von barrierefreien Webseiten gibt es eine ganze Reihe ausgefeilter Testverfahren. Sie werden in der Regel von Experten durchgeführt. Im folgenden wollen wir zeigen, wie Sie selbst einige einfache Tests zur Barrierefreiheit Ihrer Webseiten durchführen können. Für diese Tests benötigen Sie lediglich einen Browser und ein wenig Geduld.
Weiterlesen …
Tastaturbedienbarkeit
Eine der wichtigsten Säulen der Barrierefreiheit ist die Tastaturbedienbarkeit. Zunächst legen wir also die Maus bei Seite und arbeiten nur mit der Tastatur.
Basis der Tastaturbedienung ist die Tabulator-Taste. mit dieser Taste kann man von Element zu Element springen. Im ersten Schritt versuchen wir also, alle anklickbaren oder ausfüllbaren Elemente, also Links und Formular-Elemente der Website anzuspringen. Bei jedem anklickbaren Element sollte eine Änderung des fokussierten Elements eintreten. In der Regel ist das ein Rahmen, es kann aber auch eine farbliche Änderung oder eine Unterstreichung bei Links sein. Eine rein farbliche Änderung kann für farbfehlsichtige oder sehbehinderte Menschen problematisch sein. Entweder nehmen sie die Änderung nicht wahr oder sie können einen Link etwa wegen einer schlechten Farbauswahl oder zu geringen Kontrasten nicht mehr lesen.
Grundsätzlich ist es sinnvoll, eine Information über zwei Wege zu vermitteln: also etwa über eine Unterstreichung und eine Farbänderung oder eine Farbänderung und einen Rahmen.
Bei ›Einfach für Alle‹ wird der angetabbte Link unterstrichen und und umrandet sowie die Hintergrundfarbe angepasst
Mit der Return- oder Leertaste sollten wir Links, Buttons und alles andere Klickbare versuchen zu aktivieren. Wenn es keine deutlich sichtbare Änderung im angetabbten Zustand gibt oder beim Auslösen nichts passiert, haben wir schon ein Barrierefreiheits-Problem aufgespürt.
Außerdem sollte der Tabulator nicht an irgendeiner Stelle der Seite hängen bleiben – das kann besonders bei Flashanimationen oder Werbebannern passieren.
Wir greifen nun – ausnahmsweise – zur Maus und prüfen, ob wir bei klickbaren Elementen wie Links eine deutliche Hervorhebung sehen können, wenn wir diese mit der Maus ansteuern. Das dient vor allem Sehbehinderten oder Menschen mit motorischen Einschränkungen. Sie setzen eventuell die Maus ein, sind dabei aber wesentlich unsicherer als Sehende. Sie müssen deutlich erkennen können, dass sie ein Element mit dem Mauscursor fokussiert haben, dass dieses Element also anklickbar ist und brauchen eine hinreichend große Klickfläche. Üblich ist eine farbliche Veränderung bei Links oder Formularelementen, ein Rahmen oder Ähnliches. Der Mausfokus kann sich vom Tastaturfokus unterscheiden, das ist aber kein Muss.
Besonderes Augenmerk sollten wir außerdem noch auf Elemente legen, die dynamisch eingeblendet werden, also ohne dass die Seite neu geladen wird. Das sind zum Beispiel Menüs die bei Mausberührung aufklappen. Wenn wir – wieder mit der Tastatur – auf den entsprechenden Link kommen, sollte das Menü nach einem Druck auf Return aufklappen und aufgeklappt bleiben. Wir können nun alle Links in diesem aufgeklappten Menüpunkt durchgehen und sollten auch einen davon ausprobieren. Natürlich sollte auch in diesen Menüs deutlich sein, welches Element gerade den Fokus hat.
Die gleichen Elemente sollten auch mit der Maus getestet werden. Wie oben erwähnt agieren viele Menschen unsicher mit der Maus. Für sie wird es sehr schwierig, wenn sie dynamische Elemente fokussieren müssen. Das aufklappende Menü sollte nicht unmittelbar zuklappen, wenn der Mauscursor das Element kurz verlässt.
Formulare
In nächsten Schritt sollten wir noch einen speziellen Blick auf Formulare werfen. Zunächst einmal tabben wir einmal quer durch das Formular. Die Tabreihenfolge sollte logisch sein, dass heißt, so wie die Elemente optisch auf der Website angeordnet sind, so sollten sie auch angetabbt werden. Hier kann das Verhalten unerwartet sein: zum Beispiel springt der Cursor von der Auswahl der Ansprache zur Eingabe des Straßennamens und übergeht die Eingabe des Personennamens. Wenn man die Stadt eingegeben hat, springt der Cursor auf einmal zum Vornamen. Das ist nicht nur verwirrend, sondern nervig, weil wir an ein bestimmtes Ausfüll-Schema so gewöhnt sind, dass wir ein solches Verhalten als störend empfinden.
Wenn Sie in Ihrem Formular eine Funktion zum Löschen der Eingaben anbieten, sollte diese Funktion deutlich vom Absende-Button unterscheidbar sein und in der Tabreihenfolge hinter dem Absendebutton liegen. Formulare werden häufig halbautomatisch ausgefüllt– die Gefahr ist dann relativ groß, dass unaufmerksame Nutzer ihre eingegebenen Daten unabsichtlich löschen.
Nach der korrekten Tabreihenfolge prüfen wir, ob wir alle Auswahlboxen aktivieren oder deaktivieren können. Das machen wir mit der Leertaste, nicht mit Return! Jedes auswählbare Element sollte nur mit der Tastatur (Pfeiltasten) ausgewählt werden können. Bei Auswahllisten, die man aufklappen kann, sollte man mit der Cursor-auf und Cursor-ab-Taste die gewünschte Option auswählen können. Wenn man sich auf der Auswahlliste befindet, kann man sie mit der Alt und der Cursor-Runter-Taste aufklappen, um eine Übersicht über die auswählbaren Optionen zu erhalten.
Unter keinen Umständen sollte bei jeder Cursor-Bewegung in der Auswahlliste die Seite oder der Seiteninhalt neu geladen werden. Dynamische Änderungen in Formularen sind vor allem mit älterer Hilfstechnik generell sehr problematisch. Zudem wird es für Blinde schwierig, sich einen Überblick über Auswahlmöglichkeiten zu verschaffen und eine Auswahl zu treffen, wenn jede Tastaturbewegung eine ungewünschte Aktion auslöst.
Im letzten Formular-Testschritt geben wir passende Daten in die Maske ein und schauen, ob wir diese Daten mit der Tastatur abschicken können. Es gibt wohl nichts Ärgerlicheres als ein ausgefülltes Formular, welches sich nicht abschicken lässt. Man sollte dem Empfänger mitteilen, dass es sich nur um einen Test handelt. Das Abschicken erledigen wir mit Return, sobald wir den zuständigen Button erreicht haben.
Verzichten Sie in jedem Fall auf rein visuelle CAPTCHAs. Wenn Sie Audio-CAPTCHAs anbieten, sollten Sie testen, ob Sie selber in der Lage sind, die Audio-Aufgaben zu lösen. Auch die CAPTCHAs sollten im übrigen komplett über die Tastatur bearbeitet werden können.
Vergrößerbarkeit
Alle gängigen Browser erlauben es, Inhalte von Webseiten zu vergrößern. Eine Ausnahme ist der IE 6, der relative Größenangaben für Texte im CSS benötigt. Über die Tastatur erfolgt die Vergrößerung über STRG/Cmd und + bzw. STRG/Cmd und Mausrad. Die Inhalte der Seite sollten sich dabei gleichmäßig vergrößern. Das heißt, alle Inhalte verschieben sich nach rechts unten. Die Inhalte sollten sich nicht schon bei geringer Vergrößerung ineinander schieben oder gegenseitig überlagern.
Strukturierung
Vor allem für blinde Nutzer ist es wichtig, dass die Seiten korrekt strukturiert sind. Der einfachste Weg zur Prüfung der Struktur: Wählen Sie im Firefox unter Ansicht → Webseiten-Stil → Kein Stil. Hier sehen Sie das Skelett der Website und stellen auch fest, ob der logische Aufbau der Website durch Überschriften mit und ohne Design übereinstimmt. Ähnliche Funktionen finden Sie auch in anderen Browsern. Um das Design wiederherzustellen, wählen Sie im Firefox unter Ansicht → Webseiten-Stil → Standardstil.
Es kann auch nützlich sein, den Quellcode einer Webseite zu betrachten, um potentielle Probleme aufzuspüren. Einige einfache Probleme lassen sich auch ohne Kenntnis von HTML, CSS und JavaScript erkennen.
Zum Betrachten des Quellcodes rufen Sie mit der rechten Maustaste das Kontextmenü auf und wählen dort Quelltext ansehen. Die meisten Browser arbeiten mit Syntaxhighlighting, das heißt, der Code wird farblich hervorgehoben. Wir können alles ignorieren, was zwischen spitzen Klammern < und > steht und schauen uns nur den Text an.
Hier können Sie prüfen, ob überhaupt Inhalte im Quelltext zu sehen sind. Häufig sieht man einen sehr kurzen Quelltext, wo im Codebereich so etwas wie frame steht. Oder es wird nur sehr viel Programmcode angezeigt, aber kein menschenlesbarer Text. Im ersten Fall wurde die Website mit Frames gestaltet und ist damit vor allem für ältere Hilfstechnik von Blinden problematisch. Im letzteren Fall wird die Seite vermutlich komplett über JavaScript direkt im Browser erzeugt. Auch damit kommt ältere Hilfssoftware eher schlecht zurecht.
Fazit
Diese einfachen Tests können schwere Probleme in der Zugänglichkeit Ihrer Webseite aufzeigen. Sie sind allerdings kein Ersatz für eine Evaluation durch Experten oder für Praxistests durch Betroffene.
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.
Den Grad der Barrierefreiheit eines Angebots zu messen und auf dieser Basis Verbesserungen zu entwickeln ist keine einfache Aufgabe. Mit den WCAG 2.0 haben wir zwar messbare Kriterien mit insgesamt 4 Ebenen der Konformität (A, AA, AAA und garnix), aber diese Ebenen sind zu stark voneinander abgegrenzt, um kleinteiligere Vergleiche und Messungen vorzunehmen oder um Fortschritte in der Verbesserung der Zugänglichkeit eines Angebots festzustellen. Wenn eine Website sämtliche Kriterien der Ebene A erfüllt und darüber hinaus viele, aber nicht alle AA- und AAA-Kriterien, dann ist sie trotzdem nur konform zu Ebene A. Die zusätzlichen Kriterien würden zwar den Nutzern zu Gute kommen, würden aber nicht in eine abschließende Bewertung der Barrierefreiheit einfließen.
Die in einigen Testverfahren benutzte Vergabe von Punkten oder Prozenten erlaubt die Bewertung auf einer Skala und damit auch vergleichende Statistiken. Allerdings bleibt die Frage, wie aussagekräftig verlässlich und letzendlich nachvollziehbar und überprüfbar solche Statistiken sind. Ein Beispiel: wenn auf einer HTML-Seite zwei von zehn Bildern fehlerhaften Alternativtext aufweisen – ist diese Seite zugänglicher als eine Seite, bei der eins von fünf Bildern oder vier von 20 Bildern fehlerhaft gecodet sind?
Eine solche Berechnung ist zwar recht einfach anzustellen, aber ohne weitere Informationen zum Kontext, in dem die Fehler auftreten, lassen sich keine verlässlichen und nachprüfbaren Aussagen zur tatsächlichen Barrierefreiheit für die Nutzer machen. Die Bewertung des Kontextes wiederum erhöht die Komplexität der Tests, weil der Test dann nicht mehr rein maschinell durchführbar ist, sondern ein menschlicher Tester die Bewertung vornehmen muss. Das wiederum eröffnet andere Probleme durch unterschiedliche Interpretationen.
Weiterlesen …
Online-Symposium zu Meßverfahren
Die Research and Development Working Group (RDWG) der Web Accessibility Initiative des W3C plant ein Online-Symposium, wo genau diese Fragen erörtert werden. Ziel ist, Anwender der Richtlinien aus Forschung und Praxis zusammenzubringen um gemeinsam den Stand der Meßverfahren zu betrachten und Pläne für die Zukunft zu entwickeln, wohin sich die Forschung in diesem Bereich entwickeln soll. Das Symposium wird am 5. Dezember 2011 in Form einer Telekonferenz stattfinden.
Die Research and Development Working Group sucht Beiträge und praktische Erfahrungen zur Messung der Barrierefreiheit, die über die einfache Konformität zu den Standards wie WCAG 2.0, Section 508 oder BITV hinausgehen. Die Frist zur Einreichungen von Beiträgen endet am 1. November 2011, die Ergebnisse werden im Nachgang veröffentlicht. Besonders gefragt sind Beiträge die sich mit den unterschiedlichen Verfahren zur Bewertung der Barierefreiheit beschäftigen und wie man diese eventuell kombinieren kann:
»We particularly welcome discussion of the relationship of these two approaches and how to potentially combine them, as well as a discussion of any of the following types of questions:
- What sort of techniques can we explore to combine metrics that are computed automatically, semi-automatically (with input from humans), and manually (where the judgement is made by humans, even if with input from software)?
- How can we build an infrastructure (such as IBM Social Accessibility) that allows experts to store accessibility information (metadata) for use with metrics that are computed during subsequent audits?
- What metrics, or combination of metrics, can be used as predictors of accessibility?
- How shall we characterize the quality of such predictors in terms of properties such as reliability, validity, sensitivity, adequacy and adaptability?
- Which approaches can be embraced for validating, benchmarking, and comparing web accessibility metrics?
- How should we tackle metrics in web applications with dynamic content?«
w3.org/WAI/RD/2011/metrics/cfp.html#objectives
Weitere Infos dazu: Call for Papers: Online Symposium on Website Accessibility Metrics.
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.
Im Internet finden sich viele Dokumente wie Jahresberichte, Broschüren, Verträge, Berichte und Zeitschriften. Um eine geräteunabhängige Layout-Darstellung zu garantieren wird hierfür oft das PDF-Format verwendet. Dieses Format hat für sehende Menschen einige Vorteile: die Software für die Anzeige ist kostenlos erhältlich und das Layout der Dokumente bleibt erhalten. Blinde und sehbehinderte Menschen stehen dem PDF-Format immer noch sehr kritisch gegenüber. PDF-Dokumente sind in unbearbeitetem Status oft gar nicht lesbar; ein Word-Dokument hingegen ist zwar meistens auch nicht barrierefrei, aber doch zumindest meist teilweise lesbar.
Im Netz gibt es sehr viele schlechte und nur wenige gute strukturierte Word-Dokumente; dasselbe gilt auch für schlechte beziehungsweise korrekte barrierefreie PDF-Dokumente. Die Tester der schweizerischen Stiftung »Zugang für alle« kennen die Vor- und Nachteile der beiden Formate. Dies ermöglicht ihnen, die gemachten Erfahrungen mit barrierefreien Word- und PDF-Dokumenten einander gegenüberzustellen. Die häufig zu hörende Meinung »PDF-Dokumente sind schlecht«
soll durch einen Test mit Fakten hinterfragt werden.
Anhand von 20 Accessibility-Prüfkriterien hat die Stiftung einen Vergleich der beiden Formate mit dem Screenreader JAWS durchgeführt. Untersucht wurden 20 JAWS-Befehle, die für die Benutzung von Dokumenten für blinde und sehbehinderte Menschen am wichtigsten sind. Der Vergleich zeigt, dass bei 11 von 20 untersuchten Kriterien das PDF-Format von JAWS deutlich besser unterstützt wird. In Word werden lediglich zwei Funktionen besser vom verwendeten Screenreader unterstützt als im vergleichbaren PDF-Dokument.
Die kompletten Ergebnisse des Tests sind unter »Zugänglichkeit von Word- vs. PDF-Dokumenten mit JAWS«.
Der Arbeitstag des gemeinen Web-Entwicklers beginnt ja üblicherweise damit, dass man mal eben schnell was im IE & Firefox kontrollieren will. Beim Start der Virtualisierungs-Software will diese erstmal aktualisiert werden. OK. Update durchgeführt, neugestartet und, oh Wunder, die nächsten Sicherheitsupdates für XP. Na gut, schnell mal installiert, Neustart und dann endlich Firefox geöffnet. Oh, ein Update! Mal schnell runterladen, Browser neustarten, Erweiterungen auf Updates überprüfen und, man glaubt es kaum, es gibt neue Versionen. Runterladen, installieren, Browser neustarten und …
… nichts geht mehr.
Und das alles nur um festzustellen, dass zumindest der letzte Teil des Prozederes für die Katz' war, weil ausgrechnet eine für Web-Entwickler so wichtige Erweiterung namens Firebug so dermaßen voller Bugs ist, dass nur noch das Downgrade auf die Vorgängerversion hilft. Pustekuchen, weil die ist dann nämlich nicht mit der neueren Browser-Version kompatibel und verweigert die Installation.
20 GOTO 10
Der einzige Trost: Die Suche bei Twitter zeigt, dass man nicht allein mit dem Problem ist. Dabei wollten wir eigentlich nur was zu den angeblichen Accessibility-Verbesserungen in Firebug 1.4.x schreiben, aber mangels Testobjekt muss dieser Blogpost halt bis zur nächsten Version warten. Und dann geht der Spaß wieder von vorne los …
Im Punkt 2.3.1 der WCAG 2.0 geht es um eine eher seltene, aber in ihren Auswirkungen drastische Form von Behinderung: die photosensitive Epilepsie. Von ihr betroffen sind Menschen, bei denen in einem bestimmten Frequenz-Bereich blinkender oder blitzender Inhalt einen epileptischen Anfall auslösen kann. Aus dem Erfolgskriterium selbst wird natürlich nicht klar, worum es genau geht und wie dies zu verhindern bzw. zu testen ist:
2.3.1 Grenzwert von dreimaligem Blitzen oder weniger: Webseiten enthalten nichts, was öfter als dreimal in einem beliebigen, eine Sekunde dauernden Zeitraum blitzt, oder der Blitz ist unterhalb der allgemeinen Grenzwerte zu Blitzen und roten Blitzen. (Stufe A)
Im Glossar der WCAG 2.0 steht nur pauschal »Es gibt Werkzeuge, welche die Analyse durch die Erfassung des Video-Bildschirms ausführen«
, aber nicht, welche diese Werkzeuge sind und wo man sie bekommt. Zum besseren Verständnis muss man da schon die »Understanding WCAG 2.0«-Dokumente heranziehen – dort wird dann im Detail erklärt, was hinter diesem Kriterium steckt und wie man es bewertet: »Understanding Success Criterion 2.3.1: Three Flashes or Below Threshold«
Genau für diese Evaluation gibt es jetzt vom Trace Research and Development Center ein Werkzeug namens Photosensitive Epilepsy Analysis Tool (PEAT), das nun in einer Beta-Version 1.5 zum Download (für Windows) veröffentlicht wurde.
Die ganz frisch veröffentlichten Kriterien und Prüfschritte sind die Grundlage für den BIENE-Wettbewerb im Jahr 2009. Der Fachliche Beirat des Wettbewerbs und die Veranstalter haben das Testverfahren nach Abschluss des Wettbewerbs 2008 vollständig überarbeitet. Insbesondere Kriterien und Prüfschritte, die nicht mehr dem aktuellen Stand der technischen Entwicklung entsprachen, wurden entweder aktualisiert oder aus dem Kriterienkatalog entfernt. Um auch Anwendungen prüfen zu können, die auf neueren Webentwicklungen basieren, wurden vorhandene Kriterien neu formuliert und es wurden – wo erforderlich – neue Kriterien und Prüfschritte entwickelt.
Prüfverfahren des BIENE-Wettbewerbs 2009
Mit einer BIENE zeichnen die Aktion Mensch und die Stiftung Digitale Chancen die besten deutschsprachigen barrierefreien Webseiten aus. Die Wettbewerbsbeiträge durchlaufen ein mehrstufiges Verfahren und werden anschließend von einer Jury gekürt.
Die erste Stufe des Testverfahrens bildet ein Vortest, in dem Basisanforderungen der Barrierefreiheit geprüft werden. Wettbewerbsbeiträge, die diese Anforderungen erfüllen, werden anschließend in einem umfassenden Feintest detailliert weiter untersucht. Ein Praxistest mit Betroffenen bildet die letzte Stufe des Verfahrens.
Im Rahmen des Testverfahrens werden alle Kriterien anhand verschiedener Prüfschritte untersucht. Die Prüfschritte werden gemäß einer Skala bewertet und dabei unterschiedlich gewichtet. Prüfschritte, die für einen Beitrag nicht relevant und nicht anwendbar sind, gehen nicht in die Bewertung ein.
Bei der Beschreibung der Prüfschritte wird in 2009 unter Standardansicht eine Testumgebung auf Windows XP, IE 7, 1024×768 verstanden. Darüber hinaus wird auch mit anderen Betriebssystemen und Browsern getestet. Geprüft wird bis auf einige Ausnahmen im mittleren Schriftgrad.
Weiterlesen …
Anpassbare Liste der Kriterien
Sie können in der Liste bestimmte Techniken abwählen und somit Prüfschritte ausfiltern, die für Ihr Webangebot nicht anwendbar sind. Diese werden dann nicht mehr angezeigt.
Zugänglichkeit für Nutzer ohne Maus zu ermöglichen ist einer der wichtigsten Schritte beim Aufbau einer barrierefreien Webseite oder Web-Applikation. Beim Testen der Zugänglichkeit per Tastatur findet man sich immer wieder nach dem Drücken der Tabtaste in der Situation: »Wo ist mein Cursor?« oder »Welches Element hat eigentlich gerade den Fokus?«. Gerade bei Elementen, die per CSS aus dem sichtbaren Bildschirm-Bereich geschoben wurden, tabt man dann gern und lang im Dunkeln.
LogFocus – hilfreiches Bookmarklet beim Testen von Keyboard-Accessibility
Beim Aufräumen unserer Lesezeichen-Sammlung haben wir ein Skript von Dirk Ginader gefunden, das Licht in diese Situationen bringt, und das er vor einiger Zeit in ein handliches Bookmarklet gekapselt hat.
LogFocus arbeitet in allen Browsern, die eine Konsole zur Verfügung stellen: Im Firefox ist hierfür Firebug notwendig; in Safari (bzw. WebKit) muss das ›Develop‹-Menü aktiviert sein; für Internet Explorer empfiehlt sich das PlugIn Companion.JS und in Opera wird die eingebaute Konsole im Debugger Dragonfly genutzt.
Um das Bookmarklet zu installieren zieht man einfach den folgenden Link in die eigenen Bookmarks:
LogFocus
Von dort aus kann das Skript dann einfach per Klick auf jeder beliebigen Seite ausgeführt werden und die aktuelle Position wird in die Konsole geschrieben.
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
Irgendwie haben wir wohl verpasst, dass die neueste Version 4 des freien Accessibility-Checkers WAVE Ende März dem βeta-Stadium entwachsen ist: WAVE Blog - New WAVE Version Released. Neben einer verbesserten Oberfläche und einer schnelleren Reaktionszeit werden eine ganze Reihe neuer Richtlinien und auch Techniken wie WAI-ARIA getestet. Wave ist eines der wenigen Tools, dass zum Beispiel Formularelemente ohne dazugehöriges Label findet (was auch dem besten Coder schonmal passieren kann, wenn man sich bei der ID vertippt).
Die WAVE-Reports gibt es entweder über das Web-Interface oder als Firefox-Toolbar, in beiden Fällen werden die gefundenen Fehler direkt im Browser angezeigt. Für die Zukunft ist auch die Lokalisierung in verschiedene Sprachen geplant, laut WebAIM Blog werden noch freiwillige Helfer gesucht.
Nachtrag 25.04.: Ab sofort ist auch die aktualisierte Firefox-Toolbar unter wave.webaim.org/toolbar erhältlich; weitere Infos dazu im WebAIM: Blog.
»Ohne Hilfsmittel und mit etwas Empathie können wir als Webgestalter, Texter und Site-Betreiber schnell ausprobieren, wie andere mit unserer Website zurechtkommen. Es gibt nur einen Grund, warum das nicht oft getan wird: Inkompetente Entwickler oder ignorante Auftraggeber!
In diesem Beitrag geht es nicht um Checklisten, Richtlinien und Verordnungen. Auch nicht um Toolbars und Prüfprogramme. Ich schreibe vom einfachen Menschenverstand.«
Gerald Brozek: »Zugänglichkeit von Websites mit Empathie testen«
Das Hamburger Projekt BIK hat den aktuellen Stand der WCAG 2.0 (wir berichteten) unter die Lupe genommen und heraus kam eine umfassende (wenn auch noch nicht ganz vollständige) Bewertung der kommenden Richtlinien zur Barrierefreiheit:
Neu bei EfA: die Kriterien der BIENE 2008, angereichert mit allerlei zusätzlicher Funktionalität. So kann man nun über ein Formular bestimmte Techniken abwählen und damit Prüfschritte ausfiltern, die für ein Webangebot nicht anwendbar sind – diese werden dann nicht mehr angezeigt. Wie es sich gehört funktioniert das ganze sowohl Client-seitig mit JavaScript und zusätzlich nochmal mit einem Server-seitigen Fallback ohne alles.
Alternativ gibt es die Prüfschritte auch als PDF-Datei (924 kB) zum herunterladen oder als MP3-Datei (1 h 20 min, 19 MB) zum anhören.
Mitmachen & Einreichen
Für eine BIENE kommen vor allem Web-Angebote infrage, die nicht nur die gesetzlichen und technischen Mindestanforderungen an Barrierefreiheit erfüllen und den Bewertungskriterien des Wettbewerbs entsprechen, sondern vor allem innovative und kreative Lösungen auf deren Basis bieten.
Anbieter von Webseiten oder Agenturen können ihre Wettbewerbsbeiträge bis zum 15. Juli 2008 einreichen. Zusätzlich haben Nutzer die Möglichkeit, Webseiten vorzuschlagen, die sie im Sinne der Barrierefreiheit für vorbildlich halten. Anmeldungen und Vorschläge können unter www.biene-wettbewerb.de eingereicht werden.
Eines der brauchbarsten Testwerkzeuge ist nun wie angekündigt als Erweiterung für Firefox erhältlich (Download, Packungsbeilage).
Das Prüfwerkzeug Bobby ist seit dem 1. Februar nicht mehr öffentlich zugänglich. Falls Ihnen dass jetzt nichts sagt: Bobby ist dieser grinsende Polizist, mit dem unbedarfte Webmaster den Nachweis auf ihre Seiten kleben konnten, dass man eine barrierefreie Seite hat das Bobby-Prüfverfahren bestanden hat.
Das Programm war zunächst am amerikanischen Center for Applied Special Technology (CAST) entwickelt und in den letzten Jahren von der Firma Watchfire weiterentwickelt und kommerziell vertrieben worden. Letztere ist im vergangenen Jahr von IBM übernommen worden und das Programm soll dem Vernehmen nach als Teil der Rational Policy Tester Accessibility Edition weiter vertrieben werden.
Unser Lieblings-Testwerkzeug liegt in einer neuen Version vor: WAVE 4.0 (beta). Das schöne an WAVE ist, dass man nicht mit einer seitenlangen Tabelle von Fehlern (oder vermeintlichen Fehlern) konfrontiert wird, sondern die problematischen Dinge im optischen Kontext der getesteten Seite sieht. Mehr dazu und zu den Änderungen und Neuerungen vom Mit-Entwickler Jared Smith im WebAIM-Blog: »Introducing WAVE 4.0«.
Eine Toolbar für Firefox ist noch in der Mache und soll in Bälde folgen. Mit dieser lassen sich dann auch Seiten im Intranet bzw. in Passwort-geschützten Bereichen testen, oder wenn sensitive Daten nicht über's Netz verschickt werden sollen.
Auf den simplen Namen Design hört ein ziemlich cooles JavaScript-Bookmarklet (bzw. Favelet oder wie auch immer das in Ihrem Browser heisst). Wie üblich einfach in die Lesezeichen-Leiste ziehen, Seite laden, draufdrücken und schon erhält man jede Menge nützliche Infos zum Aufbau der Seite. Sowas ähnliches gibt es auch als eigenständige Anwendung in Form von xScope, allerdings ist dies Bezahlware und MacOS-only.
Ganz ohne Werkzeuge gehen die Schnelltests, die Maria Putzhuber vorstellt und mit denen sich auch Nicht-Fachleute einen ersten Eindruck von der Zugänglichkeit eines Web-Angebotes verschaffen können: »Barrierefreiheit selber testen – Schnelltest ohne Werkzeuge«. Etwas komfortabler, allerdings auch mit höheren Ansprüchen an das Vorwissen geht es dann aber doch mit entsprechender Unterstützung: »Barrierefreiheit selber testen mit Werkzeugleisten«. (via)
XHTML-CSS Validator β ist kein wirklich neuer Validator, sondern ein Tool, dass Seiten gleichzeitig an die (X)HTML- und CSS-Prüfer des W3C übergibt und deren Ergebnisse aufbereitet; weitere Erklärung zur Funktionsweise bei »About the XHTML-CSS Validator«.
Barrierefreie Informationstechnik ist natürlich nicht nur auf das Geschehen im Webbrowser beschränkt. Bei IBM alphaworks gibt es neuerdings ein ganzes Framework von Accessibility-Werkzeugen, und mit dem enthaltenen aDesigner lässt sich nun auch die Barrierefreiheit von ›Open Document Format‹-Dokumenten (also OpenOffice etc.) überprüfen.
Gut daran: es werden nicht nur die gefundenen Probleme aufgelistet, sondern man erhält auch gleich noch eine Visualisierung, wie z.B. Nutzer mit verschiedenen Formen der Sehbehinderung das Dokument wahrnehmen würden. Getestet wird übrigens auf Basis der ODF v1.1 Accessibility Guidelines Version 1.0.
Heute mal was zur Planungs- & Entwurfsphase von Websites:
