Javascript: Farbkontrast überprüfen auf einer Webseite

[marlem]

Hallo,

das was ich programmieren möchte mit Javascript kann dieses Programm:

Colour Contrast Analyser (CCA) - Vispero

Colour Contrast Analyser (CCA) Use TPGi’s free color contrast checker to optimize your content – including text and visual elements – for individuals with color-blindness or low vision impairments. Current version 3.5.5 Windows Mac Home Colour Contrast Analyser (CCA) One Color Contrast Tool for...

developer.paciellogroup.com

Angenommen in meinem Body-Tag sind folgende Farbwerte gesetzt:

body {     
      background-color:  #FBEFF2;
      color: #000;
      }

Frage:
Gibt es in Javascript die Möglichkeit aus diesen beiden Werten
zu berechnen wie gut der Farbkontrast ist?

 

[mrBrown]

The Science of Color Contrast — An Expert Designer’s Guide

Understanding the complexity of color contrast for better design and accessibility

medium.muz.li

Für das korrekte Berechnen des Kontrastes wirst du aber kaum drum rum kommen, die Seite vollständig zu rendern.

 

[marlem]

Danke! Super Link!

 

[mihe7]

Danke! Super Link!

Unabhängig von theoretischen Grundlagen ist der entscheidende Punkt:

Für das korrekte Berechnen des Kontrastes wirst du aber kaum drum rum kommen, die Seite vollständig zu rendern.

Du musst Dich von dem Gedanken lösen, dass man anhand von HTML und CSS ableiten könnte, wie die Seite sich im Browser darstellt. Schon für statische Seiten wäre das mit einem riesigen Aufwand verbunden, bei dynamischen ist es praktisch ein Ding der Unmöglichkeit:

<div id="app"></div>

<script>
var colors = [ "red", "green", "blue", "yellow", "cyan", "magenta", "black" ];
var app = document.getElementById("app");
var counter = 0;
app.style="width:100px;height:100px;";
window.setInterval(function() {
    app.style.backgroundColor = colors[counter];
    counter = (counter + 1) % colors.length;
}, 500);
</script>

 

[marlem]

Du musst Dich von dem Gedanken lösen, dass man anhand von HTML und CSS ableiten könnte

Bei der Analyse einer Webseite auf Barrierefreiheit geht es nicht darum wie eine Webseite dargestellt wird,
sondern wie wurde sie programmiert!

Wenn ich einen Auftrag bekomme eine Webseite auf Barrierefreiheit zu analysieren,
schaue mir HTML- und CSS-Code an, weil viele Sachen können nur so überprüft werden.

 

[mrBrown]

Bei der Analyse einer Webseite auf Barrierefreiheit geht es nicht darum wie eine Webseite dargestellt wird,
sondern wie wurde sie programmiert!

Wenn ich einen Auftrag bekomme eine Webseite auf Barrierefreiheit zu analysieren,
schaue mir HTML- und CSS-Code an, weil viele Sachen können nur so überprüft werden.

Also, egal ob sie Barrierefrei nutzbar ist, Hauptsache sie ist gut programmiert?
Oder anders: es ist egal ob ein eingeschränkter Nutzer sie nutzen kann, solange der Entwickler den Code schön findet?

Das klingt nach genau dem falschen Ansatz. (Außer natürlich um Kunden zufrieden zustellen, die bestätigt bekommen wollen, dass sie total Barrierefrei sind)

 

[marlem]

solange der Entwickler den Code schön findet?

Nein, mit schön hat es nichts zu tun.
Nochmal ein deutlicher Hinweis:
Es können viele Kriterien nicht automatisiert getestet werden.

Aber ich mache Beispiele:
1.1.1b Alternativtexte für Grafiken und Objekte
Ich überprüfe im HTML-Code ob Bilder einen Alternativtext haben

1.1.1c Leere alt-Attribute für Layoutgrafiken
Ich überprüfe im HTML-Code ob es Layoutgrafiken gibt

1.1.1d Alternativen für CAPTCHAs
Ich schaue mir die Webseite an ob es CAPTCHAs gibt

1.2.2a Aufgezeichnete Videos mit Untertiteln
Ich schaue mir 30 sekunden ein Video an um herauszufinden ob es Untertitel hat
oder ob Untertitel eingeschaltet werden können.

1.3.1a HTML-Strukturelemente für Überschriften
Ich schaue mir den HTML-Code an und überprüfe ob H-Tags richtig verwendet werden.
Die Überprüfung kann auch mit einem Browser-Plugin gemacht werden.

1.3.1e Datentabellen richtig aufgebaut
Ich schaue den HTML-Code an und überprüfe ob es Datentabellen gibt und ob
diese richtig aufgebaut sind.

1.4.4a Text auf 200% vergrößerbar
Hier benutze den Zoom des Browsers.
HIER spielt auch die Darstellung eine Rolle.
Ich überprüfe ob der komplette Inhalt der Webseite,
nach dem sie gezoomt wurde, noch Lesbar ist oder ob sich
Inhalte überlappen oder komplett verschwunden sind.

2.1.1a Ohne Maus nutzbar
Ich überprüfe ob alle Bedienelemente per Tabulatortaste erreichbar sind.

2.4.7a Aktuelle Position des Fokus deutlich
Ich Überprüfe ob es ersichtlich ist, auf welcher Seite ich mich innerhalb
des Webauftritts befinde.

3.1.1a Hauptsprache angegeben
Ich überprüfe im HTML-Code ob die Hauptsprache der Webseite angegeben wurde

4.1.1a Korrekte Syntax
Prüfschritt erfüllt: Das Prüfergebnis des W3C-HTML-Validators ist positiv.

 

[mrBrown]

Diese beiden Dinge widersprechen sich z.T.:

Es können viele Kriterien nicht automatisiert getestet werden.

Bei der Analyse einer Webseite auf Barrierefreiheit geht es nicht darum wie eine Webseite dargestellt wird,
sondern wie wurde sie programmiert!

Wie sie programmiert ist, kannst du automatisiert mit X Regeln erschlagen (es wird halt unglaublich viel Aufwand), das was nicht automatisiert testbar ist, ist die Darstellung.
Also entweder, viele Kriterien sind automatisiert testbar, oder es geht nicht darum, wie sie programmiert wurde.


@mihe7's Beispiel zeigt das ja auch ganz schön: Wenn du nur HTML und CSS auswertest, ist das Beispiel super lesbar. Mit JavaScript dazu flackert der Hintergrund und es wird unleserlich.
Wenn es nur darum geht, wie die Programmiert ist, ist das super. Aber Lesen kann es trotzdem niemand.




Un zu dem was @mihe7 und ich vorher meinten:

Um Dinge automatisiert testen zu können (zb den Kontrast), musst du das gesamte CSS und HTML auswerten und in einen "renderbaren Zustand" bringen. Du musst für jedes Element Position, Größe, z-Index, Farbe etc berechnet haben, was dann der Darstellung entspricht (zur wirklichen Darstellung fehlt dann nur noch das triviale Zeichnen einfacher geometrischer Formen).

Natürlich ist das machbar (angenommen, es gibt kein JS), aber das ist ein extrem großer Aufwand.

 

[marlem]

Also entweder, viele Kriterien sind automatisiert testbar, oder es geht nicht darum, wie sie programmiert wurde.

Gut, ich gebe Dir recht. Viele Sachen wären einfach mit einem extrem hohen Programmieraufwand verbunden.

 

[mrBrown]

Gut, ich gebe Dir recht. Viele Sachen wären einfach mit einem extrem hohen Programmieraufwand verbunden.

Und "viele Sachen" enthält zB schon die Berechnung des Kontrasts.

 

[marlem]

okay, ich habe es verstanden

 

[mihe7]

Huch, wasn hier los? @mrBrown hat die Probleme sehr schön auf den Punkt gebracht.

Mein zugegebenermaßen evtl. zu einfaches Beispiel sollte verdeutlichen, dass Dynamik die zeitliche Komponente ins Spiel bringt. Heute gibt es kaum noch Seiten, deren DOM statisch ist, vielmehr hängt das Ergebnis vom Zeitpunkt der Betrachtung ab.

Das bedeutet nicht, dass Deine Kriterien hinfällig würden. Eine statische Analyse kann aber nur ein Indiz liefern.

 

[marlem]

Das bedeutet nicht, dass Deine Kriterien hinfällig würden.

Die sind definitiv nicht hinfällig, weil die stehen auf w3.org:
https://www.w3.org/TR/WCAG21/

 

[marlem]

Schaut Euch mal bitte diesen Link an:

leserlich.info – Kontrastrechner

Mit diesem Kontrastrechner können für Vierfarbdruck oder Monitoranwendungen individuelle Farbwerte für Zeichen- und Hintergrundfarben auf ihre ausreichende Kontrastfähigkeit überprüft werden.

www.leserlich.info

Taugt der Kontrastrechner was?

 

[mrBrown]

Vermutlich taugt der genauso viel wie alle 79194638581537 anderen.
So viel kann man da ja nicht bei falsch machen, hab’s aber jetzt auch nicht für zig Werte getestet...