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