Zug�nglichkeitsrichtlinien f�r Web-Inhalte 1.0
Deutsche �bersetzung
- Diese �bersetzung:
- http://www.w3.org/Consortium/Offices/Germany/Trans/WAI/webinhalt.html
- �bersetzer:
- Ren� Hartmann
- Letzte �nderung dieses Dokuments:
- 11. Januar 2002
Dies ist die deutsche �bersetzung der "Web Content
Accessibility Guidelines 1.0" vom 5. Mai 1999. Dieses Dokument kann
�bersetzungsfehler enthalten. Allein ma�geblich ist die englische Version,
verf�gbar unter http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505.
Mein Dank geht an Ralf W. Stephan und Martin Stehle f�r ihre Korrekturen
und Anmerkungen zur �bersetzung.
Zug�nglichkeitsrichtlinien f�r Web-Inhalte 1.0
W3C-Empfehlung, 5. Mai 1999
- Diese Version:
- http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
- (Einfacher
Text, PostScript,
PDF, Gzip-Tar-Datei
von HTML, Zip-Archiv
von HTML)
- Neueste Version:
- http://www.w3.org/TR/WAI-WEBCONTENT
- Vorherige Version:
- http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990324
- Herausgeber:
- Wendy Chisholm, Trace R & D
Center, University of Wisconsin -- Madison
Gregg Vanderheiden, Trace R &
D Center, University of Wisconsin -- Madison
Ian Jacobs, W3C
Copyright � 1999 W3C (MIT, INRIA,
Keio). Alle Rechte vorbehalten. Es
finden die Regelungen des W3C zu Haftung,
Warenzeichen,
Verwendung von
Dokumenten und Softwarelizenzierung
Anwendung.
Diese Richtlinien erl�utern, wie Web-Inhalte f�r Behinderte zug�nglich gemacht
werden k�nnen. Diese Richtlinien richten sich an alle Entwickler von Web-Inhalten (Autoren von
Web-Seiten und Site-Designer) und an Entwickler von
Tools zur Seitenerstellung. Das prim�re Ziel dieser Richtlinien
ist die F�rderung der Zug�nglichkeit. Gleichwohl wird die Befolgung dieser
Richtlinien das Web f�r alle Benutzer verbessern, gleich welchen Benutzeragenten sie benutzen (z.�B.
Desktop-Browser, Sprach-Browser, Computer im Auto usw.) oder unter welchen
Einschr�nkungen sie arbeiten m�gen (z.�B. laute Umgebungen, schlecht oder zu
hell beleuchtete R�ume, Umgebungen, in denen die H�nde nicht benutzt werden
k�nnen usw.). Die Befolgung dieser Richtlinien wird auch dazu beitragen,
Informationen im Web schneller aufzufinden. Diese Richtlinien sollen
Entwickler von Inhalten nicht davon abhalten, Bilder, Videos usw.
einzusetzen; sie sollen vielmehr erl�utern, wie Multimedia-Inhalte besser
zug�nglich f�r ein breites Publikum gemacht werden k�nnen.
Dies ist ein Referenzdokument f�r Zug�nglichkeitsgrunds�tze und
Design-Ideen. Manche der in diesem Dokument diskutierten Strategien betreffen
bestimmte Themen der Web-Internationalisierung und des mobilen Zugriffs.
Allerdings liegt der Schwerpunkt dieses Dokuments auf der Web-Zug�nglichkeit;
es behandelt daher verwandte Themen anderer W3C-Aktivit�ten nicht
vollst�ndig. Bitte ziehen Sie f�r weitere Informationen die W3C Mobile Access Activity Home
Page und die W3C
Internationalization Activity Home Page zu Rate.
Dieses Dokument ist als stabiles Dokument konzipiert und beinhaltet daher
keine spezifischen Informationen zum Thema Browser-Unterst�tzung, da diese
Informationen sich rasch �ndern. Solche Informationen werden stattdessen auf
der Website der Web Accessibility
Initiative (WAI) bereitgestellt (Siehe [WAI-UA-SUPPORT]).
Dieses Dokument enth�lt einen Anhang, der alle Checkpunkte geordnet nach Thema und Priorit�t
auflistet. Die Checkpunkte im Anhang sind mit der Definition in diesem
Dokument Link-verkn�pft. Die Themen im Anhang umfassen Bilder, Multimedia,
Tabellen, Frames, Formulare und Scripts. Der Anhang ist sowohl als tabellarische Zusammenfassung wie auch als einfache Liste von Checkpunkten
verf�gbar.
Ein separates Dokument, genannt "Techniques for Web
Content Accessibility Guidelines 1.0" ("Techniken f�r die
Zug�nglichkeitsrichtlinien f�r Web-Inhalte") ([TECHNIQUES]), erl�utert, wie die Checkpunkte in
diesem Dokument zu implementieren sind. Das Techniken-Dokument befasst sich
detailliert mit jedem Checkpunkt und enth�lt Beispiele unter Verwendung der
Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), Synchronized Multimedia Integration Language (SMIL) und
Mathematical Markup Language (MathML). Das
Techniken-Dokument enth�lt auch Techniken zur Validierung und zum Testen
sowie einen Index von HTML-Elementen und -Attributen (und in welchen
Techniken sie Verwendung finden). Das Techniken-Dokument wurde so konzipiert,
dass es in Bezug auf Technologie-�nderungen aktuell bleibt und wird
voraussichtlich �fter aktualisiert werden als dieses Dokument.
Anmerkung: Es unterst�tzen m�glicherweise nicht alle Browser
oder Multimedia-Tools die Features, die in diesen Richtlinien beschrieben
sind. Besonders neue Features von HTML 4.0, CSS 1 oder CSS 2 werden
m�glicherweise nicht unterst�tzt.
"Web Content Accessibility Guidelines 1.0" /
"Zug�nglichkeitsrichtlinien f�r Web-Inhalte 1.0" ist Teil einer Reihe von
Zug�nglichkeitsrichtlinien, die von der Web Accessibility Initiative ver�ffentlicht wurden. Diese Reihe
umfasst auch die User Agent Accessibility Guidelines
([WAI-USERAGENT]) und die Authoring Tool Accessibility Guidelines ([WAI-AUTOOLS]).
Dieses Dokument wurde von W3C-Mitgliedern und anderen interessierten
Parteien gepr�ft und vom Direktor als W3C-Empfehlung gebilligt. Es ist ein
stabiles Dokument und kann als Referenzmaterial verwendet oder als normative
Referenz von anderen Dokumenten zitiert werden. Die Rolle des W3C bei der
Abgabe der Empfehlung ist es, auf diese Spezifikation aufmerksam zu machen
und ihre weite Verbreitung zu f�rdern. Dies verbessert die Funktionalit�t und
Universalit�t des Webs.
Die englische Version dieser Spezifikation ist die einzige normative
Version. F�r �bersetzungen in andere Sprachen siehe http://www.w3.org/WAI/GL/WAI-WEBCONTENT-TRANSLATIONS.
Die Liste bekannter Fehler in diesem Dokument ist verf�gbar unter http://www.w3.org/WAI/GL/WAI-WEBCONTENT-ERRATA.
Bitte melden Sie Fehler in diesem Dokument an [email protected].
Eine Liste aktueller W3C-Empfehlungen und anderer technischer Dokumente
ist zu finden unter http://www.w3.org/TR.
Dieses Dokument wurde erstellt als Teil der W3C Web Accessibility Initiative. Das
Ziel der Web Content Guidelines
Working Group wird in der Working Group
Charter diskutiert.
Die Liste der Checkpunkte ist sowohl als tabellarische Zusammenfassung der
Checkpunkte als auch als einfache Liste von
Checkpunkten verf�gbar.
Wenn Sie mit den Fragen der Zug�nglichkeit betreffend das Design von
Web-Seiten nicht vertraut sind, bedenken Sie, dass manche Benutzer
m�glicherweise in einer Umgebung arbeiten, die sich von der Ihren stark
unterscheidet:
- Sie sind m�glicherweise nur unter Schwierigkeiten oder �berhaupt nicht
in der Lage, zu sehen, zu h�ren, sich zu bewegen oder bestimmte Arten von
Information zu verarbeiten.
- Sie haben m�glicherweise Schwierigkeiten, einen Text zu lesen oder zu
verstehen.
- Sie haben m�glicherweise keine Tastatur oder keine Maus oder sind nicht
in der Lage, davon Gebrauch zu machen.
- Sie haben m�glicherweise einen reinen Textbildschirm, einen kleinen
Bildschirm oder eine langsame Internet-Verbindung.
- Sie sprechen oder verstehen m�glicherweise die Sprache, in der das
Dokument abgefasst ist, nicht flie�end.
- Sie sind m�glicherweise in einer Situation, in der ihre Augen, Ohren
oder H�nde besch�ftigt oder behindert sind (z.�B. bei der Fahrt zur
Arbeit, in einer lauten Umgebung o.��.)
- Sie haben m�glicherweise einen �lteren Browser, einen v�llig anderen
Browser, einen Sprach-Browser oder ein anderes Betriebssystem.
Entwickler von Inhalten m�ssen diese Situationen beim Web-Design bedenken.
W�hrend zahlreiche Situationen zu bedenken sind, kommt jede Entscheidung f�r
zug�ngliches Design im Allgemeinen mehreren Gruppen von Behinderten und der
Web-Community als Ganzes zugute. Wenn z.�B. Stylesheets verwendet werden, um den Stil der
Schrift zu beeinflussen und das FONT-Element zu eliminieren, haben
HTML-Autoren eine bessere Kontrolle �ber ihre Seiten, was diese Seiten f�r
Menschen mit eingeschr�nkter Sehf�higkeit besser zug�nglich macht und durch
die gemeinsame Verwendung von Stylesheets die Ladezeit f�r alle Benutzer oft
reduziert.
Diese Richtlinien diskutieren Fragen der Zug�nglichkeit und stellen
L�sungen f�r zug�ngliches Design bereit. Sie behandeln typische Szenarien,
die Benutzer mit bestimmten Behinderungen vor Probleme stellen. Z.�B.
erl�utert die erste Richtlinie, wie
Entwickler von Inhalten Bilder zug�nglich machen k�nnen. Manche Benutzer sind
nicht in der Lage, Bilder zu sehen, andere benutzen m�glicherweise
textbasierte Browser, die keine Bilder unterst�tzen, w�hrend wieder andere
m�glicherweise Bilder abgeschaltet haben (z.�B. wegen einer langsamen
Internet-Verbindung). Diese Richtlinien schlagen nicht die Vermeidung von
Bildern vor als einen Weg, um die Zug�nglichkeit zu verbessern. Stattdessen
erl�utern sie, dass die Verwendung eines Text-�quivalents das Bild zug�nglich
macht.
Wie macht ein Text-�quivalent das Bild zug�nglich? Beide Wortteile von
"Text-�quivalent" sind wichtig:
- Textinhalt kann dem Benutzer als synthetisierte Sprache, Blindenschrift
oder visuell dargestellter Text pr�sentiert werden. Jede dieser
Mechanismen verwendet einen anderen Sinn -- Ohren f�r synthetisierte
Sprache, Tastsinn f�r Blindenschrift, Augen f�r visuell dargestellten
Text -- auf diese Weise wird die Information zug�nglich f�r Gruppen, die
eine breite Palette von sensorischen und anderen Behinderungen
repr�sentieren.
- Um von Nutzen zu sein, muss der Text dieselbe Funktion bzw. denselben
Zweck erf�llen wie das Bild. Nehmen Sie zum Beispiel ein Foto der Erde,
aufgenommen aus dem Weltraum. Wenn der Zweck des Bildes vorrangig in der
Ausschm�ckung besteht, mag der Text "Foto der Erde vom Weltraum aus
gesehen" die ben�tigte Funktion erf�llen. Wenn der Zweck des Fotos darin
besteht, bestimmte Informationen �ber Geographie zu illustrieren, sollte
das Text-�quivalent diese Information enthalten. Wenn das Foto dem
Benutzer sagen soll, dass er das Bild ausw�hlen soll, um Informationen
�ber die Erde zu erhalten (etwa indem er es anklickt), w�re der
�quivalente Text "Informationen �ber die Erde". D.�h. wenn der Text f�r
einen Benutzer mit einer Behinderung dieselbe Funktion oder denselben
Zweck erf�llt wie das Bild f�r andere Benutzer, kann er als
Text-�quivalent angesehen werden.
Beachten Sie, dass Text-�quivalente, abgesehen von ihrem Nutzen f�r
Behinderte, allen Benutzern helfen k�nnen, Seiten schneller zu finden, da
Suchmaschinen den Text bei der Indizierung von Seiten verwenden k�nnen.
W�hrend Entwickler von Web-Inhalten Text-�quivalente bereitstellen m�ssen,
ist es die Aufgabe der Benutzeragenten (z.�B. Browser und assistive
Technologien wie Screenreader, Blindenschrift-Displays usw.), die
Information dem Benutzer zu pr�sentieren.
Nicht-Text-�quivalente zu Text (z.�B. Icons,
aufgezeichnete Sprache oder ein Video mit einer Person, die den Text in
Geb�rdensprache �bersetzt) kann Dokumente Menschen zug�nglich machen, die
Schwierigkeiten mit geschriebenem Text haben, einschlie�lich vieler Personen
mit kognitiven Behinderungen, Lernbehinderungen und Geh�rlosigkeit.
Nicht-Text-�quivalente f�r Text k�nnen auch f�r Menschen hilfreich sein, die
nicht lesen k�nnen. Eine Audio-Beschreibung ist ein Beispiel f�r ein
Nicht-Text-�quivalent zu visueller Information. Eine Audio-Beschreibung der
Videospur einer Multimedia-Pr�sentation kommt Menschen zugute, die die
visuelle Information nicht sehen k�nnen.
Die Richtlinien umfassen zwei allgemeine Themen: f�r geschmeidige
Transformation zu sorgen und Inhalte verst�ndlich und navigierbar zu
machen.
Indem sie diese Richtlinien befolgen, k�nnen Entwickler von Inhalten
Seiten erstellen, die geschmeidig transformieren. Seiten, die geschmeidig
transformieren, bleiben auch unter den Bedingungen zug�nglich, die in der Einf�hrung beschrieben wurden: physische,
sensorische und kognitive Behinderungen, Einschr�nkungen beim Arbeiten und
technologische Barrieren. Hier einige Hinweise zum Design von Seiten, die
geschmeidig transformieren:
- Trennen Sie Struktur und Pr�sentation (Siehe zum Unterschied zwischen Inhalt, Struktur und
Pr�sentation).
- Stellen Sie Text bereit (einschlie�lich Text-�quivalente): Text kann so
dargestellt werden, dass er auf fast allen Browserger�ten verf�gbar und
f�r fast alle Benutzer zug�nglich ist.
- Erstellen Sie Dokumente, die funktionieren, auch wenn der Benutzer
nicht sehen und/oder h�ren kann. Stellen Sie Information bereit, die auf
einem anderen sensorischen Kanal denselben Zweck oder dieselbe Funktion
erf�llt wie Audio und Video. Das bedeutet nicht, dass Sie eine
aufgezeichnete Audio-Version Ihrer gesamten Site bereitstellen m�ssen.
Blinde Benutzer k�nnen die Screenreader-Technologie verwenden, um
die gesamte Textinformation einer Seite darzustellen.
- Erstellen Sie Dokumente, die nicht von einem bestimmten Typ Hardware
abh�ngig sind. Seiten sollten von Benutzern ohne Maus, mit
niedrigaufl�senden Bildschirmen, Schwarzwei�-Bildschirmen, ohne
Bildschirm, allein mit Sprach- oder Textausgabe usw. verwendbar sein.
Das Thema der geschmeidigen Transformation wird vornehmlich von den
Richtlinien 1 bis 11 behandelt.
Entwickler von Inhalten sollten die Inhalte verst�ndlich und navigierbar
machen. Das bedeutet nicht nur, die Inhalte klar und einfach zu halten,
sondern auch verst�ndliche Mechanismen zur Navigation zwischen und innerhalb
der Seiten bereitzustellen. Die Bereitstellung von Navigations-Tools und
Informationen zur Orientierung maximiert die Zug�nglichkeit und
Verwendbarkeit. Nicht alle Benutzer k�nnen von visuellen Hilfen wie
Imagemaps, proportionalen Scrollbars, nebeneinander angeordneten Frames oder
Grafiken Gebrauch machen, die sehenden Benutzern von grafischen
Desktop-Browsern den Weg weisen. Auch verlieren Benutzer Kontext-Information,
wenn sie nur einen Teil einer Seite sehen k�nnen, entweder weil sie auf die
Seite wortweise (Sprachgenerierung oder Blindenschrift-Display) oder abschnittsweise
zugreifen (kleines Display oder vergr��ertes Display). Ohne Informationen zur
Orientierung sind Benutzer m�glicherweise nicht in der Lage, sehr lange
Tabellen, Listen, Men�s usw. zu verstehen.
Das Thema, Inhalt verst�ndlich und navigierbar zu machen, wird vornehmlich
in den Richtlinien 12 bis 14 behandelt.
Dieses Dokument enth�lt vierzehn Richtlinien oder allgemeine Prinzipien
zug�nglichen Designs. Jede Richtlinie umfasst:
- Die Nummer der Richtlinie.
- Die Aussage der Richtlinie.
- Navigationslinks zur Richtlinie. Diese Links erlauben die Navigation
zur n�chsten Richtlinie (Icon Pfeil nach rechts), der vorigen Richtlinie
(Icon Pfeil nach links), oder zur Position der aktuellen Richtlinie im
Inhaltsverzeichnis (Icon Pfeil nach oben).
- Das der Richtlinie zugrundeliegende Prinzip und Benutzergruppen, die
von ihr profitieren.
- Eine Liste von Checkpunkt-Definitionen.
Die Checkpunkt-Definitionen in jeder
Richtlinie erl�utern, wie die Richtlinie in typischen Situationen der
Entwicklung von Inhalten Anwendung findet. Jede Checkpunkt-Definition
umfasst:
- Die Nummer des Checkpunkts.
- Die Aussage des Checkpunkts.
- Die Priorit�t des Checkpunkts. Checkpunkte der Priorit�t�1 sind mit
Hilfe von Stylesheets hervorgehoben.
- Optionale informative Anmerkungen, erl�uternde Beispiele und
Querverweise auf verwandte Richtlinien oder Checkpunkte.
- Einen Link auf einen Abschnitt des Techniken-Dokuments ([TECHNIQUES]), wo Implementierungen und
Beispiele diskutiert werden.
Es ist beabsichtigt, dass jeder Checkpunkt gen�gend spezifisch ist, so
dass jemand, der eine Seite oder Site durchsieht, �berpr�fen kann, ob der
Checkpunkt erf�llt worden ist.
Die folgenden redaktionellen Konventionen werden in diesem Dokument
durchg�ngig benutzt:
- Elementnamen sind in Gro�buchstaben geschrieben.
- Attributnamen sind in Kleinbuchstaben geschrieben und in
Anf�hrungszeichen gesetzt.
- Links auf Definitionen sind mit Hilfe von Stylesheets
hervorgehoben.
Jedem Checkpunkt wurde von der Arbeitsgruppe eine Priorit�tsstufe
zugeordnet, abh�ngig von seinem Einfluss auf die Zug�nglichkeit.
- [Priorit�t�1]
- Ein Entwickler von Web-Inhalten muss diesen
Checkpunkt erf�llen. Andernfalls wird es f�r eine oder mehrere Gruppen
unm�glich sein, auf die Information im Dokument zuzugreifen. Die
Erf�llung dieses Checkpunkts ist eine grundlegende Erfordernis, damit
bestimmte Gruppen Web-Dokumente verwenden k�nnen.
- [Priorit�t�2]
- Ein Entwickler von Web-Inhalten sollte diesen
Checkpunkt erf�llen. Andernfalls wird es f�r eine oder mehrere Gruppen
schwierig sein, auf die Information im Dokument zuzugreifen. Die
Erf�llung dieses Checkpunkts beseitigt signifikante Hindernisse f�r den
Zugriff auf Web-Dokumente.
- [Priorit�t�3]
- Ein Entwickler von Web-Inhalten kann diesen
Checkpunkt erf�llen. Andernfalls wird es f�r eine oder mehrere Gruppen
etwas schwierig sein, auf die Information im Dokument zuzugreifen. Die
Erf�llung dieses Checkpunkts erleichtert den Zugriff auf
Web-Dokumente.
Manche Checkpunkte sehen eine Priorit�tsstufe vor, die sich unter
bestimmten (angegebenen) Bedingungen �ndern kann.
Dieser Abschnitt definiert drei Stufen der Konformit�t zu diesem
Dokument:
- Konformit�t Stufe "A": Alle Checkpunkte der
Priorit�t�1 sind erf�llt;
- Konformit�t Stufe "Double-A": Alle Checkpunkte der
Priorit�t�1 und 2 sind erf�llt;
- Konformit�t Stufe "Triple-A": Alle Checkpunkte der
Priorit�t�1, 2 und 3 sind erf�llt;
Anmerkung: Konformit�tsstufen werden im Text
ausgeschrieben, damit sie verstanden werden k�nnen, wenn sie als Sprache
ausgegeben werden.
Wird auf Konformit�t mit diesem Dokument Anspruch erhoben, so muss dies in
einer der folgenden Formen geschehen.
Form 1: Geben Sie an:
- Den Titel der Richtlinien: "Web Content Accessibility Guidelines
1.0"
- Den URI der Richtlinien:
http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
- Die erf�llte Konformit�tsstufe: "A", "Double-A" oder "Triple-A".
- Den Umfang, in dem der Anspruch erhoben wird (z.�B. Seite, Site oder
ein definierter Teil einer Site)
Beispiel f�r Form 1:
Diese Seite entspricht den "Web Content Accessibility Guidelines 1.0"
des W3C, verf�gbar unter http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505,
Stufe Double-A.
Form 2: F�gen Sie jeder Seite, die Anspruch auf Konformit�t erhebt, eines
der drei Icons des W3C hinzu und verkn�pfen Sie das Icon �ber einen Link mit
der entsprechenden Erl�uterung des W3C. Informationen �ber die Icons und
dar�ber, wie sie in Seiten eingef�gt werden k�nnen, sind verf�gbar unter [WCAG-ICONS].
Stellen Sie Inhalt bereit, der, wenn er dem Benutzer
pr�sentiert wird, im Wesentlichen dieselbe Funktion oder denselben Zweck
erf�llt wie der Audio- oder visuelle Inhalt.
Obwohl manche Menschen Bilder, Filme, T�ne, Applets usw. nicht direkt
nutzen k�nnen, k�nnen sie unter Umst�nden �quivalente Information zum Audio- oder
visuellen Inhalt nutzen. Die �quivalente Information muss denselben Zweck
erf�llen wie der Audio- oder visuelle Inhalt. Ein Text-�quivalent f�r ein
Bild, das auf ein Inhaltsverzeichnis verweist, k�nnte daher "Zum
Inhaltsverzeichnis" lauten. In manchen F�llen sollte ein �quivalent au�erdem
das Aussehen des visuellen Inhalts (z.�B. f�r Diagramme oder Werbefl�chen)
oder den Ton eines Audio-Inhalts beschreiben (z.�B. f�r Audio-Aufzeichnungen
zu Lehrzwecken).
Diese Richtlinie betont die Wichtigkeit der Bereitstellung von Text-�quivalenten f�r Nicht-Text-Inhalte
(Bilder, aufgezeichneten Ton, Video). Die M�chtigkeit von Text-�quivalenten
liegt an ihrer F�higkeit, auf Arten dargestellt zu werden, die f�r Menschen
verschiedener Behindertengruppen unter Verwendung verschiedenster
Technologien zug�nglich sind. Text kann problemlos mit Sprachgeneratoren und
Blindenschrift-Displays ausgegeben und
visuell auf Computer-Bildschirmen und Papier pr�sentiert werden.
Synthetisierte Sprache ist entscheidend f�r Blinde und f�r viele Menschen mit
den Schwierigkeiten beim Lesen, die oft eine Begleiterscheinung von
kognitiven Behinderungen, Lernbehinderungen und Geh�rlosigkeit sind.
Blindenschrift ist essentiell f�r Taubblinde ebenso wie f�r Menschen, deren
prim�re Behinderung Blindheit ist. Visuell angezeigter Text kommt geh�rlosen
Benutzern ebenso zugute wie der Mehrheit der Web-Benutzer.
Die Bereitstellung von Nicht-Text-�quivalenten f�r Text kommt ebenfalls
manchen Benutzern zugute, besonders solchen, die nicht lesen k�nnen oder
Menschen, die Schwierigkeiten beim Lesen haben. In Filmen oder visuellen
Pr�sentationen ist das visuelle Geschehen, z.�B. die K�rpersprache oder
andere visuelle Signale, m�glicherweise nicht von gen�gend Toninformation
begleitet, um dieselben Informationen zu vermitteln. Solange keine verbalen
Beschreibungen der visuellen Information verf�gbar sind, werden Menschen, die
den visuellen Inhalt nicht sehen k�nnen (oder die nicht hinschauen k�nnen),
nicht in der Lage sein, ihn zu erfassen.
Checkpunkte:
- 1.1 Stellen Sie ein Text-�quivalent
f�r jedes Nicht-Text-Element bereit (z.�B. �ber "alt", "longdesc" oder im
Inhalt des Elements). Dies umfasst: Bilder, grafisch dargestellten
Text (einschlie�lich Symbole), Regionen von Imagemaps, Animationen (z.�B.
animierte GIFs), Applets und programmierte Objekte, ASCII-Zeichnungen,
Frames, Scripts, Bilder, die als Punkte in Listen verwendet werden,
Platzhalter-Grafiken, grafische Buttons, T�ne (abgespielt mit oder ohne
Einwirkung des Benutzers), Audio-Dateien, die f�r sich allein stehen,
Tonspuren von Videos und Videos. [Priorit�t�1]
- Z.�B. in HTML:
- Verwenden Sie "alt" f�r die IMG-, INPUT- und APPLET-Elemente oder
stellen Sie ein Text-�quivalent im Inhalt des OBJECT- und
APPLET-Elements bereit.
- Stellen Sie f�r komplexen Inhalt, wo der "alt"-Text kein
vollst�ndiges Text-�quivalent bietet, eine zus�tzliche Beschreibung
zur Verf�gung, z.�B. �ber "longdesc" bei IMG und FRAME, einen Link
innerhalb eines OBJECT-Elements, oder einen Beschreibungs-Link.
- Verwenden Sie bei Imagemaps entweder das "alt"-Attribut bei AREA
oder das MAP-Element mit A-Elementen (und zus�tzlichem Text) als
Inhalt.
Siehe auch Checkpunkt 9.1 und Checkpunkt 13.10.
- Techniken
f�r Checkpunkt 1.1
- 1.2 Stellen Sie redundante
Textlinks f�r jede aktive Region einer Server-seitigen Imagemap bereit.
[Priorit�t�1]
- Siehe auch Checkpunkt 1.5 und Checkpunkt 9.1.
- Techniken
f�r Checkpunkt 1.2
- 1.3 Stellen Sie eine
Audio-Beschreibung der wichtigen Information der Videospur einer
Multimedia-Pr�sentation bereit, bis
Benutzeragenten das Text-�quivalent einer Videospur vorlesen k�nnen.
[Priorit�t�1]
- Techniken
f�r Checkpunkt 1.3
- Synchronisieren Sie die Audio-Beschreibung mit der
Tonspur gem�� Checkpunkt 1.4. Siehe auch Checkpunkt 1.1 f�r
Informationen �ber Text-�quivalente f�r visuelle Information.
- 1.4 Synchronisieren Sie f�r
jede zeitgesteuerte Multimedia-Pr�sentation (z.�B. Film oder Animation)
�quivalente Alternativen (z.�B. Untertitel oder Audio-Beschreibungen der
Videospur) mit der Pr�sentation. [Priorit�t�1]
- Techniken
f�r Checkpunkt 1.4
- 1.5 Bis Benutzeragenten Text-�quivalente f�r
Client-seitige Imagemaps darstellen, stellen Sie f�r jede aktive Region
einer Client-seitigen Imagemap einen redundanten Textlink bereit.
[Priorit�t�3]
- Siehe auch Checkpunkt 1.2 und Checkpunkt 9.1.
- Techniken
f�r Checkpunkt 1.5
Sorgen Sie daf�r, dass Text und Grafik verst�ndlich sind,
wenn sie ohne Farbe betrachtet werden.
Wenn Farbe allein als Tr�ger von Information benutzt wird, k�nnen
Menschen, die bestimmte Farben nicht unterscheiden k�nnen und Benutzer von
Ger�ten ohne Farbe oder mit nichtvisueller Anzeige die Information nicht
wahrnehmen. Wenn Vordergrund- und Hintergrundfarbe sich im Farbton zu sehr
�hneln, haben sie unter Umst�nden zu wenig Kontrast, wenn sie mit
Schwarzwei�-Monitoren oder von Menschen mit verschiedenen Arten von
Farbenschw�che betrachtet werden.
Checkpunkte:
- 2.1 Sorgen Sie daf�r, dass die gesamte
mit Farbe dargestellte Information auch ohne Farbe verf�gbar ist, z.�B. im
Kontext oder im Markup. [Priorit�t�1]
- Techniken
f�r Checkpunkt 2.1
- 2.2 Sorgen Sie daf�r, dass die
Kombinationen aus Vordergrund- und Hintergrundfarbe ausreichend
kontrastieren, wenn sie von jemandem betrachtet werden, dessen Farbensehen
beeintr�chtigt ist, oder wenn sie mit einem Schwarzwei�bildschirm
betrachtet werden. [Priorit�t�2 f�r Bilder, Priorit�t�3 f�r Text]
- Techniken
f�r Checkpunkt 2.2
Verwenden Sie in Dokumenten die korrekten
Struktur-Elemente. Beeinflussen Sie die Pr�sentation mit Stylesheets anstelle
von Pr�sentations-Elementen und -Attributen.
Inkorrekte Verwendung von Markup -- entgegen der Spezifikation --
beeintr�chtigt die Zug�nglichkeit. Der falsche Gebrauch von Markup f�r
Pr�sentationseffekte (z.�B. die Verwendung einer Tabelle f�r Layout oder
einer �berschrift, um die Schriftgr��e zu �ndern) macht es f�r Benutzer von
spezialisierter Software schwer, den Aufbau einer Seite zu verstehen oder in
ihr zu navigieren. Wenn Pr�sentations-Markup anstelle von Struktur-Markup
verwendet wird, um Struktur zu vermitteln (z.�B. indem etwas, das wie eine
Tabelle aussieht, mit dem PRE-Element von HTML konstruiert wird), erschwert
dies die verst�ndliche Darstellung einer Seite auf anderen Ger�ten (siehe die
Beschreibung des Unterschieds zwischen Inhalt, Struktur
und Pr�sentation).
Entwickler von Inhalten m�gen versucht sein, Konstrukte zu verwenden (oder
zu missbrauchen), die auf �lteren Browsern einen von ihnen gew�nschten
Formatierungseffekt erzielen. Sie m�ssen sich dar�ber im Klaren sein, dass
diese Praktiken Zug�nglichkeitsprobleme verursachen und m�ssen �berlegen, ob
der Formatierungseffekt so entscheidend ist, um daf�r in Kauf zu nehmen, dass
das Dokument f�r manche Benutzer unzug�nglich wird.
Auf der anderen Seite d�rfen Entwickler von Inhalten sich von angemessenem
Markup nicht dadurch abhalten lassen, dass ein bestimmter Browser oder eine
assistive Technologie nicht in der Lage ist, ihn korrekt zu verarbeiten.
Z.�B. ist es angebracht, das TABLE-Element f�r tabellarische
Information zu verwenden, auch wenn manche �lteren Screenreader
nebeneinander angeordneten Text vielleicht nicht korrekt behandeln (siehe Checkpunkt 10.3). Die korrekte
Verwendung von TABLE und die Erstellung von Tabellen, die geschmeidig
transformieren (siehe Richtlinie
5) erm�glichen es der Software, Tabellen auf andere Weise darzustellen
als durch ein zweidimensionales Gitter.
Checkpunkte:
- 3.1 Wenn eine angemessene Markup-Sprache
existiert, verwenden Sie Markup anstelle von Bildern, um Information
darzustellen. [Priorit�t�2]
- Z.�B.: Verwenden Sie MathML f�r mathematische
Gleichungen und Stylesheets, um Text zu formatieren und
das Layout zu beeinflussen. Vermeiden Sie auch die Verwendung von
Bildern zur Darstellung von Texten -- verwenden Sie stattdessen Text
und Stylesheets. Siehe auch Richtlinie 6 und Richtlinie 11.
- Techniken
f�r Checkpunkt 3.1
- 3.2 Erstellen Sie Dokumente, die
gegen ver�ffentlichte formale Grammatiken validieren. [Priorit�t�2]
- Z.�B.: Verwenden Sie eine
Dokumententyp-Deklaration am Anfang Ihres Dokuments, die auf eine
ver�ffentlichte DTD verweist (z.�B. die strict HTML 4.0 DTD)
- Techniken
f�r Checkpunkt 3.2
- 3.3 Verwenden Sie Stylesheets, um
Layout und Pr�sentation zu beeinflussen. [Priorit�t�2]
- Z.�B.: Verwenden Sie die CSS 'font'-Property
anstelle des FONT-Elements von HTML, um den Stil der Schrift zu
beeinflussen.
- Techniken
f�r Checkpunkt 3.3
- 3.4 Verwenden Sie relative anstelle
von absoluten Einheiten in den Attributwerten der Markup-Sprache und
Stylesheet-Property-Werten. [Priorit�t�2]
- Z.�B.: Verwenden Sie in CSS 'em' oder
Prozentgr��en anstelle von absoluten Einheiten wie 'pt' oder 'cm'. Wenn
absolute Einheiten verwendet werden, �berpr�fen Sie, ob die
dargestellte Ausgabe brauchbar ist (Siehe den Abschnitt zum Thema Validierung)
- Techniken
f�r Checkpunkt 3.4
- 3.5 Verwenden Sie
�berschriften-Elemente, um die Struktur eines Dokuments darzustellen und
verwenden Sie sie gem�� der Spezifikation. [Priorit�t�2]
- Techniken
f�r Checkpunkt 3.5
- Z.�B.: Verwenden Sie in HTML H2, um einen
Unterabschnitt von H1 anzuzeigen. Verwenden Sie keine �berschriften f�r
Schrift-Effekte.
- 3.6 Verwenden Sie korrekten Markup
f�r Listen und Listenelemente. [Priorit�t�2]
- Z.�B.: Verschachteln Sie in HTML OL-, UL- und
DL-Listen korrekt.
- Techniken
f�r Checkpunkt 3.6
- 3.7 Verwenden Sie Markup f�r Zitate.
Verwenden Sie keinen Markup, der f�r Zitate gedacht ist, um visuelle
Effekte wie Einr�ckung zu erzielen. [Priorit�t�2]
- Z.�B.: Verwenden Sie in HTML Q und BLOCKQUOTE, um
k�rzere und l�ngere Zitate zu kennzeichnen.
- Techniken
f�r Checkpunkt 3.7
Verwenden Sie Markup, der die Aussprache oder
Interpretation abgek�rzten oder fremdsprachigen Texts erleichtert.
Wenn Entwickler von Inhalten die �nderungen der nat�rlichen Sprache in
einem Dokument kennzeichnen, k�nnen Sprachgeneratoren und
Blindenschrift-Ger�te automatisch zur neuen Sprache wechseln, wodurch das
Dokument zug�nglicher f�r mehrsprachige Benutzer wird. Entwickler von
Inhalten sollten die vorherrschende nat�rliche Sprache kenntlich machen (�ber
Markup oder HTTP-Header). Entwickler von
Inhalten sollten auch die Ausschreibung von Abk�rzungen oder Akronymen
angeben.
Wenn Abk�rzungen und �nderungen der nat�rlichen Sprache nicht kenntlich
gemacht sind, sind sie unter Umst�nden nicht entzifferbar, wenn sie von einem
Sprachgenerator vorgelesen oder mit Blindenschrift angezeigt werden.
Checkpunkte:
- 4.1 Machen Sie in klarer Weise
�nderungen der nat�rlichen Sprache des Dokumententexts und s�mtlicher Text-�quivalente kenntlich. [Priorit�t�1]
- Verwenden Sie z.�B. in HTML das "lang"-Attribut.
Verwenden Sie in XML "xml:lang".
- Techniken
f�r Checkpunkt 4.1
- 4.2 Spezifizieren Sie die
Ausschreibung jeder Abk�rzung und jedes Akronyms an der Stelle des ersten
Auftretens. [Priorit�t�3]
- Z.�B.: Verwenden Sie in HTML das "title"-Attribut
der Elemente ABBR und ACRONYM. Wenn die Ausschreibung im Dokument
selbst angegeben wird, verbessert das auch die Verwendbarkeit.
- Techniken
f�r Checkpunkt 4.2
- 4.3 Machen Sie die vorherrschende
nat�rliche Sprache des Dokuments kenntlich. [Priorit�t�3]
- Setzen Sie z.�B. in HTML das "lang"-Attribut des
Elements. Verwenden Sie in XML "xml:lang". Server-Operatoren sollten
Server so konfigurieren, dass sie aus dem
HTTP-Content-Negotiation-Mechanismus Vorteil ziehen ([RFC2068], Abschnitt 14.13), so dass Clients
automatisch Dokumente in der bevorzugten Sprache anfordern k�nnen.
- Techniken
f�r Checkpunkt 4.3
Sorgen Sie daf�r, dass Tabellen den n�tigen Markup haben,
um von zug�nglichen Browsern transformiert werden zu k�nnen.
Tabellen sollten verwendet werden, um tats�chlich tabellarische
Daten ("Datentabellen") zu kennzeichnen. Entwickler von Inhalten
sollten es vermeiden, sie f�r das Seitenlayout zu verwenden
("Layout-Tabellen"). Tabellen, gleichg�ltig zu welchem Zweck, bedeuten
spezielle Probleme f�r die Benutzer von Screenreadern (Siehe Checkpunkt 10.3).
Manche Benutzeragenten erlauben es Benutzern,
zwischen Zellen von Tabellen zu navigieren und greifen auf �berschriften und
andere Informationen �ber Tabellenzellen zu. Solange kein korrekter Markup
verwendet wird, halten Tabellen f�r die Benutzeragenten keine angemessenen
Informationen bereit (Siehe auch Richtlinie 3).
Die folgenden Checkpunkte kommen unmittelbar Benutzern zugute, die auf
eine Tabelle �ber das Geh�r zugreifen (z.�B. einen Screenreader oder einen
Bordcomputer im Auto) oder die zu einem Zeitpunkt nur einen Teil einer Seite
sehen k�nnen (z.�B. blinde oder sehbehinderte Benutzer mit Sprachausgabe oder
einem Blindenschrift-Display, oder andere Benutzer
von Ger�ten mit kleinen Displays, o. �.)
Checkpunkte:
- 5.1 Kennzeichnen Sie bei Datentabellen
Zeilen- und Spalten�berschriften. [Priorit�t�1]
- Verwenden Sie z.�B. in HTML TD, um Datenzellen,
und TH, um �berschriften zu kennzeichnen.
- Techniken
f�r Checkpunkt 5.1
- 5.2 Wenn Datentabellen zwei oder
mehr logische Ebenen von Zeilen- oder Spalten�berschriften haben, verwenden
Sie Markup, um Datenzellen und �berschriftenzellen einander zuzuordnen.
[Priorit�t�1]
- Verwenden Sie z.�B. in HTML THEAD, TFOOT und
TBODY, um Zeilen zu gruppieren, COL und COLGROUP, um Spalten zu
gruppieren, und die "axis"-, "scope"- und "headers"-Attribute, um
komplexere Zusammenh�nge zwischen Daten zu beschreiben.
- Techniken
f�r Checkpunkt 5.2
- 5.3 Verwenden Sie keine
Tabellen f�r Layout, wenn diese in linearisierter Form keinen Sinn ergeben.
Ansonsten, wenn die Tabelle keinen Sinn ergibt, stellen Sie ein
alternatives �quivalent bereit (das eine linearisierte Version sein kann).
[Priorit�t�2]
- Anmerkung: Sobald Benutzeragenten Positionierung
mit Hilfe von Stylesheets unterst�tzen, sollten Tabellen nicht mehr f�r
Layout-Zwecke benutzt werden. Siehe auch Checkpunkt 3.3.
- Techniken
f�r Checkpunkt 5.3
- 5.4 Wenn eine Tabelle f�r Layout
verwendet wurde, verwenden Sie keinen Struktur-Markup zum Zweck der
visuellen Formatierung. [Priorit�t�2]
- Z.�B.: Verwenden Sie in HTML nicht das TH-Element,
um den Inhalt einer (Nicht-Tabellen�berschriften-)Zelle zentriert und
fett darzustellen.
- Techniken
f�r Checkpunkt 5.4
- 5.5 Stellen Sie Zusammenfassungen
f�r Tabellen bereit. [Priorit�t�3]
- Verwenden Sie z.�B. in HTML das
"summary"-Attribut.
- Techniken
f�r Checkpunkt 5.5
- 5.6 Stellen Sie Abk�rzungen f�r
�berschriften bereit. [Priorit�t�3]
- Verwenden Sie z.�B. in HTML das "abbr"-Attribut
des TH-Elements.
- Techniken
f�r Checkpunkt 5.6
Siehe auch Checkpunkt
10.3.
Sorgen Sie daf�r, dass Seiten auch dann zug�nglich sind,
wenn neuere Technologien nicht unterst�tzt werden oder abgeschaltet sind.
Entwickler d�rfen sich zum Einsatz neuer Technologien zur L�sung von
Problemen, die von existierenden Technologien aufgeworfen werden, ermutigt
f�hlen. Sie sollten jedoch wissen, wie sie es erreichen k�nnen, dass ihre
Seiten weiterhin funktionieren, wenn �ltere Browser zum Einsatz kommen oder
wenn Benutzer sich entscheiden, Features abzuschalten.
- 6.1 Bauen Sie Dokumente so auf,
dass sie ohne Stylesheets gelesen werden k�nnen. Z.�B. wenn ein
HTML-Dokument ohne ihm zugeordnete Stylesheets dargestellt wird, muss es
immer noch m�glich sein, das Dokument zu lesen. [Priorit�t�1]
- Wenn der Inhalt logisch aufgebaut ist, wird er in
einer sinnvollen Reihenfolge dargestellt, auch wenn Stylesheets
abgeschaltet sind oder nicht unterst�tzt werden.
- Techniken
f�r Checkpunkt 6.1
- 6.2 Sorgen Sie daf�r, dass
�quivalente f�r dynamischen Inhalt aktualisiert werden, wenn sich der
dynamische Inhalt �ndert. [Priorit�t�1]
- Techniken
f�r Checkpunkt 6.2
- 6.3 Sorgen Sie daf�r, dass Seiten verwendbar
sind, wenn Scripts, Applets oder andere programmierte Objekte abgeschaltet
sind oder nicht unterst�tzt werden. Ist dies nicht m�glich, stellen Sie
�quivalente Information auf einer alternativen zug�nglichen Seite bereit.
[Priorit�t�1]
- Z.�B.: Sorgen Sie daf�r, dass Links, die Scripts
ausl�sen, funktionieren, wenn Scripts abgeschaltet sind oder nicht
unterst�tzt werden (Verwenden Sie z.�B. nicht "javascript:" als Ziel
eines Links). Wenn es nicht m�glich ist, die Seite ohne Scripts
verwendbar zu machen, stellen Sie ein Text-�quivalent mit dem
NOSCRIPT-Element bereit oder verwenden Sie ein Server-seitiges Script
anstelle eines Client-seitigen oder stellen Sie eine alternative
zug�ngliche Seite bereit gem�� Checkpunkt 11.4. Siehe auch Richtlinie 1.
- Techniken
f�r Checkpunkt 6.3
- 6.4 Sorgen Sie daf�r, dass
die Eingabebehandlung von Scripts und Applets vom Eingabeger�t unabh�ngig
ist. [Priorit�t�2]
- Siehe die Definition von Ger�teunabh�ngigkeit.
- Techniken
f�r Checkpunkt 6.4
- 6.5 Sorgen Sie daf�r, dass dynamischer
Inhalt zug�nglich ist oder stellen Sie eine alternative Pr�sentation oder
Seite bereit. [Priorit�t�2]
- Z.�B.: Verwenden Sie in HTML NOFRAMES am Ende
jedes Framesets. F�r manche Anwendungen sind Server-seitige Scripts
m�glicherweise besser zug�nglich als Client-seitige Scripts.
- Techniken
f�r Checkpunkt 6.5
Siehe auch Checkpunkt
11.4.
Sorgen Sie daf�r, dass bewegte, scrollende oder sich
automatisch �ndernde Objekte oder Seiten angehalten oder gestoppt werden
k�nnen.
Manche Menschen mit kognitiven oder visuellen Behinderungen sind nicht in
der Lage, bewegten Text schnell genug oder �berhaupt zu lesen. Bewegung kann
auch so stark ablenken, dass der Rest der Seite f�r Menschen mit kognitiven
Behinderungen unlesbar wird. Screenreader k�nnen keinen bewegten Text
lesen. Menschen mit physischen Behinderungen k�nnen Bewegungen m�glicherweise
nicht schnell oder genau genug ausf�hren, um mit bewegten Objekten
umzugehen.
Anmerkung: Alle nachfolgenden Checkpunkte beinhalten eine
gewisse Verantwortung des Entwicklers, bis
Benutzeragenten eine angemessene Kontrolle �ber Features
bereitstellen.
- 7.1 Vermeiden Sie Bildschirmflackern,
bis
Benutzeragenten dem Benutzer eine Kontrolle �ber das Flackern
erm�glichen. [Priorit�t�1]
- Anmerkung: Menschen mit
photosensitiver Epilepsie k�nnen Anf�lle erleiden, ausgel�st durch
Flackern oder Aufblitzen im Bereich von 4 bis 59 Hertz (h�chste
Empfindlichkeit bei 20 Hertz) oder durch schnelle Wechsel von Dunkel
nach Hell.
- Techniken
f�r Checkpunkt 7.1
- 7.2 Bis
Benutzeragenten eine Kontrolle �ber das Blinken erm�glichen,
vermeiden Sie es, Inhalt blinken zu lassen (d.h. die Pr�sentation
regelm��ig zu �ndern, z.�B. ab- und einzuschalten). [Priorit�t�2]
- Techniken
f�r Checkpunkt 7.2
- 7.3 Vermeiden Sie Bewegung in Seiten,
bis
Benutzeragenten das Einfrieren von Bewegung erm�glichen.
[Priorit�t�2]
- Wenn eine Seite bewegten Inhalt enth�lt, stellen
Sie im Script oder Applet einen Mechanismus bereit, der den Benutzern
das Einfrieren der Bewegung oder der �nderung des Inhalts erm�glicht.
Die Verwendung von Stylesheets mit Scripts, um Bewegung zu erzeugen,
macht es den Benutzern einfacher, den Effekt abzuschalten oder zu
�ndern. Siehe auch
Richtlinie 8.
- Techniken
f�r Checkpunkt 7.3
- 7.4 Bis
Benutzeragenten es zulassen, den Refresh zu stoppen, erstellen
Sie keine Seiten mit automatischer periodischer Aktualisierung.
[Priorit�t�2]
- Z.�B.: Veranlassen Sie in HTML keine automatische
Aktualisierung von Seiten mittels "HTTP-EQUIV=refresh", bis
Benutzeragenten es zulassen, dieses Feature abzuschalten.
- Techniken
f�r Checkpunkt 7.4
- 7.5 Bis
Benutzeragenten es zulassen, die automatische Weiterleitung
(Redirect) zu stoppen, verwenden Sie keinen Markup, um eine Weiterleitung
zu erzielen. Konfigurieren Sie stattdessen den Server so, dass er eine
Weiterleitung ausf�hrt. [Priorit�t�2]
- Techniken
f�r Checkpunkt 7.5
Anmerkung: Die Elemente BLINK und MARQUEE sind in keiner
HTML-Spezifikation des W3C definiert und sollten nicht verwendet werden. Siehe auch Richtlinie 11.
Sorgen Sie daf�r, dass die Benutzerschnittstelle den
Prinzipien zug�nglichen Designs folgt: ger�teunabh�ngiger Zugriff auf die
Funktionalit�t, Bedienbarkeit �ber die Tastatur usw.
Wenn ein eingebettetes Objekt seine "eigene Schnittstelle" hat, muss die
Schnittstelle -- wie die des Browsers selbst -- zug�nglich sein. Wenn die
Schnittstelle des eingebetteten Objekts nicht zug�nglich gemacht werden kann,
muss eine alternative zug�ngliche L�sung bereitgestellt werden.
Anmerkung: F�r Informationen �ber zug�ngliche
Benutzerschnittstellen ziehen Sie bitte die Zug�nglichkeitsrichtlinien f�r
Benutzeragenten (User Agent Accessibility Guidelines, [WAI-USERAGENT]) und die
Zug�nglichkeitsrichtlinien f�r Tools zur Seitenerstellung (Authoring Tool
Accessibility Guidelines, [WAI-AUTOOL]) zu
Rate.
Checkpunkt:
- 8.1 Machen Sie programmierte
Elemente wie Scripts und Applets direkt zug�nglich oder kompatibel mit
assistiven Technologien [Priorit�t�1, wenn
die Funktionalit�t wichtig und nicht an anderer Stelle
verf�gbar ist, sonst Priorit�t�2]
- Siehe auch Richtlinie 6.
- Techniken
f�r Checkpunkt 8.1
Verwenden Sie Features, die die Aktivierung von
Seitenobjekten �ber eine Reihe von Eingabeger�ten erm�glichen.
Ger�teunabh�ngiger Zugriff bedeutet,
dass der Benutzer mit dem Benutzeragenten oder Dokument �ber sein bevorzugtes
Eingabeger�t (oder Ausgabeger�t) umgeht -- Maus, Tastatur, Sprache, Kopfstab
oder sonstiges. Wenn zum Beispiel ein Kontrollelement eines Formulars nur mit
einer Maus oder einem anderen Zeigeger�t aktiviert werden kann, wird jemand,
der die Seite nicht sieht, oder Spracheingabe oder ein anderes zeigerloses
Eingabeger�t benutzt, nicht in der Lage sein, das Formular zu benutzen.
Anmerkung: Die Bereitstellung von Text-�quivalenten f�r
Imagemaps oder Bilder, die als Links benutzt werden, macht es Benutzern
m�glich, diese Links ohne Zeigeger�t zu benutzen. Siehe auch Richtlinie 1.
Allgemein sind Seiten, die eine Bedienung �ber die Tastatur erlauben, auch
�ber Spracheingabe oder eine Kommandozeilen-Schnittstelle zug�nglich.
Checkpunkte:
- 9.1 Stellen Sie Client-seitige
anstelle von Server-seitigen Imagemaps bereit, au�er wenn die Regionen mit
den verf�gbaren geometrischen Formen nicht definiert werden k�nnen. [Priorit�t�1]
- Siehe auch Checkpunkt 1.1, Checkpunkt 1.2
und Checkpunkt
1.5.
- Techniken
f�r Checkpunkt 9.1
- 9.2 Sorgen Sie daf�r, dass jedes
Element, das �ber seine eigene Schnittstelle verf�gt, in ger�teunabh�ngiger
Weise bedient werden kann. [Priorit�t�2]
- Siehe die Definition von Ger�teunabh�ngigkeit.
- Siehe
auch Richtlinie 8.
- Techniken
f�r Checkpunkt 9.2
- 9.3 Spezifizieren Sie in
Scripts logische Event-Handler anstelle von ger�teabh�ngigen
Event-Handlern. [Priorit�t�2]
- Techniken
f�r Checkpunkt 9.3
- 9.4 Definieren Sie eine logische
Tab-Reihenfolge f�r Links, Formular-Kontrollelemente und Objekte.
[Priorit�t 3]
- Z.�B.: Spezifizieren Sie in HTML die
Tab-Reihenfolge mit dem "tabindex"-Attribut oder sorgen Sie f�r ein
logisches Seitendesign.
- Techniken
f�r Checkpunkt 9.4
- 9.5 Stellen Sie
Tastatur-Kurzbefehle (Shortcuts) f�r wichtige Links (einschlie�lich solcher
in Client-seitigen Imagemaps), Formular-Kontrollelemente und Gruppen von
Formular-Kontrollelementen bereit. [Priorit�t 3]
- Z.�B.: Spezifizieren Sie in HTML Kurzbefehle �ber
das "accesskey"-Attribut.
- Techniken
f�r Checkpunkt 9.5
Verwenden Sie Interim-Zug�nglichkeitsl�sungen, damit
assistive Technologien und �ltere Browser korrekt funktionieren.
�ltere Browser erlauben beispielsweise keine Navigation zu leeren
Textboxen. �ltere Screenreader lesen Listen von aufeinanderfolgenden Links
als einen einzigen Link. Der Zugriff auf diese aktiven Elemente ist daher
schwierig oder unm�glich. Auch kann eine �nderung des aktuellen Fensters oder
das Erscheinen eines neuen Fensters eine desorientierende Wirkung auf
Benutzer haben, die nicht sehen k�nnen, was passiert ist.
Anmerkung: Die folgenden Checkpunkte gelten, bis Benutzeragenten (einschlie�lich assistiver Technologien) sich dieser Probleme
annehmen. Diese Checkpunkte sind als "vorl�ufig" eingestuft, was bedeutet,
dass die Arbeitsgruppe f�r Web-Inhalt-Richtlinien sie als g�ltig und f�r die
Web-Zug�nglichkeit notwendig betrachtet zum Zeitpunkt der
Ver�ffentlichung dieses Dokuments. Die Arbeitsgruppe erwartet jedoch
nicht, dass diese Checkpunkte in der Zukunft n�tig sein werden, wenn
vorweggenommene Features und F�higkeiten Teil von Web-Technologien geworden
sind.
Checkpunkte:
- 10.1 Lassen Sie keine Pop-Ups oder
andere Fenster erscheinen und wechseln Sie das aktuelle Fenster nicht, ohne
den Benutzer zu informieren, bis
Benutzeragenten es gestatten, die Erzeugung neuer Fenster zu
unterbinden. [Priorit�t�2]
- Z.�B.: Vermeiden Sie es, in HTML Frames zu
verwenden, deren Ziel ein neues Fenster ist.
- Techniken
f�r Checkpunkt 10.1
- 10.2 Sorgen Sie bei allen
Formular-Kontrollelementen mit implizit zugeordneten Beschriftungen daf�r,
dass die Beschriftung korrekt positioniert ist, bis Benutzeragenten eine explizite
Zuordnung von Beschriftung und Formular-Kontrollelement erm�glichen.
[Priorit�t�2]
- Die Beschriftung muss unmittelbar vor dem
Kontrollelement in derselben Zeile stehen (was mehr als ein
Kontrollelement mit Beschriftung pro Zeile gestattet) oder in der Zeile
vor dem Kontrollelement (mit nur jeweils einer Beschriftung und einem
Kontrollelement pro Zeile). Siehe auch Checkpunkt 12.4.
- Techniken
f�r Checkpunkt 10.2
- 10.3 Stellen Sie eine lineare
Text-Alternative f�r alle Tabellen bereit, die Text in parallelen
Spalten mit Zeilenumbruch enthalten, bis
Benutzeragenten nebeneinander angeordneten Text korrekt
behandeln. [Priorit�t�3]
- Bitte ziehen Sie die Definition einer linearisierten
Tabelle zu Rate. Dieser Checkpunkt kommt Benutzern zugute,
deren Benutzeragenten (wie z.�B. manche Screenreader) nicht in der Lage sind,
Textbl�cke zu handhaben, die nebeneinander pr�sentiert werden; der
Checkpunkt soll Entwickler von Inhalten nicht davon abhalten, Tabellen
zur Darstellung von tabellarischer Information zu
verwenden.
- Techniken
f�r Checkpunkt 10.3
- 10.4 Bis
Benutzeragenten leere Kontrollelemente korrekt behandeln,
besetzen Sie Felder mit Platzhalter-Zeichen vor. [Priorit�t�3]
- Tun Sie dies z.�B. in HTML f�r TEXTAREA und
INPUT.
- Techniken
f�r Checkpunkt 10.4
- 10.5 Bis
Benutzeragenten (einschlie�lich assistiver Technologien)
beieinanderliegende Links getrennt darstellen, platzieren Sie druckbare
Zeichen, die nicht zu einem Link geh�ren, umgeben von Leerzeichen, zwischen
Links. [Priorit�t�3]
- Techniken
f�r Checkpunkt 10.5
Verwenden Sie W3C-Technologien (entsprechend der
Spezifikation) und befolgen Sie die Zug�nglichkeitsrichtlinien. Wenn es nicht
m�glich ist, W3C-Technologien zu verwenden, oder wenn dies Material ergeben
w�rde, das nicht geschmeidig transformiert, stellen Sie eine alternative
Version des Inhalts bereit, die zug�nglich ist.
Die aktuellen Richtlinien empfehlen W3C-Technologien (z.�B. HTML, CSS
usw.) aus mehreren Gr�nden:
- W3C-Technologien enthalten "eingebaute" Zug�nglichkeits-Features.
- W3C-Technologien werden fr�hzeitig �berpr�ft, um sicherzustellen, dass
Fragen der Zug�nglichkeit in der Design-Phase ber�cksichtigt werden.
- W3C-Technologien werden in einem offenen, auf Industrie-Konsens
basierenden Prozess entwickelt.
Viele Nicht-W3C-Formate (z.�B. PDF, Shockwave o.��.) erfordern zum
Betrachten entweder Plug-Ins oder eigenst�ndige Anwendungen. Oft erlauben
diese Formate kein Betrachten oder keine Navigation mit Standard-Benutzeragenten (einschlie�lich assistiver Technologien). Die Vermeidung
propriet�rer Technologien (propriet�re Elemente, Attribute, Properties und
Erweiterungen) wird in der Tendenz Seiten f�r mehr Menschen besser zug�nglich
machen, unter Verwendung einer breiteren Palette von Hardware und Software.
Wenn nicht zug�ngliche Technologien (propriet�r oder nicht) verwendet werden
m�ssen, m�ssen �quivalente zug�ngliche Seiten bereitgestellt werden.
Auch wenn W3C-Technologien verwendet werden, m�ssen sie gem�� den
Zug�nglichkeitsrichtlinien verwendet werden. Wenn Sie neue Technologien
verwenden, sorgen Sie f�r geschmeidige Transformation (Siehe auch Richtlinie 6).
Anmerkung: Die Konvertierung von Dokumenten (von PDF,
PostScript, RTF usw.) in
W3C-Markup-Sprachen (HTML, XML) ergibt nicht immer ein
zug�ngliches Dokument. �berpr�fen Sie daher nach der Konvertierung jede Seite
auf Zug�nglichkeit und Verwendbarkeit (siehe den Abschnitt zum Thema Validierung). Wenn sich eine Seite
nicht ohne Probleme konvertieren l�sst, �berarbeiten Sie sie entweder, bis
ihre urspr�ngliche Repr�sentation angemessen konvertiert wird oder stellen
Sie eine Version in HTML oder als einfachen Text bereit.
Checkpunkte:
- 11.1 Verwenden Sie
W3C-Technologien, wenn sie verf�gbar und der Aufgabe angemessen sind und
benutzen Sie die neueste Version, wenn sie unterst�tzt wird.
[Priorit�t�2]
- Siehe die Referenzliste
f�r Informationen �ber die neuesten W3C-Spezifikationen und [WAI-UA-SUPPORT] f�r Informationen �ber
die Benutzeragenten-Unterst�tzung f�r W3C-Technologien.
- Techniken
f�r Checkpunkt 11.1
- 11.2 Vermeiden Sie �berholte
Features von W3C-Technologien. [Priorit�t�2]
- Z.�B.: Vermeiden Sie in HTML das �berholte FONT-Element; verwenden Sie
stattdessen Stylesheets (z.�B. die 'font'-Property in CSS).
- Techniken
f�r Checkpunkt 11.2
- 11.3 Stellen Sie Informationen
bereit, so dass Benutzer Dokumente entsprechend ihren Vorgaben (Sprache,
Typ usw.) erhalten k�nnen. [Priorit�t�3]
- Anmerkung: Verwenden Sie Content-Negotiation wo m�glich.
- Techniken
f�r Checkpunkt 11.3
- 11.4 Wenn Sie auch nach besten Bem�hungen keine zug�ngliche Seite
erstellen k�nnen, stellen Sie einen Link auf eine alternative Seite bereit,
die W3C-Technologien verwendet, zug�nglich ist, �quivalente Information (oder
Funktionalit�t) enth�lt und ebenso oft aktualisiert wird wie die nicht
zug�ngliche (originale) Seite. [Priorit�t�1]
- Anmerkung: Entwickler von
Inhalten sollten nur dann auf alternative Seiten zur�ckgreifen, wenn
alle anderen L�sungen fehlschlagen, weil alternative Seiten im
Allgemeinen seltener aktualisiert werden als "prim�re" Seiten. Eine
veraltete Seite kann genauso frustrierend sein wie eine, die nicht
zug�nglich ist, weil die Information auf der urspr�nglichen Seite in
beiden F�llen nicht zug�nglich ist. Automatisch generierte alternative
Seiten m�gen zu einer h�ufigeren Aktualisierung f�hren, aber Entwickler
von Inhalten m�ssen weiterhin darauf achten, dass die generierten
Seiten jederzeit einen Sinn ergeben und dass Benutzer in der Lage sind,
in einer Site zu navigieren, indem sie Links auf den prim�ren Seiten,
den alternativen Seiten oder beiden folgen. Bevor Sie auf alternative
Seiten zur�ckgreifen, �berdenken Sie das Design der Originalseite; sie
zug�nglich zu machen verbessert sie wahrscheinlich f�r alle
Benutzer.
- Techniken
f�r Checkpunkt 11.4
Stellen Sie Informationen zum Kontext und zur
Orientierung bereit, um Benutzern das Verst�ndnis komplexer Seiten oder
Elemente zu erleichtern.
Die Gruppierung von Elementen und die Bereitstellung von
Kontext-Informationen �ber die Beziehungen zwischen Elementen kann f�r alle
Benutzer n�tzlich sein. Komplexe Beziehungen zwischen Teilen einer Seite sind
m�glicherweise f�r Menschen mit kognitiven Behinderungen und Menschen mit
visuellen Behinderungen schwer zu interpretieren.
Checkpunkte:
- 12.1 Betiteln Sie jeden Frame, um
Navigation und Identifikation zu erleichtern. [Priorit�t�1]
- Z.�B.: Benutzen Sie in HTML das "title"-Attribut
f�r FRAME-Elemente.
- Techniken
f�r Checkpunkt 12.1
- 12.2 Beschreiben Sie den Zweck von
Frames und ihre Beziehung untereinander, wenn dies aus den Titeln allein
nicht ersichtlich wird. [Priorit�t�2]
- Z.�B.: Verwenden Sie in HTML "longdesc" oder einen
Beschreibungs-Link.
- Techniken
f�r Checkpunkt 12.2
- 12.3 Unterteilen Sie gro�e
Informationsbl�cke in leichter zu handhabende Gruppen, wo angebracht.
[Priorit�t�2]
- Z.�B.: Verwenden Sie in HTML OPTGROUP, um
OPTION-Elemente in einem SELECT-Element zu gruppieren; gruppieren Sie
Formular-Kontrollelemente mit FIELDSET und LEGEND; verwenden Sie
verschachtelte Listen wo angebracht; verwenden Sie �berschriften, um
Dokumente zu strukturieren usw. Siehe auch Richtlinie 3.
- Techniken
f�r Checkpunkt 12.3
- 12.4 Ordnen Sie Beschriftungen
explizit ihren Kontrollelementen zu. [Priorit�t�2]
- Z.�B.: Verwenden Sie in HTML LABEL und sein
"for"-Attribut.
- Techniken
f�r Checkpunkt 12.4
Stellen Sie klare Navigationsmechanismen bereit --
Informationen zur Orientierung, Navigationsleisten, eine Sitemap usw. --, um
die Wahrscheinlichkeit zu erh�hen, dass eine Person auf einer Site das
findet, was sie sucht.
Klare und konsistente Navigationsmechanismen sind wichtig f�r
Menschen mit kognitiven Behinderungen oder Blindheit und kommen allen
Benutzern zugute.
Checkpunkte:
- 13.1 Identifizieren Sie das Ziel
jedes Links auf klare Weise. [Priorit�t�2]
- Linktext sollte aussagekr�ftig genug
sein, um einen Sinn zu ergeben, wenn er au�erhalb seines Kontexts
gelesen wird -- entweder f�r sich alleine oder als Teil einer Folge von
Links. Linktext sollte zugleich m�glichst knapp sein.
- Z.�B.: Schreiben Sie in HTML "Informationen �ber
Version 4.3" anstelle von "Hier klicken". Zus�tzlich zu einem klaren
Linktext k�nnen Entwickler von Inhalten das Ziel eines Links zus�tzlich
klar stellen, indem sie einen informativen Titel verwenden (z.�B. in
HTML mit dem "title"-Attribut).
- Techniken
f�r Checkpunkt 13.1
- 13.2 Stellen Sie Metadaten bereit, um
semantische Information zu Seiten und Sites hinzuzuf�gen. [Priorit�t�2]
- Z.�B.: Verwenden Sie RDF ([RDF]), um den Autor, den Typ des Inhalts usw.
anzuzeigen.
- Anmerkung: Manche HTML-Benutzeragenten k�nnen
Navigations-Tools aus den Beziehungen des Dokuments erstellen, die mit
dem LINK-Element von HTML und den Attributen "rel" und "rev"
beschrieben sind. (z.�B. rel="next", rel="previous", rel="index" usw.).
Siehe auch Checkpunkt
13.5.
- Techniken
f�r Checkpunkt 13.2
- 13.3 Stellen Sie Informationen zum
allgemeinen Layout einer Site bereit (z.�B. �ber eine Sitemap oder ein
Inhaltsverzeichnis). [Priorit�t�2]
- Heben Sie Zug�nglichkeits-Features in der
Beschreibung einer Site hervor und erl�utern Sie diese.
- Techniken
f�r Checkpunkt 13.3
- 13.4 Verwenden Sie
Navigationsmechanismen in konsistenter Weise. [Priorit�t�2]
- Techniken
f�r Checkpunkt 13.4
- 13.5 Stellen Sie Navigationsleisten bereit,
um den Navigationsmechanismus hervorzuheben und einen Zugriff darauf zu
erm�glichen. [Priorit�t�3]
- Techniken
f�r Checkpunkt 13.5
- 13.6 Gruppieren Sie verwandte Links,
identifizieren Sie die Gruppe (f�r Benutzeragenten), und erm�glichen Sie
das �berspringen der Gruppe, bis
Benutzeragenten dies gestatten. [Priorit�t�3]
- Techniken
f�r Checkpunkt 13.6
- 13.7 Wenn Suchfunktionen verf�gbar sind,
stellen Sie verschiedene Arten der Suche bereit, je nach den F�higkeiten
und Vorlieben der Benutzer. [Priorit�t�3]
- Techniken
f�r Checkpunkt 13.7
- 13.8 Platzieren Sie
unterscheidungskr�ftige Information an den Anfang von �berschriften,
Abs�tzen, Listen usw. [Priorit�t�3]
- Anmerkung: Dies wird auch als
"Front-Loading" bezeichnet und ist besonders hilfreich f�r Menschen,
die auf Information mit seriellen Ger�ten wie Sprachgeneratoren
zugreifen.
- Techniken
f�r Checkpunkt 13.8
- 13.9 Stellen Sie Informationen �ber
Zusammenstellungen von Dokumenten bereit (z.�B. Dokumente, die aus mehreren
Seiten bestehen usw.) [Priorit�t�3]
- Z.�B.: Spezifizieren Sie in HTML
Zusammenstellungen von Dokumenten mit dem LINK-Element und dem "rel"-
und "rev"-Attribut. Ein anderer Weg ist die Erstellung eines Archivs
(etwa mit Zip, Tar und Gzip, Stuffit usw.) aus mehreren Seiten.
- Anmerkung: Die
Performance-Verbesserung durch Offline-Browsen kann das Browsen
erschwinglicher machen f�r Behinderte, die m�glicherweise langsam
browsen.
- Techniken
f�r Checkpunkt 13.9
- 13.10 Erm�glichen Sie das
�berspringen von mehrzeiligen ASCII-Zeichnungen. [Priorit�t�3]
- Siehe Checkpunkt 1.1 und das Beispiel
einer ASCII-Zeichnung im Glossar.
- Techniken
f�r Checkpunkt 13.10
Sorgen Sie daf�r, dass Dokumente klar und einfach
gehalten sind, so dass sie leichter zu verstehen sind.
Konsistentes Seitenlayout, deutliche Grafiken und eine leicht
verst�ndliche Sprache kommen allen Benutzern zugute. Sie sind besonders eine
Hilfe f�r Menschen mit kognitiven Behinderungen, die Schwierigkeiten beim
Lesen haben. (Sorgen Sie jedoch daf�r, dass Bilder Text-�quivalente haben f�r
Menschen, die blind sind oder an Sehschw�che leiden sowie f�r Benutzer, die
Grafiken nicht betrachten k�nnen oder wollen. Siehe auch Richtlinie
1.)
Die Verwendung einer klaren und einfachen Sprache f�rdert effektive
Kommunikation. Der Zugriff auf geschriebene Information kann schwierig sein
f�r Menschen, die kognitive oder Lernschwierigkeiten haben. Die Verwendung
einer klaren und einfachen Sprache kommt auch Menschen zugute, deren
Muttersprache sich von Ihrer unterscheidet, einschlie�lich derer, die sich
haupts�chlich in Geb�rdensprache verst�ndigen.
Checkpunkte:
- 14.1 Verwenden Sie f�r
den Inhalt einer Site die klarste und einfachste Sprache, die angemessen
ist. [Priorit�t�1]
- Techniken
f�r Checkpunkt 14.1
- 14.2 Erg�nzen Sie Text mit grafischen oder
Audio-Pr�sentationen, wo dies das Verst�ndnis der Seite erleichtert.
[Priorit�t�3]
- Siehe auch
Richtlinie 1.
- Techniken
f�r Checkpunkt 14.2
- 14.3 Verwenden Sie einen
Pr�sentationsstil, der �ber Seiten hinweg konsistent ist. [Priorit�t�3]
- Techniken
f�r Checkpunkt 14.3
�berpr�fen Sie die Zug�nglichkeit mit automatischen Tools und
�berpr�fung durch Menschen. Automatisierte Methoden sind im Allgemeinen
schnell und bequem, k�nnen aber nicht alle Zug�nglichkeitsprobleme erkennen.
�berpr�fung durch Menschen kann hilfreich sein, um eine klare Sprache und
einfache Navigation sicherzustellen.
Beginnen Sie mit dem Einsatz von Validierungsmethoden in den fr�hesten
Stufen der Entwicklung. Fr�hzeitig erkannte Zug�nglichkeitsprobleme sind
einfacher zu korrigieren und zu vermeiden.
Nachfolgend einige wichtige Validierungsmethoden, die im Abschnitt �ber
Validierung im Techniken-Dokument im Detail diskutiert werden.
- Verwenden Sie ein automatisches Zug�nglichkeits-Tool und
Browser-Validierungs-Tool. Bitte beachten Sie, dass Software-Tools nicht
alle Zug�nglichkeitsfragen erfassen, so z.�B. die Aussagekraft von
Linktext, die Frage, ob ein Text-�quivalent angebracht ist usw.
- Validieren Sie die Syntax (z.�B. HTML, XML usw.)
- Validieren Sie Stylesheets (z.�B. CSS)
- Verwenden Sie einen Text-Browser oder Emulator.
- Verwenden Sie mehrere Grafik-Browser:
- mit Ton und Grafik aktiviert,
- ohne Grafiken,
- ohne Ton,
- ohne Maus,
- mit deaktivierten Frames, Scripts, Stylesheets und Applets.
- Verwenden Sie mehrere Browser, alte und neue.
- Verwenden Sie einen sprachgenerierenden Browser, einen Screenreader,
Vergr��erungs-Software, ein kleines Display usw.
- Benutzen Sie eine Rechtschreib- und Grammatikpr�fung. Eine Person, die
eine Seite mit einem sprachgenerierenden Browser liest, ist
m�glicherweise nicht in der Lage, ein Wort zu entziffern, das der Browser
f�r ein falsch geschriebenes Wort geraten hat. Die Beseitigung von
Grammatikproblemen verbessert das Verst�ndnis.
- �berpr�fen Sie das Dokument auf Klarheit und Einfachheit.
Lesbarkeitsstatistiken, wie sie von manchen Textverarbeitungen generiert
werden, k�nnen brauchbare Indikatoren f�r Klarheit und Einfachheit sein.
Noch besser ist es, einen Korrekturleser zu bitten, den Inhalt auf
Klarheit zu �berpr�fen. Korrekturleser k�nnen auch die Verwendbarkeit
eines Dokuments verbessern, indem sie auf potentiell bedeutsame
kulturelle Fragen aufmerksam machen, die mit der verwendeten Sprache oder
den verwendeten Icons zusammenh�ngen.
- Fordern Sie Behinderte auf, Dokumente zu �berpr�fen. Behinderte
Benutzer (Anf�nger und Fortgeschrittene) k�nnen wertvollen Feedback �ber
Probleme der Zug�nglichkeit oder Verwendbarkeit und deren Umfang
liefern.
Anmerkung des �bersetzers: F�r diejenigen, die auch das
englische Original zu Rate ziehen m�chten, sind in Klammern die englischen
Begriffe angegeben.
- Abw�rtskompatibel (backward compatible)
- Design, das mit �lteren Versionen einer Sprache,
eines Programms o.��. weiterhin funktioniert.
- Applet (applet)
- Ein Programm, das in eine Web-Seite eingef�gt
wurde.
- �quivalent (equivalent)
- Inhalt ist zu anderem Inhalt �quivalent, wenn beide
in ihrer Pr�sentation dem Benutzer gegen�ber im Wesentlichen dieselbe
Funktion oder denselben Zweck erf�llen. Im Kontext dieses Dokuments
muss das �quivalent im Wesentlichen dieselbe Funktion f�r eine
behinderte Person erf�llen (zumindest soweit dies m�glich ist, unter
Ber�cksichtigung der Art der Behinderung und des Stands der Technik)
wie der prim�re Inhalt dies f�r einen Benutzer ohne Behinderung tut.
Z.�B. kann der Text "Der Vollmond", wenn er dem Benutzer pr�sentiert
wird, dieselbe Information vermitteln wie ein Bild des Vollmonds.
Beachten Sie, dass der Schwerpunkt bei der �quivalenten Information
darauf liegt, dieselbe Funktion zu erf�llen. Wenn das
Bild Teil eines Links ist und das Verst�ndnis des Bildes wesentlich
ist, um das Ziel des Links zu erraten, muss ein �quivalent den
Benutzern auch eine Ahnung vom Ziel des Links vermitteln. Die
Bereitstellung von �quivalenter Information f�r nicht zug�nglichen
Inhalt ist einer der wichtigsten Wege, wie Autoren ihre Dokumente f�r
behinderte Menschen zug�nglich machen k�nnen.
- Indem es dieselbe Funktion wie der Inhalt erf�llt,
kann ein �quivalent den Inhalt zugleich beschreiben (d.h. wie der
Inhalt aussieht oder wie er sich anh�rt). Damit zum Beispiel Benutzer
die Informationen, die ein komplexes Diagramm vermittelt, verstehen
k�nnen, sollten Autoren die visuelle Information des Diagramms
beschreiben.
- Da Textinhalt dem Benutzer in Form von
synthetisierter Sprache, Blindenschrift und visuell dargestelltem Text
pr�sentiert werden kann, sind gem�� diesen Richtlinien Text-�quivalente (text
equivalents) f�r grafische und Audio-Information
erforderlich. Text-�quivalente m�ssen so geschrieben werden, dass sie
alle wesentlichen Informationen vermitteln. Nicht-Text-�quivalente (non-text
equivalents) (z.�B. eine Audio-Beschreibung einer
visuellen Pr�sentation, ein Video, das eine Person zeigt, die eine
Geschichte mittels Geb�rdensprache erz�hlt, als �quivalent f�r einen
geschriebene Geschichte usw.) verbessern ebenfalls die Zug�nglichkeit
f�r Menschen, die auf visuelle Information oder geschriebenen Text
nicht zugreifen k�nnen, so etwa viele Personen mit Blindheit,
kognitiven Behinderungen, Lernbehinderungen und Geh�rlosigkeit.
- �quivalente Information kann auf mehrere Arten
bereitgestellt werden, so �ber Attribute, (z.�B. einen Textwert f�r das
"alt"-Attribut in HTML und SMIL), als Teil des Element-Inhalts (z.�B.
OBJECT in HTML), als Teil des Dokumententexts oder �ber ein mit einem
Link verkn�pftes Dokument. (z.�B. gekennzeichnet �ber das
"longdesc"-Attribut in HTML oder einen Beschreibungs-Link). Je nach der
Komplexit�t des �quivalents kann es erforderlich sein, Techniken zu
kombinieren (z.�B.: Verwenden Sie "alt" f�r ein abgek�rztes �quivalent,
n�tzlich f�r vertraute Leser, zus�tzlich zu "longdesc" f�r einen Link
zu einer vollst�ndigeren Beschreibung f�r Leser, die das Dokument zum
ersten Mal lesen). Die Details dar�ber, wie und wann �quivalente
Information bereitzustellen ist, sind Teil des Techniken-Dokuments ([TECHNIQUES]).
- Ein Text-Transkript (text
transcript) ist ein Text-�quivalent von
Audio-Information, das gesprochene Worte und nicht gesprochene T�ne wie
z.�B. Ger�uscheffekte umfasst. Ein Untertitel
(caption) ist ein Text-Transkript
f�r die Tonspur einer Video-Pr�sentation, die mit der Video- und
Tonspur synchronisiert ist. Untertitel werden �blicherweise
dargestellt, indem sie �ber das Videobild gelegt werden, was geh�rlosen
und schwerh�rigen Menschen sowie solchen, die den Ton nicht h�ren
k�nnen (z.�B. in einem Raum mit vielen Menschen), zugute kommt. Ein kombiniertes Text-Transkript
(collated text transcript)
kombiniert Untertitel mit Textbeschreibungen der Video-Information
(Beschreibungen der Handlung, der K�rpersprache, der Grafiken und
Szenenwechsel der Videospur). Diese Text-�quivalente machen
Pr�sentationen zug�nglich f�r Menschen, die taubblind sind oder die
keine Filme, Animationen o.��. abspielen k�nnen. Es macht die
Information auch f�r Suchmaschinen verf�gbar.
- Ein Beispiel f�r ein Nicht-Text-�quivalent ist eine
Audio-Beschreibung (auditory description) der wichtigen
visuellen Elemente einer Pr�sentation. Die Beschreibung ist entweder
eine aufgezeichnete menschliche Stimme oder eine synthetisierte Stimme
(aufgezeichnet oder zum jeweiligen Zeitpunkt generiert). Die
Audio-Beschreibung ist mit der Tonspur der Pr�sentation synchronisiert,
gew�hnlich w�hrend nat�rlicher Pausen in der Tonspur. H�rbare
Beschreibungen enthalten Informationen �ber Handlung, K�rpersprache,
Grafiken und Szenenwechsel.
- Assistive Technologie
(assistive technology)
- Software oder Hardware, die speziell entwickelt
wurde, um Behinderten bei ihren t�glichen Aktivit�ten zu helfen.
Assistive Technologien sind z.�B. Rollst�hle, Leseger�te, Ger�te zum
Greifen usw. G�ngige assistive Technologien im Bereich der
Web-Zug�nglichkeit sind Screenreader, Bildschirmlupen,
Sprachgeneratoren und Spracheingabe-Software, die in Verbindung mit
grafischen Desktop-Browsern (neben anderen Benutzeragenten) eingesetzt
werden. Assistive Hardware-Technologien sind u.a. alternative
Tastaturen und Zeigeger�te.
- ASCII-Zeichnung (ASCII art)
- Der Begriff ASCII-Zeichnung bezeichnet Zeichen und
Symbole, die so kombiniert wurden, dass sie ein Bild ergeben. Zum
Beispiel ist ";-)" das Smiley-Emoticon. Die folgende ASCII-Zeichnung
zeigt den Zusammenhang zwischen der Frequenz des Aufblitzens und der
photokonvulsiven Reaktion bei Patienten mit offenen und geschlossenen
Augen [ASCII-Abbildung
�berspringen]:
% __ __ __ __ __ __ __ __ __ __ __ __ __ __
100 | * |
90 | * * |
80 | * * |
70 | @ * |
60 | @ * |
50 | * @ * |
40 | @ * |
30 | * @ @ @ * |
20 | |
10 | @ @ @ @ @ |
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70
Frequenz des Aufblitzens (Hertz)
- Benutzeragent (user agent)
- Software zum Zugriff auf Web-Inhalte; dies umfasst
grafische Desktop-Browser, Text-Browser, Sprach-Browser, Mobiltelefone,
Multimedia-Player, Plug-Ins und manche assistive Software-Technologien,
die in Verbindung mit Browsern verwendet werden, wie etwa Screenreader,
Bildschirmlupen und Spracherkennungssoftware.
- Bild (image)
- Eine grafische Pr�sentation.
- Bildschirmlupe
(screen magnifier)
- Ein Softwareprogramm, das einen Teil des Bildschirms
vergr��ert, so dass er einfacher gelesen werden kann. Bildschirmlupen
werden haupts�chlich von sehbehinderten Menschen eingesetzt.
- Bis
Benutzeragenten ... (until user agents
...)
- In den meisten Checkpunkten werden Entwickler von
Inhalten aufgefordert, f�r die Zug�nglichkeit ihrer Seiten und Sites zu
sorgen. Es gibt jedoch Zug�nglichkeitserfordernisse, die besser von
Benutzeragenten erf�llt w�rden (einschlie�lich assistiver
Technologien). Zum Zeitpunkt der Ver�ffentlichung dieses Dokuments
k�nnen nicht alle Benutzeragenten und assistiven Technologien den Grad
von Zug�nglichkeitskontrolle bereitstellen, den die Benutzer ben�tigen
(z.�B. erlauben manche Benutzeragenten nicht das Abstellen von
blinkendem Inhalt, oder manche Screenreader k�nnen nicht gut mit
Tabellen umgehen). Checkpunkte, die die Formulierung "Bis
Benutzeragenten..." enthalten, erlegen dem Entwickler von Inhalten die
Pflicht auf, zus�tzliche Unterst�tzung f�r Zug�nglichkeit
bereitzustellen, bis die meisten Benutzeragenten, die ihrem Publikum
auf einfache Weise verf�gbar sind, die n�tigen Zug�nglichkeits-Features
enthalten.
- Anmerkung: Die WAI-Website des W3C
(siehe [WAI-UA-SUPPORT]) stellt
Informationen �ber die Unterst�tzung von Zug�nglichkeits-Features durch
Benutzeragenten bereit. Entwickler von Inhalten wird empfohlen, f�r
aktuelle Informationen diese Seite regelm��ig zu Rate zu ziehen.
- Blindenschrift (braille)
- Blindenschrift verwendet sechs hervorstehende
Punkte, um Buchstaben und Zahlen zu repr�sentieren, die von Blinden mit
den Fingerspitzen gelesen werden k�nnen. Nachfolgend das Wort "Accessible" in Blindenschrift:
- Ein Blindenschrift-Display (braille display), auch als "dynamic braille display" bezeichnet, hebt oder senkt
Punktmuster, gesteuert durch ein elektronisches Ger�t, gew�hnlich durch
einen Computer. Das Ergebnis ist eine Blindenschrift-Zeile, die sich in
kurzen Zeitabst�nden ver�ndern kann. Die derzeitigen
Blindenschrift-Displays variieren in der Gr��e von einer Zelle (sechs
oder acht Punkte) bis zu einer Zeile von achtzig Zellen. Die meisten
verf�gen �ber zw�lf bis zwanzig Zellen pro Zeile.
- Dynamisches HTML (DHTML)
(dynamic HTML)
- DHTML ist der Marketing-Begriff, der auf einen Mix
von Standards angewandt wird, der HTML, Stylesheets, das Document
Object Model (DOM) und die Verwendung von Scripts umfasst. Es gibt
jedoch keine W3C-Spezifikation, die DHTML formal definiert. Die meisten
Richtlinien sind auf Anwendungen anwendbar, die DHTML verwenden; jedoch
legen die folgenden Richtlinien den Schwerpunkt auf Fragen des
Einsatzes von Scripts und Stylesheets: Richtlinie 1, Richtlinie 3, Richtlinie 6, Richtlinie 7 und Richtlinie 9.
- Element (element)
- Dieses Dokument verwendet den Begriff Element sowohl
im strengen SGML-Sinn (ein Element ist ein syntaktisches Konstrukt) als
auch in einem allgemeineren Sinn in der Bedeutung eines Typs von Inhalt
(z.�B. Video oder Ton) oder eines logischen Konstrukts (wie eine
�berschrift oder eine Liste). Die zweite Bedeutung betont die Tatsache,
dass eine von HTML inspirierte Richtlinie auf einfache Weise auf eine
andere Markup-Sprache angewandt werden kann.
- Entwickler von
Inhalten (content developer)
- Jemand, der Web-Seiten erstellt oder Websites
gestaltet.
- Ger�teunabh�ngig
(device independent)
- Benutzer m�ssen in der Lage sein, unter Verwendung
der unterst�tzten Ein- und Ausgabeger�te ihrer Wahl und entsprechend
ihren Bed�rfnissen mit einem Benutzeragenten umzugehen. Eingabeger�te
k�nnen Zeigeger�te, Tastaturen, Blindenschrift-Ger�te, Kopfst�be,
Mikrophone o.��. sein. Ausgabeger�te k�nnen Monitore,
Sprachgeneratoren, Blindenschrift-Ger�te o.��. sein.
- Bitte beachten Sie, dass "ger�teunabh�ngige
Unterst�tzung" nicht bedeutet, dass Benutzeragenten jedes Eingabe- und
Ausgabeger�t unterst�tzen m�ssen. Benutzeragenten sollten redundante
Eingabe- und Ausgabemechanismen anbieten f�r die Ger�te, die
unterst�tzt werden. Wenn z.�B. ein Benutzeragent Tastatur- und
Mauseingabe unterst�tzt, sollten Benutzer mit allen Features umgehen
k�nnen, indem sie entweder die Tastatur oder die Maus benutzen.
- Imagemap (image map)
- Ein Bild, das in Regionen mit zugeordneten Aktionen
unterteilt wurde. Klicken auf eine aktive Region l�st eine Aktion
aus.
- Wenn ein Benutzer auf eine
aktive Region eine Client-seitigen Imagemap klickt, errechnet der
Benutzeragent, in welcher Region der Klick ausgel�st wurde und folgt
dem Link, der dieser Region zugeordnet ist. Klicken auf eine aktive
Region einer Server-seitigen Imagemap hat zur Folge, dass die
Koordinaten des Klicks an den Server gesandt werden, der dann die
Aktion ausf�hrt.
- Entwickler von Inhalten k�nnen Client-seitige
Imagemaps zug�nglich machen, indem sie einen ger�teunabh�ngigen Zugriff
auf die gleichen Links, die mit den Regionen der Imagemap verkn�pft
sind, bereitstellen. Client-seitige Imagemaps erlauben dem
Benutzeragenten eine unmittelbare R�ckmeldung dar�ber, ob der Zeiger
des Benutzers sich �ber einer aktiven Region befindet.
- Inhalt, Struktur
und Pr�sentation von Dokumenten (document content,
structure, and presentation)
- Als Inhalt eines Dokuments wird das bezeichnet, was
das Dokument dem Benutzer durch nat�rliche Sprache, Bilder, Ton, Filme,
Animationen usw. mitteilt. Die Struktur ist sein logischer Aufbau
(z.�B. nach Kapiteln, mit einer Einf�hrung und einem Inhaltsverzeichnis
usw.). Ein Element (z.�B. P, STRONG, BLOCKQUOTE in HTML), das Struktur
spezifiziert, wird Struktur-Element genannt. Die Pr�sentation eines
Dokuments ist die Art seiner Darstellung (z.�B. als Ausdruck, als
zweidimensionale grafische Pr�sentation, als Text-Pr�sentation, als
synthetisierte Sprache, in Blindenschrift usw.) Ein Element, das
Pr�sentation spezifiziert (z.�B. FONT, CENTER), wird
Pr�sentations-Element genannt.
- Nehmen Sie zum Beispiel eine Dokumenten�berschrift.
Der Inhalt der �berschrift ist, was es besagt (z.�B. "Segelboote"). In
HTML ist die �berschrift ein Struktur-Element, das z.�B. mit einem
H2-Element markiert wird. Die Pr�sentation der �berschrift schlie�lich
kann ein fetter Textblock im Rand, eine zentrierte Textzeile, ein mit
einer bestimmten Stimme gesprochener Titel usw. sein.
- Linearisierte
Tabelle (linearized table)
- Ein Verfahren der Tabellendarstellung, bei die
Inhalte der Zellen zu einer Folge von Abs�tzen werden. Die Abs�tze
erscheinen in derselben Reihenfolge, in der die Zellen im Quelldokument
definiert sind. Die Zellen sollten einen Sinn ergeben, wenn sie in
dieser Reihenfolge gelesen werden und sollten Struktur-Elemente
enthalten (f�r Abs�tze, �berschriften, Listen usw.), so dass die Seite
nach der Linearisierung einen Sinn ergibt.
- Linktext (link text)
- Der dargestellte Textinhalt eines Links.
- Nat�rliche Sprache
(natural language)
- Gesprochene, geschriebene, oder durch Zeichen
dargestellte Sprachen wie Franz�sisch, Japanisch, amerikanische
Geb�rdensprache oder Blindenschrift. Die nat�rliche Sprache kann in
HTML mit dem "lang"-Attribut ([HTML40],
Abschnitt 8.1) und in XML mit dem "xml:lang"-Attribut ([XML], Abschnitt 2.12) angegeben werden.
- Navigationsmechanismus
(navigation mechanism)
- Ein Navigationsmechanismus ist jede Methode, mit der
der Benutzer auf einer Seite oder Site navigieren kann. Einige typische
Mechanismen sind:
- Navigationsleiste (navigation bar)
- Eine Navigationsleiste ist eine Zusammenstellung von Links auf
die wichtigsten Teile eines Dokuments oder einer Site.
- Sitemaps (site
maps)
- Eine Sitemap stellt eine Gesamt�bersicht �ber den Aufbau einer
Seite oder Site bereit.
- Inhaltsverzeichnisse (tables of contents)
- Ein Inhaltsverzeichnis listet im Allgemeinen die wichtigsten
Teile eines Dokuments auf (mit Links).
- Personal Digital Assistant
(PDA)
- Ein PDA ist ein kleiner, tragbarer Rechner. Die
meisten PDAs speichern pers�nliche Daten wie Kalender, Vertr�ge und
E-Mail. Ein PDA ist im Allgemeinen ein Ger�t, das in einer Hand
gehalten werden kann, mit einem kleinen Display, das eine Eingabe aus
verschiedenen Quellen erlaubt.
- Screenreader (screen reader)
- Ein Softwareprogramm, das dem Benutzer den Inhalt
eines Bildschirms vorliest. Screenreader werden haupts�chlich von
blinden Benutzern eingesetzt. Screenreader k�nnen in der Regel keinen
Text lesen, der auf den Bildschirm 'gemalt' wird.
- Stylesheets (style sheets)
- Ein Stylesheet ist eine Menge von Anweisungen, die
die Pr�sentation eines Dokuments spezifizieren. Stylesheets k�nnen drei
Quellen entstammen: Sie k�nnen von demjenigen stammen, der den Inhalt
bereitgestellt hat, sie k�nnen vom Benutzer erstellt oder in
Benutzeragenten eingebaut sein. In CSS ([CSS2])
wird das Zusammenwirken von mit dem Inhalt bereitgestellten, vom
Benutzer erstellten und vom Benutzeragenten bereitgestellten
Stylesheets Kaskade genannt.
- Pr�sentations-Markup (presentation markup) ist Markup, der
einen Stileffekt (anstelle einer Strukturierung) erzielt, so etwa die
B- und I-Elemente in HTML. Beachten Sie, dass die Elemente STRONG und
EM nicht als Pr�sentations-Markup betrachtet werden, da sie Information
enthalten, die nicht von einer bestimmten Schriftart abh�ngig ist.
- Tabellarische
Information (tabular information)
- Wenn Tabellen verwendet werden, um logische
Beziehungen zwischen Daten zu repr�sentieren -- Text, Zahlen, Bilder
usw., wird diese Information "tabellarische Information" genannt und
die Tabellen "Datentabellen". Die durch eine Tabelle ausgedr�ckte
Information kann visuell (durch ein zweidimensionales Gitter), durch
Ton (oft indem den Zellen �berschriftinformation vorangestellt wird)
oder in anderen Formaten dargestellt werden.
- Tool zur
Seitenerstellung (authoring tool)
- HTML-Editoren, Konvertierungstools, Tools, die
Web-Inhalt aus Datenbanken generieren sind s�mtlich Tools zur
Seitenerstellung. Siehe die "Authoring Tool Accessibility Guidelines"
([WAI-AUTOOLS]) f�r Informationen �ber
die Entwicklung von zug�nglichen Tools.
- �berholt (deprecated)
- Ein Element oder Attribut ist �berholt, wenn es
infolge neuerer Konstrukte veraltet ist. �berholte Elemente k�nnen in
zuk�nftigen Versionen von HTML obsolet werden. Der Index der
HTML-Elemente und -Attribute im Techniken-Dokument gibt an, welche
Elemente und Attribute in HTML 4.0 �berholt sind. Autoren sollten die
Verwendung �berholter Elemente und Attribute vermeiden. Benutzeragenten
sollten sie aus Gr�nden der Abw�rtskompatibilit�t weiterhin
unterst�tzen.
- Wichtig (important)
- Information in einem Dokument ist wichtig, wenn das
Verst�ndnis dieser Information entscheidend ist f�r das Verst�ndnis des
Dokuments.
- Zug�nglich (accessible)
- Inhalt ist zug�nglich, wenn er von einem Behinderten
verwendet werden kann.
- Stellvertretende Vorsitzende der Web Content Guidelines Working
Group:
- Chuck Letourneau, Starling Access Services Gregg Vanderheiden, Trace
Research and Development
- W3C-Team-Kontaktpersonen:
- Judy Brewer und Daniel Dardailler
- Wir m�chten den folgenden Personen danken, die mit ihrer Zeit und mit
wertvollen Kommentaren zur Entstehung dieser Richtlinien beigetragen
haben:
- Harvey Bingham, Kevin Carey, Chetz Colwell, Neal Ewers, Geoff Freed,
Al Gilman, Larry Goldberg, Jon Gunderson, Eric Hansen, Phill Jenkins,
Leonard Kasday, George Kerscher, Marja-Riitta Koivunen, Josh Krieger,
Scott Luebking, William Loughborough, Murray Maloney, Charles
McCathieNevile, MegaZone (Livingston Enterprises), Masafumi Nakane,
Mark Novak, Charles Oppermann, Mike Paciello, David Pawson, Michael
Pieper, Greg Rosmaita, Liam Quinn, Dave Raggett, T.V. Raman, Robert
Savellis, Jutta Treviranus, Steve Tyler, Jaap van Lelieveld, und Jason
White
F�r die neueste Version jeder W3C-Spezifikation ziehen Sie bitte die Liste
der W3C Technical Reports zu Rate.
- [CSS1]
- "CSS, level 1 Recommendation", B. Bos, H. Wium Lie (Hrsg.), 17.
Dezember 1996, �berarbeitet 11. Januar 1999. Die CSS1-Empfelung ist:
http://www.w3.org/TR/1999/REC-CSS1-19990111.
Die neueste Version ist verf�gbar unter:
http://www.w3.org/TR/REC-CSS1.
- [CSS2]
- "CSS, level 2 Recommendation", B. Bos, H. Wium Lie, C. Lilley und I.
Jacobs (Hrsg.), 12. Mai 1998. Die CSS2-Empfehlung ist:
http://www.w3.org/TR/1998/REC-CSS2-19980512.
Die neueste Version von CSS2 ist verf�gbar unter:
http://www.w3.org/TR/REC-CSS2.
- [DOM1]
- "Document Object Model (DOM) Level 1 Specification", V. Apparao, S.
Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J.
Robie, R. Sutor, C. Wilson, and L. Wood (Hrsg.), 1. Oktober 1998. Die
DOM Level 1 Empfehlung ist:
http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001.
Die neueste Version von DOM Level 1 ist verf�gbar unter:
http://www.w3.org/TR/REC-DOM-Level-1
- [HTML40]
- "HTML 4.0 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs
(Hrsg.), 17. Dezember 1997, �berarbeitet 24. April 1998. Die HTML 4.0
Empfehlung ist:
http://www.w3.org/TR/1998/REC-html40-19980424.
Die neueste Version von HTML 4.0 ist verf�gbar unter:
http://www.w3.org/TR/REC-html40.
- [HTML32]
- "HTML 3.2 Recommendation", D. Raggett (Hrsg.), 14. Januar 1997. Die
neueste Version von HTML 3.2 ist verf�gbar unter:
http://www.w3.org/TR/REC-html32.
- [MATHML]
- "Mathematical Markup Language", P. Ion and R. Miner (Hrsg.), 7. April
1998. Die MathML 1.0 Empfehlung ist:
http://www.w3.org/TR/1998/REC-MathML-19980407.
Die neueste Version von MathML 1.0 ist verf�gbar unter:
http://www.w3.org/TRREC-MathML.
- [PNG]
- "PNG (Portable Network Graphics) Specification", T. Boutell (Hrsg.),
T. Lane (Mitherausgeber), 1. Oktober 1996. Die neueste Version von PNG
1.0 ist:
http://www.w3.org/TR/REC-png.
- [RDF]
- "Resource Description Framework (RDF) Model and Syntax
Specification", O. Lassila, R. Swick (Hrsg.), 22. Februar 1999. Die
RDF-Empfehlung ist:
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222.
Die neueste Version von RDF 1.0 ist verf�gbar unter:
http://www.w3.org/TR/REC-rdf-syntax
- [RFC2068]
- "HTTP Version 1.1",
R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen, and T.
Berners-Lee, Januar 1997.
- [SMIL]
- "Synchronized Multimedia Integration Language (SMIL) 1.0
Specification", P. Hoschka (Hrsg.), 15. Juni 1998. Die SMIL 1.0
Empfehlung ist:
http://www.w3.org/TR/1998/REC-smil-19980615
Die neueste Version von SMIL 1.0 ist verf�gbar unter:
http://www.w3.org/TR/REC-smil
- [TECHNIQUES]
- "Techniques for Web Content Accessibility Guidelines 1.0", W.
Chisholm, G. Vanderheiden, I. Jacobs (Hrsg.). Dieses Dokument
erl�utert, wie die in "Web Content Accessibility Guidelines 1.0"
definierten Checkpunkte zu implementieren sind. Der neuste Entwurf der
Techniken ist verf�gbar unter:
http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/
- [WAI-AUTOOLS]
- "Authoring Tool Accessibility Guidelines", J. Treviranus, J.
Richards, I. Jacobs, C. McCathieNevile (Hrsg.). Der neueste
Arbeitsentwurf dieser Richtlinien f�r das Design zug�nglicher Tools zur
Seitenerstellung ist verf�gbar unter:
http://www.w3.org/TR/WAI-AUTOOLS/
- [WAI-UA-SUPPORT]
- Diese Seite dokumentiert die Unterst�tzung einiger in diesem Dokument
erw�hnter Zug�nglichkeits-Features durch Benutzeragenten
(einschlie�lich assistiver Technologien). Die Seite ist verf�gbar
unter:
http://www.w3.org/WAI/Resources/WAI-UA-Support
- [WAI-USERAGENT]
- "User Agent Accessibility Guidelines", J. Gunderson and I. Jacobs
(Hrsg.) Der neueste Arbeitsentwurf dieser Richtlinien f�r das Design
zug�nglicher Benutzeragenten ist verf�gbar unter:
http://www.w3.org/TR/WAI-USERAGENT/
- [WCAG-ICONS]
- Informationen �ber Konformit�ts-Icons f�r dieses Dokument und deren
Verwendung ist verf�gbar unter:
http://www.w3.org/WAI/WCAG1-Conformance.html
- [UWSAG]
- "The Unified Web Site Accessibility Guidelines", G. Vanderheiden, W.
Chisholm (Hrsg.) Die Unified Web Site Guidelines wurden
zusammengestellt vom Trace R
& D Center an der Universit�t von Wisconsin, finanziert durch
das National Institute on Disability and Rehabilitation Research
(NIDRR),� US-Bildungsministerium (Dept. of Education). Dieses Dokument
ist verf�gbar unter:
http://www.tracecenter.org/docs/html_guidelines/version8.htm
- [XML]
- "Extensible Markup Language (XML) 1.0.", T. Bray, J. Paoli, C.M.
Sperberg-McQueen (Hrsg.), 10. Februar 1998. Die XML 1.0 Empfehlung ist:
http://www.w3.org/TR/1998/REC-xml-19980210.
Die neueste Version von XML 1.0 ist verf�gbar unter:
http://www.w3.org/TR/REC-xml
