Zugänglichkeit für Blinde und Sehschwache

Zugänglichkeit für Blinde
und Sehschwache
Erläuterung einiger Problemfelder und Optimierung von Webseiten für
weniger Barrieren
Seminararbeit, Michael Haschke, 02.07.2005
Universität Leipzig
Institut für Informatik
Lehrstuhl für Angewandte Telematik / e­Business
Prof. Dr. Volker Gruhn
Zugänglichkeit für Blinde und Sehschwache
Inhaltsverzeichnis
Inhaltsverzeichnis..............................................................................................................................2
1 Einleitung und Motivation.............................................................................................................3
2 Problemstellung...............................................................................................................................4
3 Trennung zwischen Inhalt und Layout........................................................................................5
3.1 Syntax und Semantik...............................................................................................................5
3.2 HTML-spezifische nicht-semantische Elemente................................................................7
3.3 Formatierung mit Cascading Style Sheets...........................................................................8
3.4 Multimodale Präsentation......................................................................................................9
4 Reihenfolge von Inhaltsbereichen..............................................................................................11
5 Navigation mit Tastaturbefehlen................................................................................................14
5.1 Relevanz von Tastaturnavigation........................................................................................14
5.2 Aktuelle Möglichkeiten und Probleme...............................................................................15
5.3 Aussicht für die Zukunft.......................................................................................................18
6 Formulare........................................................................................................................................20
6.1 Verhalten und Probleme im Screenreader........................................................................20
6.2 Semantischer Aufbau von Formularen...............................................................................22
6.3 Zukünftige Entwicklungen...................................................................................................24
7 Zusammenfassung und Aussicht................................................................................................25
Glossar........................................................................................................................................
........27
Literaturverzeichnis........................................................................................................................29
Abbildungsverzeichnis....................................................................................................................32
Anhang.....................................................................................................................................
..........33
2
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
1 Einleitung und Motivation
„The power of the Web is in its universality. Access by everyone regardless of disability is an essential
aspect.“ - Tim Berners-Lee, W3C Director and inventor of the World Wide Web [1]
HTML-Dokumente und Web-Applikationen können durch das Internet sehr leicht
weltweit verfügbar gestellt werden. Allerdings kann mensch das Internet nicht nur mit
einem normalen Personalcomputer (PC bzw. Workstation), sondern zunehmend auch mit
Mobiles (PDAs, Handys) oder Fernsehgeräten nutzen. Die meisten dieser Endgeräte sind
für Menschen ohne körperliche oder kognitive Beeinträchtigungen gestaltet.
Menschen
mit
körperlichen
oder
geistigen
Beeinträchtigungen
sind
auf
unterschiedlichste Hilfsmittel bei der Nutzung des Internets angewiesen. Ihnen bleibt
derzeit ein beachtlicher Teil des Internets verschlossen. Wenn mensch davon ausgeht,
dass W3C-Standardkonformität eine der wichtigsten Voraussetzungen für Zugänglichkeit
darstellt (siehe Kapitel 2, WCAG 1.0 Richtlinie 3 und 11), dann wird diese Voraussetzung
von über 90 % derzeit angebotener Internetinhalte im deutschsprachigen Raum nicht
erfüllt [2]. Im Gegensatz dazu stellt das Internet – sofern es zugänglich ist – für viele
dieser Menschen eine weitere Möglichkeit für ihre Selbstständigkeit und Freiheit [6] zur
Verfügung und trägt damit zu einer Steigerung ihrer Lebensqualität bei [5].
In Deutschland wurde 2002 aufgrund des Behindertengleichstellungsgesetzes (BGG) die
Verordnung zur Schaffung barrierefreier Informationstechnik (BITV) erlassen [3], welche
sich in Anforderungen und Bedingungen an den Zugänglichkeitsrichtlinien für WebInhalte 1.0 (Web Content Accessibility Guidelines 1.0, WCAG 1.0) des World Wide Web
Consortiums (W3C) orientiert. Im BGG § 3 steht: „Barrierefrei sind [...] visuelle
Informationsquellen und Kommunikationseinrichtungen sowie andere gestaltete
Lebensbereiche, wenn sie für behinderte Menschen in der allgemein üblichen Weise,
ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe zugänglich und
nutzbar sind.“ [4]
Michael Haschke
3
Zugänglichkeit für Blinde und Sehschwache
In dieser Arbeit werden in erster Linie Methoden vorgestellt und diskutiert, welche
Inhalte für sehschwache und blinde Menschen im Sinne von BITV und WCAG1 zugänglich
machen, ohne für diese Nutzergruppe alternative Versionen dieser Inhalte
bereitzustellen. Diese Methoden können aber auch aufgegriffen werden, um Inhalte oder
Applikationen für NutzerInnen von mobilen Endgeräten zugänglicher zu gestalten [8],
denn diese NutzerInnen sind auch in ihrer Interaktion eingeschränkt, da Handys oder
PDAs nur beschränkte Möglichkeiten für Ein- und Ausgabe bieten.
Es wird nicht oder nur peripher auf weitere Methoden eingegangen, welche
Zugänglichkeit für Menschen ermöglichen, welche farbenblind, körperlich oder kognitiv
eingeschränkt sind. Zudem wird meist nur auf rein technische Aspekte für eine bessere
Zugänglichkeit eingegangen, jedoch kaum auf inhaltliche Verbesserungen für
Webinhalte (wie z.B. eindeutige Bezeichnungen von Links, etc) hingewiesen.
4
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
2 Problemstellung
Was für Sehende kein Problem darstellt, kann für Blinde zum unüberbrückbaren
Hindernis werden. Sie müssen auf jede visuelle Information verzichten. Auch für
Menschen mit starker Sehschwäche können visuelle Informationen aufgrund spezieller
Browser-Einstellungen wegfallen. Viele assistive Programme gehen nicht vom
Idealzustand der maximalen Erfüllung von Standards und Zugänglichkeit bei
Webdokumenten und Applikationen aus, sondern stellen verschiedenste Hilfsmittel zur
Verfügung, um schwer zugängliche Inhalte trotzdem navigierbar zu machen [7].
Trotzdem versagen auch diese Hilfsmittel, wenn Inhalte oder Applikationen nur sehr
unzureichend strukturiert oder sogar falsch ausgezeichnet sind.
Blinde oder sehschwache Menschen sind in ihrer Interaktion mit Webinhalten
eingeschränkt. Sehende können visuell mehrere Informationen gleichzeitig verarbeiten;
sich beispielsweise auf einen Text konzentrieren und nebenbei feststellen, wo sich auf
der Seite die Navigation befindet. Im Gegensatz dazu sind NutzerInnen von assistiven
Programmen in ihrem Fokusbereich sehr eingeschränkt. Eine Bildschirmlupe gestattet nur
die Sicht auf einen sehr begrenzten Teil des Bildschirms und Braille-Browser geben den
Textinhalt nur zeilenweise bis zu einer bestimmten Länge aus. Screenreader oder SprachBrowser können auch nicht mehrere Stellen des Dokumentes gleichzeitig vorlesen.
Aus diesem Grund müssen die Inhalte in ihrer logischen Struktur auf geräteunabhängige
Weise zugänglich gemacht werden. Beim W3C gibt es die Web Accessibility Initiative
(WAI), welche unter anderem Empfehlungen, Anleitungen und Checklisten erarbeitet,
um Zugänglichkeit in den Bereichen Web, Autorensoftware und Nutzer-Agenten (z.B.
Browser) zu unterstützen und zu gewährleisten. Für Webinhalte wurde 1999 die WCAG
1.0 als offizielle Empfehlung herausgegeben. Die WCAG 1.0 Richtlinien erläutern, wie
Webinhalte für Menschen mit Beeinträchtigungen zugänglich gemacht werden können.
Zugleich kann durch Befolgung dieser Richtlinien das Web für alle NutzerInnen
verbessert werden, unabhängig welcher Agent (Desktop-Browser, Screenreader, etc)
genutzt wird oder unter welchen Einschränkungen gearbeitet wird. Die WCAG 1.0
gliedert sich in 14 Richtlinien auf [27]:
Michael Haschke
5
Zugänglichkeit für Blinde und Sehschwache
1. Stellen Sie äquivalente Alternativen für Audio- und visuellen Inhalt
bereit.
2. Verlassen Sie sich nicht auf Farbe allein.
3. Verwenden Sie Markup und Stylesheets und tun Sie dies auf korrekte
Weise.
4. Verdeutlichen Sie die Verwendung natürlicher Sprache.
5. Erstellen Sie Tabellen, die geschmeidig transformieren.
6. Sorgen Sie dafür, dass Seiten, die neue Technologien verwenden,
geschmeidig transformieren.
7. Sorgen Sie für eine Kontrolle des Benutzers über zeitgesteuerte
Änderungen des Inhalts.
8. Sorgen Sie für direkte Zugänglichkeit eingebetteter
Benutzerschnittstellen.
9. Wählen Sie ein geräteunabhängiges Design.
10. Verwenden Sie Interim-Lösungen.
11. Verwenden Sie W3C-Technologien und -Richtlinien.
12. Stellen Sie Informationen zum Kontext und zur Orientierung bereit.
13. Stellen Sie klare Navigationsmechanismen bereit.
14. Sorgen Sie dafür, dass Dokumente klar und einfach gehalten sind.
Zu jeder Richtlinie gibt es eine Liste mit Checkpunkten unterschiedlicher Prioritäten.
Checkpunkte mit Priorität 1 müssen erfüllt werden, sonst ist der Webinhalt für eine oder
mehrere Gruppen nicht zugänglich. Mit Priorität 2 werden Checkpunkte gewertet,
welche erfüllt werden sollten. Ansonsten wird der Zugang erschwert. Priorität 3 sagt aus,
dass diese Checkpunkte erfüllt werden können, um um den Zugriff auf Webdokumente
weiter zu erleichtern. Zusätzlich zur WCAG 1.0 gibt es ein seperates Dokument
„Techniques for WCAG 1.0“, welches Möglichkeiten zur Implementierung der einzelnen
Checkpunkte erläutert. Diese Dokumente und ihre weiteren Anhänge und Ergänzungen
zeigen implizit durch ihre Forderungen und Hinweise auch die Problemstellungen für
eine Verbesserung der Zugänglichkeit für Blinde und Sehschwache auf.
Diese Arbeit wird nicht alle Richtlinien aufgreifen, sondern nur einige Problemfelder
näher betrachten. Dazu gehören:
1. Korrekte Verwendung von Markup und Stylesheets (Richtlinie 3) –
Kapitel 3
6
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
2. Geräteunabhängiges Design (Richtlinie 9)
3. Verwendung von W3C-Technologien und -Richtlinien (Richtlinie 11)
4. Bereitstellung von Informationen zum Kontext und zur Orientierung
(Richtlinie 12) – Kapitel 3, Kapitel 5
5. Einfache Dokumente und klare Navigation (Richtlinie 13 und 14) –
Kapitel 4, Kapitel 5
Diese Themenbereiche können nicht immer direkt einzelnen Kapiteln dieser Arbeit
zugeordnet werden, sondern zumeist greifen mehrere Richtlinien ineinander oder
bedingen sich.
Michael Haschke
7
Zugänglichkeit für Blinde und Sehschwache
3 Trennung zwischen Inhalt und Layout
3.1 Syntax und Semantik
Die einzelnen Elemente des HTML-Markup und ihre Beziehung zueinander werden durch
eine Grammatik (bis XHTML 1.0 durch einfache DTD) spezifiziert. Dadurch ergibt sich die
Syntax, wie HTML-Dokumente aufgebaut sein müssen. Diesen Elemente wird innerhalb
des W3C-Standards informal eine Bedeutung zugeordnet. Diese kann sprachlicher (z.B.
<em> als „hervorgehoben“) oder inhaltlich-struktureller (z.B. <h1> als „Überschrift“)
Natur sein.
Die Validierung von Webdokumenten durch automatische Tools ist ein Teil der
Überprüfung auf Zugänglichkeit – allerdings nur der erste Schritt. Solche Tools sind zwar
schnell
und
meist
einfach
zu
bedienen,
aber
können
nur
wenige
Zugänglichkeitsprobleme wirklich erkennen [9]. So gibt es beispielsweise keinen
automatischen Test, welcher erläuternde Beschreibungen für Bilder gegen die WCAGVorgaben validieren kann. Nur das Vorkommen von Beschreibungen wird evaluiert, aber
Sinnhaftigkeit oder Richtigkeit kann nicht überprüft werden.
<!DOCTYPE HTML PUBLIC "­//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Text des Titels</title>
</head>
<body>
<h1>Dies ist eine Überschrift <p>mit syntaxtisch</p> <div>falschen Bestandteilen</div></h1>
<p>Weder p noch div darf innerhalb von h1 verwendet werden!</p>
</body>
</html>
Abbildung 1: falsche Syntax impliziert falsche Semantik
Ein Bespiel ist der W3C HTML Validator, welcher Webdokumente gegen die Grammatik des
angegebenen Doctypes validiert. Der Validator kann die Syntax auf Fehler untersuchen,
aber nicht die Semantik kontrollieren, ausser bei den Fällen, in denen falsche Syntax eine
falsche Semantik impliziert (Abbildung 1).
8
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
AutorInnen von Webdokumenten stehen somit in der Verantwortung, die einzelnen Teile
sematisch korrekt auszuzeichnen. Sie wissen, ob z.B. der als Überschrift ausgezeichnete
Text auch wirklich eine Überschrift im Kontext des Dokumentes ist. Ein Validator würde
die HTML-Dokumente in Abbildung 2 und 3 beide als valide gegenüber der angegebenen
HTML-DTD bezeichnen. Semantisch unterscheiden sich diese Dokumente, wobei
Abbildung 2 das falsch ausgezeichnete Dokument darstellt.
<!DOCTYPE HTML PUBLIC "­//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Abbildung 02</title>
</head>
<body>
<p>
<b>Überschrift 1</b>
<br/><br/>
Diese Ueberschriften werden nur mit praesentations­orientierten Markup beschrieben.
<br/><br/>
<i>Überschrift 1.1</i>
<br/><br/>
Sie stellen aber semantisch keine Ueberschriften dar. </p>
</body>
</html> Abbildung 2: Präsentation statt Semantik – valide, aber falsch
Visuell könnte mensch die unterschiedlichen Teile erkennen und interpretieren, aber ein
Screenreader kann nur bei Abbildung 3 die einzelnen Teile durch ihre angegebene
Semantik erkennen und somit korrekt wiedergeben. Zudem würde bei Abbildung 2 auch
ein weiterer Mechanismus der Screenreader fehlschlagen. Viele der oft genutzten
Screenreader
und
Sprachbrowser
bieten
Funktionen
zur
Generierung
von
Überschriftenlisten. Diese nutzen AnwenderInnen, um sich einen generellen und
schnellen Überblick über die Themen und den Aufbau der Seite zu verschaffen, und um
über diese Liste zu navigieren. Wenn nun Überschriften nicht als solche ausgezeichnet
sind, wird die Zugänglichkeit zu den Inhalten des Dokumentes oder der Applikation
natürlich erheblich erschwert [6].
Michael Haschke
9
Zugänglichkeit für Blinde und Sehschwache
<!DOCTYPE HTML PUBLIC "­//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Abbildung 03</title>
</head>
<body>
<h1>Überschrift 1</h1>
<p>
Dies ist ein einleitender Text, um danach auf die Unterthemen zu kommen.
</p>
<h2>Überschrift 1.1</h2>
<p>
Und hier geht es weiter im Text, es wird nun ein Unterkapitel beschrieben.
</p>
</body>
</html>
Abbildung 3: valider HTML­Code sollte auch semantisch korrekt sein
Desweiteren sollen keine mit semantischen Informationen belegte Markup-Elemente für
optische Präsentation gebraucht werden – z.B. das Verwenden von ÜberschriftenMarkup, um Textabschnitte besonders fett hervorzuheben – denn dies bringt genau die
gleichen Probleme für Screenreader-NutzerInnen mit sich.
Somit empfielt die WCAG 1.0 in Richtlinie 3 auch: „Verwenden Sie Markup und
Stylesheets und tun Sie dies auf korrekte Weise.“
3.2 HTML­spezifische nicht­semantische Elemente
Aus verschiedenen Gründen wurde HTML in seiner Geschichte immer wieder direkt oder
indirekt
mit
präsentationsorientierten
Elementen
erweitert,
welche
keinen
semantischen Bedeutung hatten bzw. dieser nur visuell zu erfassen war [10]. Auch in
HTML 2.0 vom 22. September 1995 finden sich schon Elemente, welche sogar in der
Spezifikation als typografisch – also zur Präsentation von Textteilen – bezeichnet
werden.
Dies sind und waren Elemente wie <b> (bold, fett), <i> (italic, kursiv) und <tt> (teletype, unproportional), später kamen noch <u> (underlined, unterstrichen) oder
<strike> (striked, durchgestrichen) hinzu. Alle diese Elemente transportieren keine
Sematik, sondern formatieren Text visuell. Ein Screenreader oder ein anderes
Ausgabegerät kann diese Elemente nur dann interpretieren, wenn es um den
angedeuteten semantischen Inhalt weiss.
10
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
Die
Rückbesinnung
auf
Markup
für
Semantik
ist
eine
Ursache,
warum
präsentationsorientierte Elemente im aktuellen Working Draft von XHTML 2.0 nicht
mehr vorkommen. Somit gibt es mehrere Gründe, weshalb mensch solche
Auszeichnungen nicht verwenden sollte. Das Dokument wird unzugänglicher für
verschiedene Nutzergruppen, desweiteren ist eine Verwendung auf absehbare Zeit nicht
zukunftssicher.
Besser ist es, Textauszeichnungen mit sematischen Informationen wie – bezugnehmend
auf die zuvor aufgeführten Beispiele – „hervorgehoben“ oder „stark hervorgehoben“ zu
verwenden. In aktuellen (X)HTML Versionen gibt es dafür Elemente wie <em> (emphasis) oder <strong> (strong emphasis).
3.3 Formatierung mit Cascading Style Sheets
Vorweg: dieses Kapitel dient nicht zur Einführung in Cascading Style Sheet (CSS) Syntax
und Technik. Es wird nicht gezeigt wie mächtig CSS in seinen Möglichkeiten ist, um
Einfluss auf visuelle und akustische Präsentation auszuüben. Es wird nur demonstriert,
das Inhalt und Layout komplett trennbar ist.
Wenn Webdokumente oder -applikationen entworfen werden, sollte zuerst die Struktur
entwickelt werden und erst im Anschluss die Präsentation erfolgen. Dies ist wichtig, da
die Präsentation nicht unbedingt grafisch, sondern auch akustisch erfolgen kann. Auf die
multimodale Präsentation wird in Kapitel 3.4 näher eingegangen. Eine klare Struktur
unabhängig von der Präsentation bedeutet in jedem Fall eine bessere Zugänglichkeit,
unabhängig vom Nutzer-Agenten [11]. Die WCAG 1.0 drückt es in Checkpoint 3.3 mit „Use
style sheets to control layout and presentation“ aus.
Für Webdokumente, welche auf (X)HTML aufbauen, kann CSS genutzt werden. Speziell
für akustische Ausgaben entworfene Stylesheets nennen sich Aural Cascading Style
Sheets (ACSS). Stylesheets werden vom HTML-Dokument referenziert und sorgen für die
Präsentation der einzelnen Elemente. Dies betrifft nicht nur evtl. Schriftarten und
-farben, sondern auch visuelle Anordnung der einzelnen Seitenbereiche. Dies ist
natürlich für NutzerInnen von Screenreadern nicht von Bedeutung, zeigt aber, dass
alternative Seiten speziell für diese NutzerInnen nicht nötig sind. Gleicher Inhalt kann
durch Stylesheets auf unterschiedliche Art – visuell, akustisch oder taktil – präsentiert
werden.
Michael Haschke
11
Zugänglichkeit für Blinde und Sehschwache
Um ein gewünschtes CSS zu referenzieren gibt es verschiedene Möglichkeiten, eine
davon funktioniert über das Einfügen folgenden Codes im Kopfbereich des HTMLDokumentes:
<link rel="stylesheet" href="style.css" type="text/css" />
In der referezierten CSS Datei kann dann beispielsweise sehr einfach Einfluss auf die
Präsentation einer Überschrift genommen werden:
/* Beispiel fuer eine visuelle Praesentation einer Ueberschrift */
@media screen {
h1 { font­family: serif; color: red; font­size: 20em; }
}
/* Beispiel fuer eine akustische Praesentation einer Ueberschrift */
@media speech {
h1 { voice­family: paul, male; stress: 20; richness: 90; }
}
Nachfolgend soll die Verknüpfung ein und desselben Webdokumentes mit verschiedenen
Stylesheets demonstriert werden. An dieser Stelle kann dies nur visuell verdeutlicht
werden. Das Beispiel besteht aus einer kleinen Navigation und dem eigentlichen Inhalt,
welcher verschiedene Überschriften und Textabschnitte enthält. Abbildung 4 stellt die
unterschiedlichen Präsentationen im Browser dar. Die ausführlichen Quellcodes des
Beispiels und seinen verschiedenen Stylesheets von Abbildung 4 befinden sich im
Anhang.
Abbildung 4: XHTML­Dokument ohne und mit Stylesheets
Wie Abbildung 4 zeigt, kann die Präsentation durch Stylesheets auf unterschiedlichste
Art erfolgen. Es ist nicht nötig, semantisch falsch eingesetzte Syntax für die Präsentation
zu nutzen. Zudem wird durch die Verwendung von CSS ein Syntax-Overhead im
Webdokument vermieden. Dadurch wird dieses einfacher in seiner Struktur und somit
auch zugänglicher.
12
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
Einer der wichtigsten Vorteile von Stylesheets ist, dass diese durch die NutzerInnen mit
eigenen Stylesheets überschrieben werden können. Dies ist wichtig für die
Zugänglichkeit der Webinhalte. In ihrer Sehfähigkeit sehr eingeschränkte Menschen
können Dokumenten ihre persönlichen Stylesheets zuweisen, womit sie die Kontrolle
über Schriftgrössen, -effekte, Farben und Kontraste haben. Durch Sehschwäche oder
Farbenblindheit können Informationen wegfallen. Dies wird durch eigene Stylesheets
ausgeglichen, da die Dokumente für das jeweilige Problem angepasst werden können.
3.4 Multimodale Präsentation
Wie eingangs schon erwähnt, werden Webinhalte nicht nur mit normalen PCs genutzt,
sondern auch mit Mobiles, TV-Geräten, Projektoren, Terminals, Druckern und assistiven
Geräten
wie
Screenreadern,
Braille-Zeilen
und
Braille-Druckern.
Multimodale
Präsentation ist wichtig, denn diese verschiedenen Geräte können theoretisch beliebig
kombiniert werden. Praktisch werden in Deutschland oft Screenreader und Braille-Zeilen
zusammen eingesetzt. Zusätzlich soll das Webdokument vielleicht noch gedruckt
werden.
In Zukunft werden Anwendungen mit der Möglichkeit multimodaler Interaktion immer
wichtiger. Multimodale Interaktion erlaubt die dynamische Auswahl der bestmöglichen
Interaktion mit der Webapplikation [12]. Eingaben könnten beispielsweise per Maus,
Tastatur, Handschrift oder Sprache geschehen. Dies setzt natürlich multimodale
Präsentation zwingend voraus.
Mit CSS können Inhalte nicht nur visuell auf PC-Monitoren oder akustisch präsentiert
werden, sondern es können auch spezielle Angaben zur Präsentation auf Druckern oder
schlecht auflösenden Displays formuliert werden. In CSS 2 existieren derzeit neun
unterschiedliche Medientypen, um Angaben für die unterschiedlichen Ausgabegeräte zu
treffen. In zukünftigen Versionen von CSS könnte diese Typenliste erweitert werden [13].
Diese Typen werden nach ihren Eigenschaften bestimmten Mediengruppen zugeordnet.
Abbildung 5 zeigt eine Zusammenfassung aus dem aktuellen W3C-Dokument.
Michael Haschke
13
Zugänglichkeit für Blinde und Sehschwache
Abbildung 5: Beziehung zwischen Medientypen und ­gruppen
Die Mediengruppen beschreiben das Seitenformat (fortlaufend, seitenorientiert), das
Ausgabeformat (visuell, akustisch, taktil), Rasterung (Zeichenraster oder bitmap) und die
Interaktionsmöglichkeiten (interaktiv, statisch).
Es gibt mehrere Möglichkeit, um CSS für die verschiedenen Medientypen einzubinden,
eine davon ist die Erweiterung des Codes aus Kapitel 3.3 durch das media-Attribut:
<link rel="stylesheet" href="style.css" type="text/css" media=“screen“ />
Dadurch können Webinhalte mit Stylesheets für verschiedene Medientypen verbunden
werden. Für jeden Typ kann das entspreche Stylesheet auf obige Art und Weise
angegeben werden:
<link rel="stylesheet" href="aural.css" type="text/css" media=“speech“ />
<link rel="stylesheet" href="print.css" type="text/css" media=“print“ />
<link rel="stylesheet" href="braille.css" type="text/css" media=“braille,embossed“ />
Somit kann das Beispieldokument aus Kapitel 3.3 erweitert werden, um einen sinnvollen
Ausdruck zu ermöglichen – beispielsweise ist eine Navigation in der Druckversion nicht
nötig. Ausserdem ist Serifenschrift auf Papier besser zu lesen. Diese Unterschiede in der
Präsentation werden durch ein speziellen CSS ermöglicht, Abbildung 6 zeigt wiederum
genau dasselbe Dokument, welches auch schon in Abbildung 4 auf unterschiedliche Art
präsentiert wurde.
14
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
Abbildung 6: Beispieldokument in der Druckvorschau
Das Dokument könnte auch um entsprechende Stylesheets für die Ausgabe durch
Screenreader, Braille-Browser und Braille-Drucker ergänzt werden. So kann die Ausgabe
auf diesen Geräten an den Inhalt des jeweiligen Dokumentes angepasst werden. So sollte
der Text einer Kondolenzbekundung anders vorgelesen und betont werden als der
Bericht über eine Sommerreise.
Michael Haschke
15
Zugänglichkeit für Blinde und Sehschwache
4 Reihenfolge von Inhaltsbereichen
Webseiten
bestehen
zumeist
aus
verschiedenen
Teilbereichen.
Dies
könnten
beispielsweise der Kopfbereich mit Firmenzeichen, die Haupt- und Subnavigation, der
Bereich
für
den
eigentlichen
Inhalt,
ein
weiterer
Subinhaltsbereich
mit
Nebeninformationen, ein Suchformular und weitere Bereiche unterschiedlichsten Inhalts
sein. Eine spezielle visuelle Anordnungen dieser Unterbereiche des Dokumentes ist bei
kleinen Displays oder Screenreadern nicht möglich. Auch für NutzerInnen von
Bildschirmlupen gehen visuell grossflächige Anordnungen verloren, da nur kleine Teile
des Bildschirms gleichzeitig betrachtet werden können.
Die WCAG 1.0 fordert klare Navigationsmechanismen (Richtlinie 13) und klar und einfach
gehaltetene Dokumente (Richtlinie 14). Die einzelnen Bereiche der Webseiten sind
sequentiell nacheinander in dem entsprechenden HTML-Dokument angeordnet. Dies
bedeutet, dass auch eine lineare Ausgabe – zum Beispiel durch einen Screenreader oder
Textbrowser – der Inhalte einen logischen Sinn ergeben und möglichst einfach
navigierbar sein muss.
Jakob Nielsen nennt dies 2-D- und 1-D-Layout [24]. Ein Bildschirm kann Inhalte zweidimensional (2-D) präsentieren, während eine akustische Präsentation nur eindimensional ist (1-D). An dieser Stelle wird auch deutlich, warum eine Trennung
zwischen Struktur und Layout (bzw. zwischen Inhalt und Präsentation) unbedingt
notwendig ist. Laut Nielsen ist ein linearisiertes 2-D Layout nicht in dem Maße nutzbar
wie ein explizit entwickeltes 1-D Layout. Somit sollte zuerst die Struktur des Dokumentes
erarbeitet werden, denn ein gutes 1-D Layout ergibt sich fast automatisch aus einer guten
Struktur ergänzt um Methoden, welche den schnellen Zugang zu den einzelnen Teilen
des Dokumentes ermöglichen. Mit Hilfe von CSS kann ein 1-D Layout später in ein 2-D
Layout transformiert werden.
16
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
Eine gute Dokumentenstruktur zeichnet sich dadurch aus, dass besonders wichtige Teile
auch am schnellsten erreicht werden können. Auch 2-D Layouts sind meist so angelegt,
dass NutzerInnen die wichtigsten Teile – zum Beispiel den Hauptinhalt - durch geeignete
Darstellung in Grösse und Platzierung sehr schnell fokusieren können. Somit sollten
genau diese Teile am Anfang des Dokumentes stehen [24]. Dass heisst, Hauptnavigation
und Hauptinhalt sollten sich in der Struktur ganz oben befinden. So könnte eine
geeignete Reihenfolge sein:
1. Firmenbezeichnung/Logo (damit klar ist, bei wem mensch sich
befindet)
2. Hauptnavigation
3. Hauptinhalt
4. Subnavigation
5. Subinhalt
Dies ist natürlich nur eine Möglichkeit, konkret könnte beispielsweise auch die
Reihenfolge von Subnavigation und -inhalt getauscht sein, je nachdem wie umfangreich
die Subbereiche sind und wie sie inhaltlich gewertet werden. Desweiteren kann die
Struktur auch wesentlich komplexer werden, wenn weitere Bereiche (z.B. für Werbung)
hinzukommen. Daran wird auch deutlich wie wichtig es ist, zuerst die Struktur zu
entwickeln. Während dieser Entwicklung müssen Überlegungen angestellt werden,
inwieweit die Struktur vereinfacht werden kann; zum Beispiel ob ein Suchformular ein
einzelnen Bereich darstellen soll oder ob es in die Sub- oder Hauptnavigation integriert
werden kann.
Abbildung 7: Struktur eines Dokumentes im 1­D und 2­D Layout
Michael Haschke
17
Zugänglichkeit für Blinde und Sehschwache
Abbildung 7 zeigt, wie ein 1-D Layout in ein 2-D Layout transformiert werden könnte. Auf
diese Weise sind ansprechende grafische Layouts für normal sehende Menschen möglich.
Gleichzeitig ist derselbe Inhalt auch für Blinde, Sehschwache oder anderen NutzerInnen
von Textbrowsern gut zugänglich. Leider zeigen andere Beispiele, dass es bei Wahl einer
anderen inhaltlichen Struktur nicht immer so einfach oder teilweise sogar unmöglich ist,
ein optimal angepasstes 1-D Layout in ein optimales 2-D Layout zu transformieren [25].
Wie schon erwähnt, muss die Struktur um geeignete Navigationsmechanismen ergänzt
werden, um ein wirkliches 1-D Layout zu erreichen. Skip-Links ermöglichen das
schnellere Navigieren innerhalb einer Seite [26], da mensch durch sie direkt zu den
einzelnen Teilen der Struktur springen kann.
<ul id=”skip”>
<li><a href=“#inhalt“>direkt zum Inhalt springen</a></li>
<li><a href=“#subnavi“>zum Untermenu springen</a></li>
</ul>
<div id=“kopf“> ... </div>
<div id=“navigation“> ... </div>
<div id=“inhalt“> ... </div>
<div id=“subnavi“> ... </div>
<div id=“subinhalt“> ... </div>
Natürlich können auch zwischen den einzelnen Bereichen weitere Skip-Links eingefügt
werden, welche den Sprung an den Seitenanfang oder zurück zur Navigation
ermöglichen. Hier gilt es, ein geeignetes Maß zu finden, denn zuviele Links dieser Art
sind der Zugänglichkeit nicht förderlich, da sie verwirren und zudem die natürliche
Struktur des Dokumentes überlagern. Allerdings ist es für blinde NutzerInnen sehr
wichtig, die Strukur des Dokumentes zu kennen, um sich besser orientieren zu können.
Skip-Links können bei der Transformation vom 1-D zu 2-D Layout mit Hilfe von CSS nicht
sichtbar präsentiert werden. Diese so verborgenen Links sollten allerdings zumindest
sichtbar sein, wenn sie fokusiert wurden.
Die WCAG 1.0 fordert für eine bessere Zugänglichkeit eine kosistente Präsentation
(Checkpoint 14.3: „Create a style of presentation that is consistent across pages“) und
Navigation (13.4: „Use navigation mechanisms in a consistent manner“). Deshalb sollte
die einmal entwickelte Struktur und Navigation auf den einzelnen Seiten des
Webinhaltes beigehalten werden.
18
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
5 Navigation mit Tastaturbefehlen
5.1 Relevanz von Tastaturnavigation
Webinhalte sollten nicht nur durch optische Eingabegeräte wie Maus oder Tablets
steuerbar sein, sondern auch durch Tastaturbefehle nutzbar gemacht werden. Blinde
NutzerInnen sind auf eine Navigation über eine Tastatur (Keyboard) angewiesen. Auch
andere Nutzergruppen müssen über die Tastatur navigieren, da weitere Eingabegeräte
nicht zur Verfügung stehen oder nicht bedient werden können. Die Forderung nach der
Zugänglichkeit für verschiedene Eingabegeräte – insbesondere der Tastatur – ist auch in
der WCAG und den verschiedenen gesetzlichen Richtlinien (z.B. BITV) festgeschrieben.
Tastaturnavigation bedeutet, dass es durch Tastenanschläge oder Kombination von
Tasten möglich ist, durch den Inhalt der Website zu navigieren; zum Beispiel das
Anwählen von Links oder um den Fokus auf ein Formularelement zu setzen. Grafische
Browser bieten zumeist nur rudimentäre Möglichkeiten für eine solche Navigation.
Screenreader besitzen aufgrund ihres Einsatzgebietes natürlich wesentlich mehr
Funktionalität,
um
mit
der
Tastatur
zu
navigieren.
Diese
browser-
bzw.
screenreaderinterne Lösung hat den Nachteil, dass sich die Tastaturbefehle
herstellerabhängig unterscheiden. Somit könnte sich die gewohnte Navigation ändern,
sobald sich der Arbeitsplatz und die damit vorhande Software ändert.
Somit sollte die Logik der Navigation nicht vom Nutzeragenten, sondern vom Webinhalt
selber gestellt werden. Dann ist die Navigation – speziell die verwendeteten Tastenkürzel
(Shortkeys bzw. Hotkeys) – theoretisch immer gleich, unabhängig wo auf den Webinhalt
zugegriffen wird. Um direkt vom Webinhalt die Navigation über Tastatur zu beeinflussen,
kann auf Accesskeys und Tabindex zurückgegriffen werden. Accesskeys bedeutet die
Verknüpfung von bestimmten Seitenelementen (z.B. Links) mit Tastenkürzeln (z.B. „h“
für den Link zu „Home“). Mit Tabindex kann festgelegt werden, in welcher Reihenfolge
die verschiedenen Elemente durch die Tabulatortaste fokussiert werden.
Michael Haschke
19
Zugänglichkeit für Blinde und Sehschwache
Betriebssystem
Browser
Tastenkombination
Windows
MS Internet Explorer
Alt + Accesskey + Enter
Windows
Mozilla/Firefox/Netscape
Alt + Accesskey
Windows
Opera
Shift + Esc + Accesskey
Macintosh
MS Internet Explorer
Strg + Accesskey + Enter
Macintosh
Mozilla/Firefox/Netscape
Strg + Accesskey
Macintosh
Opera
Shift + Esc + Accesskey
Macintosh
Safari
Strg + Accesskey
Linux
Mozilla/Firefox/Netscape
Alt + Accesskey
Linux
Galeon
Alt + Accesskey
Alle BS
Amaya
Strg + Accesskey
Abbildung 8: Accesskeys in verschiedenen Browsern
Accesskeys können in den verschiedenen Browsern über Tastenkombinationen
aufgerufen werden, in Abbildung 8 sind einige Browser und deren Kombinationen
aufgelistet. Leider muss an dieser Stelle schon vorweg genommen werden, dass nicht alle
Browser Accesskeys unterstützen [14].
5.2 Aktuelle Möglichkeiten und Probleme
Accesskeys können auf einfache Weise hinzugefügt werden:
<a href=“/index.html“ accesskey=“s“>Startseite</a>
Leider kann so nicht jedem Element ein Accesskey zugewiesen werden sondern nur Links
(<a>), Teilen von Imagemaps (<area>) und Bestandteilen von Formularen (<input>,
<textarea>, <label>, <legend>, <button>). Somit ist es nicht möglich, direkt
auf den Hauptinhalt zu verweisen, ausser dieser beginnt mit einem dieser Elemente.
Ansonsten muss der Umweg über einen Skip-Link gewählt werden:
<a href=“#hauptinhalt“ accesskey=“i“>direkt zum Inhalt springen</a>
<!­­ [...] ­­>
<div id=“hauptinhalt“>
...
</div>
20
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
Wesentlich schwerwiegender ist es, dass es momentan keinen internationalen Standard
für die Verwendung von Accesskeys gibt, an welchen sich Hersteller von Nutzeragenten
und Webapplikationen orientieren könnten. Bei Verwendung von Accesskeys durch die
Webapplikation kann es dadurch zu Konflikten mit dem Nutzeragenten kommen, wenn
beide gleiche Kürzel verwenden. In vielen Online-Quellen wird beschrieben, dass
Accesskeys die browserinternen Tastenkürzel überschreiben, zumindest für Firefox
konnte dies durch einen Test bestätigt werden. Nach einer nicht-wissenschaftlichen
Studie von WATS.ca (Web Accessibility Testing and Services) sind die einzigsten freien –
damit theoretisch verwendbaren – Kürzel folgende: „/“ (slash), „\“ (backslash) und „]“
(right square bracket) [14]. Aus diesem Grund werden Accesskeys von den kanadischen
Zugänglichkeitsrichtlinien momentan nicht empfohlen [15].
Die wenigsten Überschneidungen gibt es laut dieser Studie mit numerischen
Tastenkürzeln. Zudem bieten numerische Kürzel den Vorteil, dass sie fast unabhängig
von Sprachen, Kulturkreis und verwendeten Schriftzeichen sind. Auch einige der
vorhandenen Empfehlungen basieren auf solchen Kürzeln. Beispielsweise schreibt
Grossbritannien in seinen Richlinien für Zugänglichkeit Accesskeys vor [16], an welche
sich zum Beispiel auch grosse Seiten wie GMX orientieren [17]. Somit ist es derzeit zu
empfehlen, sich bei Verwendung von Accesskeys an den britischen Standard zu halten:
•
S - Navigation überspringen
•
1 - Homepage (Startseite)
•
2 - Was ist neu
•
3 - Sitemap (Inhaltsübersicht)
•
4 - Suche
•
5 - Häufig gestellte Fragen (FAQ)
•
6 - Hilfe
•
7 - Beschwerden
•
8 - Bestimmungen und Bedingungen (AGB)
•
9 - Feedbackformular
•
0 - Accesskeyübersicht
Neben der Möglichkeit, dass viele NutzerInnen ohne Einschränkungen auch über
Tastatur navigieren wollen (bzw. müssen bei Textbrowsern wie Lynx), benutzen viele
Sehschwache nicht unbedingt einen Screenreader, sondern einen normalen grafischen
Browser und eine Bildschirmlupe. Somit sind nicht nur Accesskeys in normalen
Michael Haschke
21
Zugänglichkeit für Blinde und Sehschwache
grafischen Browsern wichtig, sondern auch ihre Darstellung ist relevant. Bisher Erstellen
nur sehr wenige Browser Übersichten über vorhandene Accesskeys. Deshalb sollte vom
entsprechenden Webinhalt auf vorhandene Accesskeys hingewiesen werden. Hierfür gibt
es verschiedene Möglichkeiten, wobei dadurch auch negative Auswirkungen für
NutzerInnen von Screenreadern entstehen können. Dies muss natürlich vermieden
werden.
Auf einigen Webseiten werden Accesskeys visuell dargestellt, indem die Tastenkürzel in
den entsprechenden Links unterstrichen oder schräggestellt werden. Es ist nicht
relevant, ob dies mit präsentationsorientiertem Markup (z.B. <u>S</u>tartseite)
oder mit semantisch besseren Konstrukten (z.B. E<em>x</em>tras) erreicht wird.
Diese Technik bricht das Wort für Screenreader und Textbrowser in mehrere Teile auf.
Screenreader interpretieren E<em>x</em>tras nicht als Extras, sondern als E x tras. Dadurch wird das Wort auch nicht korrekt vorgelesen, sondern als E­Pause­X­
Pause­Tras. Dies ist natürlich ein grosser Nachteil für Zugänglichkeit, da der normale
Sprachfluss gestört wird [19]. Zugleich sind hier fast nur nicht-numerische Zeichen als
Accesskeys möglich.
Eine weitere Möglichkeit ist die Angabe des Accesskeys vor oder nach dem Link, z.B. (6) Hilfe bzw. Hilfe (6). Diese Auszeichnung kann auf verschiedene Art und Weise
erreicht werden. Die schnellste, aber zugleich auch ungünstige Variante wäre:
<a href=“/hilfe.html“ accesskey=“6“>Hilfe (6)</a>
Visuell wird „(6)“ nur als zusätzliche Information wahrgenommen, es stört nicht
unbedingt beim Lesen. Ein Screenreader würde immer etwas wie Klammer­auf­
Sechs­Klammer­zu vorlesen, ohne dass dadurch deutlich würde, dass es sich hierbei
um die Angabe des Accesskeys handelt. Zumal im Screenreaders der Link auf gewohnte
Weise während des Vorlesens ausgelöst werden kann; und Screenreader auch Linklisten
extrahieren. Im obigen Beispiel ist fehlerhaft, dass Inhalt nicht von Präsentation
getrennt wurde, indem „(6)“ direkt zum Linktext hinzugefügt wurde. Korrekter wäre:
<a href=“/hilfe.html“ accesskey=“6“>Hilfe</a>
Auch hier kann der Accesskey in Klammern vor- oder nachgestellt angegeben werden.
Möglich ist dies durch CSS 2:
22
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
/* Nachstellen der Klammerbemerkung */
a:after { content:“ (“attr(accesskey)“)“; }
Dies hat mehrere Vorteile. Zum einen kann auf die Präsentation noch mehr Einfluss
geübt werden, beispielsweise die Angabe der Klammerbemerkung nur bei bisher noch
nicht genutzten Links. Weiter ändert sich die Klammerbemerkung, sobald der Accesskey
geändert wird. Die Klammerbemerkung muss nicht zusätzlich noch editiert werden. Ein
sehr grosser Nachteil dieser Methoade ist natürlich, dass dies nur in Browsern
funktioniert, welche CSS 2 unterstützen.
Ausgehend vom britischen Standard kann auch die Methode einer gesonderten Seite mit
Informationen zu den vorhandenen Accesskeys genutzt werden. Dafür wird eine Seite
mit einer Übersicht global verwendeter Accesskeys inklusive zusätzlich wichtigen
Informationen (bspw. Übersicht für Accesskeynutzung in den verschiedenen Browsern).
Diese Seite muss dann jeweils verlinkt werden, der britische Standard schlägt dafür
gleich Accesskey 0 (Null) vor. Diese Methode funktioniert immer, hat natürlich den
Nachteil, dass zuerst eine weitere Seite aufgerufen werden muss, um an Informationen
über die Accesskeys zu gelangen.
Alle bisher vorgestellten Methoden zur Anzeige der Accesskeys besitzen einen
gemeinsamen Nachteil. Falls ein Browser genutzt wird, welcher von sich aus Accesskeys
in irgendeiner Form anzeigt, führen diese Methoden zu redundanten Informationen.
Ausserdem – ausgehend vom britischen Standard – sind nur bestimmte globale Bereiche
per Accesskey definierbar, aber nicht die auf jeder Seite unterschiedlichen
weiterführenden Links oder kleineren Subbereiche. Dafür gibt es neben den Accesskeys,
eine weitere Möglichkeit, um die Navigation mit der Tastatur zu ermöglichen. Dazu wird
für die verschiedenen Links ein Tabindex definiert, in welcher Reihenfolge die Links mit
der Tabulatortaste angesprungen werden. Die Angabe von tabindex ist auch nicht für
alle HTML-Elemente möglich, sondern nur für die Elemente, für welche auch Accesskeys
definiert werden können.
Es können zwei verschiedene Tabindex-Arten unterschieden werden. Zum einen der
natürliche Tabindex, welcher sich durch die sequentielle Sprungfolge von Link zu Link
ergibt, ohne dass für die Links ein Tabindex angegeben wurde. Dies ist in soweit allen
aktuellen Browsern möglich. Der natürliche Tabindex startet von der zuletzt
angesprungen Sprungmarke bzw. vom Dokumentenanfang.
Michael Haschke
23
Zugänglichkeit für Blinde und Sehschwache
Desweiteren kann ein echter Tabindex angelegt werden, indem Links um ein
tabindex-Attribut erweitert werden:
<a href=“#sprungziel“ tabindex=“1“>Sprungziel</a>
Dabei kann kann ein tabindex im Bereich zwischen 0 und 32767 angegeben werden.
Normalerweise sollten nun die so ausgezeichneten Links in angegebener Reihenfolge
angesprungen werden. Leider scheint die wirkliche Implementierung dieser Funktion in
den verschiedenen Browsern zu unterschiedlichen Ergebnissen zu führen, wenn die
angebenen Indizes nicht ihrer logischen Reihenfolge entsprechen, also ein Link mit
tabindex=“1“ im Dokument nach einem Link mit tabindex=“3“ folgt. Der
Internet Explorer ab Version 5.5 folgt in diesem Fall dem weiteren natürlichen Tabindex
oder springt zum Link mit nächstgrössten Index, welches auch logisch im Dokument
folgt. Dagegen würde ein Gecko-basierter Browser (z.B. Mozilla) strikt dem echten
Tabindex folgen und somit im Dokument zurückspringen [18]. Visuell ist ein Rücksprung
nicht so sehr das Problem, da mensch sieht, wenn er im Dokument zurückspringt.
Allerdings können Blinde oder sehr Sehschwache in ihrer Orientierung auf der Seite
extrem gestört werden.
Insofern ist die Nutzung von tabindex oft kontraproduktiv, um mehr Zugänglichkeit
zu erreichen. Ein Workaround könnte sein, dass Accesskeys und natürlicher Tabindex
miteinander kombiniert werden. Dazu werden Sprunglinks (z.B. direkt zum Inhalt oder
direkt zur Navigation) eingerichtet, welche per Accesskey steuerbar sind. Danach kann
mit Hilfe des Browsers über den natürlichen Tabindex weiternavigiert werden.
Förderlich für die Zugänglichkeit kann der Einsatz von tabindex bei Formularen sein, dies
wird später in einem Extra-Kapitel in dieser Arbeit erläutert.
5.3 Aussicht für die Zukunft
Die aktuellen Diskussionen über Accesskeys kommen meist zum Schluss, dass die
dahinterstehenden Überlegungen über den Zweck sehr gut sind, aber die Umsetzung
fehlgeschlagen ist1. Momentan gibt es bei Accesskeys (und auch bei Tabindex) zuviele
praktische Probleme.
1 als Beispiel: http://www.access­matters.com/2005/04/15/quiz­211­are­access­keys­useful/
24
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
Im aktuellen Working Draft zu XHTML 2.0 [20] werden andere Methoden vorgeschlagen,
um eine geräteunabhängige Zugänglichkeit zu gewährleisten. Accesskeys in der
bisherigen Form wird es nicht mehr geben. Die Möglichkeiten sind vielfältiger, auch
wenn einige genauso problembehaftet wie die bisherigen Accesskeys sind.
Neben Ids kann den Elemente auch eine Rolle zugeordnet werden [21], z.B.:
<div id=“inhalt“ role=“content“> <!­­ ... ­­> </div>
Accesskeys werden nun im Kopfbereich der HTML-Struktur definiert [21] :
<head>
<access targetrole=“content“ key=“S“ title=“direkt zum Inhalt springen“ />
</head>
Es kann auch <access targetid=“inhalt“ key=“S“ /> verwendet werden.
Wenn für ein Element eine Rolle und eine Id angegeben wurde, soll laut W3C
targertid höher gewertet werden. Da hier aber wieder auf Eingaben der Tastatur
zurückgegriffen wird, birgt diese Methode exakt dieselben Probleme wie bei den aktuell
möglichen Accesskeys. Der einzigste Vorteil dieser Methode gegenüber den derzeitigen
Accesskeys besteht darin, dass jetzt alle Elemente per Tastenkürzel fokusiert
beziehungsweise angewählt werden können.
Eine weitere und etwas abstraktere Methode ist die Definition des access-Attributes
für bestimmte Elemente [22] :
<input type=“text“ access=“search“ />
Dieses Attribut erlaubt das schnelle Fokusieren von wichtigen Teilen des Webinhalts
durch z.B. Tastenkürzel. Allerdings ist es noch offen, wie genau die Hersteller diese
Funktion implementieren sollen. Das W3C sagt nur, das Nutzeragenten die durch dieses
Attribut speziell definierten Elemente einfach zugänglich machen sollen. Beispielsweise
könnte der Zugang zu einem derart ausgezeichneten Element über bestimmte
NutzerInnen-Aktionen erfolgen. Dies könnten Tastenkürzel oder auch Mausgesten sein.
Insofern wäre diese Methode sehr geeignet, um die von der WCAG geforderte
geräteunabhängige Bedienung umzusetzen. Bisher lief diese Forderung immer darauf
hinaus, dass der entsprechende Webinhalt auch mit Tastatur navigierbar sein sollte. Das
begründet sich wohl darauf, dass die Tastatur als eines der ersten Eingabegeräte auch
lange Zeit das einzigste Eingabegerät darstellte. Dies muss in Zukunft nicht länger
Michael Haschke
25
Zugänglichkeit für Blinde und Sehschwache
stimmen. So ist die Methode über das access-Attribut wirklich unabhängig vom
Eingabegerät – auch mit Blick in die Zukunft und den sicher neu entstehenden Geräten –
Screenreader nutzen dann die Tastatur oder andere assistive Hilfmittel zur Eingabe,
während NutzerInnen von mobilen PDAs diese Funktionen mit ihren Stift auslösen
können.
Auch tabindex soll abgelöst werden. In XHTML 2 werden dazu die Attribute
nextfocus und prevfocus eingeführt [23]. Diese sollen eine relative Navigation vom
aktuell fokusierten Element möglich machen. Da hier keine einfachen Zähler wie bei
tabindex genutzt werden, ist durch diese Auszeichnung auch genau definiert, in welcher
Reihenfolge die Elemente fokusiert werden sollen. Mit dieser Methode werden Konflikte
wie zwischen natürlichen und echten Tabindex vermieden. Die Navigation kann in den
einzelnen Teilbereichen der Seite auch wesentlich verbessert werden, indem zum
Beispiel einfache Schleifen beschrieben werden können (z.B. Sprung vom letzten
Formularelement wieder zum ersten Formularelement). So wird eine lokale
bereichsspezifische (Seitenbereich) Navigation ermöglicht, welche nicht in Konflikte mit
einer anderen lokalen Navigation auf derselben Seite gerät.
Im Quelltext sieht dies so aus:
<input type=“text“ id=“vorname“ nextfocus=“nachname“ />
<input type=“text“ id=“nachname“ nextfocus=“button“ prevfocus=“vorname“ />
<input type=“submit“ id=“button“ value=“Speichern!“ nextfocus=“vorname“ />
Die Steuerung für nextfocus und prevfocus soll im Nutzeragenten einstellbar sein,
somit ist es wie das access-Attribut unabhängig vom Eingabegerät. Diese neuen
Attribute sind sehr positiv für eine Verbesserung der Zugänglichkeit zu werten.
Momentan ist allerdings nicht abzusehen, ab wann XHTML 2 in der Praxis bei
Webanwendungen eingesetzt wird.
26
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
6 Formulare
Formulare sind wichtige Schnittstellen zwischen NutzerIn und Webanwendung, da
dadurch Interaktion möglich ist. Es können Daten übertragen (z.B. das Verschicken von
Nachrichten per Kontaktformular) oder Funktionen der Webanwendung aufgerufen (z.B.
Stichwortsuche) werden.
6.1 Verhalten und Probleme im Screenreader
Für NutzerInnen von Screenreadern ist das Auffinden von Formularen die erste Barierre.
Besonders wenn sich zusätzlich zum Formular sehr viel anderer Inhalt auf der Webseite
befindet, gestaltet sich der Zugang zu den Formularen schwierig. Einige Screenreader
bieten deshalb die Möglichkeit eines direkten Sprunges zum Formular per
Tastenkombination [6].
Während des Ausfüllens wird per Tastatur von Feld zu Feld navigiert. Dabei wird
vorgelesen, welche Eingabe verlangt wird und um was für eine Art der Eingabe
(Texteingabe, Auswahl aus Liste, Kontrollkästchen, etc) es sich handelt. Allerdings
funktioniert dies nur dann, wenn die einzelnen Felder und Bezeichner zumindest in
logisch richtiger Reihenfolge im Webdokument angegeben sind. Auch hier gilt: eine
visuell eindeutige Anordnung kann vom Screenreader nicht erkannt werden, wenn die
semantische Auszeichnung fehlt.
In Abbildung 9 werden Formularelemente mit Hilfe einer Tabelle visuell angeordnet. Dies
Abbildung 9: Formularanordnung in Tabelle
Michael Haschke
27
Zugänglichkeit für Blinde und Sehschwache
Ein weiterer ungünstiger Fall für Screenreader ist die umgedrehte Reihenfolge von
Eingabefeldern und ihren Bezeichnern. Unabhängig von zusätzlich möglichen UsabilityProblemen (z.B.: Sind nachstehende Bezeichner eindeutig zuordenbar?), kann dies zu
technisch
bedingten
Fehlern
und
Missverständnissen
bei
NutzerInnen
von
Screenreadern führen. Ein Formular wie in Abbildung 10 würde zunächst eine
unbezeichnete Eingabe verlangen, da diese erst nach dem Eingabefeld kommt. Danach
würde der Screenreader die Bezeichnung der vorangegangenen Eingabe lesen und im
Anschluss eine andere Eingabe verlangen.
Abbildung 10: Formular mit Bezeichner hinter Eingabefeld
In vielen Screenreadern (z.B. Jaws) gibt es Lese- und Editiermodus. Die unterschiedlichen
Modi sind nötig, da der Screenreader wissen muss, ob der Tastenanschlag eine Eingabe
darstellt oder einen Steuerbefehl auslösen soll. Im Editiermodus liest der Screenreader
beim Sprung zum nächsten Eingabefeld den Text vor diesem vor. Bei dem Formular von
Abbildung 10 würde diese Methode genau den oben beschriebenen Fehler produzieren.
Somit müssten die NutzerInnen ständig zwischen Lese- und Editiermodus wechseln, um
das Formular vollständig und richtig auszufüllen. Somit ist das Formular nicht auf
einfache Weise zugänglich.
Unabhängig von diesen rein technischen Fehlern gibt es weitere Hürden, welche
beachtet werden müssen. Es sollte dem Formular eine eindeutige Beschreibung
vorangestellt werden, visuelle Erklärungen wie z.B. farbliche Markierungen von
Pflichtfeldern schlägt für NutzerInnen von Screenreadern oder Farbenblinde fehl. Auch
NutzerInnen ohne Beeinträchtigung müssen nicht zwingend schlussfolgern, dass auf
diese Weise markierte Eingaben Pflicht sind. Ein weiterer Punkt sind lange
Auswahllisten. Listen mit vielen Einträgen sind aufgrund ihrer Länge schwer zugänglich,
28
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
da die Navigation komplizierter wird und somit viel länger dauert. In einigen Fällen muss
die Liste z.B. zuerst vollständig durchgesehen werden, um danach das geeignete Element
auszuwählen, wofür zurücknavigiert werden muss. Eine ungünstig gewählte Abfolge der
Elemente kann die Auswahl noch schwieriger machen.
Ein weiterer Schwachpunkt ist die Verwendung von Javascript. Sofern der Screenreader
auf einen javascriptfähigen Browser aufsetzen, können Formulare mit Javascript
funktional aufgewertet werden, indem beispielsweise Eingaben clientseitig auf
Korrektheit überprüft werden können und die Seite nicht extra neu geladen werden
muss. Allerdings schlägt diese Methode fehl, wenn Javascript deaktiviert oder aus einem
anderen Grund nicht verfügbar ist. Insofern sollte zumindest das Absenden der
Formulareingaben ohne Javascript realisiert werden. Ein anderes Problem ergibt sich,
wenn der Inhalt der Seite (respektive des Formulars) per Javascript manipuliert wird.
Zum Teil interpretieren Screenreader dies als neue Seite und springen zum Vorlesen
wieder an den Seitenanfang. Somit ist das Formular kaum navigierbar und infolgedessen
auch nicht zugänglich.
6.2 Semantischer Aufbau von Formularen
Formulare im Web können wie andere Formulare (z.B. auf Papier) genauso in
verschiedene Bestandteile aufgeteilt werden: Felder für die Eingabe, Felder zur
Beschreibung der geforderten Eingaben, inhaltliche Gruppierungen von Eingabefeldern
und Überschriften für das Formular.
Für diese unterschiedlichen Bestandteile gibt es in (X)HTML – inhaltlich equivalentes –
semantisches Markup. Für die Eingaben gibt es unter anderen folgende Möglichkeiten:
•
einzeiliges Eingabefeld <input type=“text“ />
•
mehrzeiliges Eingabefeld <textarea> </textarea>
•
Auswahllisten <select><option>...</option></select>
•
Radio-Buttons (Entweder-Oder-Auswahl) <input type=“radio“ />
•
Checkboxen <input type=“checkbox“ />
Michael Haschke
29
Zugänglichkeit für Blinde und Sehschwache
Einzelne Bestandteile in Auswahllisten können mit <optgroup> </optgroup> inhaltlich gruppiert werden. Als Bezeichner (Beschreibung) der Eingabefelder sollte das
<label> </label> Markup verwendet werden. Mehrere Eingabefelder mit ihren
Bezeichnern können mit <fieldset> </fieldset> inhaltlich zusammengefasst
werden. Diese Fieldsets können mit <legend> </legend> beschriftet werden.
Da auch im Web die Formulareingaben abgeschickt werden müssen, sollte ein
entsprechender Button dafür existieren. Dieser kann mit <input type=“submit“ /> realisiert werden. In Abbildung 11 wird das Zusammenspiel all dieser Elemente
deutlich.
Für die Zugänglichkeit am wichtigsten ist der Verbund von <label> und <input>,
denn auf diese Weise wird die Bezeichnung dem entsprechenden Eingabefeld
zugeordnet. Dies ist wichtig für NutzerInnen von Screenreadern, denn auf diese Weise
wissen diese genau, was für eine Eingabe von ihnen verlangt wird. Die Bezeichnung ist
somit theoretisch vor und nach dem Eingabefeld möglich, sofern der Screenreader das
<label> Konstrukt unterstützt,
<form action=“formhandler.php“ method=“post“>
<fieldset>
<legend>Du und Dein PC</legend>
<fieldset>
<legend>Persönliche Angaben</legend>
<label for=“vorname“>Vorname:</label>
<input type=“text“ id=“vorname“ />
<label for=“nachname“>Nachname:</label>
<input type=“text“ id=“nachname“ />
</fieldset>
<fieldset>
<legend>Angaben zu Deinem PC</legend>
<label for=“hersteller“>Hersteller:</label>
<input type=“text“ id=“hersteller“ />
<label for=“modell“>Modell:</label>
<input type=“text“ id=“modell“ />
</fieldset>
</fieldset>
<input type=“submit“ id=“aktion“ value=“Formularangaben absenden!“ />
</form>
Abbildung 11: Beispiel eines semantisch korrekt ausgezeichneten Formulars
Zusätzlich könnte das Formular mit weiteren Methoden noch zugänglicher gestaltet
werden. Besonders im Falle von sehr viel dem Formular vorangestellten Inhalt sollten
Möglichkeiten existieren, ein Formular direkt anzuspringen. Dies könnte über
Accesskeys oder – derzeit wohl die bessere Alternative – durch Übersprunglinks
(Skiplinks) realisiert werden. Auch Tabindizes werden empfohlen [28], allerdings sollte
hier von Fall zu Fall unterschieden werden. Um für einen schnellen Zugang zum
30
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
Formular die Seitennavigation zu überspringen, sind Tabindizes durchaus sinnvoll. Ein
Formular für Meinungen zu einem vorangestellten Artikel sollte sinnvollerweise auch
erst nach dem Artikel erreicht werden. Einerseits könnte ein angegebener Tabindex für
das Formular den natürlichen Tabindex für Links im Artikel stören, anderseits könnte ein
Tabindex zur Verbesserung der Navigation im Formular selber beitragen. Zumindest wird
ein Tabindex bei komplexeren Formularen von verschiedenen Organisationen (z.B. W3C,
Aktion Mensch – Einfach für Alle, WebAim, etc) empfohlen.
6.3 Zukünftige Entwicklungen
Wie Kapitel 6.1 zeigt, sind derzeitige HTML-Formulare nicht ausgereift. Zugänglichkeit,
Bedienbarkeit (Usability) und Controlling (Funktionen mit Javascript) beeinträchtigen
einander, da Funktionen und Präsentation nicht getrennt werden. Somit ist die aktuelle
Umsetzung von Formularen auch nicht geräteunabhängig. Die W3C „Device
Independence Working Group“ (Arbeitsgruppe für Geräteunabhängigkeit) [29]
beschäftigt sich mit diesem Thema und arbeitet auch mit anderen W3C Arbeitsgruppen
zusammen, unter anderem auch mit der Arbeitsgruppe für Markup [30].
Diese Arbeitsgruppe entwickelte mit XForms 1.0 eine XML-Applikation für Formulare,
derzeit besteht die offizielle W3C Empfehlung für XForms 1.0 von Oktober 2003 [31].
XForms 1.0 ist theoretisch geräteunabhängig , indem es das Prinzip von Model-ViewController (MVC) umsetzt, also strikt zwischen Datenmodell, Präsentation und
funktionalen Elementen (Kontrolleinheit) trennt. XForms ist keine alleinstehende
Anwendung, sondern wird in bestehende XML-Markup-Sprachen wie beispielsweise
XHTML oder Scaleable Vector Grafics (SVG) integriert. Ab XHTML 2.0 [32] soll XForms als
integriertes
Modul
die
derzeitigen
Formular-Elemente
komplett
ersetzen.
Geräteunabhängigkeit ensteht dadurch, das XForms in Zukunft durch die jeweiligen
Endgeräte clientseitig in optimaler Weise implementiert wird (bzw. sollte). Auch zum
derzeitigen Zeitpunkt existieren schon verschiedene client- und serverseitige
Implementierungen [33].
Durch das Datenmodell ist es möglich, Eingaben mit definierten Datentypen zu
verknüpfen, wodurch eine clientseitige Überprüfung der Eingaben möglich wird. So kann
der Browser schon vor dem Versenden der Formulareingaben entsprechnde Warnungen
ausgeben.
Michael Haschke
31
Zugänglichkeit für Blinde und Sehschwache
Durch Geräteunabhängigkeit ergibt sich für Blinde und Sehschwache der große Vorteil
der multimodalen Interaktion. XForms sind auch per Telefon oder Voice-Browser
zugänglich, da eine Schnittstelle zur natürlichen Sprache (Voice Interface) möglich ist
[34]. Dies würde der Methode von XForms als integraler Bestandteil einer anderen
Markup-Sprache entsprechen. Eine weitere Möglichkeit ist die Kombination von XForms
und VoiceXML [35]. Wie schon erwähnt, ist das XForms Datenmodell ein grosser Vorteil,
da dieses über die verschiedenen Nutzeragenten konsistent ist. Die Anpassung von
Präsentantion und Kontrolleinheit könnte über die Transformation von XForms zu
VoiceXML geschehen. Da XForms und VoiceXML beide auf der Extensible Markup
Language (XML) basieren, kann dies durch eine client- oder serverseitige XSL
Transformation (XSLT) geschehen [36]. Eine serverseitige Transformations-Applikation
ist das Consensus Projekt (Context Sensitive Adaptability - User Friendly Mobile Work
Place for Seamless Enterprise Applications) der Europäischen Union. Dieses Projekt
basiert allerdings auf der Renderer Independent Markup Language (RIML), welche
vielversprechende Konzepte vorhandener und zukünftiger Webstandards wie XHTML
2.0, XForms und Synchronized Multimedia Integration Language (SMIL) in einem so
genannten XHTML Language-Profil vereint [37]. Wobei anzumerken ist, dass Consensus
primär für schnellere Verbreitung von Internet-Anwendungen auf mobilen Geräten
geschaffen wurde.
32
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
7 Zusammenfassung und Aussicht
Die vorangegangenen Kapitel zeigen, dass es durchaus ohne zu grossen Aufwand möglich
ist, die Zugänglichkeit von Webapplikationen für Blinde und Sehschwache signifikant zu
verbessern. Dabei wurden nur Teilaspakte behandelt, Themen wie das Hinzufügen von
textuellen Beschreibungen zu Grafiken oder die eindeutige Bezeichnung von Links
wurden beispielsweise vernachlässigt, obwohl dies schon eine wesentlich verbesserte
Zugänglichkeit zur Folge hat. Das einfache Auszeichnen von Webinhalten mit syntaktisch
und semantisch korrekten Markup bringt im Umkehrschluss zur einführend erwähnten
Statistik eine Verbesserung der Zugänglichkeit bei 90% der deutschsprachigen
Internetangebote.
In naher Zukunft werden zugängliche Internetangebote in ihrer Anzahl zunehmen, denn
immer mehr wirtschaftliche und öffentliche Träger werden für dieses Thema
sensibilisiert. Öffentlich-rechtliche, Landes- und Bundesanstalten sind inzwischen per
Gesetz in vielen Ländern dazu verpflichtet, ihre Inhalte für alle Menschen zugänglich zu
gestalten. Wirtschaftlichen Unternehmen wird mit Verbesserung der Zugänglichkeit ein
wesentliche Vergrösserung ihrer Kunden- und Zielgruppen prognostiziert. Diese
Gruppen haben durch ihr Einkommen ein grosses wirtschaftliches Potential. Der Markt
zielt dabei natürlich nicht nur auf Menschen mit angeborenen Einschränkungen ab,
sondern vor allem auf den immer grösser werden Teil der Bevölkerung, welche aufgrund
des immer weiter voranschreitenden Alters mit immer mehr Einschränkungen in ihrer
Leistungsfähigkeit leben müssen. Die wichtigsten Argumente dafür liefert die
demographische Entwicklung in den Industrienationen [6]. Auch die wirtschaftlichen
Unternehmungen für die Verbesserung der Zugänglichkeit für Mobiles verbessern
indirekt auch die Zugänglichkeit für Blinde, Sehschwache und anderweitig in ihren
Fähigkeiten eingeschränkten Menschen. Denn oft kann die so entwickelte Technik
adaptiert werden. Wie die unterschiedlichen Arbeitsgruppen des W3Cs zeigen, verlaufen
Entwicklungen auf diesen Gebieten oft parallel.
Auch wenn mit den derzeitigen Werkzeugen keine 100% Zugänglichkeit erreicht werden
kann, ist jeder kleine Schritt in Richtung Zugänglichkeit eine grosse Hilfe für viele
Menschen mit Beeinträchtigungen.
Michael Haschke
33
Zugänglichkeit für Blinde und Sehschwache
Schwieriger sind sicherlich Prognosen, wieviel Zeit es bis zum endgültigen Durchbruch
verbesserter Techniken wie XHTML 2.0 oder XForms braucht. Als Beispiel könnte hier
HTML 4.0 angeführt werden, welches bei weitem nicht überall korrekt verwendet wird,
aber nunmehr schon über 10 Jahre als Standard existiert. Allerdings werden die
Übergänge fliessend sein. Sowohl client- als auch auf serverseitig wird derzeit in diese
Richtung entwickelt. Und auch wenn bis zum clientseitigen Standardgebrauch dieser
Techniken wohl etwas länger dauern wird, werden voll einsetzbare serverseitige
Implementierungen nicht lange auf sich warten lassen.
Abschliessend die Bemerkung, dass Zugänglichkeit im Kontext der gesamten Tradition
und den Zielen des World Wide Web steht. Informationen für alle ist ohne Zugänglichkeit
für alle nicht durchsetzbar.
34
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
Glossar
Bildschirmlupe Bildschirmlupen werden oft von stark sehschwachen NutzerInnen
eingesetzt und sind eine Softwarelösung, welche einen Teil des Bildschirms vergrössert,
so dass dieser leichter gelesen werden kann. Dadurch kann auch nur ein kleiner Teil des
Bildschirms gleichzeitig betrachtet werden.
Braille-Browser Braille ist Blindenschrift, welche Buchstaben und Zahlen durch sechs
Punkte präsentiert, welche mit den Fingerspitzen ertastet und auf diese Weise gelesen
werden können. Braille-Browser (auch als Braille-Display bezeichnet) geben dynamisch
änderbare Braille-Zeichen wieder. Derzeitige Braille-Displays variieren von einer Zelle
(Zeichen) bis zu einer Zeile von achtzig Zellen; derzeit verfügt eine Braille-Zeile im
Durchschnitt zwischen 12 bis 20 Zeichen.
Doctype Das angegebene Doctype legt die gewählte Dokumententypdefinition fest, nach
welcher sich die Syntax des Dokumentes richten muss.
DTD Engl. Abkürzung für Document Type Definition (Dokumententypdefinition).
Definiert Elemente, Attribute von Elementen, Entitäten und Reihenfolge, Inhalt und
Beziehung zwischen diesen zueinander. Bspw. wird HTML-Markup durch eine DTD
definiert.
Firefox Desktop-Browser des Mozilla-Projektes. Mehr Infos unter www.mozilla.org
HTML Validator Ein Programm, welches ein (X)HTML-Dokument gegenüber der
angebenen Dokumententypdefinition auf syntaktische Korrektheit überprüft.
Javascript Clientseititige objektorientierte Skriptsprache, um statische HTML-Seiten
dynamisch zu gestalten. Trotz der Ähnlichleit des Namens darf Javascript nicht mit der
Programmiersprache Java verwechselt werden.
Lynx Einfacher Textbrowser, welcher keine Grafiken anzeigen und nur über Tastatur
navigiert werden kann.
Michael Haschke
35
Zugänglichkeit für Blinde und Sehschwache
Markup Markup oder Markup Language ist eine Auszeichnungssprache. Es gibt zwei
Gruppen von Auszeichnungssprachen. (X)HTML ist eine Descriptive Markup Language,
welche die Syntax von Daten beschreibt. HTML besteht aus semantischer und
präsentationsorientierter Syntax, wogegen striktes XHTML fast nur aus semantischer
Syntax besteht.
Mausgesten Vorher definierte Bewegungen mit der Maus (z.B. kreisförmige Bewegung im
Uhrzeigersinn), welche mit diesen Gesten verknüpfte Aktionen (z.B. Drucke aktuelle
Seite) auslösen können.
Semantik Semantik
beschäftigt sich mit
Sinn und Bedeutung
von Sprache
beziehungsweise von sprachlichen Zeichen. Die Semantik stützt sich dabei in der Regel
auf eine bestimmte Syntax.
Screenreader Softwareprogramm, welches NutzerInnen den Text auf einem Bildschirm
vorliest. Diese Programme können im Normalfall keinen als Bitmap angezeigten
(„gemalten“) Text lesen.
Syntax Eine Syntax ergibt sich aus einer formalen Grammatik (bei (X)HTML definiert
durch eine DTD oder XML-Schema), um für eine formale Markup-Sprache erlaubte
Kontruktionen festzulegen und unerlaubte auszuschliessen.
Usabilty
Usability
bezeichnet
die
Gebrauchstauglichkeit
oder
besser
Benutzerfreundlichkeit einer Sache in Bezug auf seinen Verwendungszweck. Eine
besonders einfache, zum Nutzer und seinen Aufgaben passende Bedienung wird dabei als
benutzerfreundlich angesehen.
Voice-Browser Software zum sprachgesteuerten Zugriff auf das Internet via Telefon. Auch
in Verbindung mit Display möglich, z.B. für „handless interaction“
XSL Extensible Style Language, dient zur Präsentation von XML Dokumenten.
36
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
Literaturverzeichnis
[1] http://www.w3.org/WAI/
[2] ValiWatch 2005 – Aktuelle Web-Analyse zum deutschsprachigen Internet,
durchgeführt von validome.org, http://www.validome.org/lang/ge/html/valiwatchweb-2005-3 (10.05.2005)
[3] 17. Juli 2002; Verkündungsfundstelle BGBl I 2002, 2654; Sachgebiet FNA 860-9-2-3;
http://bundesrecht.juris.de/bundesrecht/bitv/ (05.05.2005)
[4] 27. April 2002; Verkündungsfundstelle BGBl I 2002, 1467, 1468; Sachgebiet FNA 860-92, GESTA G086; http://bundesrecht.juris.de/bundesrecht/bgg/__3.html (05.05.2005)
[5] THE HARRIS POLL #30 (07.06.2000),
http://harrisinteractive.com/harris_poll/index.asp?PID=93 (06.05.2005)
[6] Mary Frances Theofanos, Janice Redish: „Bridging the gap: between accessibility and
usability“; Interactions, Bd. X, Ausgabe 6, November-Dezember 2003
[7] Eva Papst: „User Report: Web- und Screenreader“, Anhang, April 2005, Seite 23, unter
anderem herausgegeben von WAI Austria (genehmigte Übersetzung von [6])
[8] Web Content Accessibility Guidelines 1.0, Abstract, Mai 1999,
http://www.w3.org/TR/WAI-WEBCONTENT/
[9] Web Content Accessibility Guidelines 1.0, Mai 1999, Appendix A – Validation
[10] XHTML 2.0 Working Draft, Juli 2004, Introduction
[11] Core Techniques for WCAG 1.0, Structure vs. Presentation
[12] W3C Multimodal Interaction Activity, Introduction, http://www.w3.org/2002/mmi/
[13] CSS 2.1 Specification, W3C Candidate Recommendation, Februar 2004, Kapital 7:
Media types, http://www.w3.org/TR/2004/CR-CSS21-20040225/
Michael Haschke
37
Zugänglichkeit für Blinde und Sehschwache
[14] John Foliot: Using Accesskeys - Is it worth it?, Februar 2003,
http://www.wats.ca/articles/accesskeys/19 (28.05.2005)
[15] Chief Information Officer, http://www.cio-dpi.gc.ca/cioscripts/help/specs_e.asp
[16] Cabinet Office, e-Government Unit, 2.4 Building in universal accessibility,
http://www.cabinetoffice.gov.uk/e-government/resources/handbook/html/2-4.asp
[17] GMX Accesskey Übersicht, http://www.gmx.net/de/496262.html
[18] Derek Featherstone, Contradictions in Accessibility - Keyboard Usage and Tabindex,
Juni 2004, http://www.wats.ca/articles/keyboardusageandtabindex/62 (30.05.2005),
deutsche Übersetzung unter http://www.einfach-fuer-alle.de/artikel/tabindex/
(30.05.2005)
[19] Joe Clark, Building Accessible Websites (ISBN 0-7357-1150-X), 2002, New Riders
Publishing, Kapitel 8: Navigation
[20] http://www.w3.org/TR/2004/WD-xhtml2-20040722/
[21] XHTML Role Access Module, http://www.w3.org/TR/2005/WD-xhtml220050527/mod-role.html
[22] XHTML Hypertext Attributes Module, http://www.w3.org/TR/2004/WD-xhtml220040722/xhtml2.html#col_Hypertext
[23] http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html
[24] Jacob Nielsen, Alternative Interfaces for Accessibility, April 2003,
http://www.useit.com/alertbox/20030407.html
[25] Dirk Schürjohann, Die wichtige Reihenfolge von Webinhalten,
http://aktuell.de.selfhtml.org/artikel/design/reihenfolge/index.htm#probleme
(30.05.2005)
[26] Takagi, Asakawa, Fukuda, Maeda; Accessibility Designer: Visualizing Usability for the
Blind; Tokyo Research Laboratory, IBM Japan
[27] aus WCAG 1.0 Übersetzung, René Hartmann, Januar 2002,
http://www.w3c.de/Trans/WAI/webinhalt.html
38
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
[28] Joe Clark, Building Accessible Websites (ISBN 0-7357-1150-X), 2002, New Riders
Publishing, Kapitel 12: Forms and Interaction
[29] Device Independence, http://www.w3.org/2001/di/#wg
[30] HyperText Markup Language (HTML) Home Page, http://www.w3.org/MarkUp/
[31] XForms 1.0, W3C Recommendation 14 October 2003,
http://www.w3.org/TR/2003/REC-xforms-20031014/
[32] XHTML 2.0, W3C Working Draft, http://www.w3.org/TR/xhtml2/
[33] XForms Implementations, http://www.w3.org/MarkUp/Forms/#implementations
[34] Dave Raggett (W3C/HP), Workshop: An Overview of W3C’s work on XHTML, XForms
& Voice Interaction, http://www.w3.org/2000/10/DIAWorkshop/raggett/xhtml-xformsvoice.html
[35] Voice Extensible Markup Language (VoiceXML) Version 2.0, W3C Recommendation
16 March 2004, http://www.w3.org/TR/2004/REC-voicexml20-20040316/
[36] Adam Hocek (Broadstrokes, Inc.), VoiceXML and Next-Generation Voice Services
(Paper for XML Conference & Exposition 2002)
[37] Jörn Turner, Michael Wasmund, Thomas Ziegert; XML & Web Services Magazin
01.2004; Seitenweise Formulare (XForms für mobile Geräte - Erfahrungen aus dem
Consensus Project)
Michael Haschke
39
Zugänglichkeit für Blinde und Sehschwache
Abbildungsverzeichnis
Abbildung 1: falsche Syntax impliziert falsche Semantik...........................................................6
Abbildung 2: Präsentation statt Semantik – valide, aber falsch.................................................6
Abbildung 3: valider HTML-Code sollte auch semantisch korrekt sein....................................7
Abbildung 4: XHTML-Dokument ohne und mit Stylesheets.......................................................9
Abbildung 5: Beziehung zwischen Medientypen und -gruppen..............................................10
Abbildung 6: Beispieldokument in der Druckvorschau.............................................................11
Abbildung 7: Struktur eines Dokumentes im 1-D und 2-D Layout...........................................13
Abbildung 8: Accesskeys in verschiedenen Browsern...............................................................15
Abbildung 9: Formularanordnung in Tabelle..............................................................................21
Abbildung 10: Formular mit Bezeichner hinter Eingabefeld....................................................21
Abbildung 11: Beispiel eines semantisch korrekt ausgezeichneten Formulars....................23
40
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
Anhang
Nachfolgend die zu Kapitel 3.3 Abbildung 4 (XHTML-Dokument ohne und mit
Stylesheets) zugehörigen Quelltexte. Es wird ein Webdokument durch Stylesheets auf
verschiedene Weise präsentiert.
kapitel_3.3-abbildung04.html
<?xml version="1.0" encoding="ISO­8859­1"?>
<!DOCTYPE html PUBLIC "­//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1­strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de">
<head>
<title>Beispieldokument Kapitel 3.3</title>
<link rel="stylesheet" media="screen" href="kapitel_3.3­abbildung04­
style01.css" type="text/css" title="standard" />
<link rel="alternate stylesheet" media="screen" href="kapitel_3.3­
abbildung04­style02.css" type="text/css" title="alternate" />
<link rel="stylesheet" media="print" href="kapitel_3.4­abbildung04­
print.css" type="text/css" />
</head>
<body>
<!­­
fuer die Uebersichtlichkeit wurde auf einige semantische Konstrukte
wie z.B. Zitate oder Aenderung der Sprache verzichtet.
­­>
<div id="navigation">
<ul>
<li><a href="#">Startseite</a></li>
<li><a href="#">Themenübersicht</a></li>
<li><a href="#">Impressum</a></li>
</ul>
</div>
<div id="inhalt">
<h1>Formatierung mit Cascading Style Sheets</h1>
<h2>Präambel</h2>
<p>
Vorweg: dieses Kapitel dient nicht zur Einführung in Cascading Style Sheet (CSS) Syntax und Technik. Es wird nicht gezeigt wie mächtig CSS in seinen Möglichkeiten ist, um Einfluss auf visuelle und aurale Präsentation auszuüben.
</p>
<h2>Wieso sollten Stylesheets verwendet werden?</h2>
<p>
Wenn Webdokumente oder ­applikationen entworfen werden, sollte zuerst die Struktur entwickelt werden und erst im Anschluss die Präsentation erfolgen. Dies ist wichtig, da die Präsentation nicht unbedingt grafisch, sondern auch aural erfolgen kann. Auf die multimodale Präsentation wird in Kapitel 3.4 näher eingegangen. Eine klare Struktur unabhängig von der Präsentation bedeutet in jedem Fall eine bessere Zugänglichkeit, unabhängig vom Nutzer­Agenten [11]. Die WCAG 1.0 drückt es in Checkpoint 3.3 mit "Use style sheets to control layout and presentation" aus.
</p>
<p>
Michael Haschke
41
Zugänglichkeit für Blinde und Sehschwache
Für Webdokumente, welche auf (X)HTML aufbauen, kann CSS genutzt werden. Speziell für aurale Ausgaben entworfene Stylesheets nennen sich Aural Cascading Style Sheets. Stylesheets werden vom HTML­Dokument referenziert und sorgen für die Präsentation der einzelnen Elemente. Dies betrifft nicht nur evtl. Schriftarten und ­farben, sondern auch visuelle Anordnung der einzelnen Seitenbereiche. Dies ist natürlich für NutzerInnen von Screenreadern nicht von Bedeutung, zeigt aber, dass alternative Seiten speziell für diese NutzerInnen nicht nötig sind. Gleicher Inhalt kann durch Stylesheets auf unterschiedliche Art ­ visuell oder aural ­ präsentiert werden.
</p>
<h2>Stylesheets einbinden</h2>
<p>
Um ein gewünschtes CSS zu referenzieren gibt es verschiedene Möglichkeiten, eine davon funktioniert über das Einfügen folgenden Codes im Kopfbereich des HTML­Dokumentes:
</p>
<code>
<link rel="stylesheet" href="style.css" type="text/css" />
</code>
</div>
</body>
</html>
kapitel_3.3-abbildung04-style01.css
body {
font­family:sans­serif;
}
h1 {
font­size:200%;
}
h2 {
font­size:150%;
}
#inhalt {
padding:20px;
color:#000;
background­color:#EEE;
border:solid 20px #999;
}
#navigation {
display:inline;
margin:30px;
float:right;
}
#navigation ul {
padding:0px;
border:none;
list­style:none;
}
#navigation ul li {
padding:0px;
margin:5px;
border­top:solid 2px #FFF;
border­left:solid 2px #FFF;
border­bottom:solid 2px #999;
border­right:solid 2px #999;
}
#navigation ul li a {
42
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
display:block;
margin:0px;
padding:10px;
color:#000;
background­color:#CCC;
font­weight:bold;
text­decoration:none;
}
code {
display:block;
padding:10px;
color:#000;
background­color:#CCC;
font­family:monospace;
font­weight:bold;
}
kapitel_3.3-abbildung04-style02.css
body {
font­family:sans­serif;
}
h1 {
font­size:200%;
}
h2 {
font­size:150%;
}
#inhalt {
clear:both;
width:40em;
padding:0em 1em;
margin:1em auto;
color:#000;
background­color:#FFF;
border­left:dashed .2em #999;
border­right:dashed .2em #999;
}
#inhalt p {
text­align:justify;
}
#navigation {
width:40em;
margin:1em auto;
}
#navigation ul {
padding:0px;
margin:0em;
list­style:none;
}
#navigation ul li {
float:left;
width:11em;
margin:1em;
padding:0em;
border­top:solid .1em #DDD;
border­left:solid .1em #DDD;
border­bottom:solid .1em #111;
border­right:solid .1em #111;
text­align:center;
Michael Haschke
43
Zugänglichkeit für Blinde und Sehschwache
}
#navigation ul li a {
display:block;
padding:.5em;
color:#000;
background­color:#CCC;
font­weight:bold;
text­decoration:none;
}
code {
display:block;
padding:1em;
color:#000;
background­color:#FFF;
font­family:monospace;
font­weight:bold;
border:dashed 1px #000;
}
kapitel_3.4-abbildung04-print.css
@page {
size:portrait;
margin­top:5.7cm;
margin­bottom:1.4cm;
}
@page :left { margin­left:2cm; margin­right:3cm; }
@page :right { margin­left:3cm; margin­right:2cm; }
body {
font­family:serif;
font­size:12pt;
line­height:175%;
}
h1, h2 {
color:#000;
}
h1 {
font­size:200%;
}
h2 {
font­size:150%;
}
#inhalt {
margin:0cm 1cm;
}
#inhalt p {
text­align:justify;
color:#333;
orphans:4;
widows:4;
}
#navigation {
display:none;
}
code {
display:block;
background­color:#EEE;
44
Michael Haschke
Zugänglichkeit für Blinde und Sehschwache
font­family:monospace;
font­weight:bold;
font­size:10pt;
}
kapitel_6.1-abbildung_09.html ist Quelltext zu Abbildung 9 (Formularanordnung in Tabelle)
in Kapitel 6.1
<!DOCTYPE HTML PUBLIC "­//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Abbildung 09 ­ Kapitel 6.1</title>
</head>
<body>
<h1>Abbildung 9 ­ Beipielformular mit Tabellenaufteilung</h1>
<form action="formular.php" method="post">
<table>
<tr>
<td colspan="3"><strong>Zur Person</strong></td>
</tr>
<tr>
<td>Akademischer Grad:</td>
<td>Vorname:</td>
<td>Nachname:</td>
</tr>
<tr>
<td><input type="text" name="akagrad" /></td>
<td><input type="text" name="vorname" /></td>
<td><input type="text" name="nachname" /></td>
</tr>
<tr>
<td colspan="3"><strong>Adresse</strong></td>
</tr>
<tr>
<td>Strasse Hausnummer:</td>
<td>Postleitzahl:</td>
<td>Stadt:</td>
</tr>
<tr>
<td><input type="text" name="strasse" /></td>
<td><input type="text" name="plz" /></td>
<td><input type="text" name="stadt" /></td>
</tr>
</table>
<input type="submit" name="button" value="Absenden!" style="margin­
top:20px;"/>
</form>
</body>
</html>
kapitel_6.1-abbildung_10.html ist Quelltext zu Abbildung 10 (Formular mit Bezeichner
hinter Eingabefeld) in Kapitel 6.1
<!DOCTYPE HTML PUBLIC "­//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Abbildung 10 ­ Kapitel 6.1</title>
</head>
Michael Haschke
45
Zugänglichkeit für Blinde und Sehschwache
<body>
<h1>Abbildung 10 ­ Beipielformular mit hinten stehenden Bezeichner</h1>
<form action="formular.php" method="post">
<strong>Persönliche Angaben</strong><br/>
<input type="text" name="vorname" /> Vorname<br/>
<input type="text" name="nachname" /> Nachname<br/>
<input type="text" name="email" /> Emailadresse<br/>
<strong>Kommentar</strong><br/>
<input type="text" name="betreff" /> Betreff<br/>
Text:<br/>
<textarea name="text" cols="40" rows="10"></textarea><br/>
<input type="submit" name="button" value="Absenden!" />
</form>
</body>
</html>
46
Michael Haschke