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…
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.
Die HTML-Arbeitsgruppe des W3C hat einen ersten öffentlichen Arbeitsentwurf von HTML5 speziell für die Ersteller von Webseiten vorgelegt: HTML5: Edition for Web Authors. Dieses Dokument ist eine Untermenge der gesamten HTML5-Spezifikation ohne die für Webentwickler eher uninteressanten Anweisungen an die Browserhersteller zur Implementierung des Standards in ihren Produkten. Es richtet sich somit an Nutzer von HTML die eine Ansicht benötigen, die sich ausschließlich auf die Details beschränkt, die für die Erstellung von Web-Dokumenten und -Applikationen relevant sind.
Die gesamte HTML5-Spezifikation befindet sich weiterhin im Status des sog. ›Last Call‹, in dem die verbliebenen Bugs und offenen Punkte abgearbeitet werden. Gerade die allnächtliche Flut von Bugs zum Thema Accessibility zeigt, dass die Spezifikation an manchen Stellen noch nicht wirklich fertig ist. Weitere Infos zu den HTML-Aktivitäten des W3C finden Sie auf den Seiten der HTML Working Group.
Funktionale Grafiken sind Grafiken, mit denen eine Funktion verbunden ist. Sie werden auf praktisch allen Webseiten eingesetzt, bekannt sind zum Beispiel das Drucker-, das Brief- oder RSS-Symbol, deren Funktion mehr oder weniger intuitiv erkennbar ist. Sie werden aber auch in komplexen Webanwendungen wie Google Text und Tabellen verwendet.
Die Symbole sind äußerst eingängig, weil wir sie teilweise schon aus anderen Kontexten kennen: den Desktop-Anwendungen, wo sie von Normal-Sehenden und Maus-Nutzern ausgiebig verwendet werden. Abgesehen von Blinden und stark sehbehinderten Menschen kommen diese Grafiken praktisch allen Menschen zugute, wenn sie gut gewählt und eingängig sind.
Weiterlesen …
Sie machen aus einer komplexen Interaktion mit der Website einen einfachen und intuitiven Prozess. Für Menschen mit Lernbehinderungen erleichtern sie ungemein die Bedienung der Seite.
Alternativer YouTube-Player
Christian Heilmanns alternativer YouTube-Player erleichtert die Bedienung durch große und leicht erkennbare Bedienelemente.
Wahl der Grafiken
Um eine Grafik verwenden zu können, sollte sie hinreichend bekannt sein. Webdesigner mögen viel Energie in eine hübschere Metapher zum Einkaufskorb investieren. Das bringt aber nur etwas, wenn die Funktion »Ware in eine Zwischenablage speichern, um sie beim Abschließen des Bestellvorgangs mit weiteren Waren zu bestellen« dem Nutzer deutlich wird. Diese ausschweifende Funktionsbeschreibung macht den Sinn dieser simplen Metapher vom Warenkorb deutlich. Statt langatmige Erklärungen abzugeben, versteht jeder Mensch mit ein wenig Erfahrung im Internet-Einkauf, was der Erschaffer der Seiten mit dem Warenkorb-Symbol mitteilen möchte.
Das gilt natürlich nur für Funktionen, die hinreichend etabliert sind. Nehmen wir an, wir entwickeln eine vollkommen neue Funktion, wenn wir etwa eine neue Webanwendung etablieren. Dann können bzw. müssen wir uns eine eigene Symbolsprache ausdenken, sofern keine Vorbilder vorhanden sind. In diesem Falle kommen wir kaum daran vorbei, dem Nutzer einen Lernprozess zu unterwerfen, indem er bei der Nutzung der Anwendung nach und nach auch die Funktionen der Symbole kennenlernt und die verwendete Bildsprache versteht. Dennoch kann der Lernaufwand möglichst gering gehalten werden, indem eingängige Symbole eingesetzt werden. Für die Erstellung solcher Funktionsgrafiken sollten entsprechend Experten beauftragt werden. Auch Tests zur Verständlichkeit mit echten Nutzern sind empfehlenswert.
Die Größe der Funktionsgrafiken
Jede Grafik muss so groß sein, dass sie mit der Maus gut anzuklicken ist. Die Grafiken müssen einen gewissen Abstand zueinander haben und sie sollten bei normaler Auflösung auf einem mittelgroßen Bildschirm gut zu erkennen und gut anzuklicken sein. Wichtig ist auch, dass die Grafiken per Tastatur angesteuert und aktiviert werden können. Sowohl für Maus- als auch für Tastaturnutzer muss erkennbar sein, welches Element sie gerade fokussiert haben, etwa über einen Rahmen oder eine Farbänderung.
Für Menschen mit motorischen Einschränkungen, die mit einer Maus oder einem speziellen Eingabegerät arbeiten, sind zu kleine Klickflächen und zu eng beieinander stehende Elemente schwierig zu treffen. Das gilt auch für die Nutzer von mobilen Endgeräten wie Netbooks, Tablet-PCs oder gar Smartphones.
Auszeichnung
Blinde benötigen einen Alternativtext, alle anderen Nutzer brauchen den title, um bei Verwendung der Maus zu erfahren, welche Funktion sich hinter der Grafik verbirgt. Ein Briefsymbol könnte eine Kommentarfunktion, eine Leserbrief-Funktion oder ein E-Mail-Formular sein. Für Funktionstexte gilt immer das Gleiche: möglichst kurz, möglichst prägnant, möglichst eindeutig. Es kommt gar nicht so selten vor, dass der Beschreibungstext die Grafik und nicht ihre Funktion beschreibt, zum Beispiel »Pfeil nach links« statt »zurück«: Das Druckersymbol bekommt also den Alternativtext und Titel »Drucken«, das RSS-Feedsymbol wird mit »Feed abonnieren« hinreichend beschrieben.
Grafische CAPTCHAs
Auch CAPTCHAs sind funktionale Grafiken. Ihr Einsatz ist eher kritisch zu sehen. Zwar stellen viele Systeme wie ReCaptcha alternative Audiodateien zur Verfügung, diese sind aber schwer zu verstehen, zumal sie auch nur auf Englisch angeboten werden. Viele Alternativ-Mechanismen funktionieren auch gar nicht, wenn die Nutzer Flash oder JavaScript blockieren. Für Hör-Sehbehinderte sind weder graphische noch auditive Lösungen verwendbar. Wir raten daher generell von der Nutzung von graphischen CAPTCHAs ab. Sie sollten durch nichtgrafische Alternativen wie Rechenaufgaben und einen leistungsfähigen Spamschutz ersetzt werden. Nebenbei bemerkt haben mittlerweile einige Programme eine bessere Erkennungsrate als Menschen.
Fazit
Der bedachte Einsatz von Bildern und Grafiken kann für viele Menschen mit und ohne Behinderung die Nutzung einer Webseite erleichtern. Wie wir gesehen haben, ist das eine Querschnittsaufgabe. Für Platzhalter-, Dekorations- und Funktionsgrafiken sind vor allem Webdesigner und Frontend-Entwickler gefragt. Für inhaltliche Bilder müssen die Redakteure Alternativtexte und Titel vergeben, wofür eine Funktion im Redaktionssystem vorhanden sein muss. Das Regelwerk sieht zwar sehr umfangreich aus, wenn man aber einmal identifiziert hat, um welchen Grafiktyp es sich handelt, ist auch leicht zu entscheiden, wie Alternativtext, Titel und Bildunterschrift aussehen sollten.
Inhaltliche Bilder ergänzen den Inhalt einer Website: Das Foto in einem journalistischen Artikel, das Diagramm der Umfrage-Statistik, das Organigramm der Firma. Ihr Einsatz ist sinnvoll, weil ein Bild die Aussage eines Textes unterstreichen kann und zu viel Text die Leser häufig abschreckt. Infografiken, wie sie im Datenjournalismus eingesetzt werden, können komplexe Sachverhalte und Zusammenhänge anschaulich vermitteln und sind daher eine gute Ergänzung zum klassischen Journalismus.
Weiterlesen …
Bilder in journalistischen und informativen Texten
Bei journalistischen Texten haben die Bilder eine begleitende Funktion. Sie unterstreichen den Inhalt des Textes, der Text bleibt aber auch verständlich, wenn das Bild aus irgendeinem Grund nicht angezeigt wird.
Hier reicht es aus, den Namen der abgebildeten Person, des Ortes oder Gegenstandes zu nennen. Genauer beschreiben sollte man das Bildobjekt nur, wenn es zum Verständnis des Textes beiträgt. Längere Beschreibungen kann man im Bild-Untertitel unterbringen: »Angela Merkel kritisiert die Opposition« ist für Alternativtext oder Bildunterschrift vollkommen ausreichend. Es ist richtig, dass Bilder auch Emotionen oder Stimmungen vermitteln sollen. Allerdings wird dieser Zweck bereits mit dem eigentlichen Fließtext verfolgt. Wenn die Stimmung von Text und Bild nicht übereinstimmt, sollte die Bildauswahl überdacht werden.
Wenn Sie ein abgebildetes Gemälde oder Kunstwerk beschreiben wollen, sollten Sie das ebenfalls im Fließtext tun. Davon profitieren alle Besucher der Website, zumal bei der im Web üblichen Auflösung für Bilder Details nicht gut zu erkennen sind.
Eine besondere Form journalistischer Produkte sind Bilderstrecken oder Fotoreportagen. Die meisten Blinden werden sich wohl nicht mit Bilderstrecken beschäftigen. Dennoch sollten auch diese Bilder Alternativ- und Titeltexte erhalten. Wir empfehlen außerdem, in einem Begleittext den Inhalt der Bilder zu beschreiben. Sehbehinderte erkennen den Inhalt eines Bildes oft erst, wenn sie wissen, was darauf zu sehen ist.
Informationsgrafiken
Informationsgrafiken erleichtern die Aufnahme von Informationen. Welche Aspekte bei ihrer Erstellung zu beachten sind, wollen wir anhand von Diagrammen anschaulich machen.
Für Diagramme ist entscheidend, dass alle Bestandteile deutlich zu erkennen sind, das gilt auch für die Begleittexte, die zumeist auch als Pixelgrafik eingebunden werden. Bei den Wahlergebnissen stehen die Parteinamen und Prozentangaben oft im Tortendiagramm. Das ist suboptimal, da die Tortenstücke meist in den Parteifarben gestaltet sind und oft zu geringen Kontrast bieten. Wenn Farbe als einziges Unterscheidungsmerkmal verwendet wird, können Farbfehlsichtige einzelne Diagramm-Bestandteile nicht mehr unterscheiden.
Das gilt auch für Legenden-Texte. Wenn Farbe als einziges Erkennungsmerkmal eingesetzt wird, können Farbfehlsichtige den Bezug zwischen Element und erklärender Legende nicht herstellen. Hier gibt es grundsätzlich zwei Lösungswege:
- Es gibt außer der Farbe ein weiteres Erkennungselement, zum Beispiel ein bestimmtes Muster.
- Element und Beschreibung werden unmittelbar miteinander verbunden, wobei die Beschreibung nicht in das Element eingebettet wird, um die Lesbarkeit zu erleichtern.
Wie kommen die Besucher zu Einfach für Alle
Durch die Farbverläufe sind die Bestandteile des Diagramms auch für Farbfehlsichtige zu erkennen.
Alternativ können die Tortenstücke auch einen kleinen Abstand zueinander haben.
Wie kommen die Besucher zu Einfach für Alle
Durch den kleinen Abstand werden die Tortenstücke leichter unterscheidbar
In jedem Fall sollten die im Diagramm dargestellten Ergebnisse auch als normale HTML-Tabelle angeboten werden, damit auch Blinde die Ergebnisse erkennen können. In keinem Fall ist es sinnvoll, die Ergebnisse im Alternativ-- oder Titeltext unterzubringen, weil das unübersichtlich ist. In unserem Fall ist ein Alternativtext wie »Herkunft der Besucher von Einfach für Alle« als Tortendiagramm« ausreichend.
Herkunft der Besucher von Einfach für Alle| Direkteingabe / nicht verfügbar | 27.753 | 42,35 % |
|---|
| Suchmaschinen | 24.024 | 36,66 % |
|---|
| Andere Sites | 13.753 | 20,99 % |
|---|
Weitere Umsetzungsbeispiele für Informationsgrafiken finden Sie in der Linkliste.
Emoticons
Emoticons werden in ihrer Bedeutung unterschätzt. Früher wurden sie über spezielle Zeichenfolgen generiert (;-) und ähnliches), heute geht man dazu über, entweder graphische Emoticons zur Einbindung in den Text anzubieten oder sie automatisch aus den Zeichenfolgen zu generieren. Einige aktuelle Screenreader erkennen die wichtigsten Zeichenketten und lesen sie zum Beispiel als »Smiley« vor. Mit den Grafiken geht das nicht, meistens haben die graphischen Emoticons auch keinen Alternativtext. Das kann durchaus problematisch sein, denn mit solchen Emoticons kann Ironie ausgedrückt werden, wer dies aber nicht erkennen kann, versteht auch nicht, dass jemand etwas ironisch gemeint hat, was zu einer endlosen Kette von Missverständnissen führen kann. Wünschenswert sind also alt-Texte für graphische Emoticons. Wenn man sie nicht all zu exzessiv einsetzt, können sie Menschen mit unterschiedlichen Behinderungen durchaus helfen, einen Text besser zu verstehen. Eine solche Funktion muss allerdings im Redaktionssystem angelegt sein, da Redakteure und Nutzer normalerweise keinen Einfluss auf die Ausgestaltung dieser Grafiken haben.
Grafiken in Gebrauchstexten
Bei Anleitungen zur Behebung von Software-Problemen oder Ähnlichem werden häufig Screenshots verwendet. Die erklärenden Texte dazu sind eher sparsam. Was der Sehende auf den ersten Blick erfasst – den Unterschied zwischen zwei Screenshots – muss der Sehbehinderte erst einmal mühsam erfassen und der Blinde hat dazu gar keine Chance. Vor allem für Sehbehinderte und Blinde ist eine exakte Beschreibung sinnvoll: Welches Menü oder welcher Dialog wird aufgerufen, welcher Karteireiter wird ausgewählt, welche Option soll aktiviert oder deaktiviert werden? Die Vorgänge sollten so detailliert beschrieben werden, dass die Aktion auch ohne den Screenshot nachvollzogen werden kann.
Alternativtexte und Bildunterschriften
Grundsätzlich sollte ein Alternativtext kurz sein. Er unterbricht meistens den Lesefluss und ist oft nicht so wichtig zum Verständnis des Textes. Längere Beschreibungen sollten in die Bildunterschrift, wo sie allen zugute kommen. Wie schon im ersten Teil erwähnt können für Alternativtext und Titel die gleichen Texte verwendet werden, die Bildunterschrift sollte sich hingegen von beiden unterscheiden.
Größe der Grafiken
Für Sehbehinderte ist es nützlich, wenn sie die Bilder vergrößern können. Zwar stellen die Browser einfache Vergrößerungsfunktionen bereit, aber wie schon im ersten Teil erwähnt verschlechtert sich die Qualität von Pixelgrafiken bei Vergrößerung. Eine Lösung besteht darin, das normale Bild mit einem Link zu einer größeren Version des Bildes zu unterlegen.
Die Erstellung und Einbindung inhaltlicher Bilder fällt in den Aufgabenbereich von Redakteuren. Sie sollten für diesen Bereich geschult und sensibilisiert werden. Auch Redaktionshandbücher und Leitfäden sollten um entsprechende Anleitungen ergänzt werden.
Bilder und Grafiken verbessern die Benutzbarkeit und Verständlichkeit von Webseiten und Anwendungen. Häufig wird nur an den blinden Nutzer gedacht, der mit Grafiken wenig anfangen kann. Doch es gibt einige Möglichkeiten, Grafiken für Blinde schmerzfrei einzusetzen, so dass sie allen Gruppen von Menschen mit Behinderung zugute kommen. Schließlich können auch für Blinde gedachte Alternativen den Inhalt für alle Nutzer aufwerten.
Im ersten Teil der Serie werden wir uns mit dekorativen Grafiken und Platzhaltern beschäftigen. Solche Grafiken sind vor allem für das Layout der Website wichtig. Im zweiten Teil wird es um inhaltliche Bilder gehen, sie ergänzen den Inhalt eines Textes oder vermitteln Informationen in einer nicht-textuellen Form. Um funktionale Grafiken wird es im letzten Teil gehen, sie spielen eine entscheidende Rolle bei Webanwendungen.
Im ersten Teil wollen wir uns zunächst mit den verschiedenen Einsatzarten von Grafiken und Beschreibungsmöglichkeiten beschäftigen, bevor wir auf den Einsatz von Platzhaltern und dekorativen Grafiken eingehen.
Weiterlesen …
Vektor- und Pixelgrafiken
Es lassen sich zwei Arten von Grafiken unterscheiden: Vektorgrafiken werden im Computer erzeugt. Schon die Buchstaben, die Sie hier lesen, sind Vektorgrafiken, aber auch alles, was sie mit Zeichenprogrammen wie Illustrator erzeugen können. Vektorgrafiken können ohne Qualitätsverlust vergrößert werden.
Bekannte Vektorformate sind Scalable Vektor Graphics (SVG) und Adobes Flash. Sie werden zum Beispiel für Kartenanwendungen wie Open Street Map eingesetzt. SVG und Flash werden sehr unterschiedlich von den Browsern unterstützt, sie werden daher selten für Schmuckelemente eingesetzt.
Daneben gibt es die Rastergrafiken, die z.B. über einen Scanner oder eine Digitalkamera in den Computer kommen. Rastergrafiken bestehen aus einzelnen Bildpunkten (Pixel). Die Qualität dieser Grafiken sinkt deutlich, wenn sie vergrößert werden.
Pixelgrafik-Formate sind zum Beispiel JPEG, PNG oder GIF. Sie werden praktisch für alle Grafikelemente auf einer Website eingesetzt: für Fotos, aber auch für Zierelemente, Logos und vieles mehr. Wenn Vektorgrafiken in einem Pixelformat gespeichert werden, haben sie die gleichen Vor- und Nachteile wie Pixelgrafiken. Sie werden von den Browsern anstandslos angezeigt, lassen sich aber kaum ohne Qualitätsverlust vergrößern. Das ist vor allem wichtig, wenn Texte in Grafiken eingebettet werden.
Für Blinde sind in Grafiken eingebettete Texte gar nicht wahrnehmbar, für Sehbehinderte mit Vergrößerungssoftware sind sie nur schlecht lesbar. Vor allem längere Texte sollten daher nicht direkt in die Grafik eingebettet, sondern über HTML eingebunden und via CSS positioniert werden.
Vier Arten von Grafiken
Im Internet lassen sich vier Arten von Grafiken nach ihrem Einsatzzweck unterscheiden:
- Platzhaltergrafiken
- dekorative Grafiken
- inhaltliche Bilder
- funktionale Grafiken
Im Folgenden werden wir durchgängig von Grafiken sprechen, wenn es sich um dekorative oder funktionale Elemente handelt und von Bildern, wenn Abbildungen von Menschen, Gegenständen oder ähnlichem gemeint sind.
Ausgezeichnete Grafiken
Alle Pixelgrafiken werden über das Image-Tag <img> eingebunden. Grundsätzlich gibt es drei Attribute, mit denen das Image-Tag beschrieben werden kann:
alt = kurzer Alternativtextlongdesc = Lange Beschreibungtitle = Titel / Tooltip
Alternativtexte gehören zum Standard und dienen vor allem blinden Screenreader-Nutzern. Der Titel erscheint, wenn man mit dem Maus-Cursor über ein Bild fährt. Die long description war ursprünglich dafür gedacht, längere Beschreibungen unterzubringen. Praktisch wurde sie kaum eingesetzt und ist in HTML5 zurzeit nicht mehr vorgesehen. Es gibt außerdem noch die Bildunterschrift, die aber als normaler Text unterhalb des Bildes untergebracht wird und für alle Nutzer ohne weiteres sichtbar ist.
Platzhaltergrafiken und dekorative Grafiken
Platzhalter- und Dekorationsgrafiken sind Teil des Layouts und fallen damit in den Aufgabenbereich des Frontend-Entwicklers. Ihr barrierefreier Einsatz muss also schon bei der Gestaltung der Website berücksichtigt werden.
Platzhaltergrafiken
Platzhaltergrafiken sind kleine unsichtbare Grafiken. Sie sind zumeist 1x1 Pixel groß und dienen zur Stabilisierung des Layouts. Sie wurden zum Beispiel bei Layout-Tabellen eingesetzt, um das Design stabil zu halten.
Wenn unsichtbare Grafiken eingesetzt werden, sollten sie ein leeres alt-Attribut erhalten, in diesem Fall werden sie von Screenreadern ignoriert.
<img src="spacer.gif" alt="">
Ohne alt-Attribut oder title wird der Dateiname vorgelesen, was in keinem Fall sinnvoll ist. Ein Alternativtext wie "Platzhalter" wird hingegen als störend empfunden. Idealerweise sollten Sie Platzhaltergrafiken jedoch vermeiden und die Formatierung den Style Sheets überlassen.
Dekorative Grafiken
Dekorative Grafiken dienen dazu, die Website optisch aufzuwerten. Sie sind in der Regel nicht anklickbar und es ist normalerweise keine Funktion hinterlegt. Sie befinden sich üblicherweise auf jeder Seite des Webauftritts und immer an der gleichen Position, das sind zum Beispiel Banner, Logo, Hintergrundbilder, Zierleisten und so weiter.
Diese Grafiken sind äußerst nützlich: sie sollten auf einen Blick verraten, auf wessen Webauftritt man sich gerade befindet, erhöhen den Wiederkennungswert ungemein und vermitteln deshalb Sicherheit und Orientierung – nützlich für Menschen mit Lernbehinderung oder ältere Menschen.
Logo und Banner sind gewöhnlich mit der Startseite verknüpft und sollten einen entsprechenden Alternativtext enthalten: »Logo Einfach für Alle – zur Startseite« zum Beispiel. Bei grafischen Links sollten Alternativtext und Titel verraten, wo die Links hinführen, eine Beschreibung der verlinkten Grafik ist selten sinnvoll.
Grafiken, die keine Funktion erfüllen, nicht zum Inhalt beitragen und nur der Dekoration dienen, sollten wie Platzhalter-Grafiken ein leeres alt-Attribut erhalten, damit sie Blinde nicht vom Inhalt ablenken.
Für Alternativtext und Titel lassen sich die gleichen Beschreibungen verwenden, der Screenreader liest nur eine der beiden Beschreibungen vor. Die Bildunterschrift – sofern vorhanden – sollte hingegen nicht die gleiche Information enthalten wie Alternativtext und title, weil sie sowohl von Mausnutzern als auch von Screenreadern doppelt wahrgenommen würde.
Was in den Alternativtext gehört oder nicht ist heiß umstritten. Manchen genügt die nüchterne Nennung von Personen- oder Ortsnamen, andere wollen die Stimmung transportiert haben. Wenn das Bild dekorativ ist, sollte es einen möglichst kurzen Alternativtext enthalten. Vor allem, wenn die Bilder in einen Text eingebettet sind, sollte man bedenken, dass lange Alternativtexte oder Bildunterschriften den Lesefluss des Blinden stören können.
Über CSS eingebundene Hintergrundgrafiken lassen sich nicht mit beschreibenden Attributen versehen und sind damit für den Blinden unsichtbar. Hier ist zu beachten, dass sehende Nutzer in der Lage sein müssen, Elemente auf der Website zu erkennen. Das kann schwierig werden, wenn das Hintergrundbild zu wenig Kontrast zu den Inhaltselementen bietet, etwa weil es mit Farbverläufen arbeitet. Achten Sie deshalb bei Hintergrundbildern darauf, dass alle anklickbaren Elemente, Formularbestandteile und Fließtexte sich gut vom Hintergrund unterscheiden lassen. Alle Farbkombinationen jenseits von Schwarz auf Weiß verschlechtern die Lesbarkeit. Der Besucher sollte außerdem auf Anhieb erkennen können, ob eine Grafik anklickbar ist – also eine Funktion hat oder nicht.
Richtet man sich nach der Barrierefreie-Informationstechnik-Verordnung (Bedingung 4.1), muss ein Wechsel der Sprache im Text für Screenreader ausgezeichnet werden. Die Sprachauszeichnung erhöht aber nicht immer die Barrierefreiheit. Häufig führt sie aus Sicht von Screenreader-Nutzern sogar dazu, dass Texte nicht richtig verstanden werden.
Hintergrund
Bei allen Webseiten sollte die verwendete Hauptsprache gekennzeichnet werden. Dies geschieht über das lang-Attribut im root-Element: <html lang="de">. Neben der verwendeten Hauptsprache können aber auch einzelne Bestandteile im Text als fremdsprachig gekennzeichnet werden.
Screenreader erzeugen Sprache, indem sie vorgefertigte Phoneme aneinander koppeln. Das allein würde aber einen Text nicht verständlich machen, neben den Phonemen haben die Screenreader Wörterbücher mit Ausspracheregeln. Da Phoneme und Ausspracheregeln in jeder Sprache ein wenig anders sind, klingen spanische, englische oder deutsche Sprachausgaben sehr unterschiedlich, auch wenn im Prinzip die gleiche Stimme eingesetzt wird. Es gibt sogar unterschiedliche Schemata für einzelne Regionen mit gleicher Sprache, die Sprachausgabe für Spanien klingt ein wenig anders als die lateinamerikanische Variante. Wenn in einem deutschen Text ein Begriff als Spanisch ausgezeichnet wurde, sollte er Spanisch ausgesprochen werden, damit auch Blinde ihn verstehen – soweit die Theorie.
Weiterlesen …
In den Wörterbüchern der Screenreader ist auch die Aussprache gängiger Fremdwörter festgelegt. Das Wort Detail wird nicht ausgesprochen, wie es geschrieben wird. Es klingt eher wie Detai, das L am Ende bleibt stumm. Der Screenreader kann das inzwischen richtig ohne Sprachauszeichnung aussprechen, ebenso wie Chance, Restaurant und viele andere Wörter. Solche Wörter müssten theoretisch als Fremdwörter mit anderer Aussprache ausgezeichnet werden. Faktisch würde das aber die Verständlichkeit verschlechtern, denn Wörter wie Computer oder Software werden im Englischen anders ausgesprochen und betont als im Deutschen.
Viele Screenreader-Nutzer stellen die automatische Spracherkennung ab, weil sie einige Webseiten ansonsten gar nicht benutzen könnten. Es kommt gar nicht so selten vor, dass die Sprache einer Webseite falsch festgelegt wurde oder dass bei Redaktionssystemen eine falsche Sprache eingestellt wurde. Die falsche Einstellung führt dazu, dass eine deutsche Webseite mit englischer Aussprache vorgelesen wird.
Das Problem besteht darin, dass die Einstellung für die automatische Spracherkennung gut versteckt ist und ungeübte Screenreader-Nutzer sie nicht finden werden. Damit wird die betroffene Webseite praktisch unbenutzbar, weil die wenigsten Blinden eine deutsche Seite verstehen werden, die mit englischer Betonung vorgelesen wird.
Außerdem ist die Sprachumstellung nicht gerade angenehm, wenn nur einzelne Wörter oder Zitate geändert werden. Obwohl die vorlesende Stimme immer die gleiche bleibt, ändern sich Stimmlage, Intonation, Betonung und Aussprache, was bestenfalls eine unangenehme Überraschung auslöst und einen schlimmstenfalls aus dem Lesefluss reißt. Das heißt, wenn die Sprachausgabe mitten im Satz auf amerikanisches Englisch, britisches Englisch oder kastilisches Spanisch umschaltet, dann macht der Zuhörer diese überraschende Änderung kognitiv wahrscheinlich gar nicht oder nur verzögert mit.
Das heißt, der eigentliche Zweck wird komplett verfehlt, der Mensch am anderen Ende der Leitung hat das Wort gar nicht verstanden, weil er eben das Spanisch der Muttersprachler nicht verstehen kann oder weil er die Umschaltung kognitiv nicht mitgemacht hat.
Hinzu kommt, dass viele Blinde ihre Sprachausgabe auf ein hohes Tempo eingestellt haben. Allerdings können sie oft nur ihre eigene Sprache in diesem Tempo verstehen, während sie für fremdsprachige Texte das Tempo niedriger schalten würden.
Eine Sprachauszeichnung für einzelne Wörter oder Phrasen kann daher mehr Barrieren auf- als abbauen. Für längere Zitate, wie sie in wissenschaftlichen Texten eingesetzt werden, kann eine Auszeichnung des Sprachwechsels hingegen sinnvoll sein. Unserer Erfahrung nach ziehen es Blinde aber vor, die Kontrolle über den Screenreader zu behalten und die Sprache wenn nötig selbst umzustellen.
Fazit
Wichtiger als die korrekte Aussprache ist die Verständlichkeit. Vermeiden Sie deshalb Anglizismen oder Fremdwörter, die von der Zielgruppe nicht verstanden werden. Wenn Sie dennoch Fremdwörter verwenden, bieten Sie eine verständliche Erklärung an. Im Gegensatz zu Sprachauszeichnungen, von denen nur Blinde profitieren, kommt der Verzicht auf Fremdwörter oder deren Erklärungen allen Nutzern zugute.
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«.
Die Verwendung simulierter Dialogfenster oder »Lightboxes« – wie man im Englischen kurz und treffend zu sagen pflegt – ist aus dem Internet und der Web2.0-Welt eigentlich kaum noch wegzudenken, zu weit verbreitet scheint ihre Verwendung – zur Freude und zum dem Ärgernis der Nutzer.
Oliver Siemoneit zeigt in seinem Beitrag die gängigen Probleme aus Sicht der Nutzer und stellt den Prototypen einer zugänglichen Lightbox vor:
»Eine kleine Untersuchung zur Barrierefreiheit von Lightboxes«
Ergänzend zum vorstehenden Artikel hier noch ein paar zusätzliche Gedanken, Anforderungen und weiterführende Links zum Thema ›Barrierefreie Lightboxes‹.
Weiterlesen …
Kontext & Anforderungen
Manchmal muss man Benutzern ein reduziertes Interface präsentieren, das den Fokus auf die wesentlichen Informationen oder auf Formularfelder setzt und die Interface-Elemente versteckt, die für die gerade zu erledigende Aufgabe unnötig sind. Wenn dies in Form eines Overlays (auch ›Lightbox‹ genannt) implementiert wird, erscheint der Inhalt als Pop-Up-Fenster oder als simulierter Dialog. Die Lightbox überlagert den Inhalt der Webseite, der Hintergrund wird typischerweise ausgegraut.
Eine Lightbox kann modal sein, d.h. der Benutzer kann nur mit der Lightbox und deren Inhalt interagieren. Oder sie kann nicht-modal sein, d.h. der Benutzer kann in diesem Fall sowohl mit der Lightbox und ihrem Inhalt, als auch mit anderen Elementen der ursprünglichen Seite interagieren.
Hürden & Schwierigkeiten
In Sachen Barrierefreiheit bringt die Benutzung von Lightboxes einige Probleme für verschiedene Gruppen von Menschen mit Behinderungen mit sich. Mögliche Schwierigkeiten sind unter anderem:
- Die Möglichkeit, die Lightbox ohne die Hilfe einer Maus oder anderer Zeigewerkzeuge über eine Tastatur-Schnittstelle zu öffnen und zu schließen.
- Die Benachrichtigung des Benutzers über die Generierung einer Lightbox bzw. das Einfügen des benötigten Codes in die Seite (dies schließt Benutzer von Vergrößerungssoftware ein, die möglicherweise das plötzliche Erscheinen einer Lightbox nicht bemerken, da dies außerhalb ihres Sichtfeldes passiert ist).
- Der Zugriff per Tastatur auf die Lightbox selber (und auf deren Position im DOM-Tree in Relation zu dem auslösenden Element) und auf die Tab-Reihenfolge (und damit die Lesereihenfolge) zu jeglichen Formular-Elementen, Steuerelementen, Links usw., die in der Lightbox enthalten sind.
- Die visuellen Grenzen der Lightbox für Benutzer mit eingeschränktem Sehvermögen oder blinde Benutzer verständlich zu machen und die Notwendigkeit, den Zugriff des Benutzers auf Inhalte innerhalb einer modalen Lightbox zu beschränken.
- Die meisten Lightbox-Scripte setzen einen relativ großen Bildschirm voraus und scheitern bei mobilen Geräten (oder verkleinern nicht auf elegante Art und Weise).
- Die meisten Lightbox-Skripte unterstützen das Drucken nicht.
Barrierefreie Lösungen
Eine Lightbox und ihr Inhalt kann durch die Benutzung einer Reihe von Techniken barrierefrei gemacht werden, wenn man Best Practices der Barrierefreiheit (wie zum Beispiel die Techniques der WCAG 2.0) einsetzt:
- Beim Öffnen der Lightbox sollte der Tastatur-Fokus auf die Lightbox gesetzt werden (idealerweise auf das erste fokussierbare Element, bei dem es sich um einen Link, ein Formular-Label oder ähnliches handeln könnte).
- Beim Schließen der Lightbox muss der Tastatur-Fokus wieder zu der exakt gleichen Stelle zurückkehren, bei der er war, als die Lightbox geöffnet wurde (normalerweise das anfänglich benutzte Element zum Öffnen des modalen Dialogs). Die ursprüngliche Tab-Reihenfolge sollte wiederhergestellt werden und der Benutzer sollte nicht länger in der Lage sein, sich per Tab zu Inhalten innerhalb des modalen Dialogs zu bewegen (d.h. die Lightbox sollte nicht einfach nur aus dem Viewport bewegt werden, sondern sollte ganz aus dem Dokumenten-Baum entfernt werden);
- Das Lightbox-Script sollte die Bedienung per Tastatur vollständig unterstützen (z.B. Esc. zum Schließen der Lightbox, Pfeiltasten zum Blättern in einer Diaschau, Home- & End-Schaltflächen wie auf einer normalen Webseite). Es sollte ein deutlich sichtbarer Fokus-Indikator vorhanden sein und Tastaturbefehle sollten in der Lightbox dokumentiert sein (z.B. »Zum Schließen drücken Sie Esc«).
- Das Lightbox-Script sollte einen vollständigen Browser-Verlauf bieten und die Änderung des
title unterstützen (z.B. über jQuery Address).
- Der Inhalt innerhalb der Lightbox muss voll skalierbar sein (z.B. mit unterschiedlichen Textgrößen).
- Das Design der Lightbox sollte robust genug sein, damit es komplett wahrnehmbar ist, wenn benutzer-definierte Farben (z.B. ein Windows Kontrast-Schema) benutzt wird.
- In modalen Dialogen sollte der Benutzer nicht zu irgendwelchen Elementen außerhalb der Lightbox navigieren können. Stattdessen muss der Tastatur-Fokus innerhalb der Lightbox verbleiben, bis der Benutzer diese absichtlich schließt, entweder indem er Esc drückt oder auf einen Schließen-Link oder eine Schließen-Schaltfläche klickt. Vor allem wenn Formulare in einer Lightbox präsentiert werden, sollte das Tabben über die Lightbox hinaus diese nicht schließen, um einen Datenverlust zu verhindern. Dies kann allerdings in anderen Fällen, wie zum Beispiel bei einer Galerie, genau das erwartete Verhalten sein.
- Die Benutzung von ARIA-Rollen & -Eigenschaften (wie zum Beispiel
aria-role="dialog"oder role="button" für das »Schließen«-Symbol), ARIA-Live-Regions und zusätzlichen ARIA-Attributen, die Beziehungen beschreiben, wie zum Beispiel aria-owns.
Anwendbare Standards & verwandte Techniken
Literatur zum Thema
Beispiele ›aus der freien Wildbahn‹
Code-Beispiele & Downloads
Tabellen haben auch im barrierefreien Webdesign nach wie vor eine Daseinsberechtigung – aber bitte wirklich nur für die Darstellung tabellarischer Daten und nicht als Layout-Ersatz. Wie Sie Datentabellen für alle Nutzer zugänglich machen und welche Fehler Sie vermeiden sollten wird in den folgenden WCAG-Techniken erklärt:
Weiterlesen …
HTML-Techniken
Typische Fehler
Eine ganze Reihe veralteter Techniken stellen zwar keine absoluten Barrieren dar, sollten aber in der modernen Webentwicklung eigentich keine Rolle mehr spielen, weil Sie die Wartung der Seiten unnötig verkomplizieren. Welche das sind sehen Sie in den folgenden WCAG-Techniken:
Weiterlesen …
HTML-Techniken
CSS-Techniken
Typische Fehler
Barrierefreie Seiten zeichnen sich dadurch aus, dass sie auch unter den widrigsten Umständen noch Leistung abliefern. Das geht natürlich nur mit einem grundsoliden technischen Fundament, bei dem Browser nicht erst mal zahllose Fehler korrigieren müssen, bevor die Seite dargestellt werden kann. Das vereinfacht nicht nur die Verarbeitung, sondern hilft auch den Nutzern bei der eindeutigen Wahrnehmung und Bedienung, wie in den folgenden WCAG-Techniken erklärt wird:
Weiterlesen …
Allgemeine Techniken
HTML-Techniken
Client-seitige Scripting-Techniken
Typische Fehler
Formulare sind die hohe Schule des barrierefreien Webdesigns – wenn hier etwas nicht nutzbar ist, dann ist oftmals für den Nutzer an dieser Stelle das Ende eines Prozesses erreicht und ein geplanter Einkauf oder eine Beteiligung an einer Diskussion bleibt ihm verwehrt. Wie Sie Ihren Formularen eine barrierefreie technische Basis geben wird in den folgenden WCAG-Techniken gezeigt:
Weiterlesen …
HTML-Techniken
CSS-Techniken
Typische Fehler
Durch einen Blogpost bei microformats.org sind wir auf eine (mögliche) Lösung für das alte Problem gestossen, dass bestimmte Microformate für Screenreader-Nutzer zu Problemen führen können (wir berichteten). Demnach ist es wohl nun endlich möglich, bei der Auszeichnung von kalendarischen Daten auf das problematische abbr-design-pattern zu verzichten.
Statt das Datum (wie bisher zwingend vorgeschrieben) mit einem semantisch fragwürdigen abbr auszuzeichnen kann man nun auch ein leeres span mit den maschinenlesbaren Informationen versehen:
<p class="vevent">
<span class="dtstart">
<span class="value-title" title="2011-02-22"> </span>
Dienstag, 22. Februar 2011
</span>
</p>
Das hierzu benutzte value-title-pattern ermöglicht es Werkzeugen wie der Firefox-Erweiterung Operator, die ISO-datetime trotzdem auszulesen und z.B. in einen Kalendereintrag zu übersetzen; Screenreader hingegen sollten diese kryptischen Daten nun nicht mehr automatisch vorlesen.
»In short, by placing the machine readable ISO datetime into the title attribute of a harmless empty span element adjacent to the human readable date and time, we are able to achieve a pragmatic balance between user experience, content fidelity, and minimizing the effects of what is essentially duplicating the data (a DRY violation, something we avoid due to potential inconsistencies unless absolutely necessary for a greater principle, such as usability – humans first as it were).«
Damit umgeht man elegant das Problem, mit den bestehenden Möglichkeiten des Markups Dinge ausdrücken zu wollen, die in diesem begrenzten Wortschatz gar nicht vorgesehen sind und unter Umständen ›falsch‹ interpretiert werden – im konkreten Fall verhindert man damit, dass ein Screenreader je nach Einstellung, »Zwanzig Millionen Einhundertzehntausend Zweihundertzweiundzwanzig«
statt des heutigen Datums vorliest.
Weil uns die Idee so gefallen hat, haben wir sie gleich einmal auf der aktuellen Veranstaltungs-Seite umgesetzt. Zum Vergleich: hier die Seite für das laufende Jahr 2011 mit dem geänderten Code und die 2010er-Seite mit der unter Umständen etwas weniger zugänglichen alten Variante.
Nachdem sich unser Lieblings-Validator eine längere Auszeit genommen hatte, ist der Dienst Validome nun wieder verfügbar. Das Tool prüft HTML-/XHTML- (leider noch ohne die kommende Version 5), WML- und XML-Dokumente, aber auch RSS- bzw. Atom-Feeds und sitemap.xml-Dateien auf ihre Konformität mit den offiziellen Standards.
Die durchgängig deutschsprachige Oberfläche bietet dabei eine sinnvolle Verlinkung der Fehlermeldungen mit Erklärungen in der Referenz SELFHTML. Bei der Prüfung werden eine ganze Reihe Fehler gefunden, die andere Validatoren übersehen – gerade bei typischen Fehlern wie unzulässigen Attributwerten, fehlerhaften Ankern und IDs kann Validome gegenüber anderen Tools punkten. Weitere Infos findet man in der Dokumentation unter »Validator-Features und Fehlerdokumente«.
Immer wieder erreichen uns Anfragen, warum der Webauftritt von ›Einfach für Alle‹ nicht gegen HTML 4 und CSS 2 validiert. Die Antwort ist einfach: Barrierefreiheit ist uns wichtiger als valider Code. EfA setzt auf neue Techniken aus der WAI-ARIA-Spezifikation des W3C, um die Zugänglichkeit unseres Angebots zu verbessern.
Der letzte Arbeitsentwurf der WAI-ARIA stammt vom 15. Dezember 2009. Ähnlich wie bei HTML5 gelten einige der Spezifikation schon als stabil und werden von aktuellen Browsern und Hilfsprogrammen unterstützt.
WAI-ARIA erlaubt unter anderem das Definieren von Orientierungspunkten einer Website: Wichtige Elemente wie die Navigation oder der Inhaltsbereich können eindeutig benannt und angesteuert werden. Bei Formularen erlaubt WAI-ARIA das eindeutige Kennzeichnen von Pflichtfeldern. Die endgültige Version der WAI-ARIA sieht auch das Steuern von Schiebereglern und die Verwendung komplexer AJAX-Anwendungen vor.
Diese Eigenschaften werden auch von aktuellen Browsern wie dem Firefox 3, dem Screenreader Jaws 10 und einigen anderen Browsern und Hilfsprogrammen unterstützt. Auch das am 1. Februar 2010 gestartete neue Portal der Aktion Mensch verwendet bereits WAI-ARIA.
Die derzeit aktuellen Versionen von HTML – HTML 4.01 und XHTML 1.0 – kennen die WAI-ARIA noch nicht, deshalb lassen sich unsere aktuellen Websites nicht validieren.
Die Web Accessibility Initiative (WAI) des W3C hat eine aktualisierte Fassung des Entwurfes zu den Authoring Tool Accessibility Guidelines (ATAG 2.0) veröffentlicht und bittet um Kommentare bis zum 30. November. Wichtige Änderungen gibt es zum Beispiel in dem Punkt, wie Autoren bei der Produktion von barrierefreien Inhalten durch die Autoren-Werkzeuge unterstützt werden sowie eine Überarbeitung der Techniken unter Implementing ATAG 2.0.
ATAG ist wie die beiden anderen WAI-Empfehlungen WCAG und UAAG ein wichtiger Baustein zur Barrierefreiheit. Die Richtlinie beschreibt, wie Autorenwerkzeuge möglichst zugängliche Web-Inhalte produzieren sollten und wie Autoren und Entwickler in ihrer Arbeit durch Werkzeuge wie Editoren und Redaktionssysteme in der Erstellung barrierefreier Inhalte unterstützt werden. Ein wichtiger Aspekt ist auch, dass solche Anwendungen natürlich für Menschen mit Behinderung bedienbar und nutzbar sein sollten.
Das HTML & CSS-Framework YAML, auf dem auch diese Seiten hier aufgebaut sind, ist seit heute in der fertigen Version 3.2 am Start. Erst vor wenigen Tagen konnte das Projekt seinen vierten Geburtstag feiern und auch nach einer so langen Zeit ist die Luft für Verbesserungen und Weiterentwicklungen noch nicht aufgebraucht. Die vorliegende Version 3.2 bringt einige wichtige Änderungen mit sich: neben dem schlankeren Framework-Kern, der Vereinfachung der Code-Basis, der Erweiterung der Gestaltungsraster (sog. Grids) und den Performance-Gewinnen gibt es eine ganze Reihe von Verbesserungen im Bereich der Accessibility, die uns natürlich besonders interessieren.
Barrierefreiheit eingebaut
Kein Framework, auch nicht YAML, ist ein Garant für barrierefreie Webseiten (obwohl eine ganze Reihe von YAML-basierten Sites bereits mit einer BIENE ausgezeichnet wurden). Dennoch zeigt sich mehr und mehr, wie sinnvoll und richtig es ist, Webentwicklern das grundlegende Handwerkszeug innerhalb von Frameworks zur Verfügung zu stellen. In YAML 3.2 wird eine neue Darstellungsmöglichkeit für Skiplinks unterstützt, die ein Überlagern des Layouts für die eingeblendeten Skiplinks ermöglicht und dadurch die sonst üblichen Probleme bei deren Integration beseitigt. Zudem wird für Webkit-basierte Browser ein JavaScript-Fix mitgeliefert, um auch Apple’s Safari und Google Chrome dazu zu bewegen, den Fokus auf die angesprungene ID zu setzen.
Weiterlesen …
Ein weiterer Schritt ist die konsequente Einbeziehung von WAI-ARIA: sämtliche bei YAML mitgelieferte Beispiel-Layouts sind nun mit sog. ARIA-Landmark-Roles versehen. Zwar handelt es sich hierbei nicht wirklich um ein Feature des Frameworks (die korrekte Auszeichnung sollte nach wie vor der Webentwickler vornehmen), dennoch ist dieser Schritt wichtig, um trotz der noch fehlenden Validierungsmöglichkeiten im W3C-Validator die positiven Effekte des kommenden Standards hervorzuheben, denn schon heute können alle modernen Browser (einschließlich des IE 8) mit WAI-ARIA umgehen und ermöglichen somit einen deutlichen Zugewinn an Barrierefreiheit auf Webseiten jeder Komplexitätsstufe.
Das ›Accessible Tabs‹-Plugin von Dirk Ginader wird mit YAML 3.2 als Erweiterung ein fester Bestandteil des Frameworks. Die Umsetzung im Rahmen dieses Plugins ist mittlerweile ausgereift, umfangreich getestet und funktioniert auch hervorragend mit aktuellen Hilfsmitteln wie Screenreadern.
Entsorgung von Altlasten
Manchmal liegt eine Verbesserung auch im Verzicht auf ein Feature: so bot das Framework bisher die Möglichkeit, Spaltenhintergründe mit Hilfe der CSS-border-Definition von bestimmten Spalten zu erzeugen. Zwar ist diese Technik denkbar einfach in der Umsetzung, sie beschwört aber in Verbindung mit den für viele Sehbehinderte typischen Einstellungen von Benutzer-definierten Farben (z.B. den Windows-Kontrastmodi) ein Zugänglichkeitsproblem herauf, da dort Vordergrund- und Rahmenfarben auf den gleichen Farbwert gesetzt werden. Inhalte mit dahinterliegenden farbigen Rahmen (den simulierten Spaltenhintergründen) waren infolgedessen zum Teil nicht mehr lesbar. Erschwerend kam hinzu, dass diese Technik im Internet Explorer ein CSS-Anpassung benötigte, die in seltenen Fällen das Auswählen von Inhalten mit der Maus im Browser blockierte. Daher ist diese Variante nun, auch aufgrund unserer Überzeugungsarbeit, nicht mehr im Framework enthalten.
Neben diesen großen Neuerungen stehen zahlreiche kleinere Korrekturen, über die das Changelog im Detail Ausfunft gibt. Download des Gesamtpakets, Lizenzbedingungen; YAML Dokumentation: Deutsch (PDF), English (PDF)
