Konformität verstehen

Alle WCAG 2.0-Erfolgskriterien wurden als testbare Kriterien formuliert, um objektiv zu bestimmen, ob Inhalte sie erfüllen. Das Testen der Erfolgskriterien würde eine Kombination von automatisierten Tests und Evaluation durch Menschen erfordern. Die Inhalte sollten von denjenigen getestet werden, die verstehen, wie Menschen mit unterschiedlichen Arten der Behinderung das Web benutzen.

Testen und testbar bezieht sich in dem Kontext auf funktionales Testen, das heißt verifizieren, dass der Inhalt wie erwartet funktioniert oder, in diesem Fall, dass er das Erfolgskriterium erfüllt. Obwohl der Inhalt möglicherweise alle Erfolgskriterien erfüllt, kann es sein, dass der Inhalt nicht immer von Menschen mit einer breiten Vielfalt an Behinderungen benutzbar ist. Daher werden Usability-Tests zusätzlich zu den erforderlichen funktionalen Tests empfohlen. Das Ziel der Usability-Tests ist es zu bestimmen, wie gut Menschen die Inhalte ihrem beabsichtigen Zweck nach benutzen können. Es wird empfohlen, dass Menschen mit Behinderungen in Testgruppen einbezogen werden, wenn Usability-Tests durchgeführt werden.

Was bedeutet Konformität?

Konformität zu einem Standard bedeutet, dass Sie die ‚Bedingungen‘ des Standard erfüllen oder diesen entsprechen. In den WCAG 2.0 sind die ‚Bedingungen‘ die Erfolgskriterien. Um konform zu den WCAG 2.0 zu sein, müssen Sie die Erfolgskriterien erfüllen, dass heißt, dass es keinen Inhalt gibt, der die Erfolgskriterien missachtet.

Anmerkung: Das bedeutet, dass, wenn es keinen Inhalt gibt, auf den ein Erfolgskriterium anwendbar ist, dann ist das Erfolgskriterium erfüllt.

Die meisten Standards haben nur eine Konformitätsstufe. Um verschiedenen Situationen Rechnung zu tragen, die möglicherweise einen größeren Grad an Barrierefreiheit als andere erfordern oder erlauben, haben die WCAG 2.0 drei Konformitätsstufen und daher drei Ebenen an Erfolgskriterien.

Konformitätsbedingungen verstehen

Es gibt fünf Bedingungen, die erfüllt werden müssen, damit der Inhalt als ‚konform‘ zu den WCAG 2.0 klassifiziert wird. Dieser Abschnitt bietet kurze Anmerkungen zu diesen Bedingungen an. Dieser Abschnitt wird mit der Zeit erweitert, um neu aufkommende Fragen zu thematisieren oder um neue Beispiele der Art und Weise, wie man die unterschiedlichen Konformitätsbedingungen erfüllt, bereitzustellen.

Bedingung 1 verstehen

1. Konformitätsstufe: Eine der folgenden Stufen der Konformität ist vollständig erfüllt.

  • Stufe A: Für eine Konformität auf Stufe A (die minimale Konformitätsstufe) muss die Webseite alle Erfolgskriterien der Stufe erfüllen oder es wird eine konforme Alternativversion zur Verfügung gestellt.

  • Stufe AA: Für eine Konformität auf Stufe AA muss die Webseite alle Erfolgskriterien der Stufen A und AA erfüllen oder es wird eine Stufe AA-konforme Alternativversion zur Verfügung gestellt.

  • Stufe AAA: Für eine Konformität auf Stufe AAA muss die Webseite alle Erfolgskriterien der Stufen A, AA und AAA erfüllen oder es wird eine Stufe AAA-konforme Alternativversion zur Verfügung gestellt.

Anmerkung 1: Obwohl eine Konformität nur in den angegebenen Stufen erreicht werden kann, werden Autoren dazu ermutigt, (in ihrer Erklärung) jeglichen Fortschritt, den sie in Bezug auf die Erfüllung von Erfolgskriterien aller Stufen über die erreichte Stufe der Konformität hinaus gemacht haben, aufzuführen.

Anmerkung 2: Es wird nicht empfohlen, Konformität auf Stufe AAA als allgemeine Richtlinie für komplette Websites zu fordern, da es bei manchen Inhalten nicht möglich ist, alle Erfolgskriterien der Stufe AAA zu erfüllen.

Die erste Bedingung beschäftigt sich mit den Stufen der Konformität. Im Wesentlichen besagt sie, dass alle Informationen auf einer Seite konform sind oder dass es eine konforme Alternativversion gibt, die von der Seite aus verfügbar ist. Die Bedingung erklärt außerdem, dass eine Konformität nicht möglich ist, ohne mindestens alle Erfolgskriterien der Stufe A zu erfüllen.

Die Anmerkung hebt hervor, dass Autoren dazu ermutigt werden, über die Konformität auf einer bestimmten Stufe hinauszugehen und jeglichen Fortschritt in Richtung auf höhere Stufen der Konformität zu vervollständigen und, wenn sie dies wünschen, darüber zu berichten.

Siehe auch Konforme Alternativversionen verstehen, worin Techniken für die Bereitstellung konformer Alternativversionen enthalten sind.

Bedingung 2 verstehen

2. Ganze Seiten: Konformität (und Konformitätsstufen) gelten nur für (eine) ganze Webseite(n) und kann nicht erreicht werden, wenn ein Teil einer Webseite ausgeschlossen ist.

Anmerkung 1: Zum Zweck der Bestimmung der Konformität gelten Alternativen zu einem Teil der Inhalte einer Seite als Teil der Seite, wenn die Alternativen direkt von der Seite aus erreicht werden können, z.B. eine lange Beschreibung oder eine alternative Darstellung eines Videos.

Anmerkung 2: Autoren von Webseiten, die aufgrund von Inhalten, die außerhalb der Kontrolle des Autors liegen, nicht konform sein können, können eine Erklärung partieller Konformität in Betracht ziehen.

Diese Bestimmung verlangt einfach nur, dass die gesamte Seite konform ist. Aussagen über „der Teil einer Seite ist konform“ können nicht gemacht werden.

Manchmal können zusätzliche Informationen von einer anderen Seite zu Informationen auf einer Seite verfügbar sein. Das longdesc-Attribut in HTML ist ein Beispiel. Mit longdesc könnte eine lange Beschreibung einer Grafik auf einer separaten Seite sein, zu der der Benutzer von der Seite mit der Grafik aus springen kann. Damit wird deutlich, dass solche Inhalte als Teil der Webseite betrachtet werden, so dass Bedingung #2 für den verbundenen Satz an Webseiten, der als eine einzige Webseite betrachtet wird, erfüllt wird. Alternativen können ebenso auf der gleichen Seite bereitgestellt werden. Zum Beispiel die Erstellung eines Äquivalents zum Steuerelement einer Benutzerschnittstelle.

Anmerkung 1: Aufgrund von Konformitätsbedingung 5 kann unter Umständen eine ganze Seite konform sein, auch wenn Teile der Seite Inhaltstechniken benutzen, welche die Barrierefreiheit nicht unterstützen, so lange sie sich nicht störend auf den Rest der Seite auswirken und alle Informationen und Funktionen an anderen Stelle auf der Seite oder von der Seite aus verfügbar sind.

Anmerkung 2: Es ist möglich, nicht-konforme Inhalte aufzunehmen. Siehe Konformitätsbedingung 5 verstehen.

Bedingung 3 verstehen

3. Vollständiger Prozess: Wenn eine Webseite Teil einer Folge von Webseiten ist, die einen Prozess darstellen (z.B. eine Folge von Schritten, die abgeschlossen werden müssen, um eine Handlung auszuführen), dann müssen alle Webseiten in dem Prozess zu der bestimmten Stufe oder höher konform sein. (Konformität zu einer bestimmten Stufe ist nicht möglich, wenn irgendeine Seite in dem Vorgang nicht zu der Stufe oder zu einer höheren Stufe konform ist.)

Beispiel: Ein Online-Shop hat eine Reihe von Seiten, die benutzt werden, um Produkte auszuwählen und zu kaufen. Alle Seiten in der Abfolge vom Anfang bis zum Ende (Kasse) sind konform, damit alle Seiten, die Teil des Prozesses sind, konform sind.

Diese Bestimmung verhindert, dass eine Webseite, die Teil eines größeren Prozesses ist, als konform betrachtet wird wenn der gesamte Prozess dies nicht ist. Dies würde verhindern, dass eine Einkaufs-Site als konform klassifiziert wird, wenn die Kasse oder andere Eigenschaften der Site, die Teil des Einkaufs- und Bezahlvorgangs sind, nicht konform sind.

Bedingung 4 verstehen

4. Ausschließliche Benutzung von Techniken auf eine die Barrierefreiheit unterstützende Art: Nur bei der Benutzung von Techniken auf eine die Barrierefreiheit unterstützende Art kann man sich darauf verlassen, dass die Erfolgskriterien erfüllt werden. Jegliche Information oder Funktionalität, die auf eine nicht die Barrierefreiheit unterstützende Art zur Verfügung gestellt wird, ist auch auf eine die Barrierefreiheit unterstützende Art und Weise verfügbar. (Siehe Barrierefreiheit unterstützend verstehen.)

Diese Konformitätsbedingung wird unten unter Barrierefreiheit unterstützend verstehen erklärt.

Bedingung 5 verstehen

5. Nicht störend: Wenn Techniken auf nicht die Barrierefreiheit unterstützende Art benutzt werden oder wenn sie auf nicht -konforme Art benutzt werden, dann blockieren sie nicht die Fähigkeit des Benutzers, auf den Rest der Seite zuzugreifen. Darüber hinaus erfüllt die Webseite als Ganzes weiterhin die Konformitätsbedingungen unter jeder der folgenden Bedingungen:

  1. wenn irgendeine Technik, auf die man sich nicht verlassen kann, in einem Benutzeragenten angeschaltet wird,

  2. wenn irgendeine Technik, auf die man sich nicht verlassen kann, in einem Benutzeragenten ausgeschaltet wird und

  3. wenn irgendeine Technik, auf die man sich nicht verlassen kann, nicht von dem Benutzeragenten unterstützt wird

Darüber hinaus gelten die folgenden Erfolgskriterien für sämtlichen Inhalt einer Seite einschließlich Inhalt, auf dessen Konformität man sich sonst nicht verlassen würde, da das Scheitern bei der Erfüllung dieser die Nutzung der Seite beeinträchtigen könnte:

  • 1.4.2 - Audio-Steuerelement,

  • 2.1.2 - Keine Tastaturfalle,

  • 2.3.1 - Grenzwert von dreimaligem Blinken oder weniger und

  • 2.2.2 - Pausieren, beenden, ausblenden.

Dies besagt im Wesentlichen, dass nicht die Barrierefreiheit unterstützende Techniken benutzt werden können, so lange alle Informationen auch verfügbar sind, indem die Barrierefreiheit unterstützende Techniken benutzt werden, welche und so lange sich das Material, das die Barrierefreiheit nicht unterstützt nicht störend auswirkt.

Nicht die Barrierefreiheit unterstützende Techniken können benutzt werden oder die Barrierefreiheit unterstützende Techniken können auf eine nicht-konforme Art und Weise benutzt werden, so lange alle Informationen durch die konforme Benutzung von die Barrierefreiheit unterstützende Techniken verfügbar sind und so lange sich das Material, das die Barrierefreiheit nicht unterstützt, nicht störend auswirkt.

Es gibt vier Bestimmungen, die sich besonders mit Problemen der Beeinträchtigung beim Gebrauch der Seite beschäftigen. Diese vier sind hier in einer Anmerkung beigefügt. Eine Anmerkung zu jeder dieser Bestimmungen weist darauf hin, dass diese Erfolgskriterien für den gesamten Inhalt einschließlich des Inhalts, der durch die Benutzung von Techniken, welche die Barrierefreiheit nicht unterstützen, erstellt wurde, erfüllt werden müssen.

Beispiel: Eine Webseite bindet eine neue interaktive, grafische Technik namens „ZAP“ ein. Obwohl ZAP die Barrierefreiheit unterstützt werden die Informationen, die in ZAP präsentiert werden, auch in HTML auf der Seite präsentiert, so dass man man sich nicht auf ZAP verlässt. Also würde diese Seite Konformitätsbedingung #1 bestehen. Wenn der Benutzer allerdings versucht, per Tab-Taste durch den ZAP-Inhalt zu gehen, dann fällt der Fokus in das ZAP-Objekt und bleibt dort stecken. Wenn er einmal dort drin ist, kann der Benutzer nichts tun, um den Fokus wieder dort herauszubekommen. Also können Tastaturbenutzer die untere Hälfte der Seite nicht benutzen. Der ZAP-Inhalt blitzt außerdem ständig hell in unterschiedlichen Frequenzen und hört damit nicht auf. Also werden Menschen mit Aufmerksamkeitsdefizit abgelenkt und diejenigen mit photosensitiven Anfallsleiden können möglicherweise Anfälle haben. Konformitätsbedingung #5 verhindert, dass Situationen wie diese auf einer konformen Seite möglich sind.

Konformitätserklärungen verstehen

Es ist nicht erforderlich, irgendeine Konformitätserklärung abzugeben, um konform zu sein. Wenn man aber eine Konformitätserklärung abgibt, dann müssen die Regeln befolgt werden.

Manchmal möchte man unter Umständen eine Erklärung nur für die Inhalte abgeben, die nach einem bestimmten Datum hinzugefügt wurden. Oder man möchte eine Konformitätserklärung zu den WCAG 1.0 für Inhalte bis zu einem gewissen Datum abgeben und zu den WCAG 2.0 für Inhalte, die nach diesem Datum erstellt oder verändert wurden. Es gibt in den WCAG 2.0 keine Verbote zu irgendwelchen dieser Praktiken so lange es klar ist, welche Seiten eine Konformitätserklärung zu welcher Version der WCAG abgeben.

Anmerkung 1: Wenn wir über Techniken „auf die man sich verlässt“ sprechen, dann sprechen wir über Webinhalts-Techniken (HTML, CSS, JavaScript usw.) und nicht über Benutzeragenten (Browser, assistierende Techniken usw.).

Anmerkung 2: Konformitätserklärungen werden normalerweise nicht auf jeder Webseite innerhalb des Geltungsbereiches der Konformität platziert.

Informationen über jegliche unternommene zusätzliche Schritte, die über die Erfolgskriterien hinausgehen

Eine der optionalen Komponenten einer Konformitätserklärung ist „Informationen über jegliche unternommene zusätzliche Schritte, die über die Erfolgskriterien hinausgehen, um die Barrierefreiheit zu verbessern“. Diese können zusätzliche Erfolgskriterien beinhalten, die erfüllt wurden, empfohlene Techniken, die implementiert wurden, Informationen zu jeglichen zusätzlich benutzen Protokollen, um den Zugriff für Menschen mit bestimmten Behinderungen oder Bedürfnissen zu unterstützen usw. Jegliche Informationen, die für Menschen hilfreich beim Verständnis der Barrierefreiheit der Seiten wären, dürfen hinzugefügt werden.

Benutzung von Metadaten um Konformitätserklärungen zu verkünden

Der nützlichste Weg, um Konformitätserklärungen an Inhalte anzuhängen, wäre, dies in normgerechter maschinenlesbarer Form zu machen. Wenn dieses Verfahren weit verbreitet ist, werden Suchwerkzeuge oder spezielle Benutzeragenten in der Lage sein, diese Informationen zu benutzen, um Inhalte, die barrierefreier sind, zu finden und bereitzustellen oder diese so zu nutzen, dass die Benutzeragenten sich dem Inhalt anpassen können. Es sind eine Reihe an auf Metadaten basierende Optionen zur Abgabe von Erklärungen in der Entwicklung und Autoren und Werkzeugentwickler werden dazu angeregt, diese zu unterstützen.

Darüber hinaus können Metadaten benutzt werden, um die Konformität zu einzelnen Erfolgskriterien zu melden sobald die Konformität auf Stufe A erreicht wurde.

Es gibt außerdem programmtechnische Berichtsformate wie beispielsweise Evaluation and Report Language (EARL), die derzeit entwickelt werden und die maschinenlesbare Formate für detaillierte Konformitätsinformationen bereitstellen könnten. So wie die Berichtsformate formalisiert werden und sich die Unterstützung für sie entwickelt, werden sie hier dokumentiert.

Beispiele für Konformitätserklärungen

Beispiele für erforderliche Komponenten von Konformitätserklärungen

Beispiel 1: Am 20. September 2009 sind alle Webseiten unter http://www.example.com konform zu den Richtlinien für barrierefreie Webinhalte 2.0 unter at http://www.w3.org/TR/2006/REC-WCAG20-20081211/. Konformität der Stufe A.

  • Die dokumentierte Menge von den die Barrierefreiheit unterstützenden Inhaltstechniken, auf die man sich verlässt für diese Erklärung ist eine Teilmenge von ISA- AsCTset#1-2008 unter http://ISA.example.gov/AsCTsets/AS2-2008.

Beispiel 2: (Benutzung eines regulären Ausdrucks) Am 12. August 2009 sind Seiten, die dem Schema http://www.example.com/(marketing|sales|contact)/.* entsprechen, konform zu den Richtlinien für barrierefreie Webinhalte 2.0 unter http://www.w3.org/TR/2006/REC-WCAG20-20081211/. Konformität der Stufe AA.

  • Die Techniken, auf die sich dieser Inhalt „verlässt“ sind: XHTML 1.0 Transitional, CSS 2.0 und JavaScript 1.2.

Beispiel 3: (Benutzung der booleschen Logik) Am 6. Januar 2009 ist http://example.com/ UND NICHT (http://example.com/archive/ ODER http://example.com/publications/archive/) konform zu den Richtlinien für barrierefreie Webinhalte 2.0 unter http://www.w3.org/TR/2006/REC-WCAG20-20081211/. Konformität der Stufe AA.

  • Die dokumentierte Menge von den die Barrierefreiheit unterstützenden Inhaltstechniken, auf die man sich verlässt für diese Erklärung beinhalten XHTML 1.0 und SMIL aus dem ISA- AsCTset#1-2008 unter http://ISA.example.gov/AsCTsets/AS2-2008.

Beispiele für Konformitätserklärungen, die optionale Komponenten enthalten

Beispiel 1: Am 5. Mai 2009 ist die Seite „G7: An Introduction“ http://telcor.example.com/nav/G7/intro.html konform zu den Richtlinien für barrierefreie Webinhalte 2.0 unter http://www.w3.org/TR/2006/REC-WCAG20-20081211/. Konformität der Stufe AA.

  • Die folgenden, zusätzlichen Erfolgskriterien wurden auch erfüllt: 1.1.2, 1.2.5 und 1.4.3.

  • Die dokumentierte Menge von den die Barrierefreiheit unterstützenden Inhaltstechniken, die für diese Erklärung benutzt wurden, sind AsCTset#1-2006 unter http://UDLabs.org/AsCTset#1-2006.html.

  • Die Techniken, auf die sich dieser Inhalt „verlässt“ sind: XHTML 1.0 (Strict) und Real Video.

  • Die Techniken, die dieser Inhalt „benutzt auf die er sich aber nicht verlässt“ sind: JavaScript 1.2, CSS2.

Beispiel 2: Am 21. Juni 2009 ist der gesamte Inhalt, der mit dem URI http://example.com/nav und http://example.com/docs beginnt, konform zu den Richtlinien für barrierefreie Webinhalte 2.0 unter http://www.w3.org/TR/2006/REC-WCAG20-20081211/. Konformität der Stufe AAA.

  • Die dokumentierte Menge von den die Barrierefreiheit unterstützenden Inhaltstechniken, die für diese Erklärung benutzt wurden, sind SMITH- AsCTset#2-2008 unter http://smithreports.example.com/AsCTsets/AS2-2008.

  • Die Techniken, auf die sich dieser Inhalt „verlässt“ sind: XHTML 1.0 (Strict), CSS2, JavaScript 1.2, JPEG, PNG.

  • Die Benutzeragenten einschließlich assistierender Techniken, mit denen dieser Inhalt getestet wurde, kann man unter http://example.com/docs/WCAG20/test/technologies.html finden.

Beispiel 3: Am 23. März 2009 ist der gesamte Inhalt, der auf dem Server unter http://www.wondercall.example.com zur Verfügung steht, konform zu den Richtlinien für barrierefreie Webinhalte 2.0 unter http://www.w3.org/TR/2006/REC-WCAG20-20081211/. Einzel-A Konformität.

  • Die Technik. auf die sich dieser Inhalt „verlässt“ ist: HTML 4.01.

  • Die Techniken, die dieser Inhalt „benutzt auf die er sich aber nicht verlässt“ sind: CSS2 und gif.

  • Dieser Inhalt wurde geteset, indem die folgenden Benutzeragenten und assistierenden Techniken benutzt wurden: Firefox 1.5 unter Windows Vista mit Screenreader X 4.0, Firefox 1.5 unter Windows XP SP 2 mit Screenreader X 3.5, IE 6.0 unter Windows 2000 SP4 mit Screenreader Y 5.0, IE 6.0 unter Windows 2000 SP4 mit Screenreader Z 2.0 und Firefox 1.5 unter Windows XP SP2 mit Screenreader X 4.0, Safari 2.0 unter OS X 10.4.

Techniken für Konformitätserklärungen

Empfohlene Techniken
  • Bekundung einer Konformitätserklärung zu den WCAG 2.0 in Dublin Core-Elementen (zukünftiger Link)

Stufen der Konformität verstehen

Erstens gibt es eine Reihe an Bedingungen, die erfüllt werden müssen, damit ein Erfolgskriterium überhaupt aufgenommen wird. Diese beinhalten:

  1. Alle Erfolgskriterien müssen wichtige Zugriffs-Probleme für Menschen mit Behinderungen sein, die Probleme thematisieren, die über die Usability-Probleme, mit denen alle Benutzer konfrontiert werden könnten, hinausgehen. In anderen Worten: Die Zugriffs-Probleme müssen ein proportional größeres Problem für Menschen mit Behinderungen als für Menschen ohne Behinderungen verursachen, damit sie als Barrierefreiheits-Problem betrachtet werden (und in diesen Richtlinien zur Barrierefreiheit behandelt werden).

  2. Alle Erfolgskriterien müssen außerdem testbar sein. Dies ist wichtig, da es andernfalls nicht möglich wäre zu bestimmen, ob eine Seite die Erfolgskriterien erfüllt hat oder nicht. Die Erfolgskriterien können durch eine Kombination aus Evaluation durch Maschinen und Menschen getestet werden, so lange es möglich ist, mit einem hohem Grad an Genauigkeit zu bestimmen, ob ein Erfolgskriterium erfüllt wurde.

Die Arbeitsgruppe hat die Erfolgskriterien einer der drei Stufen der Konformität zugeordnet nachdem sie eine große Bandbreite an Interaktionsproblemen in Betracht gezogen hat . Einige der gemeinsamen Faktoren, die bei der Festlegung der Stufen evaluiert wurden, umfassten:

  • ob das Erfolgskriterium unentbehrlich ist (in anderen Worten, wenn das Erfolgskriterium nicht erfüllt wird, dann können auch assistierende Techniken den Inhalt nicht barrierefrei machen)

  • ob es möglich ist, das Erfolgskriterium für alle Websites und Arten an Inhalten, für die das Erfolgskriterium gelten würde, zu erfüllen (z.B. unterschiedliche Themen, Inhaltsformen, Arten an Webtechniken)

  • ob das Erfolgskriterium Fähigkeiten erfordert, die von den Erstellern des Inhalts in vernünftigem Maße erreicht werden könnten (das heißt, das Wissen und die Fähigkeiten, um die Erfolgskriterien zu erfüllen, könnten in einer Woche Training oder weniger erlangt werden)

  • ob das Erfolgskriterium dem „look & feel“ und/oder der Funktion der Webseite Einschränkungen aufzwingen würde. (Einschränkungen in Bezug auf Funktion, Darstellung, Freiheit des Ausdrucks, des Designs oder der Ästhetik, welche die Erfolgskriterien den Autoren auferlegen könnten)

  • ob es keine Workarounds gibt, wenn die Erfolgskriterien nicht erfüllt werden

Barrierefreiheit unterstützend verstehen

Viele der Erfolgskriterien beschäftigen sich mit der Bereitstellung von Barrierefreiheit durch assistierende Techniken oder spezielle Barrierefreiheits-Funktionen in etablierten Benutzeragenten (zum Beispiel eine ‚Untertitel anzeigen‘-Option in einem Mediaplayer). Das heißt, die Erfolgskriterien machen es erforderlich, dass im Webinhalt etwas gemacht wird, das es assistierenden Techniken ermöglicht, dem Benutzer die Informationen des Inhalts erfolgreich zu präsentieren. Zum Beispiel wäre ein Bild, auf das Sie klicken sollen, um zu einem Thema zu gehen, für eine blinde Person nicht barrierefrei außer es würden Textalternativen für das Bild auf eine Art und Weise bereitgestellt, die Benutzeragenten einschließlich assistierender Techniken finden und anzeigen könnten. Hier liegt der Schlüssel darin, dass die Textalternative auf eine Art eingebunden sein muss, die Benutzeragenten einschließlich assistierender Techniken verstehen und benutzen können – auf eine Art, die „die Barrierefreiheit unterstützend“ ist.

Ein anderes Beispiel wäre ein individuell erstelltes Steuerelement, das auf einer Webseite eingefügt wurde. In diesem Fall würde ein Standard-Benutzeragent für gewöhnlich nicht in der Lage sein, dem Benutzer eine Alternative zu präsentieren. Wenn allerdings Informationen über das Steuerelement einschließlich dessen Name, Rolle, Wert, wie man es setzt usw. auf eine Art bereitgestellt werden, die assistierende Techniken verstehen können und so dass sie es steuern können, dann werden Benutzer mit assistierenden Techniken in der Lage sein, diese Steuerelemente zu benutzen.

Wenn neue Techniken eingeführt werden, dann müssen zwei Dinge passieren, damit Menschen, die assistierende Techniken benutzen, in der Lage sind, auf diese zuzugreifen. Erstens müssen die Techniken auf eine Art und Weise gestaltet werden, dass Benutzeragenten einschließlich assistierender Techniken auf alle Informationen, die sie benötigen, um dem Benutzer den Inhalt zu präsentieren, zugreifen könnten. Zweitens müssen Benutzeragenten und assistierende Techniken möglicherweise neu gestaltet oder modifiziert werden, um tatsächlich mit diesen neuen Techniken arbeiten zu können.

Die Barrierefreiheit unterstützend“ bedeutet, dass beides gemacht wurde und dass die Technik mit Benutzeragenten und assistierenden Techniken funktioniert.

Benötigter Grad der Unterstützung assistierender Techniken, der für „Barrierefreiheit unterstützend“ benötigt wird

Dieses Thema wirft die Frage auf, wie viele oder welche assistierenden Techniken eine Webtechnik unterstützen müssen, damit diese Webtechnik als „Barrierefreiheit unterstützend“ angesehen wird. Die WCAG-Arbeitsgruppe und das W3C legen nicht fest, welche oder wie viele assistierende Techniken eine Webtechnik unterstützen müssen, damit diese Webtechnik als Barrierefreiheit unterstützend eingestuft wird. Dies ist ein komplexes Thema und eines, das sich sowohl mit der Umgebung als auch der Sprache ändert. Ein externer und internationaler Dialog zu diesem Thema ist notwendig. Einige Anmerkungen, die dabei helfen, dieses Thema zu verstehen und zu erkunden, sind:

  1. Die Unterstützung der Barrierefreiheit von Webtechniken ändert sich je nach Umgebung

    • In einer Firma, in der alle Mitarbeiter mit bestimmten Benutzeragenten und assistierenden Techniken ausgestattet sind, müssen Webtechniken vielleicht nur von diesen Benutzeragenten und älteren assistierenden Techniken unterstützt werden.

    • Inhalte, die ins öffentliche Netz eingestellt werden, müssen vielleicht mit einer größeren Bandbreite an Benutzeragenten und assistierenden Techniken funktionieren.

  2. Die Unterstützung der Barrierefreiheit von Webtechniken ändert sich je nach Sprache (und Dialekt)

    • Es gibt verschiedene Ebenen der Unterstützung von älteren assistierenden Techniken in verschiedenen Sprachen und sogar Ländern. Manche Umgebungen oder Länder stellen möglicherweise kostenlose assistierende Techniken zur Verfügung.

  3. Neue Techniken werden nicht in älteren assistierenden Techniken unterstützt

    • Ohne Frage kann eine neue Technik nicht von allen vergangenen assistierenden Techniken unterstützt werden, also ist es nicht möglich zu verlangen, dass eine Technik von allen assistierenden Techniken unterstützt wird.

  4. Die Unterstützung für eine einzige ältere assistierende Technik ist normalerweise nicht ausreichend.

    • Unterstützung durch nur eine assistierende Technik (für eine bestimmte Behinderung) wäre normalerweise nicht genug, besonders wenn die meisten Benutzer, die sie brauchen, um auf Inhalte zugreifen zu können, diese assistierende Technik nicht haben und sie sich nicht leisten können. Die Ausnahme wären hier Informationen, die nur an Firmenmitarbeiter verteilt würden, wobei alle eine assistierende Technik (dieser Art) haben.

  5. Derzeit sind assistierende Techniken, die für die allgemeine Öffentlichkeit erschwinglich sind, häufig sehr schlecht

    • CEs sollte vermieden werden, Inhalt zu erstellen, die von einem breiten Publikum mit Behinderungen nicht benutzt werden können. In vielen Fällen sind die Kosten für assistierende Techniken zu hoch für die Benutzer, die sie benötigen. Darüber hinaus ist die Leistungsfähigkeit kostenloser oder günstiger assistierender Techniken heute oft so gering, dass Webinhalte realistischerweise nicht auf diesen kleinsten (oder auch mittleren) gemeinsamen Nenner beschränkt werden können. Dadurch entsteht ein sehr schwieriges Dilemma, das thematisiert werden muss.

Daher hat sich die Arbeitsgruppe selber darauf beschränkt zu definieren, was Unterstützung ausmacht und fügt sich der Beurteilung durch die Community und die Instanzen, die näher an den Situationen dran sind, die Anforderungen an eine Organisation, einen Kauf, eine Community usw festlegen, wie sehr, wie viele oder welche assistierenden Techniken eine Technik unterstützen müssen.

Die Arbeitsgruppe ermuntert zu weiteren Diskussionen über dieses Thema in allgemeinen öffentlichen Diskussionen der Gesellschaft, da dieses Fehlen von allgemein verfügbaren und dennoch robusten assistierenden Techniken ein Problem darstellt, das Benutzer, Technikentwickler und Autoren negativ beeinflusst.

Technische Definition von „Barrierefreiheit unterstützend“

Im Wesentlichen ist eine Webinhalts-Technik „Barrierefreiheit unterstützend“, wenn die assistierenden Techniken der Benutzer mit den Webtechniken funktionieren UND wenn die Barrierefreiheitsfunktionen von etablierten Techniken mit der Technik funktionieren. Im Besonderen muss das folgende für eine Technik wahr sein, damit die als die Barrierefreiheit unterstützende Technik qualifiziert:

Barrierefreiheit unterstützend

Sowohl von den assistierenden Techniken der Benutzer als auch von den Barrierefreiheitsfunktionen in Browsern und anderen Benutzeragenten unterstützt

Sowohl 1. als auch 2. müssen für eine Webinhalts-Technik (oder einen Bestandteil einer Technik) erfüllt werden, damit sich die Anwendung einer Webinhalts-Technik oder eines Bestandteils einer Technik als die Barrierefreiheit unterstützend qualifiziert:

  1. Die Art und Weise, in der die Webinhalts-Technik benutzt wird, muss von der assistierenden Technik (AT) der Benutzer unterstützt werden. Dies bedeutet, dass die Art und Weise, wie die Technik benutzt wird, auf Interoperabilität mit der assistierenden Technik der Benutzer in der menschlichen Sprache des Inhalts getestet wurde

    UND

  2. Dass Benutzeragenten existieren, die diese Webinhalts-Technik unterstützen und den Benutzern zur Verfügung stehen. Dies bedeutet, dass mindestens eine der folgenden vier Aussagen zutrifft:

    1. Die Technik wird nativ in weit verbreiteten Benutzeragenten unterstützt, die außerdem Barrierefreiheit unterstützend sind (wie HTML und CSS);

      ODER

    2. Die Technik wird in einem weit verbreiteten Plug-In unterstützt, das außerdem Barrierefreiheit unterstützend ist;

      ODER

    3. Der Inhalt steht in einer geschlossenen Umgebung zur Verfügung, wie in einem Universitäts- oder Firmennetzwerk, in dem der von der Technik benötigte und von der Organisation benutzte Benutzeragent außerdem die Barrierefreiheit unterstützend ist;

      ODER

    4. Der/die Benutzeragent(en), welche die Technik unterstützen, sind Barrierefreiheit unterstützend und stehen so zum Herunterladen oder zum Kauf zur Verfügung, dass:

      • sie für eine Person mit einer Behinderung nicht teurer sind als für eine Person ohne Behinderung und

      • sie für eine Person mit einer Behinderung genauso einfach zu finden und zu erhalten sind, wie für eine Person ohne Behinderungen.

Anmerkung 1: Die WCAG-Arbeitsgruppe und das W3C führen nicht genau auf, welche oder wie viel Unterstützung durch assistierende Techniken für eine bestimmte Nutzung einer Webtechnik vorhanden sein muss, damit diese als Barrierefreiheit unterstützend klassifiziert wird. (Siehe dazu Notwendiger Grad der Unterstützung assistierender Techniken für die Bezeichnung „Barrierefreiheit unterstützend“.)

Anmerkung 2: Webtechniken können auf nicht die Barrierefreiheit unterstützende Arten benutzt werden, so lange man sich nicht auf sie verlässt und die Seite als Ganzes den Konformitätsbedingungen entspricht einschließlich Konformitätsbedingung 4: Benutzung von Techniken auf Barrierefreiheit unterstützende Arten und Konformitätsbedingung 5: Nicht störend.

Anmerkung 3: Wenn eine Webtechnik auf eine die „Barrierefreiheit unterstützende“ Art benutzt wird, dann impliziert das nicht, dass die gesamte Technik oder alle Anwendungen dieser Technik unterstützt werden. Bei den meisten Techniken einschließlich HTML fehlt die Unterstützung für mindestens einen Bestandteil oder eine Art der Anwendung. Seiten sind nur dann WCAG-konform, wenn man sich darauf verlassen kann, dass die Anwendung der die Barrierefreiheit unterstützenden Technik den WCAG-Anforderungen entspricht.

Anmerkung 4: Wenn Webinhalts-Techniken aufgeführt werden, von denen es verschiedene Versionen gibt, dann sollte(n) die unterstützte(n) Version(en) spezifiziert werden.

Anmerkung 5: Eine Möglichkeit für Autoren, die Anwendung einer die Barrierefreiheit unterstützenden Technik ausfindig zu machen, wäre es, Sammlungen von Anwendungsarten zu konsultieren, bei denen dokumentiert wurde, dass sie die Barrierefreiheit unterstützen. (Siehe die Barrierefreiheit unterstützenden Webtechnik-Anwendungsarten verstehen.) Es ist möglich, dass Autoren, Firmen, Lieferanten von Techniken oder Andere die Benutzungsweisen von Barrierefreiheit unterstützenden Webinhalts-Techniken dokumentieren. Allerdings müssen alle Arten der Benutzung von Techniken in der Dokumentation der oben genannten Definition von Barrierefreiheit unterstützenden Webinhalts-Techniken entsprechen.

Die Barrierefreiheit unterstützende Anwendungen von Webtechniken verstehen

Individuelle Autoren werden normalerweise nicht in der Lage sein, alle notwendigen Tests durchzuführen, die notwendig sind um zu bestimmen, welche Arten der Benutzung welcher Webtechniken tatsächlich von welchen Versionen assistierender Techniken und Benutzeragenten unterstützt werden. Autoren können sich daher auf öffentlich dokumentierte Zusammenstellungen verlassen, die dokumentieren, welche assistierenden Techniken welche Art der Benutzung welcher Webtechniken unterstützen. Mit öffentlich meinen wir nicht, dass die Zusammenstellung und dessen Dokumentation notwendigerweise von einem Träger öffentlicher Belange entwickelt wurde, sondern nur, dass sie der Öffentlichkeit zur Verfügung steht. Jeder kann öffentlich dokumentierte Zusammenstellungen mit „Anwendungen von Webtechniken und ihre Unterstützung der Barrierefreiheit“ erstellen. Menschen können Zusammenstellungen erstellen und diesen Namen geben, mit denen Autoren darauf Bezug nehmen können. So lange sie öffentlich dokumentiert sind können Autoren oder Kunden usw. auf einfache Weise Anwendungen auswählen, die ihren Bedürfnissen entsprechen. Kunden und andere können Techniken wählen, die zu jeder Zeit zu ihrer Umgebung oder Sprache passen und festlegen, dass diese bei der Erstellung ihrer Inhalte benutzt werden sollen. Autoren werden eindringlich dazu angehalten, Quellen zu benutzen, die einen etablierten Ruf für Exaktheit und Zweckmäßigkeit haben. Entwickler von Techniken werden eindringlich dazu angehalten, Informationen über die Unterstützung der Barrierefreiheit ihrer Techniken bereitzustellen. Die Arbeitsgruppe nimmt an, dass nur Dokumente, die korrekte Informationen bereitstellen und sowohl Autoren als auch Benutzern zugute kommen, langfristig eine Marktakzeptanz erreichen werden.

Es gibt in den WCAG keine Anforderung, dass eine öffentlich dokumentierte Zusammenstellung benutzt werden muss oder dass nur Technikenanwendungen aus einer solchen Zusammenstellung benutzt werden sollen. Die öffentlich dokumentierten Zusammenstellungen werden nur als Methode beschrieben, um einen andernfalls kritischen aber etwas komplizieren Aspekt der Konformität für Autoren, die selber keine Experten bei der Unterstützung assistierender Techniken sind (oder die einfach nicht die Zeit haben, mit den Fortschritten bei der gegenseitigen Unterstützung etablierter und assistierender Techniken Schritt zu halten), einfacher zu machen.

Autoren, Firmen oder andere möchten unter Umständen ihre eigenen Zusammenstellungen an Technikanwendungen, welche die Barrierefreiheit unterstützen, erstellen und benutzten und dies ist bei der Erfüllung der WCAG erlaubt. Kunden, Firmen oder andere möchten hingegen möglicherweise festlegen, dass Technikanwendungen einer individuell erstellten oder öffentlichen Zusammenstellung benutzt werden sollen. Siehe Anhang B Dokumentation der Unterstützung der Barrierefreiheit für Anwendungen einer Webtechnik.

Aussagen zur Unterstützung der Barrierefreiheit

Beispiele für Wege, wie eine Konformitätserklärung seine Unterstützung der Barrierefreiheit dokumentieren könnte, beinhalten:

  1. Diese Konformitätserklärung erfüllt die Anforderungen an die Unterstützung der Barrierefreiheit basierend auf dem Testen des Inhalts in der Sprache/den Sprachen des Inhalts mit den Benutzeragenten A, B und C und den assistierenden Techniken X, Y und Z. Dies bedeutet, dass wir in der Lage waren, alle Erfolgskriterien für Stufe A der WCAG 2.0 durch die Benutzung dieser Produkte zu bestehen.

  2. Diese Konformitätserklärung erfüllt die Anforderung an die Unterstützung der Barrierefreiheit für die Sprache(n) des Inhalts basierend auf der Anwendung von Techniken und Anmerkungen zu Benutzeragenten, die in den Techniken für WCAG 2.0 dokumentiert sind. Sie basiert außerdem auf der Dokumentation zur Unterstützung der Barrierefreiheit für die Techniken (auf die wir uns zum Zwecke der Konformität verlassen haben), die in „Dokumentation zur Unterstützung der Barrierefreiheit der Organisation XYZ “ zur Verfügung stehen.

  3. Diese Konformitätserklärung erfüllt die Anforderung an die Unterstützung der Barrierefreiheit für die Sprache(n) des Inhalts basierend auf der Anwendung der Technik Z, wie in „Technik Z - die Barrierefreiheit unterstützende Techniken für WCAG 2.0“ dokumentiert.

  4. Diese Konformitätserklärung erfüllt die Anforderung an die Unterstützung der Barrierefreiheit für die Sprache des Inhalts basierend auf der Anwendung der Richtlinien zur Barrierefreiheit für Technik A und der Richtlinien zur Barrierefreiheit für Technik B. Informationen zur Unterstützung durch Benutzeragenten und assistierende Techniken finden Sie in „Anforderungen an die Unterstützung der Barrierefreiheit für Produkt XYZ“, die in diesen Richtlinien dokumentiert wurden.

„Durch Software bestimmt“ verstehen

Verschiedenen Erfolgskriterien verlangen, dass Inhalte (oder bestimmte Aspekte des Inhalts) „durch Software bestimmt“ werden können. Dies bedeutet, dass Inhalte auf eine solche Art und Weise verfasst werden, dass Benutzeragenten einschließlich assistierender Techniken auf die Informationen zugreifen können.

Damit Inhalte, die mit Webtechniken (wie beispielsweise HTML, CSS, PDF, GIF, MPEG, Flash usw.) erstellt wurden, für Menschen mit verschiedenen Arten an Behinderungen barrierefrei sind, ist es unentbehrlich, dass die benutzen Techniken mit den Barrierefreiheitsfunktionen von Browsern und anderen Benutzeragenten, einschließlich assistierenden Techniken, funktionieren. Damit etwas ein Erfolgskriterium erfüllt, das verlangt, dass es „durch Software bestimmt“ ist, müsste es implementiert werden, indem eine Technik benutzt wird, die assistierende Techniken unterstützt.

Inhalt, der „durch Software bestimmt“ werden kann, kann (durch Benutzeragenten einschließlich assistierende Techniken) in verschiedene sensorische Formate (z.B. visuell, auditiv) oder von individuellen Benutzern benötigte Gestaltungsweisen umgewandelt werden. Wenn bestehende assistierende Techniken dies nicht können, dann kann man nicht sagen, dass diese Informationen durch Software bestimmt sind.

Der Begriff wurde erdacht, damit es der Arbeitsgruppe möglich ist, die Stellen, an denen Informationen für assistierende Techniken (und für andere Benutzeragenten, die als Hilfen bei der Barrierefreiheit agieren) barrierefrei sein müssen eindeutig zu kennzeichnen ohne genau festzulegen, wie dies zu tun ist. Dies ist aufgrund des sich ständig ändernden Wesens der Techniken wichtig. Der Begriff ermöglicht es, dass die Richtlinien kennzeichnen, was „durch Software bestimmt“ sein muss, damit diese Richtlinien erfüllt werden und dann separate Dokumente zu haben (die Dokumente „Wie man erfüllt“, „Verstehen“ und „Techniken“), die im Laufe der Zeit aktualisiert werden können und die bestimmte Techniken auflisten, die funktionieren und die, basierend auf der Unterstützung durch Benutzeragenten und assistierende Techniken, zu jedem Zeitpunkt ausreichend sind.

„Barrierefreiheit unterstützend“ versus „Durch Software bestimmt“

„Barrierefreiheit unterstützend“ bezieht sich auf Unterstützung von bestimmten Arten der Anwendung von Webtechniken durch Benutzeragenten (inklusive assistierende Techniken). Anwendungen von Webtechniken, welche die Barrierefreiheit unterstützen, funktionieren mit assistierenden Techniken und den Barrierefreiheitsfunktionen in etablierten Benutzeragenten (Browser und Player usw.).

„Durch Software bestimmt“ bezieht sich auf Informationen im Webinhalt. Wenn Techniken, die die Barrierefreiheit unterstützen, korrekt benutzt werden, dann können assistierende Techniken und Benutzeragenten auf die Informationen im Inhalt zugreifen (d.h. die Informationen im Inhalt durch Software bestimmen) und diese dem Benutzer präsentieren.

Die zwei Konzepte arbeiten zusammen um sicherzustellen, dass Informationen dem Benutzer durch Benutzeragenten inklusive assistierende Techniken präsentiert werden können. Autoren dürfen sich nur auf Anwendungen von Techniken verlassen, welche die Barrierefreiheit unterstützen – und müssen diese korrekt anwenden, damit die Informationen durch Software bestimmbar sind – und damit von assistierenden Techniken und Benutzeragenten darstellbar sind für Benutzer mit Behinderungen.

Konforme Alternativversionen verstehen

Konformitätsbedingung #1 erlaubt es, dass nicht-konforme Seiten im Rahmen der Konformität ausgenommen werden können, so lange sie eine „konforme Alternativversion“ haben. Die konforme Alternativversion wird definiert als:

Konforme Alternativversion

Eine Version, die

  1. mit der angegebenen Konformitätsstufe übereinstimmt und

  2. die gleichen Informationen und Funktionalitäten in der gleichen menschlichen Sprache bereitstellt und

  3. genauso aktuell ist wie der nicht-konforme Inhalt und

  4. für die mindestens einer der folgenden Punkte zutrifft:

    1. Die konforme Version kann von der nicht-konformen Seite aus über einen die Barrierefreiheit unterstützenden Mechanismus erreicht werden oder

    2. die nicht-konforme Version kann nur von der konformen Version aus erreicht werden oder

    3. die nicht-konforme Version kann nur von einer konformen Seite aus erreicht werden, die außerdem einen Mechanismus bereitstellt, um die konforme Version zu erreichen.

Anmerkung 1: In dieser Definition bedeutet „kann nur erreicht werden“, dass es einen Mechanismus wie eine bedingte Umleitung gibt, der verhindert, dass der Benutzer die nicht-konforme Seite „erreicht“ (lädt), außer der Benutzer kommt gerade von der konformen Version.

Anmerkung 2: Die Alternativversion muss nicht Seite für Seite dem Original entsprechen (z.B. kann die konforme Alternativversion aus mehreren Seiten bestehen).

Anmerkung 3: Wenn es Versionen in verschiedenen Sprachen gibt, dann muss es konforme Alternativversionen für jede angebotene Sprache geben.

Anmerkung 4: Alternativversionen können bereitgestellt werden, um unterschiedlichen Technikumgebungen oder Benutzergruppen entgegen zu kommen. Jede Version sollte so konform wie möglich sein. Eine Version müsste vollkommen konform sein, um der Konformitätsbedingung 1 zu entsprechen.

Anmerkung 5: Die konforme Alternativversion muss nicht innerhalb des Bereichs der Konformität liegen und sie muss nicht einmal auf der gleichen Website sein, so lange sie so frei verfügbar ist wie die nicht-konforme Version.

Anmerkung 6: Alternativversionen sollten nicht verwechselt werden mit ergänzendem Inhalt, der die Originalseite unterstützt und die Verständlichkeit verbessert.

Anmerkung 7: Die Einstellung von Benutzerpräferenzen innerhalb des Inhalts zur Erstellung einer konformen Alternativversion ist ein akzeptabler Mechanismus, um eine andere Version zu erreichen, solange die zur Einstellung der Präferenzen benutzte Methode Barrierefreiheit unterstützend ist.

Damit wird sichergestellt, dass alle Informationen und alle Funktionalitäten, die innerhalb des Geltungsbereiches der Konformität auf den Seiten sind, auf konformen Webseiten verfügbar sind.

Warum Alternativversionen erlauben?

Warum erlauben die WCAG es, dass konforme Alternativversionen von Seiten in den Konformitätserklärungen aufgenommen werden dürfen? Das heißt, warum Seiten aufnehmen, welche die Erfolgskriterien für eine Konformitätsstufe im Geltungsbereich der Konformität oder einer Erklärung nicht erfüllen?

  • Manchmal benutzen Seiten Techniken, die noch nicht Barrierefreiheit unterstützend sind. Wenn eine neue Technik entsteht, dann kann es sein, dass die Unterstützung durch assistierende Techniken hinterherhinkt oder nur manchen Zielgruppen zur Verfügung steht. Also kann es sein, dass Autoren sich nicht bei allen Benutzern auf die neue Technik verlassen können. Es kann allerdings andere Vorteile geben, die für die Benutzung der neuen Technik sprechen, z.B. bessere Performance, ein größerer Umfang an verfügbaren Modalitäten usw. Die Bedingung „Alternativversion“ erlaubt es Autoren, solche Webseiten in ihrer Website aufzunehmen, indem eine barrierefreie alternative Seite in Techniken, welche die Barrierefreiheit unterstützend sind, zur Verfügung gestellt wird. Benutzer, bei denen die neue Technik adäquat unterstützt wird, erhalten den Vorteil der neuen Version. Autoren, die nach vorne auf die zukünftige Unterstützung der Barrierefreiheit blicken, können die Erfolgskriterien jetzt mit der Alternativversions-Seite erfüllen und außerdem mit der anderen Seite arbeiten, um den zukünftigen Zugriff einzubauen, wenn die Unterstützung durch assistierende Techniken (AT) zur Verfügung steht.

  • Aus einer Reihe an Gründen ist es unter Umständen nicht möglich, manche Inhalte auf einer Webseite zu modifizieren. Zum Beispiel:

    • Es kann möglicherweise aus rechtlichen oder historischen Gründen bedenklich sein, eine exakte visuelle Kopie eines Dokumentes beizufügen.

    • Die Webseite kann auf einer Site enthalten sein, aber der Besitzer der Site hat möglicherweise nicht das Recht, den Inhalt der Originalseite zu verändern.

    • Die Firma darf vielleicht aus rechtlicher Sicht nichts, was vorher veröffentlicht wurde, entfernen oder auf irgendeine Art verändern.

    • Ein Autor hat möglicherweise nicht die Erlaubnis, ein Dokument aus einer anderen Abteilung, Behörde oder Firma zu verändern

  • Manchmal machen Benutzer mit bestimmten Arten an Behinderungen die beste Erfahrung dadurch, dass eine Webseite speziell drauf zugeschnitten wird, dieser Behinderung Rechnung zu tragen. In solche einer Situation ist es unter Umständen nicht möglich oder praktikabel, die Webseite so zu gestalten, dass sie allen Behinderungen Rechnung trägt, indem alle Erfolgskriterien erfüllt werden. Die Bedingung „Alternativversion“ erlaubt es, dass solch spezialisierte Seiten in eine Konformitätserklärung aufgenommen werden können, so lange es eine voll konforme Seite mit einer ‚Alternativversion‘ gibt.

  • Viele Sites, die sich der Barrierefreiheit verschrieben haben, haben große Mengen an Altlast-Dokumenten. Auch wenn die Informationen in barrierefreien Formaten bereitgestellt wurden, gäbe es einen signifikanten institutionellen Widerstand und verfahrensrechtliche Hindernisse bei der Entfernung dieser Dateien en masse. Manche Organisationen, insbesondere Regierungsbehörden, geben traditionellen druck-orientierten Prozessen den Vorrang. Auch wenn diese Organisationen sich an die Veröffentlichung im Internet angepasst und das Bedürfnis nach barrierefreien Formaten wahrgenommen haben, so behalten Sie dennoch eine Papier-Mentalität bei und bestehen als „primäre“Version oft auf Formaten, die für den Ausdruck gestaltet wurden (auch bei Dokumenten, die überhaupt nur elektronisch „veröffentlicht“ werden). Auch wenn die Arbeitsgruppe der Meinung ist, dass diese Vorgehensweisen abgelehnt werden sollten, so ist sie dennoch nicht der Auffassung, dass diese verboten werden können so lange barrierefreie Versionen leicht erhältlich sind.

Wenn man Webseiten erlaubt, welche die Erfolgskriterien nicht erfüllen, dann besteht die Sorge, dass Menschen mit Behinderungen auf diese nicht-konformen Seiten treffen, nicht in der Lage sind, auf deren Inhalte zuzugreifen und nicht in der Lage sind, die „konforme Alternativversion“ zu finden. Daher ist die Möglichkeit, die konforme Seite (die Alternativversion) von der nicht-konformen Seite aus zu finden, wenn man auf diese trifft, ein zentraler Punkt der Bestimmung „Alternativversion“. Die Konformitätsbedingung, die alternative Seiten erlaubt, verlangt daher auch eine Möglichkeit für Benutzer, die barrierefreie Version unter den Alternativversionen zu finden.

Beachten Sie, dass die Bereitstellung einer Alternativversion eine Ersatz-Option für die Konformität zu den WCAG ist und dass es die bevorzugte Methode der Konformität ist, jeglichen Inhalt unmittelbar barrierefrei zu machen.

Techniken zur Bereitstellung einer konformen Alternativversion

Der wichtigste Teil bei der Bereitstellung einer konformen Alternativversion ist es, einen Mechanismus bereitzustellen, um diese von der nicht-konformen Version aus zu finden. Es wurden eine Reihe unterschiedlicher Methoden identifiziert, um dies zu tun, da spezielle Techniken möglicherweise nicht immer bei bestimmten Techniken oder Situationen möglich sind. Wenn der Autor zum Beispiel Kontrolle über den Server hat, dann gibt es einige leistungsfähige Techniken, die es den Benutzern erlauben, immer im Voraus zu wählen. In vielen Fällen hat der Autor allerdings unter Umständen keine Kontrolle über die Leistungen auf seinem Webserver. In diesen Fällen werden andere Techniken bereitgestellt. Ein Link auf der nicht-konformen Seite ist eine andere leistungsfähige Technik, aber nicht alle nicht-konformen Techniken unterstützen Hypertext-Links.

Unten stehen die Techniken, die bisher identifiziert wurden. Wir erwarten, dass mit der Zeit auch zusätzliche Techniken entwickelt werden und sie werden, wenn sie erscheinen, hier hinzugefügt und die Unterstützung dieser Methoden durch Benutzeragenten einschließlich assistierender Techniken kann demonstriert werden. Zum Beispiel könnte ein Entwickler einer neuen Technik, auf die einige assistierende Techniken nicht zugreifen können, eine Funktion einbauen, die es diesen Techniken erlauben würde, Benutzern automatisch einen Link zu zeigen, der sie zu einer Alternativversion führen könnte.

Ausreichende Techniken zur Bereitstellung von konformen Alternativversionen von Webseiten

Jeder unten stehende nummerierte Punkt repräsentiert eine Technik oder eine Kombination von Techniken, welche die WCAG-Arbeitsgruppe für ausreichend zur Bereitstellung von konformen Alternativversionen hält.

  1. G136: Bereitstellung eines Links am Beginn einer nicht-konformen Webseite, der auf eine konforme Alternativversion hinweist

  2. G190: Bereitstellung eines Links neben einem oder verbunden mit einem nicht-konformen Objekt, der zu einer konformen Alternativversion verlinkt

  3. C29: Benutzung eines Style-Switchers, um eine konforme Alternativversion zur Verfügung zu stellen (CSS)

  4. SVR2: Benutzung von .htaccess, um sicherzustellen, dass der einzige Weg, um auf nicht-konformen Inhalt zuzugreifen, von konformem Inhalt aus ist (SERVER)

  5. SVR3: Benutzung eines HTTP Referer, um sicherzustellen, dass der einzige Weg, um auf nicht-konformen Inhalt zuzugreifen, von konformem Inhalt aus ist (SERVER)

  6. SVR4: Es dem Benutzer ermöglichen, Präferenzen zur Darstellung von konformen Alternativversionen zu bestimmen (SERVER)

Verbreitete, von der Arbeitsgruppe gefundene Fehler
Zusätzliche Techniken (empfohlen) zur Bereitstellung von konformen Alternativversionen von Webseiten
  • Bereitstellung reziproker Links zwischen konformen und nicht-konformen Versionen (zukünftiger Link)

  • Ausschluss von nicht-konformem Inhalt in den Suchergebnissen (zukünftiger Link)

  • Benutzung von Inhaltsvereinbarung (content negotiation) (zukünftiger Link)

  • Keine Darstellung von Inhalten, die auf Techniken angewiesen sind, die nicht die Barrierefreiheit unterstützend sind, wenn die Technik abgeschaltet oder nicht unterstützt wird. (zukünftiger Link)

  • Benutzung von Metadaten, um es zu ermöglichen, die Position einer konformen Alternativversion vom URI einer nicht-konformen Seite aus zu bestimmen (zukünftiger Link)

Beispiele für konforme Alternativversionen
  • Eine Intranet-Site mit mehreren Versionen.

    Eine große Firma hatte die Sorge, dass die Benutzung neu aufkommender Webtechniken auf einer Intranet-Site ihre Fähigkeit einschränken könnte, die Bedürfnisse verschiedener Büro-Standorte, die eine unterschiedliche technische Basis haben und die individuelle Mitarbeiter haben, die eine breite Vielzahl an Benutzeragenten und assistierenden Techniken benutzen, zu adressieren Um dieses Anliegen in Angriff zu nehmen hat die Firma eine Alternativversion des Inhalts erstellt, die alle Erfolgskriterien der Stufe A erfüllt, indem eine begrenztere Reihe an Anwendungen von Inhalts-Techniken, welche die Barrierefreiheit unterstützen, benutzt wird. Die zwei Versionen verlinken zueinander.

  • Eine Informations-Site, die eine Rückwärts-Kompatibilität gewährleistet.

    Eine Informations-Site deckt eine große Zahl an Themen ab und möchte es Besuchern ermöglichen, die Themen, nach denen sie suchen, schnell zu finden. Um dies zu tun, hat die Site ein interaktives Menü-System implementiert, das nur in der aktuellsten Version von zwei gängigen Benutzeragenten unterstützt wird. Um sicherzustellen, dass auch Besucher, die diese bestimmten Benutzeragenten nicht benutzen, dennoch in der Lage sind, die Site effektiv zu nutzen, wird den Benutzeragenten, welche die neuere Technik nicht unterstützen, ein Navigationsmechanismus präsentiert, der nicht von dem interaktiven Menü-System abhängig ist.

„Webseite“ verstehen

Die Definition einer Webseite lautet:

Webseite

Eine nicht-eingebettete Ressource abgerufen von einem einzelnen URI unter der Benutzung von HTTP plus jeder anderen Ressource, die beim Rendern benutzt wird oder die dazu bestimmt ist, mit der Ursprungs-Ressource zusammen durch einen Benutzeragenten gerendert zu werden.

Anmerkung 1: Obwohl jede „andere Ressource“ zusammen mit der ursprünglichen Ressource gerendert würde, würden sie nicht zwangsläufig zeitgleich miteinander gerendert werden.

Anmerkung 2: Zum Zweck der Konformität mit diesen Richtlinien muss eine Ressource „nicht eingebettet“ innerhalb des Geltungsbereichs der Konformität sein, um als Webseite zu gelten.

Beispiel 1: Eine Web-Ressource, die alle eingebetteten Bilder und Medien beinhaltet.

Beispiel 2: Eine Web-Mail-Anwendung, die unter der Benutzung von Asynchronem JavaScript und XML (AJAX) entwickelt wurde. Das Programm liegt komplett unter http://example.com/mail, beinhaltet aber einen Posteingang, einen Kontaktbereich und einen Kalender. Es werden Links oder Schaltflächen bereitgestellt, die dazu führen, dass der Posteingang, die Kontakte oder der Kalender angezeigt werden, die aber nicht den URI der Seite als Ganzes verändern.

Beispiel 3: Eine anpassbare Portalseite, auf der Benutzer den anzuzeigenden Inhalt aus einer Gruppe verschiedener Inhaltsmodule auswählen können.

Beispiel 4: Wenn Sie in Ihrem Browser „http://shopping.example.com/“ eingeben, dann kommen Sie zu einer film-ähnlichen, interaktiven Einkaufsumgebung, in der Sie visuell in einem Geschäft herumgehen und Produkte aus den Regalen um Sie herum nehmen und in einen visuellen Einkaufswagen vor Ihnen legen können. Das Klicken auf ein Produkt führt dazu, dass es zusammen mit einem Datenblatt vorgestellt wird, das daneben schwebt. Dies kann eine einseitige Website sein oder einfach nur eine Seite innerhalb einer Website.

Es ist wichtig zu beachten, dass in diesem Standard der Begriff „Webseite“ sehr viel mehr beinhaltet als statische HTML-Seiten. Der Begriff „Webseite“ wurde in diesen Richtlinien benutzt, damit die Richtlinien verständlicher sind. Aber der Begriff ist mit fortschreitenden Techniken in seiner Bedeutung gewachsen, um einen große Bandbreite an Techniken zu umfassen, von denen viele nicht ‚seiten-mäßig‘ sind. Er beinhaltet außerdem zunehmend dynamische Webseiten, die im Web neu entstehen, einschließlich „Seiten“, die komplette virtuelle, interaktive Communities darstellen können. Zum Beispiel würde der Begriff „Webseite“ eine umfassende, interaktive film-ähnliche Erfahrung beinhalten, die Sie an einem einzelnen URI finden.

„Textalternativen“ verstehen

Eine Textalternative ist Text, der anstelle von Nicht-Text-Inhalten benutzt wird für diejenigen, die den Nicht-Text-Inhalte nicht sehen können Nicht-Text-Inhalt beinhaltet solche Dinge wie Bilder, Diagramme, Applets, Audiodateien usw. Menschen, die zum Beispiel nicht sehen können, wären nicht dazu in der Lage, die Informationen zu sehen, die in einem Bild oder Diagramm gezeigt werden. Daher wird eine Textalternative bereitgestellt, die es dem Benutzer erlaubt, die Informationen (den Text) in Sprache zu konvertieren. In der Zukunft wird die Tatsache, dass die Informationen in Textform vorliegen, es auch ermöglichen, die Informationen in die Gebärdensprache, in Bilder oder in eine einfachere Schriftart zu übersetzen.

Damit Menschen mit Behinderungen in der Lage sind, diesen Text zu nutzen, muss der Text „durch Software bestimmbar“ sein. Dies bedeutet, dass es möglich sein muss, dass der Text von assistierenden Techniken (und den Barrierefreiheitsfunktionen in Browsern), die Menschen mit Behinderungen benutzen, gelesen und benutzt werden kann.

Es muss Menschen, die assistierende Techniken benutzen, auch möglich sein, diese Textalternativen zu finden, wenn sie auf für sie nicht nutzbare Nicht-Text-Inhalte treffen. Um dies zu erreichen sagen wir, dass der Text mit dem Nicht-Text-Inhalt „durch Software verknüpft“ sein muss. Dies bedeutet, dass Benutzer dazu in der Lage sein müssen, ihre assistierenden Techniken zu benutzen, um den Alternativtext (den sie benutzen können) zu finden, wenn sie bei dem Nicht-Text-Inhalt (den sie nicht benutzen können) landen.