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:
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:
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.
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 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:
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:
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.
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:
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.
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.
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.
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.
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
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.
Bei einer Reihe von weiteren Forderungen der Errata ist der Korrekturbedarf eher undeutlich:
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.
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.
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.
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.
embed als "Ausnahme" zuzulassen ist gut.px zuzulassen ist Prinzipienreiterei an der falschen Stelle.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
© 2013 DIAS GmbH | Impressum | Barrierefreiheit
bitvtest.de ist ein Webangebot des BIK-Projekts