accessBlog:

12 Jan 2012

Online-Befragung zum europäischen Barrierefreiheitsgesetz

Die Europäische Union plant ein allgemeines Gesetz zur Barrierefreiheit in den Bereichen Informationstechnik, Gebäude und Verkehr. Dafür hat sie eine Online-Befragung gestartet. An der Befragung können Menschen mit und ohne Behinderung, Unternehmen und Organisationen teilnehmen.

Die Befragung läuft bis zum 29. Februar 2012 und ist aktuell nur auf Englisch verfügbar.

Informationen zur Umfrage vom Bundeskompetenzzentrum Barrierefreiheit (deutsch): www.barrierefreiheit.de/…

Die Online-Befragung der Europäischen Union (englisch): ec.europa.eu/…

05 Dez 2011

BIENE-Wettbewerb: Schneller auf neue Entwicklungen reagieren

Die Aktion Mensch will den Wettbewerb um die BIENE (»Barrierefreies Internet eröffnet neue Einsichten«) im kommenden Jahr fortsetzen und schneller auf neue Entwicklungen reagieren. Das betont Martin Georgi, Vorstand der Aktion Mensch, im Interview mit kobinet.

Weiterlesen …

kobinet: Der BIENE wurde im Sommer eine Flugpause verordnet, damit die Aktion Mensch über das Konzept dieses Wettbewerbs nachdenken kann. Können sich die Interessierten auf eine Fortsetzung im kommenden Jahr einstellen?

Georgi: Wir haben mit der BIENE seit 2003 viel erreicht. 2011 haben wir uns eine Pause gegönnt, um grundsätzliche Fragen wie die Vereinfachung des Prüfverfahrens und eine mögliche Erweiterung der Kategorien zu überdenken. Wir arbeiten derzeit mit Hochdruck an der Neukonzeption eines Wettbewerbs zur Barrierefreiheit für 2012. Daher kann ich Ihre Frage positiv beantworten: es soll eine Fortsetzung geben.

kobinet: Wenn ja – was wird neu sein am BIENE-Wettbewerb 2012?

Georgi: Hier bleibt es spannend. Was ich Ihnen jetzt schon verraten kann: Wir überlegen, die Kategorien zu erweitern und unseren Blick auch auf neue Themenfelder zu richten. Zusätzliches Vernetzungs- und Kommunikationspotential mit Nutzwert für Menschen mit Behinderung steht dabei im Zentrum unserer Überlegungen. Soziale Netzwerke oder Applications (Apps) für mobile Endgeräte sind hier nur einige Stichworte.

kobinet: Der Wettbewerb um die besten deutschsprachigen barrierefreien Angebote im Internet hat Maßstäbe in Deutschland, Österreich und der Schweiz gesetzt. Wie kann die BIENE mit der kreativen und dynamischen Entwicklung der Informationstechnologie in Zukunft Schritt halten?

Georgi: Wir befassen uns derzeit ausführlich mit diesem Thema. Um mithalten zu können, brauchen wir unter anderem erfolgreiche Kooperationen und weiterhin die richtigen Partner und Experten. Das Prüfsystem kann verschlankt werden, so dass wir schneller auf neue Entwicklungen reagieren können. Aber mehr dazu im nächsten Jahr!

30 Nov 2011

Einfache Tests zur Barrierefreiheit von Webseiten

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.

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.

12 Okt 2011

HTML5 von den Profis lernen

HTML5 ist die Zukunft und macht das Web anwendungsfähig: als Plattform für Webanwendungen hat HTML5 die Aufmerksamkeit von Entwicklern und Anwendungsanbietern. Auf Initiative der Browserhersteller Opera, Mozilla, Apple und Google gründete sich 2004 eine Gruppe, die sich zum Ziel gesetzt hatte, das Web einen großen Schritt voran zu bringen. 2006 nahm das World Wide Web Consortium (W3C) die Entwicklung unter seine Fittiche. Microsoft hat sich ebenfalls HTML5 verpflichtet und stellt einen der Vorsitzenden der HTML-Arbeitsgruppe des W3C. Mit großer öffentlicher Unterstützung wird die Entwicklung von HTML5 vorangetrieben.

Alle größeren Hersteller implementieren diesen neuen Standard, der rein formal noch gar keiner ist, schon während seiner Entstehung in ihren Browsern und stellen so Web-Entwicklern die neuen Möglichkeiten bereit. Viele Werkzeuge und Bibliotheken schlagen die Brücke zu älteren Browsern. Als Web-Entwickler kommt man also bereits heute kaum noch an HTML5 vorbei.

Das W3C-Büro Deutschland und Österreich veranstaltet nun zum Thema HTML5 ein ganztägiges Tutorial. Am 23. November werden im THESEUS Innovation Center in Berlin-Tiergarten die Grundlagen und fortgeschrittene Themen aus HTML5, CSS3 und diversen APIs behandelt. Das Tutorial vermittelt Wissen über Hintergrund und Zielsetzung von HTML5, technische Grundlagen, HTML5 und Web-Architektur, Vorstellung der Neuerungen, Demonstrationen und Beispiele, die den Stand der Entwicklung in den unterschiedlichen Browsern zeigen und Strategien für das Entwickeln von Webseiten.

Weiterlesen …

Aus dem Inhalt:

• Evolution von HTML5
• Ziele, Prinzipien und Technologien in HTML5
• HTML5 und heutige Browser
• Neuerungen beim HTML5-Markup
  • Markup Syntax
  • Strukturelle Elemente
  • HTML5 Formulare
  • HTML5 User Interaction (Edit, Drag'n’Drop), Local Storage
  • HTML5 Media
  • Integration anderer Sprachen (z.B. SVG)
• HTML5 Präsentationsschicht (d.h. CSS3)
• HTML5 Pixels: Canvas
• HTML5 in der heutigen Praxis

Zu allen Themen gibt es aussagekräftige, praxisnahe Beispiele, deren Code im Detail erläutert wird.

Ort, Zeit und Teilnahme

Das Tutorial findet am 23.11.2011 von 9:30 bis 17:00 Uhr im THESEUS Innovation Center, Salzufer 6, 10587 Berlin-Tiergarten statt. Der Teilnehmerbeitrag ist 95,20€ incl. Mehrwertsteuer (80€ + MWSt). Die Teilnehmerzahl ist auf 50 begrenzt, Anmeldeschluss ist der 16.11.2011. Die Zulassung erfolgt nach Reihenfolge der Anmeldung und Zahlungseingang des Teilnehmerbeitrags. Weitere Informationen unter ict-media.de/HTML5Tutorial/announcement…

10 Okt 2011

Warum Formulare mit Nutzern getestet werden sollten

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.

26 Sep 2011

Die Kunst des richtigen Verlinkens

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 Link
• a:focus: ein angetabbter Link
• a:hover: ein Link, der mit dem Mauscursor angesteuert wurde
• a:visited: ein besuchter Link
• a: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.

21 Sep 2011

Wie misst man Barrierefreiheit?

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.

19 Sep 2011

Barrierefreie und benutzerfreundliche PDF-Dokumente

PDF-Dokumente sind der Quasi-Standard für plattformunabhängige, digitale Dokumente. Vor allem für Blinde und Sehbehinderte sind sie aber eher schwierig zu benutzen. PDF-Dateien sind so gut wie nie barrierefrei. Das liegt daran, dass die meisten kostenlosen oder kostenpflichtigen Programme zur Erzeugung von PDF-Dateien die Barrierefreiheit nicht unterstützen. Broschüren oder Bücher nachträglich barrierefrei zu machen ist ein aufwendiger Prozess.

Die Grundlage für barrierefreie PDFs sind Tags. Ähnlich wie in HTML wird durch Tags eine Struktur über das Dokument gelegt, so dass es wie eine Webseite navigiert werden kann.

Weiterlesen …

Barrierefreiheit versus Benutzbarkeit

Viele PDF-Dateien sind grundsätzlich benutzbar, auch wenn sie nicht barrierefrei sind. Für Blinde erscheint dann der Text als Fließtext ohne Überschriften, Listen oder sonstige Strukturen. Doch es gibt auch genügend Dokumente, die gar nicht benutzbar sind. Die häufigsten Probleme sind:

• Das Dokument besteht aus einer Rastergrafik und nicht aus Text.
• Das Dokument ist gegen die Entnahme von Text kopiergeschützt.
• Das Dokument ist mehrspaltig oder enthält einen unbekannten Zeichensatz.

Beim Lesen solcher PDFs können die seltsamsten Störungen auftreten. Bei einem PDF wird nach jedem Wort ein Punkt statt einem Leerzeichen eingefügt, bei einem mehrspaltigen Text werden die Zeilen falsch zusammengesetzt, bei einem anderen Dokument steht jedes Wort in einer eigenen Zeile. Bei geschützten Dokumenten oder Rastergrafiken hingegen hat der Screenreader schlicht keine Möglichkeit, auf den Inhalt zuzugreifen.

Ob ihr nicht-barrierefreies PDF problematisch ist können Sie ganz leicht selber testen: Versuchen Sie, Ihr PDF-Dokument als Text zu speichern. In den meisten Leseprogrammen finden Sie eine entsprechende Möglichkeit im Datei-Menü. Wenn die Option ausgegraut oder nicht aufrufbar ist, ist Ihre Datei geschützt. Wenn die resultierende Text-Datei leer ist, handelt es sich vermutlich um eine Rastergrafik. Und wenn Sie einen unlesbaren Text erhalten stimmt etwas mit Ihrem Spalten- oder Zeichensatz nicht.

Unstrukturierter Text ist kein Ersatz für PDF, sondern ein schlechtes Provisorium. Eine Tabelle zum Beispiel ist in einer Textdatei vollkommen unbrauchbar.

An welcher Stelle sollte man ein PDF einsetzen?

PDF ist tatsächlich sinnvoll, wenn es um große Mengen an Informationen geht, die gestaltet sein sollen. Die aktuellen Webstandards erlauben nur eingeschränkten Einfluss auf Farbgestaltung oder Typographie, vor allem, wenn das Dokument mit allen Browsern auf allen Plattformen gleich aussehen soll. Oftmals werden PDF aber eingesetzt, weil es für den Redakteur gerade bequemer ist.

Wenn ein Text viele Seiten umfasst, keine unmittelbar wichtigen Informationen enthält, das Layout wichtig ist und der Text nicht ständig aktualisiert werden muss, kann man ihn als PDF anbieten. In allen anderen Fällen sollte immer eine HTML-Version bevorzugt werden.

Wenn Sie einige Regeln beachten, können Sie die Nutzung von PDF-Dokumenten wesentlich erleichtern.

Das PDF soll zugänglich sein

Die kostenlosen Produktivitätsprogramme OpenOffice bzw. LibreOffice können von Haus aus barrierefreie PDF erstellen. Auch Microsoft Office kann ab der Version 2007 getaggte PDF erstellen. Dazu müssen die in der Textverarbeitung vorhandenen Formatvorlagen für Überschriften und Listen verwendet werden; es können auch Alternativtexte für Bilder vergeben werden.

Für komplexere Dokumente wie etwa Flyer oder Broschüren müssen allerdings die Produkte von Adobe eingesetzt werden. Wenn es aus finanziellen oder technischen Gründen nicht möglich ist, ein strukturiertes PDF bereit zu stellen, sollten Sie zumindest – wie oben beschrieben – auf die Benutzbarkeit achten.

Das PDF soll sprechend benannt werden

Viele Nutzer sammeln PDF-Dokumente zur späteren Lektüre. Wenn die Dokumente nicht sprechend benannt sind, müssen sie geöffnet werden, um zu erfahren, um welches Dokument es sich handelt.

Vor allem Blinde mögen es nicht, PDF-Dateien im Browser zu öffnen. Die Browseranzeige ist nicht barrierefrei, zudem kann die komplette Tastatursteuerung über den Browser verloren gehen, so dass der Browser neu gestartet werden muss. Blinde ziehen es deshalb vor, PDFs zu speichern und mit dem Leseprogramm zu öffnen.

Aus diesem Grund sollten Sie auch immer ankündigen, wenn sich hinter einem Link ein PDF verbirgt. Überraschungen dieser Art sind nicht nur bei Blinden unbeliebt.

Das PDF soll klein sein

Die 50 MB große PDF-Datei ist, DSL hin, DSL her, sehr langsam beim Download. Das mag bei Druckvorlagen angemessen sein, die eine hohe Auflösung und Bildqualität von 300 dpi oder höher haben sollen. Für das Internet ist diese Datei zu groß, es dauert lange, sie zu öffnen und mit ihr zu arbeiten. Achten Sie vor allem darauf, die Bilder internetgerecht zu komprimieren.

Das PDF soll keine Informationen enthalten, die nicht auf der Website stehen

Aus der Sicht der Benutzerfreundlichkeit ist es sinnvoll, wichtige Informationen immer so einfach wie möglich zugänglich zu machen. Das heißt, die Informationen sollen auf der Webseite stehen, wenn sie wichtig sind. Es spricht nichts dagegen, sie ergänzend in ein PDF zu packen, aber das sollte keine Priorität haben.

Der große Vorteil von Webseiten besteht darin, dass sie leichter barrierefrei zu machen sind als PDF. HTML wird von den meisten Hilfstechniken gut unterstützt, was man von PDF nicht behaupten kann.

Das PDF soll nicht geschützt sein

Wenn das PDF nicht barrierefrei gemacht werden kann, sollte es zumindest nicht vor dem Kopieren von Text geschützt werden. Für Blinde ist es ansonsten nicht möglich, auf den Text zuzugreifen. Aber auch andere Nutzer werden dadurch gestört, wenn sie etwa Text für ein Zitat kopieren möchten.

Denken Sie an mobile Endgeräte

Immer mehr Menschen sind überwiegend mit kleinen und nicht sehr leistungsfähigen Endgeräten im Internet unterwegs. PDFs werden von diesen Geräten nur eingeschränkt dargestellt, weil die Grafik nicht leistungsfähig genug ist. PDF ist ein Format für große Displays. Die wenigsten Menschen werden ein mehrseitiges PDF auf ihrem Smartphone lesen. Das ist ein weiterer Grund, wichtige Informationen direkt auf der Webseite bereit zu stellen.

14 Sep 2011

Fortbildung für Web-Arbeiter

Wir haben uns wieder mal die Mühe gemacht, eine ganze Reihe neuer Konferenzen und Workshops auf der Übersichtsseite bei einfach-fuer-alle.de/events einzutragen (›Mühe‹ deshalb, weil die manuelle Einpflege von Microformats nun wirklich keinen Spaß macht, aber dafür können Sie dann alle Einträge als Kalenderdatei für Outlook oder iCal herunterladen). Falls Sie also im Herbst noch nichts vorhaben – dort finden Sie sicher eine ganze Reihe interessanter Veranstaltungen im deutschsprachigen Raum, aber auch im angrenzenden Ausland.

Besonders interessant erscheinen uns die ›beyond tellerrand‹-Konferenz am 20. – 22. November in Düsseldorf, die Fronteers-Konferenz am 06. – 07. Oktober in Amsterdam sowie der Accessibility Summit, der als reine Online-Konferenz konzipiert und durchgeführt wird. Auf der Fronteers gibt es die einmalige Chance, von internationalen Accessibility-Experten wie z.B. Derek Featherstone in einem Workshop zu lernen – Teilnehmer nehmen automatisch an der Verlosung von zwei Tickets für den Accessibility Summit teil.

Wenn Sie eine Veranstaltung zum Thema Webdesign im Allgemeinen oder Barrierefreies Internet im Speziellen kennen, die dort noch nicht aufgelistet ist, würden wir uns wie üblich über eine kurze Nachricht per Kommentar oder über das Kontaktformular freuen.

12 Sep 2011

Mit Struktur zu barrierefreien Texten

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:

1. 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.
2. 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.