Navigation

Darstellung anpassen

Service-Menü

Sprachversionen

Suche



Inhalt

Infothek

WCAG 2.0
Kommentare und Änderungsvorschläge des BIK-Projekts

11.12.2007

Hier finden Sie Übersetzungen der vom Projekt BIK eingereichten Kommentare und Änderungsvorschläge zur "Last Call Working Draft" der WCAG 2.0 vom 11.12.2007.

Auf dieser Seite:

Thema Kontraste: Ist nachgewiesen, dass der neue Algorithmus zur Berechnung der Helligkeit dem alten überlegen ist?

Bezieht sich auf: Success Criterion 1.4.3

Unser Kommentar:

In den "Techniques For Accessibility Evaluation And Repair Tools (W3C Working Draft, 26 April 2000)" wurde ein Algorithmus zur Berechnung der Helligkeit eines RGB-Werts vorgeschlagen. Als Nachweis wurden empirische Studien durchgeführt, der Algorithmus wurde und wird auch heute noch in der Praxis genutzt.

In diesem alten Algorithmus sind die RGB-Anteile wie folgt gewichtet:
0.299 * R + 0.587 * G + 0.114 * B

Die vorgeschlagene neue Berechnung der Helligkeit gewichtet die Anteile anders:
0.2126 * R + 0.7152 * G + 0.0722 * B

War der alte Algorithmus fehlerhaft? Falls nicht: ist nachgewiesen, dass der neue Algorithmus für das Anwendungsfeld angemessener ist?

Unser Änderungsvorschlag:

Überlegenheit des neuen Algorithmus im Vergleich zur alten Berechnung der Helligkeit nachweisen.

Link zum BIK-Kommentar im W3C-Mailingsystem


Thema Kontraste: Mindestkontrast notwendig für Default-Layout, falls 1.4.3 durch einen Styleswitcher zur Einstellung des Kontrasts erfüllt wird

Bezieht sich auf: Success Criterion 1.4.3

Unser Kommentar:

Es scheint etwas unausgewogen, einerseits von Webdesignern zu verlangen, sich auf eine recht begrenzte Farbpalette zu beschränken, ihnen aber anderseits die Möglichkeit zu bieten, das Erfolgskriterium durch Hinzufügen eines Kontrastreglers einfach mehr oder weniger zu ignorieren. Selbst eine Website mit extrem schwachen Kontrasten (zum Beispiel hellgrauer Text auf weißem Hintergrund) könnte das Erfolgskriterium 1.4.3 leicht erfüllen, wenn der Designer einfach einen unauffälligen Styleswitcher irgendwo ganz unten auf der Seite platziert. Wir befürchten, dass dies Webdesigner dazu verführen könnte, das Thema Kontraste im Default-Layout komplett zu ignorieren und das Erfolgskriterium 1.4.3 allein durch den Styleswitcher zu erfüllen.

Hiervon dürften zwar Benutzer mit schwerer Farbfehlsichtigkeit kaum betroffen sein (denn wer unbedingt auf bestimmte Farbkombinationen angewiesen ist, muss sowieso seinen Browser entsprechend einstellen), für Benutzer mit leichterer Farbfehlsichtigkeit könnte die Zugänglichkeit allerdings deutlich eingeschränkt werden. Diese Nutzer müssten nämlich den Styleswitcher suchen und herausbekommen, wie er genau funktioniert und welche Einstellungsmöglichkeiten er bietet – und das immer wieder bei jeder Website die sie aufsuchen.

Unser Kommentar:

Das Default-Layout sollte von vornherein einen Mindestkontrast erreichen, z.B. ein "Contrast Ratio" von 3:1 – und zwar auch dann, wenn ein Styleswitcher zur Einstellung stärkerer Kontraste angeboten wird.

Außerdem sollte in den Guidelines festgelegt sein, dass der Styleswitcher selbst einen "Contrast Ratio" von mindestens 5:1 haben sollte und weit oben im Kopfbereich der Seite positioniert sein sollte. Es sollte außerdem klar beschriftet sein (und nicht bloß als winziges und möglicherweise uneindeutiges Icon).

Link zum BIK-Kommentar im W3C-Mailingsystem


Thema Kontraste: Warum gelten die Kontrastanforderungen nicht für Linien in Diagrammen und Ähnliches?

Bezieht sich auf: Success Criterion 1.4.3

Unser Kommentar:

Warum gelten die Kontrastanforderungen nur für Text und Grafiken mit Text? Was ist mit anderen wichtigen Teilen von informationstragenden Grafiken – zum Beispiel Linien in Diagrammen, Icons oder Symbolen in Landkarten und so weiter? Oder auch andere Nicht-Text-Elemente wie die Rahmenlinien von Texteingabefeldern in Formularen?

Benutzer können in fast allen modernen Browsern ihre eigenen Farben für Text festlegen, die Farben in Grafiken können sie allerdings nicht kontrollieren. Daher ist ein ausreichender Kontrast für Grafiken sogar noch wichtiger als für Text.

Unser Änderungsvorschlag:

Alle wesentlichen Teile einer Webseite brauchen ausreichende Kontraste – nicht nur Text und Grafiken mit Text.

Link zum BIK-Kommentar im W3C-Mailingsystem


Thema Hintergrundbilder und Transparenz: In den WCAG 2.0 nicht berücksichtigt: Hintergrundbilder verschwinden bei benutzerdefinierten Farben

Bezieht sich auf: Guideline 1.4

Unser Kommentar:

Benutzer mit schweren Farbfehlsichtigkeiten stellen in ihrem Browser oft bestimmte Vorder- und Hintergrundfarben ein. Das bewirkt allerdings, dass alle Hintergrundgrafiken verschwinden – problematisch bei informationstragenden Grafiken. Diese Tatsache wird im aktuellen Entwurf nicht ausreichend berücksichtigt.

Ein verwandtes Problem wird anscheinend ebenfalls nicht berücksichtigt: Bilder mit transparentem Hintergrund sind unter Umständen auf benutzerdefiniertem Hintergrund nicht sichtbar beziehungsweise lesbar.

Unser Änderungsvorschlag:

In den Richtlinien sollte festgelegt sein, dass Bilder, die wichtige Informationen vermitteln, nicht als Hintergrundgrafiken eingebunden werden sollen.

Dieses Problem wird zwar bereits in F3 ("Failure of Success Criterion 1.1.1 due to using CSS to include images that convey important information") behandelt, allerdings bezieht sich dieser "Failure" nur auf Success Criterion 1.1.1 und damit auf blinde Benutzer (denn via CSS eingebundene Hintergrundgrafiken können kein alt-Attribut haben). Er sollte sich auch auf Benutzer mit Farbfehlsichtigkeiten beziehen.

In den Richtlinien sollte außerdem festgelegt sein, dass alle Bilder, die wichtige Informationen vermitteln, unabhängig von der eingestellten Hintergrundfarbe sichtbar bzw. lesbar bleiben müssen.

Link zum BIK-Kommentar im W3C-Mailingsystem


Thema Sprachauszeichnung: Warum werden Namen und technische Begriffe ausgenommen?

Bezieht sich auf: Success Criterion 1.4.3

Unser Kommentar:

In Deutschland werden Eigennamen und technische Begriffe normalerweise entsprechend den englischen Ausspracheregeln ausgesprochen, also sollten sie von Screenreadern auch so vorgelesen werden (Beispiel: Firefox, fieldset, label).

Wenn ein Eigenname oder technischer Begriff nicht in die Sprache eingegangen ist, dann kann die richtige Aussprache nur per Sprachauszeichnung via lang-Attribut sichergestellt werden (Beispiel: <span lang="en">Firefox</span>).

Unser Änderungsvorschlag:

Deutlich machen, dass die Sprachauszeichnung via lang-Attribut auch bei Eigennamen und technischen Begriffen in vielen Fällen angebracht ist.

Link zum BIK-Kommentar im W3C-Mailingsystem