Sie sind hier: Start > Artikel

Rettet die Barrierefreiheit vor sich selber!

Der Kanadier Joe Clark ist einer der profiliertesten Experten zum Thema Barrierefreiheit im Web. Er bezeichnet sich als Berater für Zugänglichkeit (accessibility consultant) und ist Autor des Buches »Building Accessible Websites« (2002) das nicht nur im englischsprachigen Raum so etwas wie ein Standardwerk ist.

Der Text des Buchs ist komplett im Netz unter joeclark.org/book zu finden. Clark engagiert sich mit zunehmend kritischer Distanz in der WAI-Arbeitsgruppe des W3C. Insbesondere befasst er sich mit dem Thema Multimedia und Fragen der Zugänglichkeit von Filmen im Web und anderswo.

Tags:

Autor: jc

A List Apart (ALA) versteht sich als Online-Magazin »für Menschen, die Websites machen«. Das klingt bescheiden für eine digitale Publikation, die sich mit Autorität und Engagement mit dem Design, der Entwicklung sowie der Bedeutung von Web-Inhalten beschäftigt und sich dabei konsequent Web-Standards einfordert.

Mitte November 2003 hat Joe Clark auf ALA einen beachtlichen Artikel über den laufenden Prozess der Aktualisierung und Neuformulierung der Zugänglichkeitsrichtlinien veröffentlicht. Ein Prozess, der zu Empfehlungen führen dürfte, zu deren Einhaltung seine Leser künftig gesetzlich verpflichtet sein könnten. Grund genug für Clark, zu warnen, zu lamentieren und zu appellieren. Clark fordert alle Web-Entwickler auf, den aktuellen Stand zu kommentieren, Beispiele zu liefern, sich einzumischen – damit die sprachliche und inhaltliche Neugestaltung der Richtlinien nicht an ihrem eigenen Anspruch scheitert und die Barrierefreiheit noch vor sich selbst gerettet werden kann.

Anmerkungen zum deutschen Text:

Die Lektüre des Originaltextes von Joe Clark stellt eine gewisse Herausforderung dar, richtet er sich doch an ein Fachpublikum, das über mehr als grundlegende Kenntnisse und Erfahrungen zum Thema Web-Entwicklung verfügt. Es ist in der Regel auch vertraut mit Organisation und Arbeitsweise des World Wide Web Consortium (W3C) und der Web Accessibility Initiative (WAI) sowie dem Status und dem Inhalt der Zugänglichkeitsrichtlinien für Web-Inhalte (Web Content Accessibility Guidelines) – kurz WCAG.

Joe Clark nimmt für sich in Anspruch, kein überkritischer Querulant des WCAG 2.0-Entwurfes zu sein. Er erkennt die Verbesserungen im Vergleich zur ersten Version, doch angesichts der geringen verbleibenden Zeit bis zur endgültigen Verabschiedung der vermeintlich verbesserten Zugänglichkeitsrichtlinien, bliebe nun mal keine Zeit, das Positive zu betonen. Vielmehr sei es nun erforderlich, das Schlimmste noch zu verhindern.

Noch eine kurze Anmerkung:
Wir haben uns ausnahmsweise dafür entschieden, die »Du«-Form zu benutzen, um die persönliche Ansprache und die Atmosphäre des englischsprachigen Artikels möglichst nahe am Original zu halten.

Der Übersetzer nimmt für sich nicht in Anspruch, ein kongenialer Interpret des scharfzüngigen und bisweilen sarkastischen Joe Clark zu sein. Der geneigte Leser möge nicht überkritisch sein. Erkennt er Verschlechterungen im Vergleich zur Originalversion von Joe, dann kann dies durchaus zutreffen. Denn auch die Sprache ist eine Barriere, wenn es um Zugänglichkeitsrichtlinien geht. Bevor er sich indes über holprige Formulierungen, gewundene Phrasen und andere Merkwürdigkeiten in Passagen mokiert, in denen die WCAG 2 selbst zitiert bzw. ins Deutsche übertragen werden, bittet der Übersetzer zunächst um einen gnädigen Blick in den Originaltext. Denn dann wird wohl noch deutlicher, warum Joe so eine scharfe Klinge gegen die »Matadoren der Standard-Fraktion« führt.

Wie die Barrierefreiheit vor sich selbst gerettet werden kann.

Übersetzung eines Artikels von Joe Clark in ‘A List Apart’: How to Save Web Accessibility from Itself, 14. November 2003.

Auch wenn es der Rest der Welt noch kaum wahrgenommen hat; unabhängige Web-Entwickler (indie developers) wissen nun meist, dass Websites korrekterweise unter Berücksichtigung publizierter Zugänglichkeitsstandards »gebaut« werden sollten. Die Hauptquelle für diese Standards ist eine Sammlung von »Empfehlungen« der Web Accessibility Initiative (WAI) des World Wide Web Consortium (W3C). Diese Zugänglichkeitsrichtlinien für Web-Inhalte (Web Content Accessibility Guidelines, in ihrer ersten Version abgekürzt mit WCAG 1.0) wurden zuletzt im Mai 1999 offiziell aktualisiert.

Eine neue Version der Richtlinien, die WCAG 2.0, wird derzeit geschrieben. Dieser Entwicklungsprozess geht zäh voran und läuft Gefahr, viele der Irrtümer der WCAG 1.0 zu wiederholen: Unrealistische Vorgaben, losgelöst von der realen Welt der praktischen Web-Entwicklung, Empfehlungen, die gleichzeitig zu vage und zu spezifisch sind.

Aber du, lieber unabhängiger Entwickler, kannst daran mitwirken, diese Tragödie zu verhindern, indem du einfach ein wenig Zeit investierst und dich in einem deiner Fachgebiete engagierst. Wir sollten nicht alle an der Überarbeitung der gesamten WCAG arbeiten, sondern uns auf einzelne Themen konzentrieren, bei denen wir besondere Erfahrung oder Expertise haben. Schon mit diesem begrenzten Engagement wirst du dazu beitragen können, die Barrierefreiheit (Web Accessibility) vor sich selbst zu retten.

Aufgeklärtes Selbstinteresse

Wenn du dich dafür entscheiden hast, standard-konforme Webseiten zu erstellen, muss du dich zwangsläufig an die existierenden Richtlinien halten. Es ist vorhersehbar, dass die Berücksichtigung der WCAG 2.0 künftig auch gesetzlich eingefordert wird.

Es ist also dein aufgeklärtes und vorurteilsfreies Selbstinteresse sicherzustellen, dass die neuen Richtlinien sinnvoll sind. Außerdem gilt: Wir brauchen einfach mehr Beiträge von Web-Entwicklern.

Das Partizipationsproblem

Ich selbst habe seit 1999 Beiträge an die W3C-Mailinglisten, die sich mit dem Thema der Zugänglichkeit befassen, geschickt – und ich habe immer noch nicht begriffen, wie die WAI arbeitet. Ich denke, das musst auch du nicht. Es reicht zu wissen, dass es zwei zentrale Mailinglisten für WAI-Diskussionen gibt:

WCAG-IG
WAI Interest Group für allgemeine Diskussionen zum Thema Zugänglichkeit.
WAI-GL
WAI Guidelines, digitale Heimat der Web Content Accessibility Guidelines Working Group, Diskussionsforum für aktuelle und zukünftige Richtlinien.

Dabei überrascht es kaum, dass sich mehr Menschen für das allgemeine Geplauder auf der WCAG-IG interessieren, als für die themenspezifische WAI-GL-Liste. Von Juni 2002 bis Juni 2003 haben 290 unterschiedliche Personen bei WAI-IG gepostet und nicht einmal halb so viele, nämlich 114, bei der WAI-GL.

Das hört sich viel an, ist es aber nicht. Denn Web-Entwicklung ist zu einem weiten Feld geworden, mit vielen überlappenden Spezialthemen. WCAG 2.0 berührt vieler dieser Themen, unter anderem: Seitenstruktur (XHTML und ähnliche Auszeichnungssprachen), CSS, Multimedia, Gebrauchstauglichkeit (Usability), Informationsdesign, Textinhalte, und eine Vielzahl behinderten-spezifischer Aspekte. Ich weiß, dass es eine ganze Reihe von führenden Experten zu unterschiedlichen Themen gibt, die sich nicht mit Fragen der Barrierefreiheit im Sinne von Einschränkungen für Menschen mit Behinderungen befassen. Diese Experten, deren Namen von eingefleischten unabhängigen Entwicklern (indie developers) sofort erkannt würden, sind auf keiner der beiden Mailinglisten vertreten. Es gibt keinen Hinweis dafür, dass anerkannte Experten zu wichtigen Themen mit WCAG-Bezug sich am Entwicklungsprozess der neuen Richtlinien beteiligen.

Das bleibt nicht ohne Folgen. Die derzeitigen Arbeitsentwürfe (working drafts) der WCAG 2.0 sind ohne Zweifel eine erkennbare Verbesserung der vorsintflutlichen WCAG 1.0. Und dennoch haben sie einen viel zu geringen Bezug zum real existierenden Web.

Genau hier kannst du dich einbringen.

Stück für Stück

Zur Zeit der Veröffentlichung dieses Artikels (14. November 2003) umfasste der aktuelle Entwurf der WCAG 2.0 rund 14.000 Wörter (ohne Markup). Ich kenne niemanden, der etwas so Umfangreiches in einer Sitzung verdauen könnte. Das ähnelt einer Anakonda, die versucht, einen Range Rover zu verschlingen. Also habe ich den WCAG-Entwurf in verschiedene Aktionspunkte (action items, wie die Managertypen das nennen) aufgeteilt. Dabei habe ich folgende Themen ausgewählt.

  1. Neuformulierung: Die gesamte Richtlinie muss neu und klarer formuliert werden
  2. Beispiele: Die Richtlinie braucht mehr Beispiele als bisher, die am besten aus aktuellen Webseiten gewählt werden (anonymisiert, falls erforderlich)
  3. Ein wirres Konzept: Irgendwas stimmt nicht mit der grundlegenden Idee der Richtlinie
  4. Unmöglich: Die Richtlinie ist so, wie sie derzeit vorliegt, nicht umzusetzen – oder so gut wie nicht.
  5. Nicht unser Problem: Dieser Aspekt kann vernünftiger Weise nicht durch Richtlinien erfüllt werden, die Web-Inhalte regeln.

Mängelbericht

Bevor nun irgendjemand anfängt, mich einer zu kritischen Haltung anzuklagen – das käme einer Klage gleich, dass der Himmel zu blau sei – versteht diesen Artikel bitte als einen Mängelbericht zu den WCAG 2.0. Wir können es uns einfach nicht leisten, positiver und, klingeling, schmeichelhafter zu sein, als dies durch die existierenden Richtlinien gerechtfertigt ist. Es gibt nur noch ein kleines Zeitfenster, um das zu reparieren, was falsch gelaufen ist. Und das können wir eben nicht tun, ohne zu identifizieren, was falsch ist. Dies ist nicht die Zeit das Positive hervorzuheben.

Diese Vorgehensweise ähnelt technischen Dokumentationen, wo aufeinanderfolgende Entwürfe zu Mängelberichten führen, bei denen jeder einzelne Punkt entweder korrigiert wird oder abgehakt wird, weil es doch kein Mangel ist, oder man lebt erst einmal mit ihm – bis zum nächsten Entwurf. Dieser Prozess wiederholt sich so lange, bis alle Beteiligten jeden einzelnen Fehler behoben oder sich entschieden haben, mit ihm zu leben.

(Für ein früheres Face-to-Face WCAG-Meeting habe ich zwei eigene Papiere geschrieben, die Mängel und Empfehlungen auflisten, falls es jemanden interessieren sollte. (Anmerkung des Übersetzers: Face-to Face-Meetings werden die periodisch stattfindenden persönlichen Treffen der WAI genannt, das letzte fand kürzlich in Japan statt.)

Wo sind die Originaltexte?

Die WCAG 2.0 sind ein bewegliches Ziel

Diese Dokumente verwenden nicht genügende Sprungmarken (fragment identifier). Deshalb kann man nicht immer direkt auf die jeweiligen Sektionen und Abschnitte verweisen. Dort, wo es einen Textlink gibt, gebe ich ihn an. Aber nicht selten wird dir keine andere Wahl bleiben, als den »Suchen«-Befehl in deinem Browser zu benutzen. Hinzu kommt, dass sich in den folgenden Entwürfen Formulierungen ändern werden – das ist garantiert.

Aktionspunkte (action items)

Neu Formulieren

Diese Richtlinien müssen neu geschrieben und klarer formuliert werden. Aber das Problem ist eigentlich noch größer: In seiner Gesamtheit sind die WCAG 2.0 ein armselig geschriebener Morast. Der bisherige Entwurf verletzt die eigenen Richtlinien, nämlich einfach und klar zu schreiben. Es ist ein totales Durcheinander und eine Neuformulierung in klarem Englisch ist dringend erforderlich. Die Web Accessibility Initiative verfügt über ein Budget. Also sollte sie professionelle Berater engagieren, die diese sprachliche Überarbeitung leisten. Es ist an der Zeit mit einer W3C-Tradition der unverständlichen Dokumente zu brechen.

Trotzdem, mit Blick auf den Zweck dieses Aktionspunktes konzentrieren wir uns auf Abschnitte, die so wie sie niedergeschrieben sind praktisch keinen Sinn machen.

  1. Überblick über Design-Prinzipien: Hier werden die vier Themen oder »Ziele« der WCAG 2.0 in einer holprigen Art und Weise mit Adjektiven bezeichnet.

    • Wahrnehmbar (Perceivable)
    • Bedienbar (Operable)
    • Verständlich (Understandable)
    • Robust (Robust)

  2. Inhalt für jeden Nutzer wahrnehmbar machen. Dieser Checkpoint muss repariert werden. Könnte man ihn so, wie er geschrieben steht, in die Praxis umsetzen?

    Jeder Nicht-Text-Inhalt, der in Worten ausgedrückt werden kann, erhält ein Textäquivalent mit der Funktion oder Information, den der Nicht-Text-Inhalt zu übermitteln beabsichtigt.

    1. Nicht-Text-Inhalt, der in Worten ausgedrückt werden kann, erhält ein Textäquivalent, das explizit mit ihm verbunden ist.

    2. Nicht-Text-Inhalt, der nicht in Worten ausgedrückt werden kann, erhält einen beschreibenden Zusatz, der dann als sein Textäquivalent dient.

    3. Das Textäquivalent sollte die gleiche Funktion erfüllen, die der Autor für den Nicht-Text-Inhalt vorgesehen hat (d. h., es stellt alle beabsichtigten Informationen dar und/ oder erfüllt die gleiche Funktion wie der Nicht-Text-Inhalt).

  3. Was aber ist »Nicht-Text-Inhalt«?

    Nicht-Text-Inhalt umfasst, aber beschränkt sich nicht auf Bilder, Texte, die aus Rasterbildern bestehen, Image Map-Regionen, Animationen (wie animierte GIFs), ASCII-Zeichnungen, Bilder, die als Gliederungspunkte verwendet werden, Platzhaltergrafiken, grafische Schaltflächen, Geräusche und Musik (ob diese mit oder ohne Interaktion mit dem Benutzer abgespielt werden), einzelne Audio-Dateien, Tonspuren von Videofilmen, und Videofilme selbst…

  4. Warnung der WAI vor dem Gebrauch von Illustrationen: Wenn diese Richtlinie es überhaupt verdient, aufgenommen zu werden, muss sie neu formuliert werden.

    Designer müssen behutsam sein, wenn sie sich dafür entscheiden, Illustrationen zu benutzen. Die Wahrnehmung eines Bildes ist möglicherweise eine erworbene Fertigkeit, die für einige einfacher ist als für andere. Einige Nutzer mögen die Bilder überspringen; andere »lesen« nur die Bilder. Designer müssen außerdem berücksichtigen, dass visuelle Konventionen nicht allgemeingültig (universell) sind und dass Individuen ihre eigenen mentalen Schemata und Erwartungen entwickeln, wenn sie visuelle Informationen verarbeiten.

  5. Zurückübertragene (retransmitted) Untertitel und Audio-Beschreibungen. Kannst du diese Richtlinie begreifen?

    Wenn Inhalte von einem anderen Medium oder einer Quelle erneut ausgestrahlt werden (rebroadcast) und diese den Übertragungsanforderungen für Zugänglichkeit entsprechen (unabhängig von diesen Richtlinien), erfüllt diese erneute Ausstrahlung den Checkpoint wenn es den anderen Richtlinien entspricht.

  6. Definitionen sollten definitiv sein. Diese sind es nicht.

    Inhalt (content)

    Inhalt ist die Information oder Bedeutung oder Funktion.

    Präsentation (presentation)

    Präsentation ist die Darstellung von Inhalten und Struktur in einer Form, die vom Benutzer mit seinen Sinnen aufgenommen werden kann.

    Struktur (structure)

    Struktur beinhaltet beides: die hierarchische Struktur des Inhalts und die nicht-hierarchischen Beziehungen, wie Querverweise, oder die Beziehung zwischen dem Kopf und den Datenzellen einer Tabelle.

Beispiele

In diesem Unterkapitel benötigen die Richtlinien mehr Beispiele. Und genau hier können meine Leser am meisten Gutes tun – mit der geringsten Anstrengung: Alles was wir brauchen, zumindest in den meisten Abschnitten, sind die Beiträge von ein paar Leuten, sind ein, zwei Beispiele von Webseiten aus der realen Welt. Die Seiten, die du vorschlägst können die Kriterien voll erfüllen, zum Teil erfüllen oder ihnen komplett widersprechen.

Ebenso kannst du deine eigenen Erlebnisse als Nutzer des Webs wiedergeben.

Der wichtigste Punkt ist es aber, die WAI von ihrer Gewohnheit abzubringen, neunmalkluge Hypothesen aufzustellen. (Anmerkung des Übersetzers: Im Original heißt es etwas deftiger: »habits of half-arsed hypothesizing«.) Wir verlangen, dass die Richtlinien auf tatsächliche Webseiten aller Art angewendet werden können. WAI ist nicht daran interessiert, diese Webseiten selbst zu finden. Also müssen wir denen die Fakten auf einem Tablett präsentieren.

  1. Noch mehr Textäquivalente. WAI kann davon gar nicht genug bekommen. Aber wir brauchen ein breites Spektrum von aktuellen Beispielen, von Textäquivalenten die heute tatsächlich eingesetzt werden – egal ob diese gut gemacht sind oder nicht.

    1. Nicht-Text-Inhalt der in Worten ausgedrückt werden kann, erhält ein Textäquivalent, das explizit mit ihm verbunden ist.

    2. Nicht-Text-Inhalt, der nicht in Worten ausgedrückt werden kann, erhält einen beschreibenden Zusatz (label), der dann als sein Textäquivalent dient.

      • Das Textäquivalent sollte die gleiche Funktion erfüllen, die der Autor für den Nicht-Text-Inhalt vorgesehen hat (d. h., es stellt alle beabsichtigten Informationen dar und/ oder erfüllt die gleiche Funktion wie der Nicht-Text-Inhalt).

  2. WAI befasst sich in gefährlich dilettantischer Weise mit dem Aspekt des Schreibens, also einem Thema, bei dem es einen nachweislichen Mangel an Fachwissen hat. Mit ihrer Besorgnis um »konkrete Konzepte« und ähnliche Klassifizierungen des geschriebenen Wortes beabsichtigt WAI, Menschen mit Lernschwierigkeiten weiterzuhelfen. Doch hier dürfen wir wenig Gutes erwarten, bevor wir nicht genau wissen, worüber eigentlich gesprochen wird. Oder verstehst du folgendes?

    • Beispiel 1: Die Beschreibung eines Prozesses.

      Eine Seite beschreibt, wie man lernt Fußball zu spielen. Jeder Schritt, mit dem die Grundbegriffe des Spiels vermittelt werden, wird mit dem Foto eines Spielers illustriert, der das macht, was im Text beschrieben wird.

    • Beispiel 2. Ein konkretes Konzept

      Das primäre Konzept auf einer Seite ist konkret. Es erläutert Mount Pinatubo (Ein aktiver Vulkan auf den Philippinen. Anmerkung des Übersetzers.) Es beinhaltet sowohl eine Beschreibung des Ausbruchs von 1991 als auch Fotos von dem Ausbruch und die Nachwirkungen. Es verlinkt zu einer anderen Seite, die ein Video enthält und noch einer Seite, mit einer 3D-Simulation von den Geschehnissen unter der Erdkruste und innerhalb des Vulkans während der Eruption.

    • Beispiel 3: Ein Kind berichtet von einem Schulausflug.

      Ein Kind machte mit seiner Schulklasse einen Ausflug zu einer Fahrradfabrik. Sie schrieb einen Bericht für ihre Familie und für ihre Freunde, um ihn ins Internet zu stellen. In dem Bericht verwendet sie auch das Logo der Firma und das Bild eines Fahrrades auf dem Fließband. Für weitere Informationen verlinkt sie ihren Bericht mit der Unternehmens-Homepage. Sie fügt Fotos bei, die sie in der Fabrik gemacht hat.

    • Beispiel 4. Börsendaten

      Eine Nachrichten-Website vergleicht die wirtschaftliche Entwicklung vom dritten Quartal des laufenden Jahres mit dem gleichen Zeitraum der letzten drei Jahre. Diese vergleichen die Kurse der beliebtesten Aktien. Sie präsentieren die Daten in einem Balkendiagramm und verlinken zu den Rohdaten, die herangezogen wurden um das Balkendiagramm zu erzeugen.

    • Beispiel 5. Die Geschichte der Musik

      Ein Großvater hat als Hobby Musik zu hören und zu spielen. Er erstellt eine Webseite, die Beispiele von vielen verschiedenen Musikrichtungen und Instrumenten enthält. Bei der Beschreibung einer speziellen Musikrichtung verlinkt er auf kurze Klangbeispiele.

  3. Auch der Nutzen von zugänglichen Alternativen könnte ein paar Fallstudien gut gebrauchen (die, komisch genug, WAI von seiner eigenen Seite ziehen könnte).

    • Menschen, die blind oder stark sehbehindert sind, Menschen mit kognitiven Einschränkungen oder die aus irgendeinem Grund Schwierigkeiten haben, Texte zu lesen, können sich Texte laut vorlesen lassen.

    • Menschen die taub oder schwerhörig sind, oder die aus irgendeinem Grund Schwierigkeiten haben, vertonte Informationen zu verstehen, können eine Textversion lesen oder sich diese durch ihre assistive Technologie übersetzen und in Gebärdensprache präsentieren lassen.

    • Menschen die blind oder taub und blind sind, können sich die Informationen in Braille (Blindenschrift) aufbereiten lassen.

  4. Beispiele für die Zugänglichkeit von Multimedia: Ich weiß, dass ich nicht der einzige bin, der ein Auge auf Untertitel und zusätzliche Audio Beschreibungen hat. Ich weiß aber auch, dass nur wenige, die bei WAI mitmischen, das tun. Hier sind Beispiele und Erfahrungen aus dem realen Leben gefordert.

    • Beispiel 1: Ein Filmausschnitt mit zusätzlicher Audio-Beschreibung und Untertiteln.

      Ein Filmausschnitt wird auf einer Webseite veröffentlicht. In diesem Film versucht ein Kind einen kleinen Hund in sein Zimmer zu locken, indem es eine Spur aus Brotkrümeln auslegt. Das Kind murmelt unhörbar vor sich hin während es die Spur legt. Wenn man dem Video nicht zusieht, ist es nicht offensichtlich, dass das Kind eine Spur auslegt, denn alles, was man hört ist ein Murmeln. Die Ton-Beschreibung, in die das Gemurmel des Kindes hie und da eingestreut wird, sagt: »Charlie legt ein paar Krümel auf jede Stufe, die zu seinem Zimmer führt.« Der Untertitel der angezeigt wird, während er murmelt ist [unverständliches Gemurmel].

    • Beispiel 2: Ausschnitt aus einem Nachrichtenfilm.

      Ein Videoclip begleitet eine Nachricht zur jüngsten Überflutung in einer großen Stadt. Der Reporter beschreibt für jeden, was zu sehen ist. Der Untertitel gibt wieder, was der Reporter erzählt.

    • Beispiel 3. Ein Zeichentrick-Stummfilm

      Ein Zeichentrickfilm zeigt einen Pantomimen, der eine Leiter hoch steigt. Keine Untertitel oder Ton-Beschreibung ist erforderlich. Stattdessen wird ein Textäquivalent angegeben …

  5. Ohne Zweifel könnten wir ohne Mühe realistischere Beispiele für die Einbettung einer zweiten Sprache finden. Unten habe ich zudem die Textfehler der WAI bereinigt.

    Die Erleichterung bei der unzweideutigen Decodierung von Zeichen und Wörtern in Form von Inhalt ist für Menschen, die gerade zu lesen beginnen oder eine zweite Sprache erlernen hilfreich …

    Zitat: »Und mit einem Bestimmten je ne sais quoi betrat sie beides, den Raum und sein Leben, für immer.« (Im Original: »And with a certain je ne sais qoui, she entered both the room, an his life, forever.«)

    Im vorhergehenden Satz ist die Wendung »je ne sais quoi« als Französisch markiert. Abhängig von der Auszeichnungssprache, kann Deutsch (bzw. im Original: Englisch) entweder als Sprache für das gesamte Dokument gewählt werden, außer wo anders angegeben, oder die Sprachauszeichnung kann für jeden Abschnitt vorgenommen werden.

  6. Der WAI ist es offenbar entgangen, dass die korrekte Auszeichnung von Tabellen die Tabellenstruktur kristallklar macht. Und außerdem, welche »semantische Auszeichnung« könnte beispielsweise gleich klingende Worte oder gleich geschriebene Worte mit unterschiedlicher Bedeutung (Homonyme und Homographe) oder Sprachbilder verständlich machen?

    Eine Zusammenfassung der Beziehungen innerhalb einer Tabelle sollte gegeben werden, wenn dies möglicherweise nicht aus der Analyse der Tabellenstruktur, wohl aber aus einer visuellen Gestaltung der Tabelle hervorgeht.

    Wenn zusammengezogene Wortformen in einer Weise benutzt werden, dass sie zweideutig sein könnten, sollte eine semantische Auszeichnung hinzugefügt werden, sodass Wörter unverwechselbar und verständlich werden.

  7. Und nun kommt die Stelle wo die Matadoren der Standards-Fraktion brillieren (Semantisch quasi unnachahmlich. Im Original heißt es: Here is where standardistas shine). Wir sind besessen mit der korrekten Benutzung von Aufzählungen, Überschriften und anderen XHTML-Elementen. Es ist an der Zeit, WAI den Geschmack ihrer eigenen glorreichen standardkonformen Medizin zu verabreichen. Wir werden wohl Schwierigkeiten haben, wenn es darum geht, Beispiele für »Kapitel« und »Abschnitte« zu finden, denn es gibt keine HTML-Element für Kapitel und Abschnitte – und das obwohl sie als »Beziehungen« des link-Elements definiert sind.

    (Diese Passage in den WCAG ist ganz besonders erbärmlich, versteigt sie sich doch dazu den Aufbau eines Fahrrades anzuführen, um die Struktur des Web zu erläutern.)

    1. Der Inhalt (der vorausgehenden Versionen) wurde durchgesehen, um die folgenden Vorgehensweisen, welche die Orientierung und Bewegung erleichtern, zu berücksichtigen, um sie als angemessen anzuwenden.

      1. Text in logische Absätze unterteilen

      2. Hierarchische Abschnitte und Titel angeben, vor allem bei längeren Dokumenten

      3. Wichtige nicht-hierarchische Beziehungen darlegen, wie etwa Querverweise oder eine Zusammengehörigkeit von Tabellenkopf und -zellen, sodass diese unzweideutig in einem Datenmodell oder durch Auszeichnungen dargestellt werden können

      4. Teilen von sehr großen Dokumenten in Abschnitte oder Kapitel mit logischen Bezeichnungen

      5. Andere?

  8. Wie viele »sich erweiternde Strukturen « (expanding outlines) und »dynamische Fischaugenblicke« (dynamic fisheye views) hast du in letzter Zeit durch den W3C-Validator laufen lassen?

    Mechanismen zur Seitennavigation

    Ein Seiten-Navigationsmechanismus ist ein Mechanismus, um sich einfach auf einer Seite zu orientieren und sich leicht auf ihr zu bewegen. Mechanismen zur Seitennavigation beinhalten unter anderem, aber nicht ausschließlich:

    • Eine Homepage mit Hyperlinks und Links auf den folgenden Seiten, die auf andere Seiten auf der Website verweisen

    • Sitemap(s)

    • Suchmaschine(n)

    • Sich erweiternde Strukturen

    • »Dynamic fisheye views«, die alle verlinkten Seiten verweisen sowie auf Themen, die sich auf irgendeine Seite beziehen

    • virtuelle 3D-Darstellungen des Seiteninhalts

  9. Hat jemand vielleicht bessere Beispiele für konsistenten Seitenaufbau?

    • Der Inhalt (der vorausgehenden Versionen) wurde durchgesehen, dabei wurden untenstehende Ideen berücksichtigt:

      1. Navigationsleisten sollten, wann immer möglich, konsistent platziert werden

      2. Ein ähnliches Layout für die Komponenten der Benutzeroberfläche sollten für einzelne Abschnitte oder die ganze Website benutzt werden

      3. Ähnliche Komponenten der Benutzeroberflächen sollten mit ähnlicher Terminologie bezeichnet werden

      4. Überschriften konsistent benutzen

      5. Templates (Vorlagen) für eine durchgehende Präsentation von Abschnitten oder der ganzen Webseite einsetzen

      6. Seiten mit ähnlicher Funktion sollten ein ähnliches Erscheinungsbild und Layout haben

      7. Schaltflächen (controls) die gleich aussehen oder sich gleich anhören sollten so gestaltet sein, dass sie die gleiche Aktion auslösen

      8. Konventionen die dem Benutzer aller Wahrscheinlichkeit nach vertraut sind, sollten befolgt werden

      9. Ungewöhnliche Funktionen einer Benutzeroberfläche oder Verhaltensweisen, die möglicherweise den erstmaligen Benutzer verwirren könnten, sollten dem Nutzer zunächst beschrieben werden, bevor er auf sie trifft.

  10. PopUp-Fenster und Frames sind für das W3C ein immer wieder auftauchendes Schreckgespenst, obwohl sie kaum einmal benutzt werden. Und doch sollten wir ohne Mühe bessere Fallstudie finden als diese:

    • Beispiel 1: Ein Formular um ein PopUp-Fenster zu deaktivieren.

      Auf einer Seite mit Links wird ein Kästchen zum Anklicken (checkbox) vorgesehen, sodass die Benutzer wählen kann, ob sie die resultierenden Seiten in einem neuen Fenster sehen wollen oder nicht.

    • Beispiel 2: Eine Warnung, bevor sich ein PopUp-Fenster öffnet.

      Am Ende einer Nachricht werden verschiedene Links zu weiteren Informationen angeboten. Vor jedem dieser Links steht das Symbol eines kleinen Pfeils mit dem Textäquivalent: »Link öffnet sich in neuem Fenster«

    • Beispiel 3: Frames, die nicht die angeklickten Seiten zurückverfolgen (track history), sorgen für ein unerwartetes Verhalten der Zurück-Schaltfläche (back button).

    • Beispiel 4. Formulare

    Anmerkung des Autors Clark: Einige dieser Beispiele sind sehr kurz. Sollten sie erweitert und mit weiteren Details erläutert werden?

Ein wirres Konzept

Diese Richtlinien demonstrieren ein so tief gehendes Missverständnis des Themas, das sie vorgeben zu behandeln, dass sie entweder gelöscht oder von Grund auf neu geschrieben werden sollten. Und hier kannst du helfen: Versuche herauszufinden, was sie eigentlich ausdrücken wollten und formuliere es neu. Oder gib Gründe an, am besten gestützt auf Beispiele von Webseiten aus dem richtigen Leben und die Entwicklungspraxis, warum einzelnen Richtlinien gelöscht werden sollten.

  1. Kodierung mit Unicode ist wünschenswert, aber es ist weder die einzige Kodierungsform die es gibt, noch verringert ihr Fehlen die Zugänglichkeit.

    Der Text von Inhalten wird mit Unicode zur Verfügung gestellt oder es gibt ausreichende Hinweise, sodass der Text automatisch in Unicode zurückübertragen werden kann.

  2. Diese Richtlinie bezieht sich auf die Untertitelung von Multimedia im Web. Nimmt man sie wörtlich, müssen alle in Echtzeit gesendeten Töne transkribiert, also übertragen werden. Das bedeutet, jede einzelne Internet-Radiostation müsste ihre Sendungen untertiteln.

    Weiterhin gilt: Wenn du irgendeine Webcam betreibst, musst du dir noch eine andere Seite, auf die du verlinken kannst, dazu schnorren, damit du irgendwie auf das »äquivalent« des von der Kamera gezeigten Bildes verweisen kannst.

    Wenn der Web-Inhalt in Echtzeit und nur als Ton vorliegt und nicht zeit-sensitiv ist und nicht interaktiv, dann ist ein Transkript oder ein anderes Nicht-Ton äquivalent ausreichend. […]

    Wenn der Web-Inhalt ein nicht-interaktives Video in Echtzeit ist (z. B. eine Webkamera, die das aktuelle Wetter zeigt), muss entweder ein äquivalent angeboten werden … (z. B. eine fortlaufende Aktualisierung des Wetterberichts) oder ein Link zu einem äquivalent … (etwa ein Link zu einer Website mit Wetterbericht).

  3. Die Web Accessibility Initiative missversteht den Einsatz von Formatvorlagen (Cascading Style Sheets, CSS). Hier fordern die Richtlinien unterschiedliche Erscheinungsformen für Dutzende von HTML-Elementen. (Sollten die Elemente em, cite und i wirklich unterschiedlich aussehen?) Es wird auch gefordert, besondere schwarz-weiße und rein akustische Style Sheets zu erstellen.

    Die bestehenden strukturierenden Elemente haben jeweils eine unterschiedliche visuelle Erscheinungsform oder akustische Eigenschaft und unterscheiden sich vom Fließtext. […]

    Die strukturierenden Betonungen werden so gewählt, dass sie sich auf den wichtigen unterschiedlichen Display-Formen unterscheiden (z. B. schwarz-weiß, kleines Display, Mono Audio-Playback). […]

    1. Für visuelle Präsentationen sollten unterschiedliche Schriftarten, Stile, Größen und weiße Fläche genutzt werden, um die Struktur hervorzuheben.

    2. Farbe und Grafik sollten eingesetzt werden, um die Struktur hervorzuheben.

    3. Für akustische Präsentationen sollten Stimmen mit unterschiedlicher Färbung und verschiedene Töne für wichtige Überschriften, Abschnitte und andere Strukturelemente verwendet werden.

    4. Wenn der Inhalt für eine bestimmte Zielgruppe aufbereitet wird und die Präsentation des strukturierten Inhalts nicht ausreichend deutlich wird, um die Anforderungen des jeweiligen Publikums zu erfüllen, sollten zusätzliche Grafiken, Farben, Töne und andere Präsentationsmöglichkeiten, die die Struktur hervorheben, eingesetzt werden.

  4. Kontraste von Vorder- und Hintergrund sind, wie es so schön heißt, eine persönliche Angelegenheit. WAI bietet bislang keinen Hinweis darauf, wie Webautoren vernünftigerweise vorwegnehmen, wie Personen mit eingeschränktem Sehvermögen oder Lernschwächen durch bestimmte Kombinationen von Schrift und Hintergrund verwirrt werden. Ferner, wer betreibt seinen Monitor eigentlich noch mit 256 Graustufen; ganz zu schweigen von Schwarz-Weiß-Darstellung (z. B. Ein-Bit-Farben, wie der Original-Macintosh)?

    1. Wenn Textinhalte auf einem Hintergrundbild oder -muster dargestellt werden, sollte der Text auch dann leicht lesbar sein, wenn die Seite mit 256 Graustufen betrachtet wird.

    2. Textinhalt sollte nicht auf einem Hintergrundbild oder -muster dargestellt werden, es sei denn, der Text ist in einer Schwarz-Weiß-Darstellung leicht lesbar (keine Graustufen).

    3. Ton-Inhalte sollten keine Hintergrundgeräusche enthalten, oder der Hintergrundsound ist mindestens 20 Dezibel leiser als der Ton-Inhalt im Vordergrund.

    4. Textinhalt sollte nicht auf einem Hintergrundbild oder einer Farbe dargestellt werden, es sei denn, die verwendeten Farben für Text und Hintergrund oder das Hintergrundbild bestehen den folgenden Test:

      • Zurzeit sind keine Test/ Algorithmen verfügbar

  5. WAI hat nicht erkannt, dass viel, oder sogar die meisten Web-basierten Spiele, immer für irgendjemanden unzugänglich sind. Es macht also wenig Sinn, vor einer unvorhersehbaren Meldung (eines Spielprogrammes) zu warnen, in der Absicht diese dadurch vorsehbarer zu machen.

    Wo inkonsistente oder unvorhersehbare Meldungen (responses) funktionaler Bestandteil des Inhalts einer Seite sind (z. B. Mystery Games, Adventure Games, Quizfragen etc.) sollte der Benutzer gewarnt werden, bevor er auf solche Meldungen stößt.

  6. Und hier ist wohl das größte einzelne Minenfeld, in dem sich die Web Accessibility Initiative selbst wiederfindet: Die Formulierung von Richtlinien für Menschen mit Lernbehinderung, von denen möglicherweise niemals eine signifikante Zahl online sein wird.

    Der aktuelle Entwurf ist eine große Verbesserung im Vergleich zu früheren Versionsvorschlägen, aber WAI klammert sich noch immer an die Vorstellung, dass »Inhalte überarbeitet werden können«, um zu zeigen, dass diese so einfach wie möglich verfasst sind. Aber wer zu simpel schreibt, verschreckt möglicherweise seine Zielgruppe. Hier wandelt sich die Zugänglichkeit, im Sinne eines Bemühens Webseiten zugänglicher zu machen, zu einer Neu-Formulierung der ursprünglichen eigenen Arbeit – und führt unweigerlich zu einer Illustration der eigenen Worte.

    Inhalte sollten nicht komplexer verfasst sein als erforderlich und/ oder ergänzt werden um vereinfachte Versionen des Inhaltes.

    • Der Inhalt (der vorausgehenden Versionen) wurde durchgesehen, unter Berücksichtigung der folgenden Strategien zur Bewertung der Komplexität von Inhalten. Die Strategien sollen in angemessener Weise angewendet werden:

      1. Vertrautheit mit Begriffen und Sprachstruktur

      2. Vernünftige Länge und Komplexität von Sätzen

      3. Zusammenhang von Absätzen (und Gespür für deren Länge)

      4. Klarheit von Überschriften und Linkbeschriftungen, wenn diese ohne Kontext gelesen werden

      5. Genauigkeit und Einzigartigkeit von Seitenbezeichnungen

      6. Vorsichtiger Gebrauch von Großbuchstaben, wo normale Groß-und Kleinschreibung der Verständlichkeit förderlicher wäre

      7. Zusätzlicher Gebrauch von Nicht-Text-Inhalten, um den Text für Schlüsselseiten oder -absätze einer Webpräsenz zu ergänzen, wo dies als angemessen erachtet wird.

  7. Abwärts-Kompatibilität Es gibt eine bestimmte Grenze, bis zu der man zurückgehen sollte, in einer Welt, wo fast jeder einen Browser der Version 5 oder aktueller benutzt und Webautoren valides HTML und CSS schreiben, die ihrerseits über Browser- und Gerätegrenzen hinaus kompatibel sein sollten.

    Wie immer gibt es viele Diskussionen um Menschen mit veralteter Technologie, auch ein Zugänglichkeitsthema, das aber jenseits des Gestaltungsbereiches der WAI liegt. Jeder muss sich neue Versionen beschaffen, warum sollten Menschen mit Behinderungen hier eine Ausnahme machen? Sollte standardkonformer Fortschritt im Web nur deshalb behindert werden, weil irgendwo irgendjemand noch seinen alten Screen Reader benutzen sollte?

    Auch gibt es keinerlei Verständnis für das neue und wertvollere Konzept der fortschreitenden Verbesserung (progressive enhancement) – ein Modell, dass nur das allernotwendigste HTML und CSS verwendet, um zunächst mit jedem nur denkbaren Gerät kompatibel zu sein, um dann zusätzliche Funktionen für anspruchsvollerer Geräte hinzuzufügen.

    Der Nutzen einer Bestimmung und die Dokumentation von grundlegenden Anforderungen an Benutzeragenten (user agents):

    • Individuen können – entweder durch die Seitendokumentation oder automatisch per Metadaten – feststellen, ob sie wahrscheinlich in der Lage sind, eine Seite zu nutzen oder nicht. In Verbindung mit einer Suchmaschine oder einem Proxy Server, kann das dazu dienen, dass Seiten automatisch gefiltert werden, die für einen Nutzer nicht zugänglich sind oder auch um die wichtigsten Seiten herauszufiltern, die am nützlichsten sein könnten.

    • Indem Seiten dazu veranlasst werden ihre grundlegenden Anforderungen zu dokumentieren, wird dies auch dazu führen, dass sie ihre Annahmen über Benutzeragenten bewerten und es wird die Anzahl der Seiten minimieren, die unweigerlich nicht zugänglich sein werden, weil sie sich nicht im klaren über Aspekte der Rückwärts-Kompatibilität sind.

    Der Nutzen beim Design von Abwärts-Kompatibilität:

    • Für Menschen, die alternative Browsertechnologien und -geräte nutzen müssen, werden Inhalte zugänglich gemacht.

    • Menschen die sich keine neueren Technologien leisten oder aus anderen Gründen keinen Zugang haben können, profitieren auch von der Abwärts-Kompatibilität, in der Weise, dass sie nicht – wie oft der Fall – neuere Softwareversionen oder Geräte erwerben müssen.

So gut wie unmöglich

Die Web Accessibility Initiative veröffentlicht den folgenden Richtlinienentwurf, obwohl dieser tatsächlich kaum umzusetzen ist. Hier wirst du wieder gebraucht, um technische Erklärungen zu liefern, die eigentlich von den WAI-Mitglieder selbst hätten kommen sollen, was bislang jedoch nicht geschehen ist. Oder du könntest Beispiele aus dem wahren Leben nennen und ausprobieren, wie schwierig es würde, die Richtlinien auf real existierende Seiten anzuwenden.

  1. »Collating a script«, also die Zuordnung eines Skripts für Audio-Beschreibung und Untertitel, wurde bislang genau ein einziges mal durchgeführt – für ein Demonstrationsprojekt, das nicht online dokumentiert ist. In der Praxis ist es unmöglich anzuwenden, weil es an Austauschformaten für Untertitel, Audio-Beschreibung und verwandte Anwendungsgebiete fehlt. Außerdem gibt es nicht sehr viele Beispiele für Multimedia-Anwendungen, die untertitelt und beschrieben wurden. Beides zu finden ist sogar ziemlich selten, wenn man die gesamte Bandbreite von Fernsehprogrammen und Kinofilmen mit berücksichtigt, zwei doch recht gut eingeführten Anwendungsbereichen.

    Live-Untertitelung ist für Online-Medien so gut wie unmöglich, wenn man dabei standardkonformen Code verwendet, während Live-Audio-Beschreibung gerade mal bei fünf Übertragungen außerhalb der Online-Sphäre versucht worden ist. Indes erfordern Untertitel, dass natürlich gleichzeitig gelesen und geschaut werden muss. Das ist doch keine Telepathie.

    1. Ein Textdokument, dass alle Audio-Beschreibungen und Untertitel in einem Skript vereint (das also Dialoge, wichtige Geräusche und wichtige visuelle Informationen in einem Textdokument zusammenführt), ist zur Verfügung zu stellen.

    2. Untertitel und Audio-Beschreibungen werden für alle Live-Übertragungen zur Verfügung gestellt, die dieselbe Information übermitteln.

    3. Die Präsentation verlangt vom Benutzer nicht, die Untertitel zu lesen und gleichzeitig der visuellen Darstellung zu folgen, um den Inhalt zu verstehen.

  2. Es ist unmöglich ein Style Sheet zu schreiben, dass Größe und Farbdarstellungsmöglichkeiten eines Displays herausfindet und dann, abhängig vom Ergebnis, unterschiedliche Befehle ausführt. Kaum jemand verwendet Schwarz-Weiss-Bildschirme; akustische Formatvorlagen (Aural Style Sheets) werden so gut wie nicht unterstützt und Stereo-Ton ist wohl die Regel. Die Richtlinie verlangt offenkundig einen Umschalter für Formatvorlagen (Style Sheet switcher) bei jeder einzelnen Website. Das Konzept die »Betonung der Struktur zu variieren« (»varying the emphasis on structure«) ist ziemlich schwer zu verstehen, es sei denn es bedeutet, dass bestimmte Elemente unsichtbar gemacht werden oder andere Elemente wiederum in 96-Punkt-Typen dargestellt werden.

    1. Die strukturierenden Hervorhebungen werden so gewählt, dass sie sich bei den wichtigsten unterschiedlichen Display-Typen (z. B. schwarz-weiß, kleines Display, Mono-Playback) unterscheiden.

    2. Inhalte werden so gestaltet, dass Benutzer die Darstellung der strukturierenden Elemente kontrollieren können.

    3. Wechselnde Darstellungsformate werden zur Verfügung gestellt, um die strukturierenden Hervorhebungen verändern zu können.

  3. Diese Richtlinie, die beabsichtigt Menschen mit Leseschwierigkeiten und Menschen mit ähnlichen Lernschwierigkeiten zu helfen, setzt eine Windows-artige Combo-Box voraus (Auswahlmenü mit Feld zur Tastatureingabe). Es würde außerdem eine Rechtschreibprüfung für jede Eingabe auf der entsprechenden Website erfordern. Das wäre dann in der Verantwortung des Besuchers – und es ist bereits möglich.

    1. Wo es möglich ist, kann der Benutzer aus einer Liste von Optionen seine Auswahl treffen und zudem eine direkte Texteingabe generieren.

    2. (Schreib-)Fehler werden identifiziert und wo das möglich ist, werden Korrekturvorschläge gemacht.

    3. Eine Prüfung für falsch geschriebene Wörter ist anzuwenden und eine korrekte Buchstabierung ist vorzuschlagen, wenn Texteingabe erforderlich ist.

Nicht unser Problem

Die Web Content Accessibility Guidelines 1 (WCAG) der Web Accessibility Initiative beabsichtigen «Web-Inhalte für Menschen mit Behinderungen zugänglich zu machen« Die Betonung liegt hier auf »Inhalt«. Allerdings gehen die vorgeschlagenen Richtlinien für die WCAG 2.0 weit über den Web-Inhalt hinaus. Sie erstrecken sich auf vom Inhalt losgelöste technische Bereichen und, ja tatsächlich, bis ins Gehirn des Autoren.

An dieser Stelle kann dein Beitrag zu einer Expertenmeinung werden, nämlich wie die vorgeschlagene Richtlinie auf deine Seite angewendet werden könnte. Würde die Seite durchfallen, den Test bestehen oder wäre sie irgendwo in der Mitte? Wäre es sogar für dich möglich, herauszufinden, ob du den Standards genügtest – oder nicht? Wie würde eine Zugänglichkeitsrichtlinie für Web-Inhalte wie die folgende deine Web-Entwicklung beeinflussen?

  1. Möchtest du wirklich, dass die Web Accessibility Initiative dir diktiert, wie »komplex« oder »ungewohnt« deine Inhalte sein dürfen, oder ob diese überhaupt komplex sind?

    Inhalte werden als komplex erachtet, wenn die Beziehungen zwischen einzelnen Informationen nicht einfach herauszufinden sind. Wenn die Darstellung von Informationen beabsichtigt, Trends oder Beziehungen zwischen Konzepten hervorzuheben, sollte dies ausdrücklich in der Zusammenfassung erklärt werden.

    Beispiele für komplexe Informationen:

    • Datentabellen,

    • Konzepte, die esoterisch oder schwer zu verstehen sind,

    • Inhalte, die mehrere Wahrnehmungsebenen einbeziehen.

    ungewohnter Inhalt

    Inhalte könnten ungewohnt sein, wenn spezifische Begriffe benutzt werden, die nur einer bestimmten Gruppe eigen sind.

  2. Abkürzungen und Akronyme stellen ein Problem dar, das vielleicht niemals zufrieden stellend gelöst werden kann, zumindest nicht so lange bis Screen Reader – und das ist der springende Punkt- verbessert werden, um mit diesen Spezialfällen besser umgehen zu können. Ferner ist die Diskussion um diakritische Zeichen ein Versuch, Autoren, die in arabischer oder hebräischer Sprache schreiben dazu zu zwingen, Vokalmarkierungen zu benutzen, die im allgemeinen von Erwachsenen Schreibern gar nicht verwendet werden – und das alles, weil Screen Reader nicht mit einem Schriftsystem klar kommen, das von Erwachsenen benutzt wird.

    1. Abkürzungen und Akronyme werden, jedes Mal wenn sie auftauchen, deutlich erklärt.

    2. Symbole, wie diakritische Zeichen, die im üblichen Gebrauch der natürlichen Sprache, in der ein Inhalt verfasst ist, für eine unzweideutige Identifikation von Wörtern erforderlich sind, sollen dargestellt werden oder es wird ein anderer Standardmechanismus zur Erzielung von Eindeutigkeit angeboten.

Wie kannst du Beiträge leisten?