Die Web Content Accessibility Guidelines (WCAG), ausgearbeitet von einer Arbeitsgruppe der WAI vom W3C, erläutern, wie Web-Inhalte für behinderte Menschen zugänglich gemacht werden können.
Die WCAG 1.0 richten sich an die Entwickler von Web-Inhalten, also die Autoren und Gestalter von Web-Sites und an die Entwickler von Tools zur Seitenerstellung. Würden diese Werkzeuge die Umsetzung der Barrierefreiheit unterstützen, würde der Aufwand zur Realisierung barrierefreier Web-Auftritte erheblich sinken. Die jetzigen Autorenwerkzeuge vergrößern eher den Aufwand, da sie oft keinen sauberen, validen Code produzieren und die Umsetzung der Richtlinien im Nachhinein manuell vorgenommen werden muss.
Die WCAG 2.0 richten sich nicht nur an die Entwickler, Autoren und Programmierer von Web-Sites, sondern auch an andere Gruppen wie Politiker und Manager, welche die Aufträge planen und vergeben. Dafür wurde versucht, dass Dokument so lesbar und anwendbar wie möglich zu gestalten, ohne dabei auf die Genauigkeit und Klarheit zu verzichten, die technische Spezifikationen benötigen [![[extern, englisch]](../../lib/img/en.gif)
25].
Die Richtlinien bieten Zugänglichkeitsgrundsätze und Design-Ideen an, die sowohl im Prozess der Erstellung als auch zur Bewertung der Web-Site ihre Anwendung finden sollen. Sie sind als Werkzeuge und Hilfsmittel zu sehen, mit denen der Grad der Zugänglichkeit bzw. Barrierefreiheit bestimmt werden kann [![[intern]](../../lib/img/intern.gif)
19].
Es werden zum einen eine Reihe von Regeln aufgestellt, um die theoretischen Erkenntnisse mit den Merkmalen existierender Systeme zu vergleichen, zum anderen bieten die Richtlinien einen Satz von Regeln an, um die Ergebnisse des Vergleichs bewerten zu können. Die Ergebnisse können dann zur Korrektur der theoretischen Befunde und zur Verbesserung des Nutzersystems genutzt werden, um damit die höchstmögliche Stufe der Barrierefreiheit zu erreichen [ 19].
Die WCAG sollen die Entwickler nicht davon abhalten, Bilder, Videos und andere Multimedia-Elemente einzusetzen, sondern erläutern, wie diese Multimedia-Inhalte zugänglich gestaltet und umgesetzt werden können. Werden die Gestaltungsprinzipien nicht umgesetzt, so könnten behinderte Menschen entweder gar keinen Zugang zum Inhalt bekommen oder diesen nur mit Schwierigkeiten erfassen [ 34].
Wenn Inhalte für unterschiedlichste Ein- und Ausgabegeräte zugänglich gemacht werden, so werden diese auch für Menschen in den unterschiedlichsten Situationen zugänglich sein. Sie können dann nämlich auch mit adaptiven Strategien und assistiven Technologien Zugang zu den Informationen erhalten. Die Richtlinien behandeln typische Szenarien, die Benutzer mit bestimmten Behinderungen vor Probleme stellen. So wird zum einen deutlich, welche Benutzergruppen von der Umsetzung bestimmter Punkte profitieren und zum anderen, wie wichtig dessen Realisierung ist [ 34].
Die Versionen 1.0 und 2.0 der WCAG unterscheiden sich in Aufbau, Struktur und Handhabung so wesentlich, dass in separaten Abschnitten einzeln auf sie eingegangen werden muss, um sie anschließend vergleichen zu können.
Die WCAG 1.0 haben zwei allgemeine Themen der zugänglichen Gestaltung in den Fokus gesetzt. Die erste Forderung ist, für eine unverfälschte Transformation der Inhalte zu sorgen, d.h. es sollen Dokumente erstellt werden, die mit den verschiedensten Ein- und Ausgabegeräten richtig dargestellt und wahrge-nommen werden können. Das zweite wichtige Thema dieser Richtlinien ist die Forde-rung, die Inhalte verständlich und navigierbar zu gestalten. Dies bedeutet, die Inhalte klar und einfach zu halten und verständliche Mechanismen zur Navigation zwischen und innerhalb der Seiten bereitzustellen, wie z.B. Navigationstools und Informationen zur Orientierung, denn diese erhöhen die Zugänglichkeit und Verwendbarkeit der Inhalte [ 34].
Für den Einstieg in das Dokument wird im ersten Abschnitt die Zielstellung und der Zusammenhang mit anderen W3C-Dokumenten angegeben. Das Kapitel Einführung im WCAG-Dokument möchte zuerst einmal das Bewusstsein für die Probleme schaffen, auf die bestimmte Nutzergruppen stoßen können und zeigt anhand von Beispielen die Wichtigkeit von barrierefreien Web-Inhalten auf.
Außerdem wird auch schon an dieser Stelle betont, dass jede Entscheidung für zugängliches Design im Allgemeinen mehreren Gruppen von behinderten Menschen und der ganzen Gemeinschaft von Internet-Nutzern zugute kommt [ 34].
Im Vorfeld der eigentlichen Richtlinien werden noch die 2 Hauptthemen genannt und eingeordnet und Erklärungen zum Aufbau des Dokuments, der Prioritäten und Konformitätsstufen gegeben.
Einen kurzen schematischen Überblick über den Aufbau der Richtlinien gibt die folgende Liste:
Die 2 Themen werden in insgesamt 14 Richtlinien aufgeschlüsselt, die jeweils durch eine Nummer und die Aussage gekennzeichnet sind, so dass sie auch referenziert werden können. Jede Richtlinie erläutert zuerst das ihr zugrundeliegende Prinzip und nennt die Benutzergruppen, die von deren Einhaltung profitieren.
Dann bietet sie jeweils eine Liste von Checkpunkt-Definitionen, welche erläutern, wie die Richtlinie in typischen Situationen der Entwicklung von Inhalten Anwendung findet. Jede dieser Definitionen umfasst wiederum eine Nummer und die Aussage des Checkpunktes. Außerdem wird die Priorität des jeweiligen Checkpunktes sowie informative Anmerkungen, erläuternde Beispiele und Querverweise auf verwandte Richtlinien oder Checkpunkte angegeben.
Die Checkpunkte sollen so genügend spezifisch formuliert sein, dass mit ihnen an einem bestimmten Web-Auftritt überprüft werden kann, ob der Checkpunkt erfüllt worden ist.
Jedem Checkpunkt wurde eine Prioritätsstufe zugeordnet, die seinen Einfluss auf die Zugänglichkeit ausdrücken soll. Es gibt 3 Prioritätsstufen, mit deren Einhaltung dann auch die Konformität des Web-Auftritts mit den Richtlinien 1.0 definiert wird.
Die Priorität 1 ist als Muss-Forderung formuliert und deren Erfüllung wird als grundlegende Erfordernis dargelegt, damit bestimmte Gruppen das Web-Dokument verwenden können. Die Priorität 2 ist als Soll-Forderung ausgedrückt. Mit der Umsetzung der Checkpunkte mit dieser Priorität werden signifikante Hindernisse für den Zugriff auf Web-Sites beseitigt. Die Erfüllung der Priorität 3, welche als Kann-Bestimmung formuliert ist, soll den Zugang zu Web-Inhalten erleichtern [ 34].
Die Konformitätsstufe "A" bedeutet also die korrekte Umsetzung aller Checkpunkte der Prioritätsstufe 1. Äquivalent dazu setzt die Konformitätsstufe "Double-A" die Erfüllung aller Checkpunkte der Priorität 1 und 2 voraus und die Stufe "Triple-A" die vollständige Realisierung der Checkpunkte mit den Prioritäten 1, 2 und 3.
Erhebt eine Web-Site oder auch nur Teile dieser den Anspruch auf Konformität mit diesen Richtlinien, so wird die erfüllte Konformitätsstufe mit einem Verweis auf das Referenzdokument auf jeder Seite angegeben, die diesen Anspruch erhebt [ 34].
Die WCAG 1.0 beinhalten im Anhang außerdem Informationen zur Validierung, also wie die Zugänglichkeit überprüft werden kann, und die 10 wichtigsten Validierungsmethoden, welche im Dokument zu den Techniken weiter im Detail diskutiert werden. Des Weiteren befindet sich im Anhang ein Glossar zu wichtigen Begriffen, die im Dokument verwendet werden und eine Liste von Referenzen zu den einzelnen W3C-Spezifikationen.
Weiterhin ist noch anzumerken, dass die Anforderungen und Bedingungen der Anlage der "Barrierefreie Informationstechnik-Verordnung" (BITV) grundsätzlich auf den WCAG 1.0 basieren, die Prioritätsstufen allerdings auf andere Art zugeteilt sind. Die BITV sieht zwei Prioritätsstufen vor.
Dabei wurden die Checkpunkte der Richtlinien mit der Priorität 1 und 2 zur Priorität I zusammengefasst und die Checkpunkte der Priorität 3 werden unter der Prioritätsstufe II aufgelistet. In der Anlage der BITV sind außerdem auch nur die Forderungen der Checkpunkte ohne Angaben von Beispielen oder konkreten Techniken angeführt.
Da der Gesetzgeber keinen Einfluss auf die W3C-Spezifikationen nehmen kann, werden rechtlich verbindliche Standards auf Grundlage der WCAG 1.0 erarbeitet.
Die BITV sind ausdrücklich vor, die Verordnung unter Berücksichtigung der technischen Entwicklung regelmäßig zu prüfen und spätestens nach drei Jahren auf ihre Wirkung hin zu überprüfen [ 20]. Bei der Überarbeitung der BITV werden dann wahrscheinlich die WCAG 2.0 als Grundlage dienen, da diese eine Verbesserung der Version 1.0 darstellen und zu jenem Zeitpunkt wahrscheinlich vom W3C verifiziert wurden.
Im Augenblick werden die internationalen Gesetze und Verordnungen gesammelt, um zu sehen, ob und wie die WCAG 1.0 in die Rechtssprechung eingeflossen ist und welche Auswirkungen das auf die Entwicklung der WCAG 2.0 bezüglich Übersetzbarkeit und Umsetzbarkeit in nationale Richtlinien und Gesetze haben könnte [![[extern, deutsch]](../../lib/img/de.gif)
50].
Die BITV (Barrierefreie Informationstechnik-Verordnung) ist am 24.07.2002 in Kraft getreten, kurz nach dem BGG (Behindertengleichstellungsgesetz), dessen §11 sie ausführt [ 52]. Seitdem haben wir verbindliche Regeln für barrierefreies Internet in Deutschland.
Nach einem Jahr Gültigkeit hat z.B. das AbI (Aktionsbündnis barrierefreie Informationstechnik) in seiner Benchmarking-Studie an 60 Internetangeboten des Bundes, der Länder und auch von Städten die Wirkung der BITV getestet. Keiner der Kandidaten verdiente das Prädikat "barrierefrei" im Sinne der BITV. Jedoch waren bei 16 Kandidaten entsprechende Bemühungen zu erkennen, und zwar überwiegend bei Angeboten des Bundes. Nur 3 der erkennbar um Barrierefreiheit Bemühten gehörten zu Ländern und Kommunen. Es tut sich also wirklich etwas unter dem heilsamen Zwang der BITV [ 57].
Bei den Ländern und Kommunen kann es noch länger dauern, denn ihre Verpflichtung auf Barrierefreiheit hängt ab von den erst langsam nachkommenden LGGs (Landesgleichstellungsgesetze). Am 25. Juni hat Bayern sein LGG verabschiedet und ist damit das vierte in der Runde derer, die wie das BGG eine barrierefreie Informationstechnik fordern. Da stimmt es etwas nachdenklich, dass noch kein Bundesland eine Durchführungsverordnung entsprechend der BITV erlassen hat. Nirgends außerhalb der Bundesbehörden haben wir verbindliche Terminpläne [ 53].
Post, Bahn, Telefonbuchverlage und andere privatwirtschaftliche Einrichtungen müssen nicht die Barrierefreiheit aktiv betreiben, sondern dürfen laut BGG abwarten, bis sie von einem autorisierten Behindertenverband zu einer Zielvereinbarung gebeten werden. Voraussetzung ist nur, dass die Verbände bereit sind. Das Zielvereinbarungsregister beim BMGS (Bundesministerium für Gesundheit und Soziales) ist eingerichtet und verzeichnet mit Datum Mai 2003 den ersten Eintrag. Es geht um die Barrierefreiheit im öffentlichen Nahverkehr, hier die Stuttgarter Stadtbahn [ 53]. Es ist also zu erkennen, dass die Verordnung durchaus schon praktische Relevanz in Deutschland erreicht hat.
Die WCAG 1.0 sind Teil einer Reihe von Zugänglichkeitsrichtlinien, die von der Web Accessibility Initiative (WAI) veröffentlicht wurden. Um die Übereinstimmung des erstellten Web-Auftritts mit den Checkpunkten der WCAG 1.0 zu erleichtern, wird in dem dazugehörigen Dokument "Checklist of Checkpoints forWeb Content Accessibility Guidelines 1.0" eine tabellarische Zusammenstellung und eine einfache Liste der Checkpunkte, geordnet nach Thema und Priorität, angeboten [ 34].
Außerdem gehört zu dieser Reihe ein weiteres separates Dokument, welches die Techniken für die Richtlinien enthält und erläutert, wie die einzelnen Checkpunkte zu implementieren sind. Es befasst sich detailliert mit jedem Checkpunkt und enthält Beispiele unter Verwendung der verschiedenen aktuellen Markup-Sprachen. Des Weiteren enthält es Techniken zur Validierung und zum Testen von Web-Dokumenten. Dieses Dokument nimmt Bezug auf konkrete Technologien und muss daher auf dem neuesten Stand bleiben und öfter aktualisiert werden als die Richtlinien [ 34].
Des Weiteren gehören noch die Richtlinien für User Agents und Autorentools zu der Reihe der Zugänglichkeitsrichtlinien, die von der Web Accessibility Initiative veröffentlicht wurden. Für die vollständige Umsetzung und Evaluation der Richtlinien auf Web-Sites werden also die 3 Dokumente der WCAG 1.0 benötigt.
Die vom W3C im Mai 1999 verabschiedeten WCAG 1.0 sind inzwischen nicht nur in Gesetze und Verordnungen in verschiedenen Ländern eingeflossen, sondern bilden auch die Basis für viele der bekannten Testwerkzeuge wie "Lift" und "Bobby".
Alle diese Verordnungen und Testwerkzeuge haben ein gemeinsames Problem: viele der in der WCAG 1.0 gemachten Vorgaben sind entweder zu restriktiv, irrelevant oder zu unverständlich, sie entsprechen nicht mehr dem Stand der Technik oder sie sind international nicht durchsetzbar. Die WCAG-Arbeitsgruppe hat diese Problematik natürlich auch erkannt und arbeitet schon seit geraumer Zeit an einem Nachfolger. Dieser wird dann im nächsten Abschnitt erläutert [ 33].
Die WCAG 1.0 enthalten insgesamt 14 Richtlinien und 65 Checkpunkte und sind damit sehr detailliert und konkret verfasst worden. Die Checkpunkte sind sehr spezifisch und die Beispiele geben eine konkrete Technik zur Umsetzung an. Dies könnte den Entwickler dazu verleiten, nur das Beispiel zu realisieren und das relativ umfangreiche Techniken-Dokument außen vor zu lassen.
Außerdem könnte die recht hohe Anzahl an Checkpunkten abschrecken, die Richtlinien vollständig umzusetzen. In den WCAG werden auch viele Punkte mehrmals in verschiedenen Kontexten genannt, so dass sie dann auch schnell überlesen werden könnten, weil dieser vermutlich schon umgesetzt wurde.
Manche Punkte werden von Entwicklern und Gestaltern auch als nicht praxistauglich und nicht relevant oder als zu kompliziert angesehen und daher nach eigenem Ermessen nicht realisiert. Die WCAG 1.0 ist zum größten Teil sehr technisch und in Fachsprache formuliert, so dass jemand mit dem Ehrgeiz, seine Web-Site barrierefrei zu gestalten, der aber nicht konkret dazu geschult oder ausgebildet worden ist, sich abwenden könnte, da erst Fachbücher studiert werden müssen, um die einzelnen Checkpunkte zu verstehen.
Sehr gut zu handhaben ist das Prinzip der Prioritätsstufen, da sie eine Orientierung für Entwickler und Gestalter bieten und Barrierefreiheit quasi in Stufen erreicht werden kann. Die Checkpunkte der Priorität 1 sind größtenteils ohne viel finanziellen und zeitlichen Aufwand umzusetzen und der Web-Auftritt kann damit zumindest barrierearm gestaltet werden.
Die WCAG 1.0 setzen eher auf das Ideal der barrierefreien Seite, sehen Barrierefreiheit aber nicht als Prozess an, der sich dem Idealzustand nähern will. Eine für wirklich alle barrierefreie Web-Site ist sehr schwer zu realisieren, weil es sehr viele Behinderungsarten und andere Einschränkungen zu bedenken gilt und es letztlich wohl auch eine Kostenfrage ist, ob z.B. alle Inhalte mit einem Dolmetscher in Gebärdensprache übersetzt werden können [ 50].
Damit ist es eine Spezifikation ohne Kompromisse und setzt absolute, messbare Maßstäbe fest. Entschließt sich der Entwickler allerdings einen Checkpunkt anders umzusetzen, so wird seine Web-Site wahrscheinlich nicht vollständig durch die automatischen Tools validieren und das offizielle Logo der Konformität nicht ausgegeben. Eine andersartige Realisierung ist vor allem dann angebracht, wenn Praxiserfahrungen gezeigt haben, dass durch die standardkonforme Umsetzung Mitglieder der angesprochenen Zielgruppen Probleme beim Zugang und Verständnis der Informationen bekommen haben, denn manche Behinderungsformen benötigen bestimmte Umsetzungsformen, die andere mit anderen Behinderungsformen von der Nutzung ausschließen. Die Einhaltung der Richtlinien garantiert also nicht die praktische Zugänglichkeit, was zur Folge hat, dass die erstellten Web-Auftritte intensiv mit Betroffenen getestet werden müssen. Hierbei besteht dann allerdings die Gefahr, dass jeder Betroffene seine persönlichen Anliegen verallgemeinert und die Entwickler aus einer Anzahl sich zum Teil widersprechenden Forderungen selektieren müssen, was am besten wie umzusetzen ist.
Die Version 1.0 ist also möglicherweise zu konkret formuliert, was auf der einen Seite zwar dabei helfen kann, die Richtlinien umzusetzen, auf der anderen Seite aber bei andersartiger Umsetzung keine Konformität mehr erreicht. Außerdem könnte die benötigte Einarbeitungszeit in die 3 zusammengehörigen Dokumente, deren Umsetzung und dessen Evaluation Auftraggeber davon abhalten, Barrierefreiheit als Kriterium in das Pflichtenheft mit aufzunehmen, da sie dafür einen zu großen finanziellen und zeitlichen Aufwand befürchten.
Ein weiterer Kritikpunkt liegt darin, dass die WCAG und damit auch die BITV fast nur auf HTML bezogen sind und selten andere Techniken zeigen oder empfehlen, selbst wenn diese schon entwickelt und besser einsetzbar waren, und somit diese Dokumente schon zum Zeitpunkt der Erstellung quasi veraltet waren. Auch dieser Punkt soll in den WCAG 2.0 korrigiert werden.
Die WCAG 2.0 vom W3C baut auf die Version 1.0 auf, soll aber vor allem generalisierter gelesen werden und sich an ein größeres Zielpublikum wenden. Natürlich verfolgen die Richtlinien das gleiche Ziel, nämlich zu erklären, wie Web-Inhalte für Menschen mit Behinderungen zugänglich gestaltet werden können und wie die verschiedenen Level der Zugänglichkeit erreicht werden können [ 50].
Die in dieser Version vorgestellten Design-Prinzipien berücksichtigen mehr Konzepte, die in web-basierten Inhalten Anwendung finden, sind aber nicht mehr spezifisch auf HTML, XML oder andere Techniken bezogen. Dieses Verfahren wurde gewählt, um die Gestaltungsprinzipien auf eine Vielfalt von Situationen und Technologien anwenden zu können, selbst wenn diese Technologien noch nicht existieren [ 25].
Das Gesamtziel und damit die Forderungen der WCAG 2.0 sind, Web-Inhalte so zu gestalten, dass sie für die größtmögliche Anzahl von Benutzern wahrnehmbar, bedienbar, navigierbar, verständlich und mit der großen Zahl der bestehenden und zukünftigen Benutzeragenten und assistiven Technologien kompatibel sind [ 25].
Ein wichtiges Ziel der WAI mit der Erarbeitung des WCAG 2.0 ist eben aber auch einen Standard zu erschaffen, der ohne weiteres in die internationale Gesetzgebung umgesetzt und von der Privatwirtschaft für Ausschreibungen eingesetzt werden kann.
Für den richtigen Umgang mit dem Dokument wird in der Einführung der WCAG 2.0 wieder deren Zielstellung formuliert und Angaben dazu geliefert, wie das Dokument aufgebaut und zu lesen ist. Des Weiteren wird das angesprochene Publikum und der Gültigkeitsbereich des Dokuments abgesteckt und die Aufteilung der nun verwendeten Niveaus und Konformitätsstufen erklärt. Im Anschluss daran werden die fünf Hauptforderungen kurz erläutert und Beispiele zu Situationen angegeben, in denen Benutzer auf Barrieren treffen könnten.
Auch die WCAG 2.0 bestehen aus einer Reihe von zusammenhängenden Dokumenten, um das Verständnis der Richtlinien zu erleichtern und den Anwendern zu helfen, die für sie relevanten Teile des Dokuments fokussieren zu können. Es existieren im wesentlichen drei Schichten der Richtlinien.
Die Hauptschicht gibt einen Überblick über die Gestaltungsprinzipien und beinhaltet die Richtlinien und Checkpunkte. Diese Schicht wird durch das WCAG 2.0-Dokument repräsentiert [ 25].
Die zweite Schicht besteht aus den technologie-spezfischen Checklisten, die Informationen darüber anbieten, was bei der Verwendung der verschiedenen Technologien erforderlich ist, um die Zugänglichkeitsrichtlinien einzuhalten [ 25]. Diese Dokumente existieren zum gegenwärtigen Zeitpunkt allerdings noch nicht.
Die Grundschicht besteht aus den Informationen zu den technologie-spezfischen Anwendungen, ähnlich dem Techniken-Dokument der Version 1.0. Diese Dokumente sollen Code-Beispiele, Screenshots und andere spezifische Informationen zu den Technologien beinhalten und nicht-normativ sein. Sie werden verschiedene Strategien und gegenwärtig bevorzugte Verfahren enthalten, wie die Anforderungen erreicht werden können und außerdem wird auf verschiedene Markup-Sprachen und Techniken eingegangen [ 25].
Der Aufbau der Richtlinien wird zunächst kurz schematisch dargestellt:
Die Forderungen ergeben die 5 Richtlinien der Zugänglichkeit, die zuerst wieder die Hauptaussage und die Notwendigkeit der Umsetzung formulieren. Jede dieser Richtlinien beinhaltet wiederum mehrere, nicht auf eine bestimmte Technologie spezifizierte Checkpunkte, allerdings hier insgesamt nur 21. Die Checkpunkte sind natürlich auch wieder mit einer Nummer und ihrer Kernaussage charakterisiert und bestehen weiterhin aus den normativen Erfolgskriterien und den nicht-normativen Definitionen, Angaben zu Vorteilen bzw. Nutzen für die verschiedenen Benutzergruppen und Beispielen.
Zu jedem Checkpunkt werden direkt die benötigten Definitionen der verwendeten Begriffe angegeben, die im Anhang des Dokuments auch noch in einer geordneten Reihenfolge zu finden sein werden. Außerdem werden der Information wegen die Nutzergruppen genannt, die von der Umsetzung des Checkpunktes profitieren und wie sich konkret der Vorteil und Nutzen für diese Gruppen auswirkt. Des Weiteren werden zu jedem Checkpunkt Beispiele angegeben, die verbal und ohne technische Details beschreiben, an welchen Stellen die Umsetzung der Checkpunkte Anwendung finden sollten und wie sie aussehen könnten.
Eine wertvolle Hilfe für alle an einem Webprojekt Beteiligten werden die neuen Erfolgskriterien sein, in denen beschrieben wird, wie ein Webangebot sich verhalten muss, um die Vorgaben eines bestimmten Checkpunktes erfüllt zu haben. Wenn z.B. ein Testprogramm in der Lage ist, die Hierarchie und die logische Struktur eines Textes aus dem QuellCode zu ziehen, so ist damit die Richtlinie 1.3 erfüllt. Im Falle einer HTML-Seite würde das dann bedeuten, dass der Autor zur Auszeichnung der Überschriften die dafür vorgesehenen Überschriftenelemente ***h1-h6 benutzt hat [ 33].
Die WCAG 2.0 weisen den Checkpunkten keine Prioritätsstufen zu, sondern definieren 3 verschiedene Niveaus der Implementierung in den Erfolgskriterien, die als "Minimum", "Level 2" und "Level 3" bezeichnet werden. Das bedeutet, dass jeder Checkpunkt auf einem unterschiedlichen Niveau implementiert werden kann, also entweder nur die minimalen oder noch darüber hinausgehende Forderungen erfüllt werden, aber jeder Checkpunkt umgesetzt wird.
Um Anspruch auf Konformität mit den Richtlinien erheben zu können, müssen also zumindest alle Checkpunkte auf dem Minimum-Niveau erfüllt sein, welche einen wesentlichen Vorteil für behinderte Menschen bedeuten, da damit die grundlegenden Barrieren beim Zugang und Umgang mit Web-Inhalten entfernt werden [ 25].
Für das Erreichen weiterer Konformitätsstufen werden verschiedene Möglichkeiten angeboten. Werden alle Kriterien der Level 2 oder 3 erreicht, so können diese Stufen angegeben werden. Wenn der Web-Auftritt manche aber nicht alle Kriterien des Levels 2 erreicht, so nennt sich die Konformitätsstufe 1+. Analog dazu wird die Stufe 2+ vergeben, wenn alle Kriterien des Levels 2 und manche, aber nicht alle, des Levels 3 umgesetzt wurden [ 25].
In der neusten Version vom 24. Juni 2003 wurden die Level nochmals umbenannt, nämlich in "Core"- und "Extended"- Stufen, die nicht den Prioritäten in den WCAG 1.0 entsprechen sollen. Zu jedem Checkpunkt gehören außerdem je ein oder mehrere "Best-Practise"-Punkte, die nicht zwingend umgesetzt werden müssen, aber dem Benutzer der Richtlinien die Umsetzung dieser erleichtern sollen. Die Checkpunkte mit der "Core"- Auszeichnung sind generell umzusetzen, damit ein Web-Dokument für den größten Teil der Nutzer zugänglich wird. Die "Extended"-Checkpunkte sind als zusätzliche Punkte zu sehen, die in Zusammenhang mit dem jeweiligen "Core"-Checkpunkt aufgezeigt werden. Dementsprechend heißen die Konformitätsstufen "WCAG 2.0 Core", "WCAG 2.0 Extended" und "WCAG 2.0 Core+", wobei für letztere alle Punkte der "Core"-Kategorie und manche aber nicht alle der "Extended"-Kategorie zu erfüllen sind [ 26].
Die WCAG 2.0 soll mehr ergebnisorientiert arbeiten, d.h. bewertet wird nicht mehr das, was beim Absender losgeschickt wird, sondern das, was beim Empfänger ankommt. Erst wenn dieses Ergebnis für die weitaus meisten Menschen benutzbar ist, kann sich eine Web-Site wirklich barrierefrei nennen [ 33].
Im Anhang des Dokuments wird ähnlich wie in der ersten Version ein Glossar und Informationen zu den mitwirkenden Personen angeboten. Außerdem werden kurz die Unterschiede der beiden Versionen und die Verbesserungen der zweiten Version aufgelistet und wiederum eine Liste von Referenzen zu den einzelnen W3C-Spezifikationen angegeben.
Die zweite Version der WCAG basiert auf der ersten Version und vereinigt und reflektiert Meinungen und Erfahrungen mit dem ersten Dokument. Diese sind auch im Archiv der Mailing-Liste einzusehen [ 49]. Der vorliegende Arbeitsentwurf fokussiert die Checkpunkte und versucht, die Richtlinien auf ein größeres Feld von Technologien anwendbar zu gestalten und Begriffe zu verwenden, die von einem breiteren Zielpublikum verstanden werden können. Die Checkpunkte sollen viel allgemeiner, vor allem weniger HTML-spezifisch, gelesen werden können [ 50].
Seit der Veröffentlichung des stabilen WCAG 1.0-Dokuments im Mai 1999 sammelte die Arbeitsgruppe der Richtlinien in einer Mailing-Liste Meinungen zu den Prioritäten, der Handhabbarkeit der Dokumente und Anfragen zu Klarstellungen von Bedeutungen spezieller Checkpunkte und deren zufriedenstellender Umsetzung [ 49].
Mit der Berücksichtigung dieser Punkte beabsichtigt die zweite Version zuerst einmal effektiver organisiert zu sein. Dazu werden die Prioritäten einiger Checkpunkte angepasst und Anforderungen modifiziert, entfernt oder hinzugefügt, die mit den Änderungen der Internet-Technologien seit der ersten Veröffentlichung notwendig sind. Außerdem reflektiert die Version 2.0 Erfahrungen, die bei der Implementierung der Checkpunkte der WCAG 1.0 gesammelt wurden [ 25].
Die Überarbeitung der Richtlinien bietet mehrere Verbesserungen gegenüber der ersten Version und verfolgt neben dem gleichen Hauptziel, die Zugänglichkeit für Web-Inhalte zu steigern, weitere Ziele, die diese Weiterentwicklung beinhalten. Zum ersten sollen die Anforderungen technologieübergreifend anwendbar sein.
Dann sollen die Konformitätsanforderungen für die einzelnen Checkpunkte klarer formuliert und das veröffentlichte Dokument einfacher zu handhaben sein. Die Arbeitsgruppe für die WCAG 1.0 hat sich außerdem zum Ziel gesetzt, das Dokument für ein breiteres und vielfältigeres Publikum zu schreiben [ 25].
Für jeden Checkpunkt soll klarer angegeben werden, wer von dem zugänglicher gestalteten Inhalten profitiert. Zu guter letzt soll sicher gestellt werden, dass die neuere Version abwärtskompatibel zur WCAG 1.0 ist. Aus diesem Grund und zur leichteren Migration von 1.0 auf 2.0 existiert ein Dokument, dass Checkpunkt für Checkpunkt der beiden Versionen miteinander vergleicht und zuordnet [ 24].
Eine Möglichkeit dazu wäre der gerade aktuell diskutierte Ansatz, die "Core"-Kriterien als Muss, die "Extended"-Kriterien als Soll und die "Best Practices"- Punkte als "Nice to have" ohne normativen Charakter festzulegen. Das entspräche dann zumindest von der Struktur her dem aus den WCAG1 bekannten A-, AA- und AAA-Prinzip, allerdings mit verbesserten und umsortierten Inhalten [ 33].
Kurz formuliert ist die Zusammenfassung folgende:
Hier wird schnell deutlich, dass meistens mehrere Checkpunkte der ersten Version zu einem Checkpunkt zusammengefasst wurden. Die Anzahl solcher Punkte wurde von 65 auf 21 reduziert und damit überschaubarer gemacht. Die einzelnen Checkpunkte gehen nicht mehr so ins Detail, was es zu beachten gilt, sondern versuchen es über Beispiele anzudeuten. Damit soll erreicht werden, dass das Dokument generalisierter gelesen werden kann.
Manche Teilnehmer der Mailing-Liste allerdings sehen diese Art der Umsetzung als wenig praktikabel an, da die Abstufungen zu weich gestaltet sind. Mit den sehr allgemeiner gehaltenen Regeln für nahezu alles und jeden werden die vielen Sonderfälle nicht betrachtet und die Forderungen und Ansprüche zu ungenau angegeben. Ein mögliches Ergebnis daraus könnte sein, dass Unternehmen und Agenturen eigene Hausregeln für Barrierefreiheit erschaffen, wie es beispielsweise auch bei IBM schon passiert ist, und normale Anbieter die Richtlinien gar nicht einsetzen, weil die Anforderungen zu unklar sind [ 50]. So befürchten es zumindest die Diskussionsteilnehmer.
Sehr positiv hingegen bewerten sie die sinnvolle Zusammenfassung in die 5 Richtlinien. So werden auch die Redundanzen in der ersten Version entfernt. Außerdem sehen sie mit der überarbeiteten Form der Richtlinien die Möglichkeiten größer, das Dokument schon früher in der Entwicklung und Gestaltung der Inhalte einsetzen zu können und nicht nur nachträglich zum Testen [ 50].
Obwohl es auch bei den WCAG 1.0 bedacht wurde, dieses in der Konzeption und Entwicklung einzusetzen, gestaltete es sich dort schwierig, da die Checkpunkte doch sehr technologie-spezfisch formuliert sind. In der zweiten Version können die Richtlinien und Checkpunkte in die Überlegungen für das Konzept und die Gestaltung mit einbezogen werden und beim Testen kann geprüft werden, ob die Erfolgskriterien erfüllt wurden. Des Weiteren befinden die Mitglieder der Liste die Vor-Ort-Definitionen, die sehr verständlich geschrieben sind, und die Angabe der besseren Zugänglichkeit für die einzelnen Benutzergruppen für gut, denn diese könnten auch bei der Erstellung des Pflichtenheftes zu Rate gezogen werden [ 50].
Insgesamt ist die Wichtigkeit der einzelnen Punkte zwischen den Dokumenten verlagert worden, was sich vor allem in den 5 Richtlinien der WCAG 2.0 wiederspiegelt. Die Zugänglichkeitsrichtlinien 1.0 bestanden bis auf die Richtlinien 12 bis 14 aus Anweisungen zur Umsetzung von Techniken, damit die Inhalte passfähig transformieren und nicht von einem bestimmten Hardwaretyp abhängig sind. Nur die letzten drei Richtlinien befassen sich damit, Orientierungs- und Navigationshilfen bereitzustellen und möglichst einfach und klar formulierte Informationen anzubieten.
In der zweiten Version wird letzterem 3 von 5 Richtlinien zugeordnet, die Wahrnehmbarkeit, die Navigierbarkeit und die Verständlichkeit.
Damit liegt der Fokus nicht mehr so stark darauf, die Inhalte technisch korrekt umzusetzen und damit für die technische Zugänglichkeit zu sorgen, sondern vor allem darauf, die Inhalte auch für größere Benutzergruppen verständlich zu gestalten. In diesem Punkt liegt aber auch das Hauptproblem, denn es ist schwer zu definieren, was beispielsweise einen Text für alle klar und simpel zu verstehen macht. Auch können manche Inhalte nicht verändert werden, weil sie urheberrechtlich geschützt sind. Andere Inhalte, z.B. wissenschaftliche Arbeiten oder Forschungsergebnisse, können nicht in eine sehr einfache Sprache transformiert werden.
Für diesen Punkt sind also auch schwer objektive Kriterien zu bestimmen, welche auf alle Arten von Inhalten und Web-Sites anwendbar sind. Die Erfolgskriterien für diese Richtlinien stehen noch vollständig unter Bearbeitung. An deren Stelle sind momentan die Diskussionspunkte und die Schwierigkeiten, Kriterien zu finden, der Arbeitsgruppe aufgeführt. Außerdem birgt dieser Teil den größten Zeit- und Arbeitsaufwand und wird von keinem automatisierten Validierungstool geprüft werden können. Es können nur Anhaltspunkte zum Bedenken dieses Problems angegeben werden und der Autor muss sich bemühen, die Inhalte mit der einfachsten und klarsten Sprache, die ihm möglich ist, zu vermitteln.
Die Überlegungen und Aussagen des Abschnitts "3.3 WCAG 2.0" wurden anhand des Arbeitsentwurfes mit Stand vom 18. April 2003 aufgestellt und formuliert. Allerdings ist zu beachten, dass es sich wirklich um Entwürfe handelt, die noch keinerlei normativen Charakter haben, sondern nur der Diskussion in der WCAG-Arbeitsgruppe und der interessierten Öffentlichkeit dienen und sich noch ändern können.
Nach dem Abschluss der Bearbeitung dieses Kapitels wurde tatsächlich eine weitere überarbeitete Version der WCAG 2.0 veröffentlicht und diese beinhaltet wiederum veränderte Punkte, die für die Bearbeitung dieses Abschnitts noch nicht berücksichtigt werden konnten.
Es handelt sich eben noch um ein den Veränderungen unterworfenes Dokument, deshalb werden im folgenden einige neuere Änderungen angeführt.
Der alte (aber zur Zeit natürlich weiterhin gültige) Standard besaß insgesamt 14 einzelne Richtlinien zu unterschiedlichen Aspekten der barrierefreien Webentwicklung. Die ersten Entwürfe des Nachfolgers hatten diese weiter zusammengefasst und bestanden nur noch aus 5 Richtlinien (Perceivable, Operable, Navigable, Understandable and Robust), wobei diese in der letzten Fassung weiter auf nur noch vier Richtlinien zusammengefasst wurden (Perceivable, Operable, Understandable and Robust).
Jede dieser Richtlinien enthält nun mehrere Checkpunkte (z.Zt. insgesamt 18, im ersten Entwurf 21), die entweder Kernanforderungen ("Core", d.h. ein deutliches Muss) oder Soll-Anforderungen ("Extended") sind. Alle diese Anforderungen beziehen sich nicht auf bestimmte Technologien wie HTML oder CSS, sondern sind so gehalten, dass sie auf alle bereits vorhandenen oder zukünftigen Technologien anwendbar sind [ 33].
In der Liste der "Core"-Checkpunkte werden sich im Gegensatz zum Vorläufer keine Vorgaben mehr finden, die nicht eindeutig testbar und verifizierbar sind. Die aktuelle Version leidet ja bekanntlich unter dem Mangel, dass sie weder durch Maschinen, die dann doch wieder nur eine Liste mit "User Checks" ausgeben noch durch 5 menschliche Prüfer, die hinterher zu 6 Ergebnissen kommen, eindeutig und unmissverständlich überprüfbar ist. Ziel der Neufassung ist, dass alle Anforderungen eindeutig durch maschinelle Prüfverfahren oder, da wo dies nicht möglich ist, durch geschulte Evaluatoren testbar sind [ 33].
Außerdem wurden im aktuellen Arbeitsentwurf weitere Überlegungen für deutliche Konformitätserklärungen angestellt und veröffentlicht. Anbieter, die sich zur Einhaltung der WCAG 2.0 verpflichten, müssen also den Mindeststandard der "Core"-Checkpunkte erfüllen und können darüber hinaus in einer Konformitätserklärung beschreiben, welche weitergehenden Kriterien man freiwillig oder auf Grund einer bestimmten Nutzerstruktur erfüllt hat. Also zum Beispiel Core plus Extended 1.3, 2.1, 2.2 und 4.5.
Der so informierte Benutzer einer solchen Seite weiß dann, dass er hier mit seiner Braille-Zeile arbeiten kann, weil die notwendigen Techniken berücksichtigt sind und er nicht erst beim gescheiterten Versuch der Betätigung des Bestellknopfes merkt, dass "Bobby approved" (Auszeichnung nach einem Check mit dem automatischen Prüftool "Bobby", siehe auch Abschnitt 9.2.2) leider nur für die Startseite eines mehrseitigen Bestellvorgangs galt [ 33].
Eine wichtige Vorgabe für die Entwicklung der WCAG 2.0 ist, dass dieser Standard besser als der Vorläufer für den weltweiten Einsatz geeignet sein muss. Dabei geht es noch nicht mal um solche Dinge wie die Vorgabe zur Auszeichnung von Abkürzungen und Akronymen, wo sich nicht einmal Amerikaner und Briten einigen können, was denn das eine und was das andere sei [ 33].
Die WCAG 2.0 sollen sich ohne weiteres in nationale Gesetzgebung und Normen umsetzen lassen und diese Gesetze sollen dann auch zueinander kompatibel sein. Ansonsten wäre es z.B. denkbar, dass eine Technik in Europa ausdrücklich gefordert wird, in den USA aber verboten ist - "dann hätten entweder Microsoft und IBM ein Problem oder Europa kein Betriebssystem mehr. Viele Firmen mit gemeinsamen Vertriebsorganisationen für Deutschland, Österreich, Schweiz oder sogar für ganz Mitteleuropa haben dann außerdem das Problem, dass man bei ihnen zwar mit der selben Währung einkaufen kann, sie aber trotzdem für jedes Land einen eigenen Online-Shop anbieten müssten, nur weil die jeweiligen Standards zur Barrierefreiheit etwas anderes als Mindestanforderung verlangen" [ 33].
Dieser Punkt ist auch einer der Gründe dafür, dass sich der Entwurf im Vergleich zu seinem Vorläufer kürzer und präziser präsentiert: alles was nicht vollständig und exakt verifizierbar ist (und davon gibt es in den WCAG 1.0 und damit auch in der BITV nicht wenig) kann kein Muss-Kriterium ("Core") sein [ 33].
Nach der unverbindlichen Schätzungen von W3C-Mitarbeitern ist bis Februar 2004 mit einem sog. "Last Call" (letzte Gelegenheit zur Kritik) zu rechnen. Der Status eines "Release Candidate" (Veröffentlichungskandidat) wäre dann voraussichtlich noch im ersten Quartal 2004 erreicht, und wenn es keine Komplikationen gibt, steht die finale Version 2.0 gegen Ende des zweiten Quartals 2004 bereit.
Wobei spätestens der "Last Call" so stabil sein sollte, dass damit ernsthaft gearbeitet werden kann. Zum Prozess der Verabschiedung gehört nämlich auch, dass Beispiel-Implementationen gesucht oder erstellt werden, um die tatsächliche Umsetzbarkeit zu gewährleisten und das geht nur mit einem einigermaßen stabilen Dokument [ 33].
Die in der Mailing-Liste diskutierten Problembereiche finden sich sowohl in der ersten Version als auch in den WCAG 2.0 wieder. Viele Fragen und Diskussionen gab es auch zu den konkreten Umsetzungen einzelner Checkpunkte. Zum Teil wird sogar über Sinn und Zweck mancher Checkpunkte und Anforderungen diskutiert.
In den WCAG 2.0 wird z.B. gefordert, den Sprachwechsel von der vorwiegenden Sprache, z.B. deutsch, zu einer anderen, wenn z.B. Begriffe oder Zitate in englisch wiedergegeben werden, innerhalb eines Textes zu markieren. In der Mailing-Liste wiederum wird gesagt, dass diese Sprachwechsel von fast allen Browsern und assistiven Technologien ignoriert oder nicht zufriedenstellend umgesetzt werden [ 50].
Gleichermaßen in beiden Dokumenten wird die Notwendigkeit hervorgehoben, Textäquivalente für jedes Nicht-Text-Element und Nicht-Textäquivalente zu Text bereitzustellen. In der Mailing-Liste wird das Problem unter dem Aspekt diskutiert, dass viele Agenturen einfach eine gesonderte Nur-Text-Version bereitstellen, diese als barrierefrei deklarieren und damit das Problem der eingeschränkten Zugänglichkeit gelöst sehen [ 50].
Damit wird aber wieder eine Sonderlösung geschaffen, was erstens nicht das Ziel sein darf und daher nur einen Übergangszustand darstellen sollte und zweitens höchstens einen Mehrwert für blinde und sehbehinderte Internetnutzer bringt, da die textbasierten Browser und deren Zusatzmittel besseren Zugang erhalten könnten.
Auch die Trennung von Inhalt und Präsentation wird in den zwei Dokumenten betont. Dies ist ja gerade mit den XML-Technologien und dem Einsatz von Content Management Systemen gut zu realisieren.
Unter diesen Voraussetzungen ist auch die Forderung nach der Konsistenz in der Präsentation leicht zu erfüllen. Außerdem können Strukturinformationen leichter gesetzt werden und die Umsetzung einer Struktur im Inhalt wird unterstützt.
Dies sind ebenfalls Diskussionspunkte in der Mailing-Liste und werden in der zweiten Version der Zugänglichkeitsrichtlinien stärker hervorgehoben als in deren Erstausgabe.
Ein weiterer wichtiger Punkt, der sowohl in der Mailing-Liste als auch in den Richtlinien beider Versionen angesprochen wird, ist das geräteunabhängige Design und die Forderung, sich nach den W3C-Techniken und Richtlinien zu richten. Oft liegt aber auch das Problem auf der Seite der Benutzeragenten, da diese selbst W3C-Spezifikationen nicht korrekt umsetzen. In anderen Fällen passiert es, dass manche Technologien von dem einen Browser korrekt dargestellt werden und mit dem anderen wiederum gar nicht oder sehr fehlerhaft. In solchen Fällen müssen wenigsten zugängliche Alternativlösungen erstellt werden oder es ist dafür zu sorgen, dass es auch ohne eine bestimmte Version des Browsers oder ohne ein bestimmtes PlugIn darstellbar ist und Informationen aufgenommen werden können [ 50]. Die WCAG 2.0 erweitern dies sogar und fordern eine Gestaltung, die auch für zukünftige Technologien und Benutzeragenten und natürlich auch für ältere Varianten dieser so zugänglich wie möglich ist [ 25].
Ein Problem, welches in der Mailing-Liste außerdem oft diskutiert und wofür nach Lösungen gesucht wird, ist die richtige und zugängliche Gestaltung von Formularen, deren Beschriftungen und dem Umgang mit Platzhaltern in solchen Formular-Kontrollelementen [ 50].
In den WCAG 1.0 werden diese Fragen in einzelnen Checkpunkten betrachtet und versucht zu lösen. In dem Dokument sind diese Checkpunkte allerdings auch als vorläufig eingestuft, bis sich Benutzeragenten einschließlich der assistiven Technologien dieser Probleme annehmen. In den WCAG 2.0 werden diese Punkte nicht explizit aufgeführt oder erläutert.
In den WCAG 2.0 finden sich auch Kriterien und Anhaltspunkte für die barrierefreie Gestaltung umfangreicher Web-Sites und vor allem deren kritischer Navigationsgestaltung. Dies war und ist ebenfalls ein Thema bei den Teilnehmern der Mailing-Liste.
Ein anderer Diskussionspunkt liegt immer wieder bei der Wahl und Angabe der richtigen Schrift und Schriftgröße. In den WCAG 1.0 wird dazu noch gesagt, dass relative Einheiten anstelle von absoluten verwendet werden sollten [ 34]. Im zweiten Dokument sind weder zu den zu verwendenden Schriftarten noch zu den Schriftgrößen Angaben zu finden.
Natürlich können diese nicht komplett objektiv angegeben werden, denn die Lesbarkeit der Schriften hängt von vielen verschiedenen Faktoren ab und ist individuell zu beurteilen, aber Empfehlungen wären für die Orientierung hilfreich.
Die WCAG 2.0 geben Richtlinien und Checkpunkte vor, die beachtet werden sollten, wenn Web-Inhalte zugänglich gestaltet werden, sie geben aber keine Hinweise mehr auf die konkrete Realisierung. Außerdem ist es fraglich, wie die Erfolgskriterien für die einzelnen Niveaus bei wirklich allen Checkpunkten objektiv geprüft werden können. Dies erschwert natürlich auch die Konformitätstests mit den Dokumenten.
In der Mailing-Liste wird immer wieder über die korrekte Umsetzung spezifischer Checkpunkte diskutiert, da entweder die Anforderungen zu ungenau sind oder das Problem in den Richtlinien nicht behandelt wird. So entstehen oft Arten von Zwischenlösungen, die dann zwar nicht WCAG-konform sind, aber aus Erfahrungen die bestmögliche Zugänglichkeit für bestimmte Nutzergruppen bieten.
Zusammenfassend lässt sich sagen, dass die zweite Version der WCAG deutlich weniger technologie-spezfisch und allgemein verständlicher verfasst ist. Der Fokus des Dokuments liegt in der Verbesserung der Zugänglichkeit für die Informationsaufnahme und den Interaktionsmöglichkeiten für möglichst alle Ein- und Ausgabegeräte und nicht in deren technischer Umsetzung [ 25].
Vielleicht werden die oben angesprochenen Problembereiche auch in den dazugehörigen Dokumenten der WCAG beantwortet oder zumindest Hinweise und Empfehlungen dazu angeboten. Das Hauptdokument mit den Richtlinien und Checkpunkten ist sehr allgemein geschrieben und deshalb werden die Dokumente mit den technologie-spezfischen Checklisten und Anwendungen einen wesentlichen Beitrag leisten müssen, um die Anforderungen insgesamt oder zum größten Teil auf das jeweilige Dokument umsetzen zu können.
Die Handhabbarkeit dieser Richtlinien wird sich erst herausstellen, wenn alle dazugehörigen Dokumente veröffentlicht sind und angewendet werden können. Manche in der Mailing-Liste angesprochenen Probleme finden sich durchaus in den Richtlinien wieder. Ob diese eindeutiger gelöst sind, wird sich in der Praxis zeigen, aber die konkrete Umsetzung und der Grad der Barrierefreiheit wird wahrscheinlich für jede einzelne Web-Site mehr Möglichkeiten und damit auch Ansätze für Diskussionen bieten. Trotzdem oder vielleicht auch gerade deswegen ist eine praktische Überprüfung von Accessibility mit transparenten Prüf- und auch Zertifizierungsverfahren dringend nötig.
Lesen Sie, warum ich mich an die Standards halte und warum das Layout mit Cascading Style Sheets statt Tabellen oder Frames gestaltet wurde. Sollten Sie Probleme mit dem Layout haben, so finden Sie in der Liste standardkonformer Browser Links zu entsprechenden Download-Seiten.
Die ![[intern]](../../lib/img/intern_hellblau.gif){kind=small}
Gesamtübersicht dieses Webauftrittes erreichen Sie jederzeit über das AccessKey-Pad mit Alt+6.
Verwenden Sie Tastenkürzel, etwa Alt mit der entsprechenden Zahl, um auf diesem Webauftritt zu navigieren.
![[intern]](../../lib/img/intern_dunkelblau.gif){kind=small}
