analyser le contraste

Nina Popravka a écrit :

On Sat, 13 Oct 2007 00:13:24 +0200, SAM
<stephanemoriaux.NoAdmin@wanadoo.fr.invalid> wrote:

C'est un contraste couleur à couleur ?
et alors pour qui ? (type de +/- daltonien)
http://www.etre.com/tools/colourblindsimulator/

'tain... pour mon papa daltonien, tu m'intéresses plus que
furieusement...

Ah ben je vais te faire plaisir. Plutôt que de tester une image, teste
directement un site :
http://www.fujitsu.com/global/accessibility/assistance/cd/

C'est sous Win et ça doit fonctionner sous Wine.

Olivier a écrit :

Olivier Masson a écrit, le 12/10/2007 09:02 :

Olivier a écrit :

je n'ai pas tout compris la question mais ce logiciel semble y
répondre (en) :
<http://www.fujitsu.com/global/accessibility/assistance/wi/>

Chez moi, ça a marché. En tout cas, cela m'a fait modifier quelques
contrastes.

J'avions mal regardé ... mais l'est censé être aussi pour Mac !!!

L'outil ne semble pas connu alors qu'il est une aide correcte

M'en va l'essayer tt de suite

--
sm

Nina Popravka a écrit :

On Sat, 13 Oct 2007 00:13:24 +0200, SAM
<stephanemoriaux.NoAdmin@wanadoo.fr.invalid> wrote:

C'est un contraste couleur à couleur ?
et alors pour qui ? (type de +/- daltonien)
http://www.etre.com/tools/colourblindsimulator/

'tain... pour mon papa daltonien, tu m'intéresses plus que
furieusement...

y en a plein wikipedia

Olivier Masson a écrit :

Tiens, le nouvel ASM

vi ;-)

Mais ... finalement ... ce "contraste" c'est quoi ?

Le contraste défini par les WCAG (trop tard pour que j'aille chercher le
lien)

tout à l'heure, alors ?

C'est un contraste couleur à couleur ?
et alors pour qui ? (type de +/- daltonien)

Pour les daltoniens, il y a des simulateurs, comme celui que tu donnes.
Le contraste, c'est pour une bonne lisibilité.

à ce que je crois, le contraste serait +/- défini à partir d'une
transposition des couleurs en nuances de gris (et ce sans soucis des
daltoniens).

Et premièrement : tu ne sais plus quelle couleur tu as défini pour le
background ni pour le foreground ?

Ben dis donc, personne pige ce que je veux alors que j'ai donnée un
exemple.

Ben alors ?
Où est le problème ?

Le fond sera vert, ok ?
Le fond de #cont sera également vert, ok ?
Mais les logiciels qui testent le contraste dans une CSS (et autres
logiciels plus globaux de validation), sont incapables de comprendre que
mon div aura un fond vert si je ne l'ai pas explicitement indiqué dans
la CSS.

et donc ?

c'est grave ?

Sinon il existe une extension pour Firefox : Colorzilla
qui permet de connaitre la couleur de n'importe quel pixel cliqué à
l'écran :

Je connais mais je l'aime pas. Je préfère Colormania (entre autres)

Ben ... pas moi : Windows only :-(

Car chercher le style du background-color d'un truc qui n'est défini
que par héritage de styles, ça ne doit pas être facile à faire.

Ah ? Je pensais que oui.

Heu ... en plus des attributs 'style' dans les balises, on a les class
et même les divs et tout ça s'imbrique en interférant ...
C'est dèjà assez compliqué quand on crée sa feuille de style, alors
remonter depuis un emplacement à travers les méandres ... (et sans
parler des couleurs de survol) qui peuvent être accentués par des FdS
séparées et contradictoires ... je vois mal comment faire.

Le dom inspector de Fx ?

Là je suis sur un site avec Fx et web developper extension,
je clique qque part
web developer en barre latérale me montre les styles (les css) qui
s'appliquent pour cet élément
il trouve de 3 à 4 fichiers de css et pour certaines régles lignes 1000
et plus ... chapeau !
Mais il oublie les styles inclus dans les balises ... :-(

Que de ressources :)

Je trouve ça passionnant !
bien que je ne retienne pas tout :-(

J'en ai déjà lu pas mal.
Pour le traitement des couleurs (ça n'a rien à voir avec mon problème),
Mac a toujours été en en avance donc normal de voir Safari.

Ben ... les couleurs font quand même parti du pb (contraste)

Et sans aucun rapport :
est-ce que IE (7) y arrive
http://event-horizon.twiddles.com/sites/experimental/css3-bg/
Firefox n'y arrive pas mais Safari : oui

Ca marche sous Safari Windows (swift) et pas sur tout le reste (FF, Op,
IE7).

Ça continue quoi. Ça fonctionne où ça veut, quand ça veut :-(

--
sm

SAM a écrit :

Olivier Masson a écrit :

Tiens, le nouvel ASM

vi ;-)

Mais ... finalement ... ce "contraste" c'est quoi ?

Le contraste défini par les WCAG (trop tard pour que j'aille chercher
le lien)

tout à l'heure, alors ?

Pas trouvé chiffre dans les WCAG 1 mais seulement :
"2.2 Ensure that foreground and background color combinations provide
sufficient contrast when viewed by someone having color deficits or when
viewed on a black and white screen. [Priority 2 for images, Priority 3
for text]." (http://www.w3.org/TR/WCAG10-HTML-TECHS/#color-images)

Pour les atroces WCAG 2, il te faut un contraste 7:1 ou 5:1, que tu peux
obtenir selon la formule qu'ils donnent
(http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/#G17)

Le fond sera vert, ok ?
Le fond de #cont sera également vert, ok ?
Mais les logiciels qui testent le contraste dans une CSS (et autres
logiciels plus globaux de validation), sont incapables de comprendre
que mon div aura un fond vert si je ne l'ai pas explicitement indiqué
dans la CSS.

et donc ?

c'est grave ?

Ce serait sympa de reprendre le début du fil pour comprendre...

Heu ... en plus des attributs 'style' dans les balises, on a les class
et même les divs et tout ça s'imbrique en interférant ...
C'est dèjà assez compliqué quand on crée sa feuille de style, alors
remonter depuis un emplacement à travers les méandres ... (et sans
parler des couleurs de survol) qui peuvent être accentués par des FdS
séparées et contradictoires ... je vois mal comment faire.

Si c'était impossible, un navigateur ne pourrait rien afficher.
Quant aux class, id, etc. il y a une ordre de priorité, donc je ne vois
pas en quoi c'est insurmontable, sauf bien sûr lorsque l'on a du texte
qui sort d'un conteneur par exemple (mais là, on peut déjà se dire que
la lisibilité n'est pas garantie.)

Ben ... les couleurs font quand même parti du pb (contraste)

Oui mais là il ne s'agit en rien de savoir si les couleurs seront
fidèles. Les profils ICC, c'est très bien, mais pour ça puisse être
utile dans le cadre de la créa d'un site, il faudrait que tout le monde
ait un écran calibré avec un profil ICC associé. Ce qui ne sera jamais
le cas, même pour le quart des internautes, Mac ou pas (parce que les
gens sur Mac, en plus d'avoir du Intel et d'acheter MSOffice, ils sont
pas plus malins et passionnés que les PCistes.)

Donc la colorimétrie, c'est très intéressant mais, si je m'y intéresse
par ailleurs, on en est trèèèèèès loin sur le net.
Je me contente de chercher les contrastes sur les textes pour savoir
s'ils seront aisément lisibles pour tous.

Ça continue quoi. Ça fonctionne où ça veut, quand ça veut :-(

Ben c'est du CSS3 d'un autre côté. Les CSS2 ne sont déjà pas intégrés...
Si Safari était leader sur le marché des navigateurs, ce serait déjà
intégré dans Firefox et Opera. Mais comme c'est IE qui dirige tout,
pourquoi s'emmerde à intégrer des fonctionnalités que l'on ne pourra pas
utiliser avant des années, voire des lustres (on a déjà pas certains
sélecteurs) ?

Olivier Masson a écrit :

SAM a écrit :

c'est grave ?

Ce serait sympa de reprendre le début du fil pour comprendre...

J'ai fait (relu post 1) et, bien que j'ai la comprenette lente,
j'avais bien lu, et ... est-ce que c'est grâve ?
(que les outils d'analyse demandent qu'on leur donne le background)
Si oui, pourquoi ?
n'y a t'il pas qu'à cliquer sur le fond ?

Au fait, comment font-ils pour trouver la couleur du texte ?

Heu ... en plus des attributs 'style' dans les balises, on a les class
et même les divs et tout ça s'imbrique en interférant ...
C'est dèjà assez compliqué quand on crée sa feuille de style, alors
remonter depuis un emplacement à travers les méandres ... (et sans
parler des couleurs de survol) qui peuvent être accentués par des FdS
séparées et contradictoires ... je vois mal comment faire.

Si c'était impossible, un navigateur ne pourrait rien afficher.

Je n'ai pas dit "impossible"
Le navigateur n'a qu'à descendre dans l'arbo, au fur et à mesure que le
code html se charge il doit certainement sérier les règles qui
s'attachent à chaque élément (du DOM ?).

à moins qu'on ne puisse interroger la mémoire du soft, je ne vois, pour
un élément donné, que de remonter tout le DOM à partir de là en essayant
d'attraper les attributs style, class, id, puis à les mettre en
corrélation avec les règles éditées dans la FdS, règles parfois bien
tordues ...

Quant aux class, id, etc. il y a une ordre de priorité, donc je ne vois
pas en quoi c'est insurmontable,

div, ul, li { background: yellow; color: blue; }
div { background: orange }
.truc { background: azure }
div.truc { background: #ffc }
.truc li { background: white, color black }
div.truc li { background: #cff }
li.truc { color: red }
div.truc li.truc { color: inherit }

etc ... etc ... etc ...

yè souis perdou là ...
et pourtant yè n'ais què los fundos y colores
par chancce sans les autres règles pour distraire
et sans 2 ou 3 autres FdS contradictoires ou complémentaires
Quelles sont les couleurs texte et fond du li de class truc dans le div
de même class en supposant qu'il n'ait pas en plus un style particulier?

et je vois pas un regexp résoudre la question (écrire tous les fonds et
colors manquants)

Je me contente de chercher les contrastes sur les textes pour savoir
s'ils seront aisément lisibles pour tous.

Je vais regarder les liens que tu donnes et je reviens.
(bien que tu aies dit que tu avais un outil génial piqueur de couleurs)
(et que je comprends: mon pb est résolu)

Ça continue quoi. Ça fonctionne où ça veut, quand ça veut :-(

Ben c'est du CSS3

(snip)
oui, bien sûr, mais néanmoins.

--
sm

SAM a écrit :

Je vais regarder les liens que tu donnes et je reviens.

bon, je me suis bien amusé à réaliser un analyseur en JS :-)

Sinon on a :

soft Win et Mac :
http://www.paciellogroup.com/resources/contrast-analyser.html
bof bof ... il ne pique pas les couleurs au clic sur écran

extension Fx :
http://juicystudio.com/article/colour-contrast-analyser-firefox-extension.php
bluffant sinon epoustoufflant !

en ligne :
http://juicystudio.com/services/luminositycontrastratio.php#specify

(bien que tu aies dit que tu avais un outil génial piqueur de couleurs)
(et que je comprends: mon pb est résolu)

de toutes façons cette histoire de contrastes calculés ... ça ne me
convainc pas quand je vois :
- #666666 #f1f1f1 5.08
(AAA succès pour le grand texte; AA pour le texte régulier)
- Echantillon #ffffff #678c44 3.88
(AA succès pour le grand texte seulement)

pour lesquels c'est avec le 2nd, pourtant le + mauvais, que j'y
déchiffre le mieux

--
sm

SAM a écrit :

n'y a t'il pas qu'à cliquer sur le fond ?

Au fait, comment font-ils pour trouver la couleur du texte ?

Euh... avec color ?
T'as du louper un truc : il y a des analyseurs de contraste qui lisent
tout simplement les feuilles de style.
Ils lisent color et background-color, comme je l'ai dit 30 fois déjà.

Est-ce que c'est grave ? Non, mais, comme je l'ai aussi dit 30 fois, mon
but est de ne pas avoir à entrer background-color à chaque fois que j'ai
color.

div, ul, li { background: yellow; color: blue; }
div { background: orange }
.truc { background: azure }
div.truc { background: #ffc }
.truc li { background: white, color black }
div.truc li { background: #cff }
li.truc { color: red }
div.truc li.truc { color: inherit }

etc ... etc ... etc ...

yè souis perdou là ...
et pourtant yè n'ais què los fundos y colores
par chancce sans les autres règles pour distraire
et sans 2 ou 3 autres FdS contradictoires ou complémentaires
Quelles sont les couleurs texte et fond du li de class truc dans le div
de même class en supposant qu'il n'ait pas en plus un style particulier?

et je vois pas un regexp résoudre la question (écrire tous les fonds et
colors manquants)

Je vois toujours où est-ce si compliqué (théoriquement, car moi je
serais bien incapable de faire un tel soft.)
http://openweb.eu.org/articles/cascade_css/

SAM a écrit :

extension Fx :
http://juicystudio.com/article/colour-contrast-analyser-firefox-extension.php

Ah ben voilà, celui-là fait ce que je souhaite apparemment !

de toutes façons cette histoire de contrastes calculés ... ça ne me
convainc pas quand je vois :
- #666666 #f1f1f1 5.08
(AAA succès pour le grand texte; AA pour le texte régulier)
- Echantillon #ffffff #678c44 3.88
(AA succès pour le grand texte seulement)

pour lesquels c'est avec le 2nd, pourtant le + mauvais, que j'y
déchiffre le mieux

Je suis d'accord. Pas du tout pour ton exemple où le 2nd est très peu
lisible pourmoi, mais montre bien que cela dépend de chacun. Et c'est
bien ce que je reproche aux normes et préconisations de plus en plus
précises mais qui passent à côté de bcp de choses.

En plus, notre sensibilité au rouge, vert et bleu est différente, si en
plus on mélange fond et premier plan, ça donne un paquet de combinaison.
Et la formule des WCAG ne prend pas du tout ça en compte.

Olivier Masson a écrit :

SAM a écrit :

extension Fx :
http://juicystudio.com/article/colour-contrast-analyser-firefox-extension.php

Ah ben voilà, celui-là fait ce que je souhaite apparemment !

Oui, il n'a pas l'air mal :-)
Comme quoi, ts comptes faits, ça doit pas être si compliqué ? ;-)

pour lesquels c'est avec le 2nd, pourtant le + mauvais, que j'y
déchiffre le mieux

Je suis d'accord. Pas du tout pour ton exemple où le 2nd est très peu
lisible pourmoi, mais montre bien que cela dépend de chacun.

Oui, mais peut-être pas seulement, dépend du moniteur et du système (les
Macs OS X affichant les caractères assez différemment (plus gras) des
Windows. Sans-doute les Linux aussi ont leurs méthodes)

En plus, notre sensibilité au rouge, vert et bleu est différente,

toutafé

Pour la sensibilité perso :
http://www.easyrgb.com/calibrate.php

Mais là on ne s'en sort plus question d'accessibilité et bien être du
visiteur .

--
sm