sprungmarker testet

Barrierefreiheit: immer noch in der argumentativen Beta

Ist es nicht so, dass wir uns in der Barrierefreiheit – abgesehen von wenigen wirklichen Fachgesprächen – noch immer in der argumentativen Beta bewegen? Sind wir in Sachen Webstandards oder Javascript-Frameworks nicht schon viel professioneller unterwegs, was meint, dass die professionelle Streuung in Artikeln und Fachinformationen eben schon viel üppiger und besser ist. Aber warum ist das in der Barrierefreiheit nicht so?

Man kann das an einem konkreten, aktuellen Beispiel – dem Artikel Kontrastreiche Farbwelten – etwas herausarbeiten, wo leider etliche Unschärfen in der barrierefreien Argumentation zu finden sind. Der Artikel ist sicherlich ein gut gemeinter Versuch, die Problematik der Farbkontraste von Webseiten im Hinblick auf Barrierefreiheit herauszuarbeiten, in vielem ist er auch fachlich auf dem richtigen Weg, aber das Insgesamt ist nicht wirklich stimmig und stimmt eben dann nur halb. Ich werde mich nur auf den Hauptstrang Rot-Grün-Blindheit und Kontraste fokussieren, weil der Artikel hier nicht genau genug argumentiert.

Kontraste sind wichtig für Menschen mit schwachem Sehvermögen

Der Artikel beginnt in der Argumentation mit der Farbfehlsichtigkeit und gibt dafür ein Beispiel mit Screenshot für Rot-Grün-Blindheit. Damit wird in die Kontrastproblematik eingeleitet, es folgen die Vorgaben des WCAG 2 (ich würde hier eher die WAI nennen, das W3C ist eher sehr allgemein gehalten). Als Randbemerkung hierzu: In Deutschland optimieren wir Webseiten immer noch nach dem aktuellen BITV, leider warten wir ja immer noch auf die BITV 2. Freilich weichen wir schon einige Zeit auf das WCAG 2 aus, aber es sollte schon eine Anmerkung wert sein, dass wir da derzeit alle in einer Grauzone arbeiten.

Wir haben nun mit dem WCAG 2 ein Werkzeug an der Hand, das uns endlich aus der argumentativen Beta bringt. Im Gegensatz zu Version 1 ist das WCAG 2 viel präziser, bietet mit den Understandings und den technischen Dokumenten schlicht ein gutes Paket, um ein Thema wie Kontraste genau aufzuarbeiten. Wir sollten die WCAG 2 daher auch wirklich nutzen und zu Fragen wie Kontraste einfach mal die Spezifikation genau lesen:

The intent of this Success Criterion is to provide enough contrast between text and its background so that it can be read by people with moderately low vision (who do not use contrast-enhancing assistive technology (…). Color deficiencies can affect luminance contrast somewhat. Therefore, in the recommendation, the contrast is calculated in such a way that color is not a key factor so that people who have a color vision deficit will also have adequate contrast between the text and the background.

Quelle: Contrast (Minimum) -WCAG 2

Hier wird genau ausgeführt, für wen die Kontrastproblematik vorrangig wichtig ist: für Menschen mit low vision, was grob übersetzt heisst für Menschen mit schwachem oder reduziertem Sehvermögen. Welche Ursachen schwaches Sehvermögen haben kann wie Grauer oder Grüner Star, kann man bei Hellbusch gut nachlesen: Anforderungen an ein sehbehindertengerechtes Screendesign. Davon zu unterscheiden ist die Farbproblematik, die etwas auch Rot-Grün-Blinde betrifft. Es wird bei dem Kontrastverhältnis, das das WCAG 2 vorgibt, darauf geachtet, dass auch die Farben für Farbfehlsichtige ausreichend kontrastieren, daher auch der klare Hinweis in der Spezifikation, dass Kontrast in dieser Frage eine untergeordnet Rolle spielt, hier greift Use of Color:

1.4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)

Quelle: Guideline 1.4 Distinguishable: Make it easier for users to see and hear content including separating foreground from background. – WCAG 2

Hierbei ist vorderhand wichtig, dass man mit Farbe allein nichts regelt, sondern immer noch mit anderen Elementen wie Unterstreichungen oder zusätzlichen Zeichen etwas unterscheid- und erkennbar macht. Kontraste spielen hier nur eine untergeordnete Rolle. Es ist quasi eher umgekehrt, durch eine gelungene und geeignete Farbgebung wird der Kontrast erst unterstüzt. Ebenso ist es wichtig, dass man gewisse Farbkombinationen für Farbfehlsichtige vermeidet.

Abgesehen davon, dass der Artikel das argumentativ ungelenk aufbaut – 90 % der Leser nehmen jetzt an, Kontraste haben nur was mit Rot-Grün-Blindheit zu tun -, dass das Problem Farbe nur einseitig behandelt wurde (WCAG 2 1.4.1, 1.4.8), sind auch sonst noch Unstimmigkeiten enthalten (Stichworte unter anderem: Was ist ein gemusterter Hintergrund und warum sollte man das auch machen, wichtigen, lesbaren Text auf diesen zu setzen? Geht es hier eher um Schriftgrafiken? Das wäre dann ja eine genauere Betrachtung wert oder der Hinweis, dass die Farbpalette in vollem Umfang zur Verfügung steht, eben gerade nicht, weil sich viele Kombinationen aufgrund von Konstrastproblemen ausschliessen …).

Fazit

Dass Kontraste für eine barrierefreie Optimierung wichtig sind, wissen wir ja schon seit WCAG 1. Jetzt komm es darauf an, dass wir uns das technisch und inhaltlich genauer ansehen. Dazu gehört, dass man zum einen die Spezifikation des WCAG 2 genau durcharbeitet mit all ihren unterschiedlichen technischen Dokumenten und zum anderen dass wir uns endlich auch inhaltlich genauer damit beschäftigen. Was bedeutet es wirklich, dass jemand mit schwachem und reduziertem Sehvermögen Kontrastprobleme hat und warum hat das ein Rot-Grün-Blinder nicht so. Beherzigen wir beide Wege – eine technische und inhaltliche Tiefe -, dann kommen wir auch aus der argumentativen Beta in Fragen der Barrierefreiheit raus und das über einige Fachkreise hinaus. Denn jeder Entwickler, der sich für Barrierefreiheit interessiert, kann mit dem WCAG 2 technisch versierte und genau auf den Nutzer zugeschnittene Webseiten realisieren. Gehen wir es endlich genauer an!

Und: setzen wir nicht immer alles in den barrierefreien Konjunktiv nach dem Motto wir sollten, könnten, müßten – auch das macht der Artikel. Gerade in der barrierefreien Argumentation und in Fachartikeln muss es um den Indikativ gehen.

8 Antworten auf “Barrierefreiheit: immer noch in der argumentativen Beta”

  1. Hi Sylvia,

    schön, dass Du wieder Zeit und Lust gefunden hast, einen Deiner wirklich guten und lehrreichen Artikel zu verfassen. Dein Blog wird so langsam eine der wichtigsten Anlaufstellen in Deutschland für Barrierefreiheit.

    Dankeschön für Deine Mühe und die Arbeit!

    Gruß, Andreas

  2. Hallo Sylvia,
    erstmal Danke für deine Kritik. Ich finde es wichtig, dass du auf diesen Artikel eingehst.
    Aber er soll und kann lediglich die Oberfläche der Thematik beleuchten und zum Nachdenken anregen. Dem Leser ist es freigestellt mehr in die Tiefe zu gehen. Und natürlich, für jeden Bereich im Webdesign gibt es Spezialisten, die mehr im Thema stecken.

    Trotzdem möchte ich zu ein paar Punkten kurz Stellung nehmen:
    1.) Farbfehlsichtigkeit dient hier lediglich als Beispiel. Habe ich leider nicht genügend betont.
    2.) Eine Farbe definiert sich immer über Farbton (hue), Sättigung, Hellwert (value). Also ist Kontrast sehr wohl abhängig von den gewählten Farben. Der Screenshot von snook.ca zeigt das deutlich.
    3.) „…Was ist ein gemusterter Hintergrund und warum sollte man das auch machen, wichtigen, lesbaren Text auf diesen zu setzen?…“ Ich kenne mehr als genug Beispiele, in denen eben dieses gemacht wird.
    4.) Diesen Satz:
    „…oder der Hinweis, dass die Farbpalette in vollem Umfang zur Verfügung steht, eben gerade nicht, weil sich viele Kombinationen aufgrund von Kontrastproblemen ausschliessen..““
    bitte vollständig zitieren:
    „Die Farbpalette steht also nach wie vor in vollem Umfang zur Verfügung, es muss aber immer darauf geachtet werden, welche Farbkombinationen man verwendet.“

    Viele Grüße,
    Henry

  3. Hallo,
    Was javascript anbelangt ist nicht alles so blitz blank wie es vorgegeben wird. Es wäre ja alles so toll gäbe es nicht die fast täglichen Sicherheitslöcher in den diversen Engines. Die ach so tollen Extensions von diesem oder jenem Framework, die unter anderem mit barrierefreiheit promoted werden, weiss der teufel ob diese in 2 Jahren noch überhaupt weiterentwickelt werden und spätestens beim nächsten Browserupgrade nicht mehr funktionieren. Bugs bugs bugs. Mir grausst wenn ich an javascript denke und die Zeit die ich damit verplempere.

    Ich denke dass die enorme Komplexitätssteigerung in den letzten Jahren (und kein ende in sicht) uns dahin führt den Boden unter den Füssen zu verlieren. Wir rennen den Innovationen hinterher in der Erwartung dass alles besser wird. Aber ist das tatsächlich so?

  4. @Henry

    grundsätzlich gehen wir da sicherlich konform, dass man nicht alles in die Tiefe argumentieren kann. Aber – und da möchte ich Dir schon widersprechen, auch ein Artikel, der nur die Oberfläche darstellen soll, wie Du anmerkst, sollte eindeutig und genau genug sein, dass der Leser alle wichtigen Infos auch richtig einordnet.

    Das war mir bei Deinem Artikel einfach zu wenig genau, ich weiss durchaus, wie Du alles gemeint hast, aber ich habe halt einen anderen Hintergrund schon. Für Einsteiger und Leser, die sich da und dort schon etwas besser auskennen, war das einfach zu wenig genau.

    Das wollte ich mit meiner Kritik sagen. Dein Artikel läßt zuviele Ecken und Kanten offen. 🙂 Dadurch können Missverständnisse auftreten.

    Zu Deinen Detailanmerkungen:
    Ich habe nur den Bezug auf Kontrast in Deinem Artikel rausgelesen, nicht den Farbaspekt. Vielleicht auch ein Hinweis, dass das Thema noch nicht ganz rund war. Was die gemusterten Hintergründe angeht, müsste man erst mal definieren, was Du darunter verstehst. 🙂 Ich habe in meinem ganzen Entwicklerleben noch keinen Text auf gemustertem Hintergrund umsetzen müssen und da bin ich auch froh drum. Ich hab das einfach nicht verstanden, was Du damit meinst.

    Die letzte Anmerkung war mehr eine sprachliche, die Farbpalette steht eben nicht in vollem Umfang zur Verfügung, weil eben nur eingeschränkt. Das war mehr der Hinweis darauf, dass es sprachlich für mich das nicht so zusammenpasst. 🙂

  5. @Andreas

    Nun ja, sowas ist immer relativ und ich strebe das auch nicht an. Freilich wäre mir lieber, es würden mehr aktuelle Themen aufgenommen und auch mehr diskutiert. Ich versuche das anzustossen, soweit es meine Ressourcen auch zulassen.

  6. @Armand

    hm, etwas schwierig auf so einen Rundumschlag zu antworten. 🙂 Es stimmt sicherlich, dass wir einen weitaus höheren Komplexitätsgrad mittlerweile gerade in der Entwicklungsarbeit haben, weil die Entwicklung einfach komplexer und schneller voranschreitet. Oder es kommt uns auch nur so vor, wer weiss.

    Aber, wichtige Entwicklungen wie Js-Frameworks als Standards darf man nicht so einfach damit abtun, weil es in 5 Jahren vielleicht schon wieder anderes gibt. Was ich nicht wirklich glaube. Die Spannen werden sicherlich um einiges länger sein.

    Wichtig ist auch, dass Js-Frameworks wie jQuery oder Dojo tatsächlich sehr viel Wert auf Fallbacks und Barrierefreiheit legen. Insofern hat sich da wirklich viel getan und das kann man einfach mal anerkennen, anwenden und abwarten, wie sich alles entwickeln wird.

  7. @Sylvia Egger

    Hallo nochmal,

    Welcher Entwickler weiss schon ob diese oder jene JS-Bibliothek die er vor 2 Jahren in einem Projekt verwendet hat wegen Bugs oder Sicherheitslücken dringend ersetzt werden muss. Dazu braucht es Wartung von Projekten und dementsprechend Zeit. Je mehr Bibliotheken verwendet werden desto grösser ist dieser Wartungsaufwand. Sicherheit ist mitlerweile zu so einem komplexen Thema geworden, dass nur noch einige wenige Experten mitreden können. Als normaler Entwickler kann man nur hoffen, dass alles gut geht.

    Man kann sich bei jedem Projekt fragen; was der tatsächliche Vorteil von Javascript ist, u.a. auf Bezug von Barrierefreiheit, wenn man alle Fakten gegeneinander abwägt. (Wartung, Ajax, Sicherheit,…).

    Das klinkt jetzt vielleicht ein wenig konservativ, aber ich schlaf besser wenn ich es fertiggebracht habe Projekte mit purem html, und so weit es eben möglich war barrierefrei erstellt zu haben. (Dieses als Abschlusssatz von einem der an Barrierefreiheit intersssiert ist, sich aber nicht als Experte in dieser Disziplin betrachtet.)

  8. @Armand

    Sicherlich hast Du recht, dass man sich immer wieder Gedanken machen muss, was mit Javascript gelöst werden soll. Diese Frage sollte sowieso immer am Anfang stehen.

    Auch sollte man immer bei einem Framework bleiben und nicht mehrere einbinden, schon aus Gründen der Übersichtlichkeit, Wartbarkeit und der Größe – mehrere Frameworks würden ja alles extrem aufblähen. Bei der Entscheidung für ein barrierefreies Framework hat man dann halt nicht immer die große Auswahl, auch unterscheiden sich Frameworks dann auch schlicht in der jeweiligen Anwendbarkeit. Aber für 80% der Fälle ist jQuery da eine gute und hinreichende Wahl.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert