Erklärungen zur Checkliste Accessibility v. 1.0

Transcrição

Erklärungen zur Accessibility-Checkliste
Erklärung der Erfolgskriterien der Checkliste für die Gestaltung
barrierefreier Websites
Version 1.0
1.10.2008
Inhalt:
1.
Allgemeine Seiteninformationen ...................................................................................................................... 2
2.
Layout .............................................................................................................................................................. 3
3.
Inhalt ................................................................................................................................................................ 5
4.
Schrift............................................................................................................................................................... 8
5.
Bilder und Grafiken ........................................................................................................................................ 10
6.
Tabellen ......................................................................................................................................................... 11
7.
Formulare ...................................................................................................................................................... 13
8.
Scripts und Programme ................................................................................................................................. 18
9.
Bedienungshilfen ........................................................................................................................................... 19
10.
PDF.............................................................................................................................................................. 22
11.
Anhang und Tools........................................................................................................................................ 23
Diese Erklärungen dienen der Checkliste (Checkliste online unter www.access-for-all.ch/checklist/) zur
Beurteilung der wichtigsten Vorgaben an eine barrierefreie Website.
Die wichtigsten und gewichtigsten Kriterien wurden durch die Autoren, Mitarbeiter der Stiftung Zugang für alle
mit dem Ziel ausgewählt, eine übersichtliche, verständliche und gut handhabbare Anleitung zu schaffen.
Die Erfüllung aller Erfolgskriterien ist die beste Voraussetzung, die gesetzliche Anforderung als barrierefreie
Website zu erfüllen. Die Erfolgskriterien basieren auf den Web Content Accessibility Guidelines 1.0 (WCAG 1.0)
des World Wide Web Konsortiums (W3C) und den Schweizer Richtlinien des Bundes für die Gestaltung von
barrierefreien Websites (P028).
Für eine definitive Beurteilung und im Zweifelsfall gelten immer die WCAG 1.0 mit ihren 14 Richtlinien und
insgesamt 66 Checkpunkten.
Aktualisierung
Die aktuellste Version finden Sie immer unter: www.access-for-all.ch/checklist/
Haben Sie Anregungen oder einen Fehler gefunden, bitten die Autoren um Mitteilung.
Mailto: [email protected]
Referenz für dieses Dokument
Die aktuellen (X)HTML-Techniken für die Erfüllung der Web Content Accessibility Guidelines 1.0 (WCAG 1.0)
werden hier detailliert beschrieben:
http://www.w3.org/TR/WCAG10-HTML-TECHS/toc
1. Allgemeine Seiteninformationen
1.1
Die Website verwendet aktuelle und gültige W3C-Technologien, der DOCTYPE
entspricht HTML 4.01 oder XHTML 1.0 (transitional oder strict oder frameset). Der Code
validiert mit dem W3C-Validator.
Browser und andere Benutzeragenten wie Screen-Reader parsen Dokumente entsprechend dem angegebenen
Doctype und verwenden dazu die Doctype Definiton (DTD). Es muss aktuelles Markup verwendet werden, als
gültiger Doctype sollte deshalb mindestens HTML 4.01 Transitional, am besten sollte XHTML 1.0 Transitional
oder Strict, verwendet werden. Von der Verwendung von XHTML 1.1 raten wir ab. Der Doctype muss gültig und
richtig geschrieben sein. Die Seiten müssen gegenüber dem angegebenen Doctype ohne Fehler validieren.
Liste mit den empfohlenen Doctypes: http://www.w3.org/QA/2002/04/valid-dtd-list.html
Anmerkung:
Die Code-Wohlgeformtheit und die Code-Validität sind die Voraussetzungen für qualitativ steuerbare und
überprüfbare Webinhalte. Moderne Browser funktionieren so, dass sie das Dokument anhand der DokumentDeklaration laden und entsprechend darstellen. Bei Ungereimtheiten, wenn die Deklaration ungenügend oder
falsch ist, fallen Browser in den „Quirksmode“, was ein reduzierter und primitiver Darstellungsmodus ist. XHTMLDokumente verlangen wohlgeformten und syntaktisch richtigen Code, Screen-Reader und Bildschirmlupen sind
viel stärker darauf angewiesen als die visuellen Browser und verzeihen weniger Fehler.
WCAG 1.0:
Test automatisierbar:
3.2 AA
ja
11.1 AA
Geprüft wird:
Gültigkeit des Doctype, Markup-Struktur (wellformed), Code-Validität (valid)
Test-Tool:
W3C-Validator: http://validator.org/
1.2
Die Hauptsprache der Webseiten ist richtig deklariert.
Die Auszeichnung der Hauptsprache der jeweiligen Seite ist sehr wichtig. Andernfalls würde der Screen-Reader
eine deutschsprachige Webseite in Englisch vorlesen.
Code-Beispiel:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de-ch" lang="de-ch">
<head>
oder:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html lang=“de“>
WCAG 1.0:
4.3 AA
Geprüft wird:
nein
Richtige Sprachdeklaration der Hauptsprache von jeder Seite
Test-Tool:
Quelltextanalyse
Accessibility-Checkliste Erklärungen
Autoren: Sven Jenzer, Markus Riesch (Stiftung Zugang für alle)
Version 1.0
Weitergabe unter gleichen Bedingungen und Namensnennung – CC by SA
Seite 2/24
1.3
Wenn Frames verwendet werden sind diese mit sinnvollen Titeln und Namen versehen.
Die Frames werden damit auch für Screen-Reader-User bedienbar. Die Namen sind im Kontext der Bedienbarkeit
der Seite sinnvoll, es soll der Zweck oder Inhalt deutlich werden.
Code-Beispiel:
<frameset rows="15%,*">
<frame src="titlebar.html" name=“Logo Kochrezepte Meier“ scrolling=“no“>
< frameset cols="20%,*">
<frame src="sidebar.html" name=“Navigation“ title=“Navigation“>
<frame src="recipes.html" name=“Inhalt“ title=“Inhalt, alle
Rezepte“>
</frameset>
<noframes> Alle Links für Nicht-Frame-Useragenten
</noframes >
</frameset>
Anmerkung:
Der Zeichenvorrat für das obligatorische name-Attribut ist begrenzt, Leerzeichen und Satzzeichen können nicht
verwendet werden. Im title-Attribut können ganze Sätze stehen, falls nötig kann der Inhalt oder Zweck des
Frames hier genauer beschrieben werden. Falscher Frame-Name: „top“, richtig: „Hauptnavigation“.
WCAG 1.0:
4.3 AA
teilweise
Geprüft wird:
Test-Tool:
Vorhandene und sinnvolle Frame-Name-Attribute und Frame-Title-Attribute.
Quelltextanalyse
Bedingt mit: Accessibility-Toolbar (Navigation – Frames) oder AIS-Toolbar (Doc Info – List
Frames)
2. Layout
2.1
Für Text und Titel wird Markup und keine Grafik verwendet.
Die Nutzung der Überschriften (header h1, h2, h3, ... h6) für Titel, ist die Grundlage für die semantische
Gliederung einer Seite. Screen-Reader können Überschriften strukturiert auslesen und blinde User können damit
Bereiche gezielt auswählen und die Gliederung einer Seite verstehen. Jede visuell erkennbarer Titel (z.B. durch
grössere Schrift und/oder fetter Schriftart) muss als Header der korrekten Hierarchiestufe definiert sein.
Für Aufzählungen werden die vorgesehenen Listenelemente (ul, ol, dl) und für Zitate (q, cite oder blockquote)
verwendet. Diese logischen Auszeichnungen werden nicht für Darstellungseffekte missbraucht.
WCAG 1.0:
3.1 AA
Geprüft wird:
teilweise
Schriftgrafiken werden nicht verwendet. Für Titel, Listen usw. wird das vorgesehene Markup
verwendet.
Quelltextanalyse
Web Developer Extension (Images – Make Images Invisible) oder (Images – Replace Images
with Alt Attributes)
Test-Tool:
3.5 AA
Version 1.0
Seite 3/24
2.2
Das Layout wird mit Stylesheets und nicht mit Layouttabellen erzeugt.
Die Verwendung von Layouttabellen (Layout der Website durch die Verwendung von Tabellen) erschwert den
Zugang zum Inhalt einer Website mit assistierenden Technologien (z.B. Screen-Reader).
Mit Stylesheets (CSS) kann die gesamte optische Anordnung, das Layout, gesteuert werden, die Gliederung der
Seiten in Bereiche, seien dies Spalten, Kasten oder Boxen, die Positionierung von Elementen auf der Seite.
Tabellen können nur für die Darstellung von Datentabellen eingesetzt werden.
WCAG 1.0:
Geprüft wird:
3.3 AA
5.3 AA
teilweise
Keine Layouttabellen vorhanden
Test-Tool:
Firefox (Ansicht – CSS abschalten) oder AIS Toolbar (Structure – Table borders)
2.3
Für die Darstellung der Elemente werden Stylesheets verwendet.
Schriftarten, Schriftfarben, Schriftgrössen- und abstände, Rahmenlinien, Rahmenfarbflächen usw. werden mit
Stylesheets (CSS) definiert.
Stylesheets ermöglichen die Trennung von Inhalt, Struktur (Semantik) und Darstellung, was Screen-Readern und
anderen Ausgabegeräten die Wiedergabe erleichtert. Zudem verbessern sie die Nachhaltigkeit einer Website
deutlich. Vorteile sind die bessere Kompatibilität mit Browsern und anderen Ausgabegeräten aber auch der
einfachere Unterhalt.
WCAG 1.0:
3.3 AA
teilweise
Geprüft wird:
Trennung von Inhalt mit (X)HTML und Darstellungssteuerung mit CSS
Test-Tool:
Firefox (Ansicht – CSS abschalten) oder WAVE Toolbar (Text only view)
2.4
Die Navigation ist in der ganzen Website konsistent.
Die Navigationsleisten bleiben in allen Bereichen der Website gleich oder der Benutzer erfährt rechtzeitig wenn
sich diese verändert. Die Kontrolle des Benutzers über die Position in der Website ist gewährleistet.
WCAG 1.0:
Geprüft wird:
13.4 AA
nein
Konsistenz der Navigation und Position innerhalb Webangebot ist für Benutzer klar
Test-Tool:
Walkthrough
2.5
Themenverwandte Links sind gruppiert und für unterschiedliche Benutzeragenten gut
bedienbar. Für mehrstufige Navigation werden verschachtelte Listen verwendet.
Für die Gruppierung und semantisch richtige Strukturierung von Links sind Listen-Elemente zu verwenden. Listen
helfen Screen-Reader-Usern zu erkennen, welche Links zusammen gehören und wo eine neue Linkgruppierung
beginnt. Listen können mit CSS in beliebiger Art und Weise visuell angeordnet und ausgezeichnet werden. Auch
eine horizontale Darstellung von Links (z.B. horizontale Navigationsleiste) ist als Liste zu definieren.
WCAG 1.0:
Geprüft wird:
13.6 AA P028 p2
teilweise
Linklisten mit Markup (ul, li oder ol, li) und mit Headern (h1, h2, h3 ... h6) gruppiert
Test-Tool:
Firefox (Ansicht – CSS abschalten) oder AIS Toolbar (Stucture/Order View)
Version 1.0
Seite 4/24
3. Inhalt
3.1
Die klarste und einfachste Sprache wird verwendet, die für die Website angemessen ist.
Alle Texte und besonders Meldungen, Anweisungen und Anleitungen müssen klar verständlich sein, ohne dass
ein besonderes Vorwissen notwendig ist. Fremdwörter und amtsinterne Fachbegriffe sollen durch gebräuchliche
Wörter der Benutzer-Sprache ersetzt werden. Auf gleichlautende Begriffe bei (Fehler-)Meldungen und den
zugehörigen Webseiten-Elementen wird geachtet.
Tipps das Schreiben in einfacher Sprache:

Verwenden Sie eine einfache, unkomplizierte Sprache
–
Verwenden Sie die einfachsten Worte auf möglichst einfache Weise. Vermeiden Sie
komplizierte Strukturen und abstrakte Begriffe, und seien Sie klar in den Ideen, die Sie
vermitteln wollen.
Vermeiden Sie abstrakte Begriffe
–
Wenn Sie abstrakte Begriffe erwähnen müssen, verwenden Sie konkrete Beispiele und
Vergleiche, die den Menschen helfen, das Problem zu verstehen.
Verwenden Sie kurze Worte aus der Alltagssprache
–
Vermeiden Sie lange Worte, die schwer zu lesen und auszusprechen sind. Verwenden Sie nur
Worte, die in der Alltagssprache bekannt sind und von Ihrer Zielgruppe verwendet werden.
Achten Sie jedoch darauf, Erwachsenensprache zu verwenden, wenn Sie für erwachsenen
Menschen schreiben!
Verwenden Sie praktische Beispiele
–
Praktische Beispiele können dabei helfen, dass Menschen abstrakte Begriffe verstehen und
Informationen in Beziehung zu Situationen aus ihrem eigenen Leben setzen.
Verwenden Sie meistens kurze Sätze
Stellen Sie nur einen Gedanken pro Satz vor
–
Versuchen Sie nicht, mehr als einen Gedanken oder ein Thema pro Satz zu behandeln.
Verwenden Sie eher aktive als passive Verben
–
Gestalten Sie Ihr Dokument so interessant wie möglich. Aktive Verben machen Ihr Dokument in
der Regel lebhafter und weniger kompliziert.
Gehen Sie nicht von bereits vorhandenem Wissen über Ihr Thema aus
Verwenden Sie eine einfache Zeichensetzung
–
Vermeiden Sie Strichpunkte, Gedankenstriche und Kommas.
Verwenden Sie keinen Konjunktiv
–
Die „unsichere Zukunft“ (...könnte passieren..., solltest Du/sollten Sie tun...) ist ungenau und
verwirrend. Vermeiden Sie den Konjunktiv, soweit es geht.
Verwenden Sie keine Fremdwörter
–
Dies betrifft ebenfalls Worte, die häufig verwendet werden, aber fremden Ursprungs sind. Wenn
Sie es nicht vermeiden können ein Fremdwort zu verwenden, da es sehr gebräuchlich ist,
erklären Sie es.
Weitere Informationen in den Europäischen Richtlinien für leichte Lesbarkeit:
http://www.inclusion-europe.org/documents/101.pdf
WCAG 1.0:
14.1 A
Geprüft wird:
nein
Verständliche, einfache, dem Kontext angemessene Sprache
Test-Tool:
Walkthrough
Version 1.0
Seite 5/24
3.2
Grosse Informationsblöcke sind in kleinere aufgeteilt, wenn dies der Übersichtlichkeit
dient.
Die Unterteilung längerer Texte durch Einfügen von Abständen und die Gliederung mit Zwischentiteln
(Überschriften) vereinfachen den Lesefluss und schaffen Übersicht.
Bemerkung:
Dies erhöht die Lesefreundlichkeit ebenfalls: Die Spaltenbreite ist nicht zu gross, idealerweise zwischen 45 und
75 Zeichen. Der Zeilenabstand ist auf mindestens 130% erhöht.
WCAG 1.0:
Geprüft wird:
12.3 AA
nein
Übersichtliche und dem Kontext angemessene Gliederung
Test-Tool:
Walkthrough
3.3
Auf automatische Popup-Fenster wird verzichtet, das Öffnen neuer Fenster erfolgt mit
Ankündigung im Linktext.
Ein blinder Anwender sieht nicht, wenn sich ein neues Fenster auf dem Bildschirm öffnet. Dies muss für ihn auf
sinnvolle Weise erkennbar sein.
Falls das Linkziel ein neues Fenster öffnet, für zum Beispiel ein Plugin wie Acrobat-Reader, wird dies innerhalb
des Links mittels Text mitgeteilt. Bei Bildern, Grafiken, Icons eignet sich das Alt-Attribut zur Link-Beschriftung.
Beispiele:
Zusammenfassung (PDF, 34 KB)
Bestellformular (Neues Fenster)
Bemerkung:
Die Information über ein neues Fenster kann unter Umständen auch als unsichtbarer Text definiert werden.
WCAG 1.0:
13.1 AA
teilweise
Geprüft wird:
Verständliche, einfache, dem Kontext angemessene Sprache
Test-Tool:
T.A.W., WAVE-Toolbar, Walkthrough
3.4
Abkürzungen werden beim ersten Auftreten erläutert.
Das Ausschreiben beim ersten Auftreten von Akronymen (z.B.: W3C) und von Abkürzungen (z.B. HTML) mit in
Klammern gesetzter Abkürzung, erfüllt die Anforderungen der WCAG 1.0.
Beispiel:
Die United Nations Organisation (UNO) wählte heute den neuen Sekretär.
Abkürzungen können beim ersten Auftreten auch mit den (X)HTML-Elementen <abbr>, <acronym>, kombiniert
mit gleichlautendem <title> ausgezeichnet werden. Erforderlich wird dies, wenn es sich um eine technische oder
wissenschaftliche Abkürzung oder ein Akronym handelt, welches nicht im Fliesstext erläutert wird.
Code-Beispiel:
<p>Ein frühes Zitat von Tim Berners-Lee, dem <acronym lang=“en“ title="World
Wide Web Consortium">W3C</acronym>-Direktor und Erfinder des World Wide
Web.</p>
Version 1.0
Seite 6/24
Bemerkung
Allgemein bekannte und häufige Abkürzungen, wie z.B.: „PDF“ müssen nicht erläutert werden.
WCAG 1.0:
Geprüft wird:
4.2 AAA
nein
Für den Kontext wichtige Abkürzungen werden beim ersten Auftreten erläutert
Test-Tool:
Walkthrough
3.5
Der Kontrast der Schrift gegenüber dem Hintergrund ist ausreichend gross.
Zu beachten sind alle Texte der Navigation, des Inhalts und die Überschriften aber auch die Feldlinien der
Eingabefelder von Formularen. Relevant sind auch die passiven und aktiven Navigationselemente. Bei
Elementen die unterschiedliche Farbzustände haben können, sind beide Zustände zu messen. Bei schmalen
Schriften wird die Farbe auf dem Bildschirm, nicht die Definition gemessen, die durch Anti-Aliasing
möglicherweise geschwächt wird.
WCAG 1.0:
2.2 AA
nein
Geprüft wird:
Test-Tool:
Kontrast von Text (Navigation, Titel, Text). Farbdifferenz >500, Helligkeitsdifferenz >125
Walkthrough, Colour Contrast Analyser
3.6
Die Erkennbarkeit ohne Farben ist gewährleistet. Fehlermeldungen oder wichtige
Unterscheidungen sind nicht allein durch Farbe gekennzeichnet.
Für die Bedienung ist die Farbsichtigkeit alleine nicht erforderlich. Zum Beispiel werden Fehlermeldungen nicht
allein durch rote Farbhinterlegung gekennzeichnet sondern immer mit einem aussagekräftigen Meldungstext
kombiniert.
Version 1.0
Seite 7/24
Beispiel:
Abbildung 1: Dieser Sitzungsplan ordnet die Sitzungen mit sieben unterschiedlichen Farben den unterschiedlichen
Abteilungen zu. Für Farbfehlsichtige, Farbenblinde und Blinde ist diese Information nicht verfügbar.
WCAG 1.0:
2.1 AA
nein
Geprüft wird:
Inhalte werden nicht nur über Farben vermittelt und sind auch ohne Farbwahrnehmung
verfügbar.
Test-Tool:
Walkthrough, Colour Contrast Analyser
4. Schrift
4.1
Die Schriftgrössen sind skalierbar und mit relativen Massen definiert (em, %).
Damit Schriften unkompliziert in allen Browsern vergrössert werden können, ist auf die Massangabe in relativen
Einheiten (em, %) zu achten, solange IEX 6 noch verbreitet ist der „Px“ nicht vergrössern kann. „Px“ ist auch
deshalb eine ungeeignete Masseinheit, weil Pixel auf unterschiedlichen Monitoren unterschiedlich gross sind.
Auch Navigationselemente, sofern sie mit Text und CSS erstellt wurden, sind mit den Massangaben in „em“ gut
vergrösserbar. Die Skalierbarkeit muss im Browser um mindestens 2 bis 3 Stufen gewährleistet sein.
WCAG 1.0:
3.4 AA
Geprüft wird:
Test-Tool:
teilweise
Text-Schriftgrösse ist skalierbar, mit relativen Massangaben festgelegt (em, %)
T.A.W., WAVE, Text-Schriftgrösse ist im Browser 2-3 Stufen vergrösserbar (auch im IE 6) und
das Layout gewährleistet die subjektiv gute Lesbarkeit der vergrösserten Schrift.
Version 1.0
Seite 8/24
4.2
Für Titel werden die vorgesehenen Überschriften (h1, h2, h3, ...) in der richtigen
Reihenfolge angewendet.
Überschriften sind immer hierarchisch aufgebaut (h1 zuerst). Überschriftenebenen werden nicht übersprungen.
Die Überschriften bilden die Struktur der Website und bilden das semantische Gerüst. Somit werden auch
Navigationsblöcke und Fusszeilen am besten durch eine Überschrift gekennzeichnet. Der Screen-Reader-User
kann sich alle Überschriften einer Seite anzeigen lassen und gut zwischen diesen navigieren.
Beispiel:
Abbildung 2: Am Beispiel von www.be.ch wird sichtbar,
wie die Website mittels Überschriften gut gegliedert ist.
Oben die Website in Normalansicht.
Abbildung 3: Dieselbe Webseite mit abgeschaltetem CSS
(links). Ohne Design wird die Text-Struktur sichtbar. Zur
besseren Unterscheidung wurden die Überschriften
farbig hinterlegt: h1 gelb und h2 rot.
Ein Blinder kann durch diese Gliederung mit dem ScreenReader bequem von Überschrift zu Überschrift springen
und sich rasch eine gute Übersicht verschaffen.
WCAG 1.0:
3.5 AA
teilweise
Geprüft wird:
Sichtbare und unsichtbare Headings (h1, ... h6) sind in korrekter Hierarchie vorhanden
Test-Tool:
WAVE Toolbar (Structure View) Accessibility Extension (Navigation), AIS Toolbar
4.3
Für Aufzählungen werden Listen verwendet. Für mehrstufige Navigationsebenen
werden verschachtelte Listen verwendet.
Listen sind wichtige Elemente für die semantische Gruppierung und Gliederung. Sie helfen insbesondere
Screenreadernutzern zu erkennen, wenn Informationen aufgelistet werden oder welche Links zusammen gehören
und wo eine neue Linkgruppierung beginnt.

Inhaltliche Aufzählungen, wie zum Beispiel Produktlisten, nicht nur als Liste darstellen, sondern auch als
Liste formatieren.

Navigationen immer als Liste formatieren. Auch wenn es sich um eine horizontale Navigation handelt.

Links in logischen Einheiten zusammenfassen. Zum Beispiel mehrere Hauptkategorien-Gruppen in
jeweils einer Liste (<ul> oder <ol>) und Unterkategorien wiederum in einer weiteren Liste
zusammenfassen.

Listen korrekt verschachteln, siehe Beispiel.
Version 1.0
Seite 9/24
Code-Beispiel:
<ul id="menue">
<li><a href="#">Oberpunkt 01</a>
<ul class="submenue" id="active">
<li><a href="#">Untermenü 1.a</a></li>
<li><a href="#">Untermenü 1.b</a></li>
<li><a href="#">Untermenü 1.c</a></li>
</ul>
</li>
<li> ... </li>
</ul>
WCAG 1.0:
Geprüft wird:
3.6 AA
teilweise
Alle Aufzählungen, insbesondere Navigationselemente, werden als korrekt verschachtelte
Liste dargestellt
Test-Tool:
Firefox (Ansicht – CSS abschalten) Quelltext-Analyse
5. Bilder und Grafiken
5.1
Bilder und Grafiken mit visuellem Inhalt, sind mit einem aussagekräftigen Alternativtext
beschrieben, bei viel Inhalt (z.B. Infografik) wird mit longdesc ein Beschrieb verlinkt.
Damit Bilder mit Informationsgehalt auch für blinde und sehbehinderte Anwender (und Suchmaschinen)
zugänglich sind, müssen diese mit einem sinnvollen Alternativ-Text beschrieben sein.
Handelt es sich bei der Grafik um ein Foto oder um ein Symbol (z.B.: Drucken, PDF) so muss der dargestellte
Inhalt gleichbedeutend im Alt-Text beschrieben sein.
Handelt es sich um eine Informationsgrafik, so genügt die Beschreibung im Alternativtext zu einem Diagramm
oder Organigramm oft nicht. Sie sollte zusätzlich beschrieben werden. Dies kann direkt im angrenzenden Text
erfolgen oder durch das Longdesc-Attribut. Damit kann dem Bild ein (nur für Screen-Reader ersichtlicher)
Verweis auf eine Zusatzseite mit der entsprechenden Beschreibung geboten werden.
Code-Beispiel:
<p><img src=“dasbild.gif“ alt=“Das Organigramm der Verwaltung“
longdesc=“organigramm-verwaltung.html“></p>
WCAG 1.0:
1.1 A
teilweise
Geprüft wird:
Alternativtexte der Bilder und Grafiken sind vorhanden und sinnvoll. Bilder mit hohem
Informationsgehalt besitzen falls notwendig eine ausführliche Beschreibung auf einer
zusätzlichen Seite, welche über das Longdesc-Attribut verknüpft ist.
Test-Tool:
Webdeveloper Toolbar oder AIS Toolbar, Quelltext-Analyse
5.2
Bilder und Grafiken mit einem Link, geben im Alternativtext deutlich Aufschluss über
das Linkziel.
Falls es sich bei einem Bild um eine verlinkte Grafik handelt, muss der Alternativtext Klarheit über das Linkziel
schaffen. Z.B.: „Zum Haupttext“, „Seite ausdrucken“, usw. Alternativtexte möglichst kurz und präzis formulieren.
WCAG 1.0:
1.1 A
Geprüft wird:
nein
Alle grafischen Links besitzen einen aussagekräftigen Alternativ-Text, welcher das Linkziel
beschreibt
Test-Tool:
Webdeveloper Toolbar oder AIS Toolbar, Walkthrough
Version 1.0
Seite 10/24
5.3
Bilder und Grafiken ohne inhaltliche Relevanz (Abstandhalter, dekorative Elemente)
sind mit einem leeren Alt-Attribut versehen.
Dekorative Grafikelemente sowie Grafiken als Layouthilfen sollen nicht beschriftet werden, solange keine
nützlichen Informationen auf dem Bild vorhanden sind. Wenn kein Alt-Text gewünscht ist, keinesfalls den Alt-Tag
weglassen. Stattdessen einen leeren Alt-Tag einfügen: alt=""
So ignoriert das Bildschirmleseprogramm die Grafik, andernfalls würde es den Pfad und den Dateinamen zur
jeweiligen Grafik vorlesen, was sehr störend ist.
Bemerkung:
Verlinkte Grafiken müssen immer einen sinnvollen Alternativ-Text besitzen, dieser darf nicht aus einem leeren AltTag alt="" bestehen.
WCAG 1.0:
Geprüft wird:
1.1 A
nein
Alternativtexte der Schmuckelemente sind vorhanden und leer.
Test-Tool:
Webdeveloper Toolbar, AIS Toolbar, WAVE-Toolbar, Quelltext-Analyse
6. Tabellen
6.1
Datentabellen sind mit Spalten- und Zeilenüberschriften gekennzeichnet und seriell
lesbar.
Bei einfachen Tabellen mit nur 1 Zeilen- oder Spaltenüberschrift sollte das „Scope“-Attribut verwendet werden.
Bei Tabellen niemals leere Zellen verwenden um Abstände zu erzeugen, ist eine Zelle leer, so wird am besten ein
Zeichen gesetzt wie: - oder 0 (null).
Code-Beispiel für eine Datentabelle mit Spaltenüberschriften und mit Scope:
Chur
Bern
Basel
1287
2355
2233
<table>
<caption>Drei Städte im Vergleich</caption>
<tr>
<th scope="col">Chur</th>
<th scope="col">Bern</th>
<th scope="col">Basel</th>
</tr>
<tr>
<td scope="row">1287</td>
<td>2355</td>
<td>2233</td>
</tr>
</table>
Version 1.0
Seite 11/24
Code-Beispiel für eine Datentabelle mit Spalten- und Zeilenüberschriften mit Scope:
Poststellen
2005 2006 2007
Hauptfilialen 2389 2357 2312
Filialen
657
654
649
Agenturen
135
129
150
<table>>
<caption>Poststellen in der Schweiz</caption>
<tr>
<th scope="col">Postellen</th>
<th scope="col">2005</th>
</tr>
<tr>
<th scope="row">Hauptfilialen</th>
<td>2'389</td>
<td>2'357</td>
<td>2'312</td>
</tr>
<tr>
<th scope="row">Filialen</th>
<td>657</td>
<td>654</td>
<td>649</td>
</tr>
<tr>
<th scope="row">Agenturen</th>
<td>135</td>
<td>129</td>
<td>150</td>
</tr>
</table>
WCAG 1.0:
5.1 A
nein
Geprüft wird:
Zeilen- und/oder Spaltenüberschriften sind korrekt ausgezeichnet
Test-Tool:
Accessibility-Toolbar (Structure>Complex Data Table), Quelltext-Analyse
6.2
Komplexe Datentabellen sind mit entsprechendem Markup versehen und seriell lesbar.
Bei komplexeren Tabellen ist der Einsatz von Headers unumgänglich.
Code-Beispiel mit Headers und ID’s:
<table>
<caption>Drei Städte im Vergleich</caption>
<thead>
<tr>
<th id="Stadt_1">Chur</th>
<th id="Stadt_2">Bern</th>
<th id="Stadt_3">Basel</th>
</tr>
</thead>
<tbody>
<tr>
<td headers="Stadt_1">1287</td>
</tr>
<tbody>
</table>
Der Screen-Reader liest dieses Beispiel so: „Drei Städte im Vergleich Chur 1287, Bern 2355, Basel 2233“.
Version 1.0
Seite 12/24
Eine illustrierte Anleitung für einfache und komplexe Datentabellen:
http://www.webaim.org/techniques/tables/data.php
WCAG 1.0:
Geprüft wird:
5.2 A
nein
Datentabellen sind richtig linearisierbar durch den Einsatz von entsprechendem Markup
Test-Tool:
Accessibility-Toolbar (Structure – Complex Data Table), Quelltext-Analyse
6.3
Datentabellen mit viel Inhalt werden mit einer Zusammenfassung beschrieben
(summary).
Bei längeren Tabellen ist es für Screen-Reader-Benutzer eine Hilfe wenn zu Beginn der Tabelle eine
Zusammenfassung kurz erläutert um was es in der folgenden Aufstellung geht. Bei kurzen Tabellen ist dies nicht
erforderlich, der Lesefluss soll möglichst wenig gestört werden.
Code-Beispiel mit summary:
<table summary=“Die Fledermauspopulationen dreier Städte werden verglichen“>
<caption>Die Fledermaus im Stadtgebiet</caption>
<tr> …
WCAG 1.0:
5.5 AAA
nein
Geprüft wird:
Datentabellen besitzen falls notwendig eine sinnvolle Zusammenfassung
Test-Tool:
Accessibility-Toolbar (Structure – Simple Data Table)
7. Formulare
7.1
Formularbeschriftung und Formulareingabefeld sind mit <label> logisch verknüpft.
Für die logische Verknüpfung der Beschriftung mit dem Formularelement müssen immer Labels eingesetzt
werden. So wird dem Screen-Reader-Benutzer jeweils die Label-Beschriftung vorgelesen, während der Fokus
bereits im dazugehörenden Eingabefeld ist.
Code-Beispiel:
<form action="formular.cgi">
<fieldset>
<legend>Anmeldung</legend>
<label for="v-name">Vorname: </label>
<input type="text" id="v-name" name="Bitte Vornamen eingeben"
value="Ihr Vorname"><br />
<label for="n-name">Nachname: </label>
<input type="text" id="n-name" name="Bitte Nachnamen eingeben"
value="Ihr Nachname"><br />
Bitte ankreuzen: <input type="checkbox" id="auswahl" name="AGBs
gelesen" value="AGBs gelesen"> <label for="auswahl">Die AGBs habe ich
gelesen.</label><br />
</fieldset>
</form>
Bemerkung:
Formularfelder ohne Beschriftung sind mit einer unsichtbaren Beschriftung zu ergänzen, welche über ein Label
mit dem Formularfeld verknüpft ist.
Version 1.0
Seite 13/24
Anwendungs-Beispiel:
Das Eingabefeld „Suchen“ wird häufig ohne Beschriftung angeboten, dies ganz im Sinne der übersichtlichen
Gestaltung.
Abbildung 4: Eingabefeld "Suchen" ohne visuell erkennbare Beschriftung (normale Ansicht mit CSS).
Bei deaktiviertem CSS wird erkennbar, dass eine unsichtbare Beschriftung „Suchen“ vorhanden ist, welche als
unsichtbarer Text definiert ist und das Eingabefeld einleitend beschreibt.
Abbildung 5: Unsichtbare Beschriftung "Suchen" wird bei deaktiviertem CSS sichtbar.
Die unsichtbare Beschriftung „Suchen“ ist über ein Label mit dem Eingabefeld verknüpft und somit wird die
Suchfunktion auch für blinde Anwender sehr gut zugänglich.
Code-Beispiel:
<form action="suche.htm" method="get" id="searchHome">
<div class="hidden"><label for="query">Suchen</label></div>
<input name="query" id="query" type="text">
<input class="Hand button" value="Suchen" type="submit">
</form>
WCAG 1.0:
Geprüft wird:
12.4 AA
nein
Jedes Formularfeld besitz eine korrekte Verknüpfung zur zugehörigen Beschriftung
Test-Tool:
Accessibility-Toolbar (Structure>Fieldset / Label), Quelltext-Analyse
7.2
Lange Formulare weisen mit <fieldset> gruppierte Informationsblöcke auf.
Lange Formulare sollen nicht nur visuell benutzerfreundlich gegliedert werden, sondern auch logisch. Sie müssen
mit <Fieldset> in Gruppen zusammengefasst und unterteilt werden. Jede Fieldset-Gruppe wird mit <Legend>
betitelt. Siehe Code-Beispiel 7.1.
Das nachfolgende Formular besteht aus zwei visuell getrennten Eingabegruppen „Fragen und Anregungen“ und
„Kontaktangaben“. Diese zwei Formularfelder-Gruppen werden jeweils mit einem <fieldset> gruppiert.
Abbildung 6: Kontaktformular mit zwei Gruppen mit Formularfeldern.
Version 1.0
Seite 14/24
Abbildung 7: Bei deaktivierten CSS werden die durch Fieldset gruppierten Bereiche sichtbar. Dadurch werden auch
komplexe Formulare für blinde Anwender übersichtlich und zugänglich.
Bemerkung:
Bei einer Auswahl aus Checkboxen oder Radio-Buttons sind immer Labels und Fieldsets zu verwenden.
Abbildung 8: Das Label verknüpft den Radio-Button mit "Ja" oder "Nein". Damit ein Screen-Reader aber auch die Frage
"Arbeitnehmer/in" zuordnen kann ist hier ein Fieldset notwendig. Fieldset darf ineinander geschachtelt werden.
WCAG 1.0:
12.3 AA
nein
Geprüft wird:
Lange Formulare sind gruppiert und beschriftet
Test-Tool:
Accessibility-Toolbar (Structure>Fieldset / Label), Quelltext-Analyse
Version 1.0
Seite 15/24
7.3
Formularbeschriftungen und Eingabefelder sind visuell nah genug beieinander und der
Farbkontrast der Schrift und der Feldbegrenzungslinien ist ausreichend gross.
Die Beschriftung und das dazugehörige Formular-Element (Eingabefelder, Checkboxen, usw.) müssen visuell
nah genug beieinander stehen, damit auch bei starker Vergrösserung (bis 700%) eine Zuordnung ersichtlich ist.
Die Feldbegrenzungslinien weisen einen minimalen Kontrast von 5:1 zum Hintergrund auf. Siehe auch
Checkpunkt 3.5.
Beispiel:
Die folgende Abbildung zeigt Formularfelder die zu weit von der Beschriftung entfernt sind. Ein stark
sehbehinderter Anwender ist auf eine starke Bildschirmvergrösserung angewiesen und er sieht in seinem kleinen
Bildausschnitt nur die Beschriftungen oder die Eingabefelder.
Abbildung 9: Der rote Bereich ist ungefähr der Bildschirmausschnitt, den eine stark sehbehinderte Person sieht, die
auf einen Zoomfaktor 6 angewiesen ist. Die Beschriftung und das zugehörige Eingabefeld sind für sie zu weit
auseinander.
WCAG 1.0:
10.2 A
nein
Geprüft wird:
Formularfelder sind direkt neben oder unterhalb der zugehörigen Beschriftung
Test-Tool:
Visuelle Sichtung
7.4
Formularbeschriftungen und Eingabefelder sind seriell in der richtigen Reihenfolge
angeordnet.
Die Beschriftung und das dazugehörige Formular-Element (Eingabefelder, Checkboxen, usw.) werden nicht nur
visuell zueinander, sondern auch seriell in der richtigen Reihenfolge angeordnet. Für das Layout sollen möglichst
keine Tabellen verwendet werden. Für Screen-Reader ist die Anordnung in der Reihenfolge: Beschriftung (Label),
Eingabefeld, ideal.
WCAG 1.0:
Geprüft wird:
10.2 A
nein
Beschriftungen und Formularfelder sind in der richtigen Reihenfolge angeordnet
Test-Tool:
Analyse bei deaktiviertem CSS
Version 1.0
Seite 16/24
7.5
Fehlermeldungen sind im Wortlaut eindeutig und im eingeblendeten Bereich auf dem
Bildschirm sichtbar. Die betroffenen Eingabefelder werden visuell hervorgehoben.
Bei fehlerhaften Eingaben wird dem Benutzer eine „System-Meldebox“ mit richtig lautendem Hinweis
eingeblendet. Alternativ kann eine Fehlermeldung direkt am Seitenanfang oder am Anfang des Inhaltbereichs
eingeblendet werden. Der Wortlaut ist gleichlautend wie die betroffene Beschriftung. Idealerweise ist der
betroffene Formularbereich im sichtbaren Bereich oder es führt ein Link von der Fehlermeldung direkt vor die
betroffene Feldbeschriftung, damit der Screen-Reader-Benutzer die Feldbeschriftung lesen und danach in das
folgende Control-Feld navigieren kann. Die Fehlermeldung wird visuell hervorgehoben.
Bei komplexeren Formularen wird empfohlen die Fehlermeldung nach der Formular-Validierung direkt in das
Label zu schreiben. Auf diese Art und Weise können blinde Anwender bei jedem Eingabefeld direkt die
Fehlermeldung erkennen.
Im Nachfolgenden Beispiel wird die Fehlermeldung visuell hervorgehoben und gleichzeitig als unsichtbarer Text
in das Label des Formularfeldes geschrieben.
Abbildung 10: Die Fehlermeldung wird visuell hervorgehoben und unsichtbar in das Label geschrieben.
Code-Beispiel:
<label for="vn">Vorname: *<span class="unsichtbar">Bitte füllen Sie dieses
Pflichtfeld aus.</span></label>
<input id="vn" name="vorname" type="text">
<div id="advice-required-vorname">Bitte füllen Sie dieses Pflichtfeld
aus.</div>
WCAG 1.0:
14.2 AAA
nein
Geprüft wird:
Fehlermeldungen sind im Wortlaut eindeutig und im eingeblendeten Bereich auf dem
Bildschirm lesbar. Die betroffenen Eintragsfelder werden visuell hervorgehoben.
Visuelle Sichtung, Quelltext-Analyse
Test-Tool:
7.6
Erforderliche Eingebefelder sind für alle Lesarten gekennzeichnet (z.B. nicht allein
durch Farbe oder Hervorhebung fett).
Den Hinweis „Pflichtfeld“ auch im Label-Text vermerken. Oder es können Grafiken mit einem Sternchen-Symbol,
in denen der Alt-Text "Pflichtfeld" hinterlegt ist, verwendet werden.
Der Screen-Reader-Anwender erfährt nicht welche Angaben zwingend ausgefüllt werden müssen wenn diese nur
mit dem Stern-Zeichen (*) gekennzeichnet sind. In diesem Fall kann die textuelle Information „Pflichtfeld“ als
unsichtbarer Text im Label ergänzt werden.
Code-Beispiel:
<label for="vn">Vorname: *<span class="unsichtbar">Pflichtfeld</span></label>
<input id="vn" name="vorname" type="text">
<div id="advice-required-vorname">Bitte füllen Sie dieses Pflichtfeld
aus.</div>
WCAG 1.0:
Geprüft wird:
2.1 A
nein
Die Information Pflichtfeld ist als Text vorhanden
Test-Tool:
Visuelle Sichtung, Quelltext-Analyse
Version 1.0
Seite 17/24
8. Scripts und Programme
8.1.
Wenn JavaScript verwendet wird, können die Seiten auch bedient und alle Inhalte
können erreicht werden, wenn JavaScript im Browser abgeschaltet wird.
Alle Inhalte sollen erreicht werden können, wenn JavaScript deaktiviert ist. Navigations- und Formularelemente
sollen funktionieren oder durch ein gleichwertiges Alternativangebot zugänglich gemacht werden. Screen-Reader
und andere Assistenzgeräte haben u.U. Schwierigkeiten mit JavaScript.
WCAG 1.0:
Geprüft wird:
Test-Tool:
6.3 AA
teilweise
Die Seite kann vollständig bei deaktiviertem JavaScript benutzt werden.
T.A.W., JavaScript über die Web Developer Toolbar (oder Browser-Einstellungen)
deaktivieren
8.2.
Wenn Applets oder ähnliche spezifische Programmierungen (z.B. Flash-Movie)
verwendet werden, steht eine redundante Alternative zur Verfügung, wenn Programmierungen
ausgeschaltet sind oder nicht unterstützt werden.
Altenativangebote für audiovisuelle Inhalte sind gleichwertig, sie können über den NOSCRIPT-Bereich oder einen
zusätzlichen Link erreicht werden. Videos mit wichtigem gesprochenem Inhalt haben eine Audiodeskription.
WCAG 1.0:
Geprüft wird:
6.3 AAA
nein
Audio- und Video-Inhalte mit Informationsgehalt werden auch alternativ angeboten
Test-Tool:
Sicht- und Hörprüfung
8.3.
Wenn JavaScript in der Seite für Elemente verwendet wird, stellen Sie sicher, dass
dieses geräteunabhängig ist, z.B. nicht nur mit der Maus bedienbar ist.
Es muss sichergestellt sein, dass die Website ohne Maus und somit auch allein mit der Tastatur bedienbar ist
oder deren Inhalt alternativ zugänglich ist. Empfehlungen für die gebräuchlichen JavaScript-Event-Handler:
Erfoderlich:
Für alle Event Handler:
•
Benutze Geräte unabhängige Event-Triggers anstelle von oder in Ergänzung zu Geräte
abhängigen.
•
Teste Geräte abhängige Event Triggers um zu bestimmen ob zusätzliche Tastatur Events nötig
sind.
•
Bestimme keine Event Handler die sich auf Maus-Koordinaten stützen.
onmouseover und onmouseout
•
Benutze sie immer in Verbindung mit den onfocus und onblur Event Handlern um Keyboard
Bedienung zu ermöglichen.
•
Biete eine zugängliche Alternative an, wenn der Inhalt oder die Funktionalität native nicht zugänglich
gemacht werden können.
ondblclick
•
Nicht benutzen
onclick
•
Wenn mit Elementen verwendet die keine Links oder Controls sind, biete einen redundanten Geräte
unabhängigen Event Handler oder eine zugängliche Alternative an.
onfocus, onblur, onselect und onchange
•
Teste um zu bestätigen, dass die Zugänglichkeit nicht tangiert wird.
Version 1.0
Seite 18/24
Empfohlen:
onchange
•
Verwende einen „Go“ Button anstelle von onchange (Mit klarem Button-Text im Kontext).
•
Biete eine Anleitung auf der Seite an, die dem User click + ALT + Pfeiltaste erklärt um in Drop Down
Boxen navigieren zu können, die onchange verwenden.
Gewährleiste direkte Links als Alternative für Elemente die nur durch Event Handler aktiviert werden können.
Quelle:
IBM Web-Accessibility - Techniken für Scripts mit Event Handlern (Übersetzung: Sven Jenzer 30.5.08)
http://www03.ibm.com/able/guidelines/web/webscripts_eventhandlers.html
Weiterführend zu JavaScript und Accessibility:
Creating accessible JavaScript:
http://www.webaim.org/techniques/javascript/
WCAG 1.0:
Geprüft wird:
9.3 AA
teilweise
Alle Event-Handler sind auch mit der Tastatur bedienbar
Test-Tool:
Accessibility-Toolbar (Structure>Event Handler), Quelltext-Analyse
9. Bedienungshilfen
9.1.
Eine Site-Map bietet eine Informationsübersicht der Site.
Um eine Übersicht der Anordnung und Struktur einer ganzen Website auch ohne visuelle Sicht auf das Layout zu
erhalten, eignet sich eine Liste mit der strukturierten Darstellung aller Seiten gut. Mit dem empfohlenen Markup
werden Bereiche mit Überschriften versehen (h1, h2, h3, ...) und die Seitenlisten mit Listen (ul, li) formatiert.
WCAG 1.0:
13.3 AA
nein
Geprüft wird:
Eine semantisch korrekt aufgebaute Sitemap ist vorhanden
Test-Tool:
Walkthrough
9.2.
Linkziele sind eindeutig benannt (keine nichtssagenden Formulierungen wie: „mehr ...“
und „hier klicken“). Bei Links auf Nicht-HTML-Dateien ist das Datenformat (z.B. PDF, Word)
und deren Dateigrösse beschrieben.
Links immer mit klaren Linkzielen versehen. Unklare Linkziele sind: „Mehr...“, „weiter ...“,“ >>“
Falls das Linkziel ein neues Fenster oder ein Plugin (z.B. Acrobat) öffnet, ist dies innerhalb des Links mittels Text
mitzuteilen. Bei verlinkten Bildern, Grafiken, Icons eignet sich das Alt-Attribut zur Link-Beschriftung hervorragend.
Mitgliederliste Verein IZZ (PDF 150 KB)
Fortsetzung Gesamtanalyse (in neuem Fenster)
Version 1.0
Seite 19/24
Abbildungen 11 und 12: Links eine Webseite mit zahlreichen unklaren „mehr“-Links mit eingeblendeter nichtssagender
Linkliste, wie sie ein Blinder benutzt. Rechts dieselbe Webseite nach Überarbeitung. Die Links sind direkt die
Überschriften oder Anrisstexte, diese Verbesserung sieht zudem auch noch besser aus.
WCAG 1.0:
Geprüft wird:
13.1 AA
Test automatisierbar: nein
Alle Links besitzen ein aussagekräftiges Linkziel
Test-Tool:
Walkthrough, AIS Toolbar -> Doc Info -> List Links (new Window), Bildeinstellungen / Alt
9.3.
Eine logische Tabulatorreihenfolge bei Links, Formularfeldern und Objekten
gewährleistet Tastaturbedienbarkeit.
Die Tab-Reihenfolge soll seriell in der richtigen Reihenfolge angeordnet sein. Bei Bedarf kann dazu das HTMLAttribut „tabindex“ verwendet werden.
Bemerkung:
Beim Einsatz des Attributs tabindex ist Vorsicht geboten. Damit die Reihenfolge schlussendlich korrekt ist,
braucht jeder Link und jedes Formularelement einen Tabindex. Besser ist die seriell korrekte Anordnung.
WCAG 1.0:
Geprüft wird:
9.4 AAA
nein
Mit Tab-Taste korrekte Tab-Reihenfolge
Test-Tool:
Walkthrough, In Firefox und IE durchtabben
9.4.
Navigationslinks werden auch bei Bedienung ohne Maus (Tastatur) sichtbar bei der
Anwahl (Fokus).
Für Sehbehinderte sowie für alle nicht-mausbedienenden Benutzer ist die Sichtbarkeit der Cursor-Position in
verlinkten Elementen nur dann möglich, wenn eine Hervorhebung bei der Anwahl erfolgt (CSS-Selektor: focus)
Code-Beispiel:
p a:hover, p a:focus, p a:active
color: #fff;
background-color:#888;
}
{
WCAG 1.0:
Geprüft wird:
13.5 AAA
nein
Mit der Tab-Taste wird bedient und beurteilt, ob die Sichtbarkeit der Cursor-Position
gleichwertig ist wie bei Maus-Bedienung.
Test-Tool:
Walkthrough mit den aktuellen Browsern
Version 1.0
Seite 20/24
9.5.
Accesskeys bieten Links mit Tastenkürzel auf die wichtigsten Seiten an.
Ein blinder Benutzer muss im Normalfall eine Webpage Zeile für Zeile "anhören" bis er zu der Stelle gelangt, die
ihn interessiert. Accesskeys bieten Screen-Reader-Benutzern die Möglichkeit, sich innerhalb einer Webseite
rasch zu bewegen.
Die Stiftung "Zugang für alle" empfiehlt, Accesskeys wie folgt zu definieren:
0 "Startseite"
1 "Navigation" (Link innerhalb Webpage)
2 "Inhalt" (Link innerhalb Webpage)
3 "Kontakt"
4 "Sitemap"
5 "Suche"
6-9 optional (nur falls nötig und sinnvoll)
WCAG 1.0:
Geprüft wird:
9.5 AAA
nein
Accesskeys sind vorhanden und funktionieren
Test-Tool:
Test der Accesskeys über die Tastatur
Accessibility-Toolbar (Structure>AccessKeys)
9.6
Bei Webseiten mit mehrstufiger Navigation werden Sprungmarken zum Inhalt, zur
Navigation, zur Subnavigation bereitgestellt.
Ein blinder Benutzer muss im Normalfall eine Webpage Zeile für Zeile "anhören" bis er zu der Stelle gelangt, die
ihn interessiert. Sprungmarken bieten Screen-Reader-Benutzern die Möglichkeit, sich innerhalb einer Webseite
rasch zu bewegen.
Es wird empfohlen, auf jeder Website, unabhängig ihrer Komplexität, mindestens zwei Sprungmarken
(Sprunglinks) anzugeben. Diese werden ganz am Anfang der Seite angebracht und sind in der Regel als
unsichtbare Links definiert, so dass sie nur für blinde Anwender erkennbar sind.
Code-Beispiel der CSS-Klasse zur Darstellung von verstecktem Text:
.unsichtbar {
position:absolute;
left:-1000px;
top:-1000px;
width:0;
height:0;
overflow:hidden;
display:inline;
}
Code-Beispiel von zwei „unsichtbaren“ Sprunglinks:
<body>

<a title="[Alt+1] Direkt zur Navigation" href="#navigation"><span
class="unsichtbar">[Alt+1] Direkt zur Navigation span></a>
<a title="[Alt+2] Direkt zum Inhalt" href="#content"><span
class="unsichtbar">[Alt+2] Direkt zum Inhalt</span></a>
...
WCAG 1.0:
Geprüft wird:
Test-Tool:
13.6 AAA
nein
Sprunglinks sind vorhanden und funktionieren korrekt
CSS mit Accessibility-Toolbar deaktivieren
Überprüfung der Sprunglinks mit Maus oder Tastatur
Version 1.0
Seite 21/24
9.7
Grafische und/oder akustische Ergänzungen werden eingesetzt um das Verständnis zu
erhöhen. z.B.: Bei Fehlermeldungen.
Fehlermeldungen nach Benutzereingaben sollen nicht allein durch farbige Hervorhebung, sondern auch durch
einen Warnton und einen textuellen Hinweis erfolgen. Dieses 2-Sinne-Prinzip gilt auch umgekehrt bei akustischen
Signalen. Fehlermeldungen als Systemmeldung auszugeben ist auch gut.
WCAG 1.0:
Geprüft wird:
14.2 AAA
nein
Fehlermeldungen werden mindestens in zwei der folgenden Formen hervorgehoben: visuell
(z.B. über Farbe), textuell oder akustisch
Test-Tool:
Walkthrough
10. PDF
10.1
Informationen in angebotenen PDF-Dokumenten sind barrierefrei zugänglich.
Diese Kriterien müssen erfüllt sein.
Erfolgs-Kriterien (muss)
1.
Allgemeine Dokument-Eigenschaften
1.1.
Es ist eine logische Reihenfolge aller Elemente vorhanden (korrekte Lesereihenfolge).
1.2.
Die Hauptsprache des PDF-Dokuments ist definiert.
1.3.
Sprachänderungen im Dokument sind definiert.
1.4.
Im Dokument werden Schriftarten/Zeichencodierungen verwendet, die es ermöglichen, Zeichen in Text zu
extrahieren.
1.5.
Screen-Reader werden durch die Sicherheitseinstellungen nicht beeinträchtigt.
2.
Strukturinformationen
2.1.
Das PDF-Dokument ist getagged (korrekte Tagbaum-Struktur).
2.2.
Bilder und Grafiken (im Rasterformat [jpg, gif]) mit visuellem Inhalt, sind mit einem aussagekräftigen
Alternativtext beschrieben. Layoutgrafiken (Grafiken ohne Informationsgehalt) sind als Hintergrund
definiert. Grafiken im Vektorformat (svg, eps…) sind im Rasterformat vorhanden und beschriftet.
2.3.
Für Titel werden die vorgesehenen Überschriften mit Standardtags in der richtigen hierarchischen
Reihenfolge angewendet.
2.4.
Tabellen können sinnvoll linearisiert werden. Falls nötig sind Spalten- und Zeilenüberschriften definiert.
2.5.
Für Absätze werden korrekte Standardtags verwendet.
2.6.
Für Formularfelder werden korrekte Feldbeschriftungen verwendet.
2.7.
Lesezeichen sind vorhanden.
3.
Darstellung
3.1.
Das PDF-Dokument lässt sich umfliessen und vergrössert darstellen.
3.2.
Alle Inhalte müssen im Kontrastmodus gelesen werden können.
Version 1.0
Seite 22/24
Diese Kriterien können erfüllt sein, müssen aber nicht.
Erfolgs-Kriterien (kann)
4.
Allgemeine Dokument-Eigenschaften
4.1.
Links (Hyperlinks, Referenzen) sind korrekt verlinkt.
4.2.
Verzeichnisse (Inhaltsverzeichnis, Index) sind korrekt verlinkt.
4.3.
Die vollständige Prüfung in Acrobat 8.0 Professional darf keine Fehler aufweisen.
5.
Strukturinformationen
5.1.
Aufzählungen werden korrekt als Liste definiert.
5.2.
Tabellen und Abbildungen sind beschriftet.
5.3.
Für Fussnoten werden korrekte Standardtags verwendet.
5.4.
Abkürzungen sind definiert.
Weitere Informationen zu barrierefreien PDF-Dokumenten unter: http://www.access-for-all.ch/de/pdf.html
WCAG 1.0:
8.1 AA
nein
P028
Test-Tool:
Adobe Acrobat Professional ab Version 7
11. Anhang
Tools zur Beurteilung der Barrierefreiheit
Nach Möglichkeit werden bei jedem Erfolgskriterium Tools für die Überprüfbarkeit angegeben. Ein Tool kann aber
die Barrierefreiheit einer Website nur zum Teil schlüssig testen. Am aufschlussreichsten ist ein Test durch
Behinderte und dem Einsatz ihrer assistierenden Technologien, kombiniert mit Quelltext-Analyse.
Die Testumgebung – die aktuellen und meistverwendeten Komponenten
Betriebssystem
Microsoft Windows XP Professional, Service Pack 3 (Schweizerdeutsch)
Optional: Mac-OSX 10.4 (Schweizerdeutsch)
Bildschirmauflösung
1024 x 768 Pixel, 32 Bit Farbe
Browser
Internet Explorer 6
Internet Explorer 7
Firefox 2.x
Firefox 3.x
Optional: Safari 3.x
Optional: Opera 8.x
Assistenzsoftware
Bildschirmlupe ZoomText: http://www.zoomtext.de/
Screen-Reader JAWS: http://www.freedomsci.de/serv01.htm
Der Webformator ist ein Hilfsmittel (gratis) für blinde Internetnutzer, das Webseiten für die Sprachausgabe oder
die Ausgabe über eine Braillezeile aufbereitet und eignet sich gut zum Testen: http://www.webformator.de/
Version 1.0
Seite 23/24
Tools
AIS Web Accessibility Toolbar EN 1.2 (27.2.2006)
Plugin für den Internet Explorer mit zahlreichen nützlichen Funktionen für die Prüfung auf Zugänglichkeit.
http://www.visionaustralia.org/info.aspx?page=614
Web Developer Toolbar
Toolbar für Firefox
http://chrispederick.com/work/web-developer/
Colour Contrast Analyser for Web Pages
Nützliches Tool zur Messung des Farb- und Helligkeits-Kontrastes.
http://www.visionaustralia.org.au/info.aspx?page=628
Online Tools
W3C-Validator
Online-Dienst des W3C zur Prüfung von HTML-Dokumenten auf Validität.
http://validator.w3.org/
WAVE 3.0 Web Accessibility Tool
Stellt gewisse Accessibility-Mängel grafisch sehr gut dar.
http://wave.webaim.org/
Tools-Listen
Eine vollständige Liste der nützlichen und weniger nützlichen Tools bietet die Web Accessibility Initiative auf ihrer
Website an.
http://www.w3.org/WAI/ER/tools/complete
Auch unsere Liste mit automatischen Test-Tools wird laufend aktualisiert:
http://www.access-for-all.ch/de/tools.html
Referenz für dieses Dokument
Die aktuellen (X)HTML-Techniken für die Erfüllung der Web Content Accessibility Guidlines 1.0 (WCAG 1.0)
werden hier detailliert beschrieben:
http://www.w3.org/TR/WCAG10-HTML-TECHS/toc
Glossar
Das umfangreichste Glossar im deutschen Sprachraum rund um Internettechnologien:
http://jendryschik.de/wsdev/glossar/
Version 1.0
Seite 24/24