Navigation

Darstellung anpassen

Service-Menü

Sprachversionen

Suche



Inhalt

Infothek

WCAG 1.0 / 2.0
WCAG Samurai Errata

27.06.2007

Ob die seit Jahren diskutierten WCAG 2.0 jemals fertiggestellt werden und sich dann in der Praxis als Maßstab für Barrierefreiheit durchsetzen, weiß niemand. Der kanadische Accessibility-Experte Joe Clark hat daher Anfang Juni 2007 die WCAG Samurai Errata mit interessanten, teilweise fragwürdigen Vorschlägen für die Korrektur der geltenden WCAG 1.0 veröffentlicht.

Ob die seit Jahren diskutierten WCAG 2.0 jemals fertiggestellt werden und sich dann in der Praxis als Maßstab für Barrierefreiheit durchsetzen, weiß niemand. Der kanadische Accessibility-Experte Joe Clark hat daher Anfang Juni 2007 die WCAG Samurai Errata mit interessanten, teilweise fragwürdigen Vorschlägen für die Korrektur der geltenden WCAG 1.0 veröffentlicht.

Einige dieser Vorschläge werden im Folgenden kommentiert:

Priorität 3 abschaffen?

Clark schlägt vor, allen Checkpunkten der WCAG dieselbe Verbindlichkeit zu geben. Auch die Checkpunkte der Priorität 2 "müssten" demnach erfüllt werden. Das ist ein sinnvoller Vorschlag, der in Deutschland bereits vollzogen ist.

Für die Weiterentwicklung der BITV interessanter ist der zweite Teil:

No to Priority 3: Not only do you not have to comply with any Priority 3 guidelines, most of which are unworkable, you must not comply with them.

Alle Checkpunkte der Priorität 3 sollen gestrichen werden. Das betrifft also nicht nur die mittlerweile veralteten, praktisch ohnehin kaum noch relevanten Checkpunkte zu Platzhaltern, druckbaren Zeichen oder Textalternativen zu Tabellen oder Imagemaps.

Zwei Gründe führt Clark an:

  • Die Einhaltung von Checkpunkten der Priorität 3 ist nicht immer angebracht und
  • Checkpunke der Priorität 3 sind Sache des Browsers oder Screenreaders.
1. Die Einhaltung von Checkpunkten ist nicht immer angebracht

Allgemein:

Among other issues, you are already obliged to use HTML according to the semantics of your document, and there can be more than one way to mark up your document content.

Am Beispiel der summary für Tabellen (Checkpunkt 5.5):

The summary attribute, by specification, cannot be manifested visually. HTML provides numerous ways of clarifying the purpose of tables (caption, summary, headers), and the same thing can also be done by explaining a table in plain text. When we say you must ignore this guideline, we mean you must ignore the requirement to use summary.

Das summary-Attribut ist ausschließlich für Benutzer mit Screenreadern vorgesehen, es gibt auch andere Möglichkeiten, den Aufbau von Datentabellen zu erläutern, nicht immer ist die Nutzung der summary zweckmäßig. Man soll daher nicht dem Checkpunkt der WCAG, sondern der Semantik des Attributs folgen, man soll es nur verwenden, wenn das für den Benutzer Sinn macht.

Leider ist das keine Selbstverständlichkeit. Außerhalb von Deutschland sind die Checkpunkte der Priorität 3 ja nicht einmal verbindlich, sie "können" erfüllt werden. Aber diese Unverbindlichkeit wird nicht als Aufforderung verstanden, Summaries nur anzubieten, wenn dies für den Benutzer Sinn macht. Die Existenz eines mit Text versehenen summary-Attributs gilt als Merkmal für Barrierefreiheit.

Also wird das summary-Attribut eingesetzt und gefüllt. Weil das so in der Richtlinie steht, ohne Rücksicht auf seine Semantik, den besonderen Informationsbedarf von Benutzern mit Screenreader. Man wiederholt noch einmal die auch für nicht sehende Benutzer lesbaren Überschriften, kopiert Informationen, die ohne weiteres auch dem Kontext zu entnehmen sind und (weil von allgemeinem Interesse) im summary-Attribut eigentlich nichts zu suchen haben.

Und das hat zur Folge: Benutzer erwarten im summary-Attribut nichts nützliches, sie beachten es nicht. Für den Fall, dass es tatsächlich gebraucht wird, über das Attribut also ein spezieller Informationsbedarf von Benutzern mit Screenreadern bedient werden könnte, steht es nicht mehr zur Verfügung.

"Schadet doch nichts" ist daher nicht die richtige Charakterisierung des Checkpunkts 5.5. Wie eine Reihe von anderen Checkpunkten verdankt er sich der Idee, Barrierefreiheit könne man an formalen Indizien festmachen. Materialisiert hat sich diese Idee in automatischen Prüfwerkzeugen wie "Bobby". Ihr trauriges Ergebnis ist das beschriebene schematische, gedankenkose Abhaken von Checkpunkten. Das hat nichts mit Barrierefreiheit zu tun, ist auch kein erster Schritt dahin. Barrierefreiheit geht nicht ohne Bezug auf das, was Clark Semantik nennt, den Benutzer.

Eine Korrektur wäre daher sinnvoll. Die Streichung des Checkpunkts hätte eine positive Wirkung auf die Barrierefreiheit.

2. Checkpunkte sind Sache des Browsers oder Screenreaders:
Beispiel Auszeichnung von Abkürzungen

Auch die Auszeichnung von Abkürzungen (4.2) gehört aus Sicht von Clark zu den Checkpunkten, deren Einhaltung nicht immer angebracht ist.

Acronyms and abbreviations without expansions in real-world use (e.g., DVD) don't have to be marked up.

Die Ausschreibung von "DVD" ist nicht nur überflüssig, sie wirkt negativ. Denn die meisten Benutzer sind zwar mit der Abkürzung vertraut, nicht aber mit ihrer ersatzweise vorgelesenen Ausschreibung. Auch hier: die schematische Benutzung des title-Attributs beschädigt es. Sie sorgt dafür, dass dort nichts Nützliches erwartet wird, es wird vom Screenreadernutzer abgeschaltet.

Der Checkpunkt müsste also zumindest genauer gefasst werden, es wäre zu klären, in welchen Fällen die Auszeichnung von Abkürzungen die Zugänglichkeitfür behinderte Benutzer verbessern kann.

Es kommt aber noch etwas anderes dazu. Auch wenn der Screenreader an Stelle einer Abkürzung deren Ausschreibung vorlesen sollte, ist die Auszeichnung nach Auffassung von Clark überwiegend nicht angebracht. Denn es ist falsch, die Sicherstellung der richtigen Aussprache beim Anbieter der Inhalte einzufordern.

Nor are we interested in perpetuating an unequal playing field, in which authors must mark up extensive bits and pieces of documents but makers of adaptive technology never have to update their own exception dictionaries.

Clark ist richtigerweise der Auffassung, dass die korrekte Aussprache von Texten die Aufgabe des Screenreaders ist. Der Text muss dafür Unterstützung leisten, er muss angeben wo er welche Sprache verwendet. Den Rest erledigt aber der Screenreader.

Die Basis dafür sind die in Bibliotheken für die verschiedenen Sprachen bereitgestellten Ausspracheregeln. Diese Regeln besorgen auch die richtige Aussprache von Abkürzungen wie "usw.", "DVD" oder "NATO". Manche Abkürzungen werden wie "usw." expandiert, die meisten werden wie "DVD" buchstabiert, einige werden wie Wörter ausgesprochen, zum Beispiel "NATO".

Denn auch die Aussprache von Abkürzungen ist in den Sprachen allgemein festgelegt, sie ist nicht dokumentspezifisch. Ihre Festlegung hat in Dokumenten nichts zu suchen, es ist unangebracht, bei jeder Verwendung einer Abkürzung aufs Neue die spezielle oder allgemeinere, jedenfalls in der betreffenden Sprache allgemein gültige Regel dazuzuschreiben, nach der sie auszusprechen ist.

Clark weist (in seinem @media-Vortrag) darauf hin, dass die Screenreaderhersteller da noch einiges zu tun haben. Richtig ist die Zuweisung der Aufgabe an den Screenreader hier trotzdem. Denn praktisch gibt es ohnehin keine Alternative dazu. Wie gesagt: niemand hört sich an Stelle von Abkürzungen das an, was in zugeordneten title-Attributen abgelegt ist.

Die Schlussfolgerung:

You don't have to expand abbreviations and acronyms unless a person with a disability cannot understand the document without the expansion.

Verlangt wird die Ausschreibung nur, wenn ein behinderter Nutzer das Dokument ohne sie nicht verstehen kann. Der Vollständigkeit halber: woran denkt Clark da, wann ist nach seiner Auffassung die dokumentseitige Angabe der Ausschreibung erforderlich?

Es soll Fälle geben, in denen der Schreibung nicht zu entnehmen ist, wie eine Abkürzung ausgesprochen werden soll. Es geht um zweideutige Wörter, die je nach Bedeutung unterschiedlich ausgesprochen werden. Die Auszeichnung von Abkürzungen sei dann unter Umständen sinnvoll.

Ein (deutschsprachiges) Beispiel von Clark:

GAU - Größter anzunehmender Unfall (worst-case scenario)
Gau - (county, state)

Quelle:http://joeclark.org/appearances/atmedia2007/

Eine Zweideutigkeit gibt es bei "GAU". Sie ist aber zumindest für die Aussprache nicht relevant, denn in beiden Bedeutungen wird die Buchstabenfolge gleich ausgesprochen. Außerdem lässt sie sich über die Großschreibung problemlos auflösen. Denn der GAU wird groß geschrieben, die Verwaltungseinheit nicht.

Soll man nach Fällen suchen, in denen alle drei Bedingungen (Mehrdeutigkeit, unterschiedliche Aussprache, nicht über Groß- und Kleinschreibung auflösbar) erfüllt sind, Abkürzungs-Tags also (in der Theorie, wenn es den jahrelangen Missbrauch nicht gegeben hätte) einen Nutzen für die richtige Aussprache von Wörtern haben könnten?

Clark weist zu Recht darauf hin, dass das Verhältnis von Aufwand und Ertrag in dieser Sache nicht gut ist. 8 Jahre intensiver Diskussion um die richtige Interpretation von Checkpunkt 4.2 haben kein positives Ergebnis hervorgebracht.

(Das gilt auch für die zweite mögliche Nutzanwendung von Abkürzungs-Auszeichnungen für die allgemeine Verbesserung der Verständlichkeit. Siehe hierzu: Abkürzungen auszeichnen?)

Es spricht also einiges dafür, auch den Checkpunkt 4.2 zu streichen.

Was bleibt?

Was bleibt von der Priorität 3 nach Streichung der Checkpunkte, die veraltet sind, immer schon fragwürdig waren, deren Anwendung nicht immer angebracht ist oder die beim Browser besser aufgehoben sind?

Einige Checkpunkte könnten als Anregungen für die verständliche Aufbereitung von Webangeboten genutzt werden. Das betrifft:

  • die gleiche Gestaltung gleichartiger Inhalte (14.3)
  • die Unterstützung der Orientierung durch aussagekräftige Überschriften (13.8)
  • die Veranschaulichung durch Beispiele oder Schaubilder (14.2)

Auch der Checkpunkt 4.2 zu Abkürzungen könnte so verstanden werden. Bei Bedarf abrufbare Erläuterungen zu Fachbegriffen oder nicht allgemein üblichen Redewendungen sind eine gute Unterstützung der allgemeinen Verständlichkeit von Fachtexten.

Die Checkpunkte werden aber nicht in diesem Sinne verstanden und genutzt. Die Alternative zur Streichung wäre also eine grundlegende Überarbeitung, die Checkpunkte müssten anders gefasst und erläutert werden. In ihrer jetzigen Form sind auch sie nutzlos, sie können keine Verbindlichkeit beanspruchen.

Es bleibt unter dem Strich also fast nichts übrig.

Clark nennt die Festlegung der Hauptsprache und schlägt vor, sie dem Checkpunkt zu Sprachwechseln zuzuordnen. Kontraste von Text erwähnt er nicht. Sie sind in den WCAG nicht eigenständig gefasst, gehören zu Checkpunkt 2.2.

Zwei Hinweise an dieser Stelle:

  1. Nicht an allen Stellen teilen wir Clarks Verständnis der Checkpunkte der Priorität 3. Das betrifft insbesondere die in den Errata ausgeklammerten Anforderungen an die Verständlichkeit. Die vorgeschlagene Streichung ist aber richtig. Nicht überprüfbare Anforderungen können in der Praxis keine Geltung beanspruchen, sie haben in der BITV nichts zu suchen.
  2. Im BITV-Test sind die Korrekturvorschläge von Clark schon seit einigen Jahren umgesetzt. Nicht sinnvolle Bedingungen der BITV werden dort nicht geprüft, die der WCAG Priorität 3 entsprechenden BITV-Bedingungen spielen bis auf die beiden angegebenen Ausnahmen im Test keine Rolle.

PDF nur wenn nötig?

Clark schlägt vor, die Verwendung des PDF nur für bestimmte Anwendungsfälle zuzulassen. Es soll nur verwendet werden für Aufgaben, die sich mit HTML nicht umsetzen lassen. Er listet insgesamt 13 Fälle auf, in denen der Einsatz des PDF erlaubt sein soll. Dokumente mit Fußnoten gehören dazu, Dokumente, die nicht änderbar sein sollen, bestimmte mathematische Formeln, Schrifttypen, Formulare. (Siehe den Abschnitt der Errata zu Guideline 11. Eine ähnliche Auflistung in deutscher Übersetzung findet sich bei Einfach für Alle.)

Die Idee ist nicht schlecht. Denn klar ist: HTML ist aus Sicht der Barrierefreiheit das bessere Format und die meisten im Web veröffentlichten PDFs könnten wohl genauso gut HTML-Seiten sein. Webanbieter sollten also prüfen, ob es wirklich nötig ist, durch Wahl des Formats PDF die allgemeine Zugänglichkeit eines Dokuments einzuschränken.

Für verbindliche und überprüfbare Vorgaben taugt die Festlegung erlaubter Einsatzbereiche allerdings nichts.

Der "Haken" ist Anwendungsfall 4:

Custom-crafted solely for printing. I really mean that, and not a document so badly designed that people have no choice but to print it out because reading onscreen is so tedious. Your service-bureau files, if they are on the Web at all, can stay PDFs.

Das Dokument wird über das Web verbreitet, das ist der Ausgangspunkt. Es kann ohne Ausdrucken genutzt werden und es wird auch gelegentlich so genutzt, weil das weniger umständlich ist, die Schrift sonst zu klein ist oder kein Papier verschwendet werden soll. Woran soll man also erkennen, dass es "nur für den Ausdruck" gestaltet worden ist, dass seine Nutzung am Computer nicht beabsichtigt, quasi missbräuchlich ist?

PDFs werden auch am Computer gelesen, HTML-Seiten werden auch ausgedruckt. Die vorgeschlagene Unterscheidung ist für über das Web verbreitete Inhalte nicht sinnvoll und nicht durchführbar.

Man kann Clark auch anders lesen, er will wohl auch sagen, dass die Gestaltung eines Dokuments seine Verbreitung als PDF rechtfertigt. Plausibel und als Begründung für den Einsatz von PDF akzeptabel wäre das jedenfalls. Denn wenn eine vorgegebene Gestaltung bei Wechsel des Ausgabegerätes unverändert bleiben soll, ist PDF zweifellos das besser geeignete Format, mit HTML geht das schlechter.

Aber auch dieser Ansatz liefert keine handhabbare Abgrenzung nicht erlaubter Einsatzbereiche. Denn jedes Dokument ist in irgend einer Weise gestaltet, der Anbieter kann stets darauf beharren, dass diese Gestaltung eine gewisse Bedeutung hat, auf verschiedenen Ausgabemedien erhalten bleiben soll, die Wahl des Formats also wohlbegründet ist. Clark zieht ein wenig her über "badly designed" Dokumente, die eigentlich die per PDF erreichbare Geräteunabhängigkeit nicht beanspruchen können. Aber über Geschmack lässt sich streiten, das führt nicht weiter.

Fazit also: Es macht Sinn, über die Vor- und Nachteile des Formats aufzuklären und zu sagen, für welche Zwecke es nicht geeignet ist. Die letztendliche Entscheidung muss man dann aber dem Anbieter überlassen.

Die andere Seite der "Zulassung" des Formats: An PDFs sind dieselben Anforderungen zu stellen, die auch HTML-Seiten erfüllen müssen. Und das bedeutet vor allem: Barrierefreiheit ist keine Formsache, Tagging per Knopfdruck reicht nicht aus, Barrierefreiheit ist nicht Screenreader-Nutzbarkeit. Nebenbei ist damit auch die einzige definitiv nicht akzeptable Begründung für den Einsatz des PDF zurückgewiesen: Man soll es nicht einsetzen, um sich den Aufwand für die barrierefreie Aufbereitung von über das Web verbreiteten Informationsangeboten zu sparen.


Dynamische Webangebote direkt zugänglich machen?

Do not provide alternative presentations or alternate pages (Checkpoint 6.5). Make the original page accessible.

Alternative Spezialangebote für Behinderte sind häufig nicht gleichwertig, daher immer problematisch. Selbst wenn das alternative Angebot nicht schlechter ist: Der Benutzer hat andere Erfahrungen gemacht, er weiß nicht, ob ihm etwas entgeht. Auch gibt es keinen vernünftigen Grund, zum Beispiel Tastaturbedienbarkeit nur bei gleichzeitigem Verzicht auf dynamisch generierte Inhalte zu ermöglichen oder Benutzern mit Screenreader die sofortige Überprüfung ihrer Formulareingaben vorzuenthalten.

Dynamische Webangebote sollten daher direkt zugänglich sein.

Fraglich ist aber die Entgegensetzung von alternativen Angeboten und direkter Zugänglichkeit:

  1. Manches von dem, was dynamische Webangebote für sehende Benutzer attraktiv macht, insbesondere die mehrgleisige, beiläufige Reaktion auf Benutzereingaben ist für nicht oder schlecht sehende Besucher keine Bereicherung, sondern eine Barriere. Dass die dynamischen Inhalte verzichtbar sind, das Ganze auch ohne sie funktioniert, muss nicht immer die zweitbeste Lösung sein.
  2. Die Entwicklung und Verbreitung von Standards für die barrierefreie Gestaltung dynamischer Inhalte ist nicht abgeschlossen. Allgemein anerkannte, verbindliche Regeln gibt es noch nicht. Die direkte Zugänglichkeit reicht daher nicht aus, das Ganze muss auch ohne die dynamischen Elemente funktionieren.

Bewegung einschaltbar?

Sounds may not play without user activation.
Videos may not play without user activation. Your page or site may not automatically play videos upon loading the page.

Der Benutzer entscheidet, ob er ein Musikstück hören oder sich ein Video ansehen will. Das ist eigentlich eine Selbstverständlichkeit, erst recht, wenn auch Benutzer bedient werden sollen, die nicht gut hören oder sehen.

Do not cause flickering, flashing, or blinking. Advertisements served by a third party on a page you control are covered by this guideline and may not cause flickering or blinking, either.

Die Webseite soll nicht versuchen, ihrem Besucher die Befassung mit (vielleicht besonders wichtigen) Inhalten aufzuzwingen. Es macht an dieser Stelle auch keinen Sinn, zwischen Werbung und anderen Inhalten einen Unterschied zu machen. Denn verkaufte Werbeflächen erfüllen den Tatbestand der Behinderung durch Ablenkung genauso wie blinkende Hinweise auf eigene Neuheiten. Das ist eine gute Klarstellung.

Schließlich:

"Moving content," scrolling, crawling, or animation cannot play automatically, even in advertisements. The site visitor must choose to experience such moving content (either by site-wide preference, by explicitly clicking or selecting an on switch, or by another means that is accessible to users with disabilities).

Der Besucher muss nicht reagieren, wird nicht gezwungen, nach mehr oder weniger gut auffindbaren Ausschaltern zu suchen. Die Bewegung wird also eingeschaltet.

Auch das ist ein guter Vorschlag. Aber manchen Anbietern sind schon die jetzigen Anforderungen zu hoch. Die für die WCAG 2 diskutierte automatische Beendigung von Bewegungen ist nicht viel schlechter, vielleicht konsensfähiger.


embed zulassen?

If the sole cause of invalidity on your HTML or XHTML page is the use of the embed tag for video, your page is deemed to comply if the video is made accessible by captioning or audio description, as required by the content.

Das embed-Element wurde vom W3C nie in die HTML-Spezifikation aufgenommen, seine Verwendung ist ein klarer Verstoß gegen die Sprachregeln. Das spricht gegen die vorgeschlagene Ausnahmeregelung.

Auf der anderen Seite hat die Nutzung von embed aus Sicht der praktischen Barrierefreiheit keinerlei Nachteile. Und eine 100% saubere, unter allen Umständen und in allen Browsern funktionierende alternative Technik zur Einbindung von Multimedia scheint es nicht zu geben.

Hier ist also zwischen zwei Übeln abzuwägen. Vielleicht sollte die Weiterentwicklung der BITV auch diesen Vorschlag übernehmen.


Quote?

You do not have to use the q element; you do have to indicate inline quotations, as by the use of quotation marks or figure dashes.

Clark weist zu Recht darauf hin, dass in der Schrift bereits Zeichen für Inline-Zitate vorgesehen sind. Wie für die Kennzeichnung von Fragen oder die Andeutung von Pausen gibt es auch für Zitate Satzzeichen, deren Bedeutung unabhängig von der Gestaltung allgemein festgelegt ist.

Für die Gliederung eines Textes in Zitate und kommentierende Absätze sind die Anführungszeichen nicht gut geeignet, da verwendet auch die Gestaltung andere Mittel (zum Beispiel Einrückung). Die Auszeichnung mit blockquote ist also richtig. Die Auszeichnung mit q ist dagegen nicht nötig, eine entsprechende Korrektur ist sinnvoll.


px für Schriftgrößen?

You may use any defined units for text sizing, layout, or other purposes. The difference between relative and absolute units is immaterial to these errata. (px, by specification, was and is a relative unit.) Use of px as a unit to size text is explicitly permitted.

Richtig ist: px ist im Sinne der HTML-Spezifikation eine relative Einheit.

Richtig ist auch, dass die Veränderbarkeit von Schriftgrößen eigentlich nicht zu den Aufgaben von Webdesignern gehören sollte. Browser können das erledigen, in fast allen gängigen Browsern kann man auch mit px definierte Schriften problemlos vergrößern oder verkleinern.

Aber Clark weiß natürlich auch, dass der marktbeherrschende Browser nach wie vor die Veränderung der Schriftgröße bei px-definierten Schriften nicht zulässt. Sein Lösungsvorschlag:

If you're using IE6 because you don't even know there is such a thing as a Browser, let alone more than one of them, then you need to have your grandkids over so they can download Firefox and teach you how to make the fonts bigger and smaller.

(...)

And anyway, font resizing is an issue for nondisabled people - or people who don't have a visual impairment, more accurately.

Quelle: http://joeclark.org/appearances/atmedia2007/#fonts

Die Enkelkinder sollen helfen, auch sei die Sehschwäche im Alter gar keine echte Behinderung, nicht gravierend genug. Das ist sicher kein akzeptables Verständnis von Barrierefreiheit. Clark hält das auch gar nicht durch, fordert gleich darauf, auch etwas für die bessere Zugänglichkeit entsprechender Browserfunktionen zu unternehmen.

Aber zurück zur Schriftgröße:

Barrierefreiheit ist nicht dasselbe wie Benutzbarkeit mit bestimmten Browsern oder Screenreadern. Sie muss sich auf geltende Standards stützen, sonst ist sie nicht nachhaltig. Es ist falsch, sich zu eng an der Leistungsfähigkeit von bestimmten Browsern oder Screenreadern zu orientieren. Denn wenn man das macht, muss beim nächsten Versionswechsel wieder von vorne angefangen werden.

Das Ziel der Orientierung an Standards ist aber die praktische Benutzbarkeit, die darf nicht auf der Strecke bleiben. Deswegen ist die Semantik (relativ oder absolut) von px im Zusammenhang mit der Veränderbarkeit von Schriftgrößen nicht interessant. So lange der Internet Explorer nicht vom Markt verschwunden ist, dürfen Seiten, die barrierefrei nutzbar sein wollen, die Einheit px für die Bestimmung von Schriftgrößen nicht verwenden.


Schriftgrafiken?

There is no prohibition against using pictures of text ("images to represent text") if correct text equivalents are provided.

Richtig ist: Schriftgrafiken sind für blinde Benutzer nicht sehr problematisch. Sprachwechsel können nicht ausgezeichnet werden, abgesehen davon kann sie das Text-Äquivalent gut ersetzen. Sie können aber die Zugänglichkeit für sehbehinderte Benutzer einschränken, denn die Farben sind nicht variabel und man kann sie in der Größe weniger gut anpassen.

Checkpunkt 3.1 der WCAG verbietet daher mit gutem Grund den Einsatz von Schriftgrafiken:

use markup rather than images to convey information


Sitemap?

Do not provide a Sitemap or table of contents unless the site cannot be understood or navigated without it.

Es gibt unterschiedliche Meinungen über den Nutzen von Sitemaps. Wenn klar ist, welche Information gebraucht wird, ist eine leistungsfähige Suchfunktion vielleicht wichtiger. Wer mehr Anregung und Unterstützung braucht, ist vielleicht mit der schrittweisen Orientierung des Menüsystems besser bedient.

Die Sitemap soll diese Navigationsmöglichkeiten aber nicht ersetzen. Sie ermöglicht einen anderen, für manche Benutzer besser geeigneten Zugang, das ist ihr Beitrag zur Barrierefreiheit. Der Vorschlag, sie nur alternativ zu anderen Navigationsmitteln anzubieten geht an der Zweckbestimmung des Checkpunkts vorbei.


Was noch?

Bei einer Reihe von weiteren Forderungen der Errata ist der Korrekturbedarf eher undeutlich:

  • "Do not use server-side imagemaps"

    Server-side imagemaps werden selten verwendet. Bekannt sind Beispiele, in denen sie für Stadtpläne eingesetzt werden. Der Benutzer kann per Maus eine Pixelposition markieren, der Server liefert auf dieser Basis Informationen.

    Soll der Einsatz von server-side Imagemaps für solche Fälle verboten werden? Dagegen spricht: Für nicht sehende Benutzer ist dieser Art der Auswahl unabhängig von der eingesetzten Technik nicht möglich. Eine für sehende Mausnutzer gleichwertige, zugleich besser zugängliche technische Lösung gibt es daher nicht.

  • "Do not use frames."

    Es gibt viele gute Argumente für den Verzicht auf Frames, meist aus dem Bereich der Usability. Entsprechend selten findet man sie auf barrierefreien Webangeboten. In den (sicherlich sehr seltenen) Fällen, in denen der Einsatz von Frames für eine bestimmte Anwendung mehr Vor- als Nachteile hat, spricht jedoch aus Sicht der Barrierefreiheit nichts gegen ihre Nutzung, vorausgesetzt sie sind korrekt ausgezeichnet.

  • "Do not use tables for layout."

    Diese Forderung steht bereits in den WCAG 1.0, Checkpunk 3.3 sagt, dass das Layout über Styles realisiert werden soll. Ein wenig relativiert wird die Forderung durch die Checkpunkte 5.3 und 5.4, die vorschreiben, dass Layouttabellen linearisierbar sein müssen und keine Strukturelemente enthalten dürfen.

    Gesagt wird damit:

    Die Barrierefreiheit steht und fällt nicht mit dem Ersatz von Layouttabellen durch Stylesheets. Stylesbasierte Seiten sind nicht automatisch besser zugänglich und es gibt aus Sicht der Barrierefreiheit einen wesentlichen Unterschied zwischen linearisierbaren und nicht linearisierbaren Layouttabellen.

    Das ist richtig, eine Korrektur ist daher nicht angebracht.

  • "Ignore all references to ... monochrome displays."

    Clark schlägt vor, Helligkeitskontraste nicht zu beachten und stattdessen bestimmte Farbkombinationen zu vermeiden. Diese Entgegensetzung ist falsch. Die Helligkeit (der Reflexionsgrad) ist der wichtigste Kontrastfaktor, das gilt auch bei Farbfehlsichtigkeit. Man kann sich mithilfe eines Simulators wie vischeck leicht davon überzeugen, dass auch ungünstige Farbkombinationen kontrastieren, wenn die beiden Farben nicht denselben Helligkeitswerte haben.


Fazit

  • Viele Checkpunkte der Priorität 3 sind veraltet oder sie waren immer schon fragwürdig. Einige weitere Checkpunkte haben in der Praxis keine positive Wirkung, teilweise verschlechtert ihre Anwendung die Barrierefreiheit von Webangeboten. Der Vorschlag, die Priorität 3 zu streichen ist daher eine gute Anregung für die fällige Überarbeitung der BITV. Die wenigen sinnvoll anwendbaren Reste können anderen Checkpunkten zugeordnet werden.
  • Der Vorschlag, auf Basis der unterschiedlichen Leistungsfähigkeit zulässige Anwendungsgebiete für PDFs zu definieren ist nicht praktikabel. Denn das PDF erlaubt im Unterschied zu HTML die medienübergreifend einheitliche Gestaltung, jedes PDF-Dokument kann diesen Vorzug des Formats für sich in Anspruch nehmen.
  • Dynamische Webangebote sollten direkt zugänglich sein. So lange das nur eingeschränkt möglich ist, muss die Dynamik aber verzichtbar sein.
  • Der Vorschlag, die Benutzerkontrolle besser sicherzustellen ist gut. Wenn Bewegungen nach einer festgelegten Zeitspanne von selbst aufhören, ist das aber auch nicht viel schlechter.
  • Der Vorschlag, embed als "Ausnahme" zuzulassen ist gut.
  • Inline-Zitate müssen nicht ausgezeichnet werden.
  • Der Vorschlag, px zuzulassen ist Prinzipienreiterei an der falschen Stelle.
  • Der Vorschlag, Schriftgrafiken zuzulassen ist nicht gut, denn Grafiken sind nicht angemessen für die Darstellung von Texten, sie legen sehbehinderte Benutzer auf eine vorgegebene Gestaltung fest.
  • Der Vorschlag, Sitemaps zu verbieten ist auch nicht gut.

Links

Zu den Errata gehört ein Einleitungspapier. Alle Zitate beziehen sich, wenn nicht anders angegeben auf das Einleitungspapier oder die eigentlichen Errata.

Autor: Michael Zapp
Veröffentlicht am 27.06.2007