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.

�berblick

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]).

Status dieses Dokuments

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 wai-wcag-editor@w3.org.

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.

1. Einf�hrung

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.

2. Themen zug�nglichen Designs

Die Richtlinien umfassen zwei allgemeine Themen: f�r geschmeidige Transformation zu sorgen und Inhalte verst�ndlich und navigierbar zu machen.

2.1 F�r geschmeidige Transformation sorgen

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.

2.2 Inhalte verst�ndlich und navigierbar machen

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.

3. Wie die Richtlinien aufgebaut sind

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.

3.1 Dokument-Konventionen

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.

4. Priorit�ten

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.

5. Konformit�t

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].

6. Zug�nglichkeitsrichtlinien f�r Web-Inhalte

Richtlinie 1. Stellen Sie �quivalente Alternativen f�r Audio- und visuellen Inhalt bereit.

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

Richtlinie 2. Verlassen Sie sich nicht auf Farbe allein.

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

Richtlinie 3. Verwenden Sie Markup und Stylesheets und tun Sie dies auf korrekte Weise.

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

Richtlinie 4. Verdeutlichen Sie die Verwendung nat�rlicher Sprache.

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

Richtlinie 5. Erstellen Sie Tabellen, die geschmeidig transformieren.

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.

Richtlinie 6. Sorgen Sie daf�r, dass Seiten, die neue Technologien verwenden, geschmeidig transformieren.

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.

Richtlinie 7. Sorgen Sie f�r eine Kontrolle des Benutzers �ber zeitgesteuerte �nderungen des Inhalts.

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.

Richtlinie 8. Sorgen Sie f�r direkte Zug�nglichkeit eingebetteter Benutzerschnittstellen.

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

Richtlinie 9. W�hlen Sie ein ger�teunabh�ngiges Design.

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

Richtlinie 10. Verwenden Sie Interim-L�sungen.

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

Richtlinie 11. Verwenden Sie W3C-Technologien und -Richtlinien.

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

Richtlinie 12. Stellen Sie Informationen zum Kontext und zur Orientierung bereit.

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

Richtlinie 13. Stellen Sie klare Navigationsmechanismen bereit.

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

Richtlinie 14. Sorgen Sie daf�r, dass Dokumente klar und einfach gehalten sind.

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

Anhang A -- Validierung

�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.

1. 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.
2. Validieren Sie die Syntax (z.�B. HTML, XML usw.)
3. Validieren Sie Stylesheets (z.�B. CSS)
4. Verwenden Sie einen Text-Browser oder Emulator.
5. Verwenden Sie mehrere Grafik-Browser:
   • mit Ton und Grafik aktiviert,
   • ohne Grafiken,
   • ohne Ton,
   • ohne Maus,
   • mit deaktivierten Frames, Scripts, Stylesheets und Applets.
6. Verwenden Sie mehrere Browser, alte und neue.
7. Verwenden Sie einen sprachgenerierenden Browser, einen Screenreader, Vergr��erungs-Software, ein kleines Display usw.
8. 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.
9. �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.
10. 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.

Anhang B - Glossar

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.

Danksagung

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

Referenzen

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