[accessibilité] taille de polices relatives

(reprise du message précédent)

P75 a écrit :

Edit En fait je viens de comprendre le systeme des em avec des div imbriqué

Ah bon ben… tant mieux alors!

Laurent Denis a écrit :

La différence avec ton exemple, c'est que les caisses ne dépendent pas de leur propre norme d'accessibilité. Dans le cas des contenus Web, je voudrais, dans la famille "nowhere", 1) une UAAG actualisée et 2) des UA respectueux d'UAAG... ce qui signifie dans ce cas concret zoom graphique et ERA ALA Opera chez tout le monde. Plop.

Pour l'instant, on reporte l'insuffisance de deux des pieds du tripode ATAG WCAG UAAG uniquement sur les producteurs du contenu. C'est en tous cas de cette manière que je délimiterais précisément le problème du pragmatisme, pour ma part. Sans préjudice d'un ou deux autres appendices mutationnels (ARIA).

Me gourge ?

Non, tu te gourges pas et tu a parfaitement raison.

"Tant que les agents utilisateurs..."

C'est mon coté boy scout sans doute, mais j'assume.

Cela dit, pour UUAG c'est assez largement au delà des compétences des producteurs de contenus (je veux dire de peser sur le bazard) et, de mon point de vue la voie API me semble pour le coup d'un pragmatisme de bon aloi.

En revanche je suis très impatient qu'on se prenne ATAG pour en faire quelque chose d'opérationnel
Et tiens, soyons fous, que ça rentre dans les processus habituels d'accompagnement.
On le fait tous un peut, plus ou moins, plus ou moins bien...

"si tous les gars du monde..."

Laurent Denis a écrit :

Hum... Très en vogue, oui (c'est curieux, d'ailleurs). Mais au delà de la limite, je ne sais pas : quand je jongle avec Zoomtext ou des outils de loupe ou de projection équivalents, la différence ne me semble pas vraiment sensible. Me gourgerais-je encore ?

Non, tu à raison, dans le même temps c'est une bonne raison pour tenter de repousser au mieux le moment où le recours à des dispositifs de ce genre devient nécessaire.

Jean-Pierre

Benjamin D.C. a écrit :

Ah bon ben… tant mieux alors!

Merci pour ton explication précédente
Modifié par P75 (13 Dec 2007 - 00:39)

Comment tester les changements de polices par défaut des navigateurs IE6 et IE7 ?

car sous firefox Outil/Options je teste avec "taille" de "Polices et couleurs"

(Petit aparté pour les accesskeys: contrairement à ce que dit Laurent Denis, il ne faut pas les éliminer d'office: mes usability testings pratiqués en entreprise sur des aveugles ont montré qu'ils sont nombreux à les demander et à s'en servir, malgré leur manque de systématique. Il est nécessaire de se poser la question et, franchement, la réponse dépendra du type de ton audience,des buts de ton site, de tes propres conceptions, etc. D'un point de vue ergonomique, on ne peut pas les condamner ainsi

Pardon pour ce hors-sujet.)

smitty a écrit :
(Petit aparté pour les accesskeys: contrairement à ce que dit Laurent Denis, il ne faut pas les éliminer d'office: mes usability testings pratiqués en entreprise sur des aveugles ont montré qu'ils sont nombreux à les demander et à s'en servir, malgré leur manque de systématique. Il est nécessaire de se poser la question et, franchement, la réponse dépendra du type de ton audience,des buts de ton site, de tes propres conceptions, etc. D'un point de vue ergonomique, on ne peut pas les condamner ainsi

Pardon pour ce hors-sujet.)

Le problème, si j'ai bien compris, c'est que les acceskey diffèrent d'un OS à l'autre et il n'y a pas vraiment moyen de les standardiser. Même les touches chiffrées posent problème.

Patidou a écrit :
Le problème, si j'ai bien compris, c'est que les acceskey diffèrent d'un OS à l'autre et il n'y a pas vraiment moyen de les standardiser.

Non: il y a deux problématiques (en fait trois...):
- absence de standardisation de la touche principale de l'accesskey (valeur de l'attribut HTML du même nom) d'un site à l'autre;
- absence de standardisation de la touche à utiliser en conjonction avec cette touche principale (Ctrl ou Alt ou autre...) d'un système à l'autre, d'un navigateur à l'autre, etc.;
- carambolage avec des raccourcis clavier du navigateur, du système, etc.

Florent V. a écrit :

- carambolage avec des raccourcis clavier du navigateur, du système, etc.

Le problème le plus dramatique étant encore la collusion entre les raccourcis pour les lecteurs d'écran (surtout JAWS) et les acceskeys.

smitty a écrit :

D'un point de vue ergonomique, on ne peut pas les condamner ainsi

En laissant de côté les douloureux problèmes d'accessibilité, le point de vue ergonomique sur un machin :
- dont l'utilisation est inexplicable au visiteur sans un cours approfondi d'identification de son OS, de son navigateur et de son clavier
- qui requiert de toutes manières la consultation d'une page d'aide explicitant les racourcis utilisés sur le site
- qui n'est pas mappable avec des choix utilisateurs configurables dans le navigateur
- et qui me fait mal aux doigts d'une manière générale...

m'échappe totalement, je l'avoue, en effet
Modifié par Laurent Denis (18 Dec 2007 - 18:43)

bonjour,

Jean-Pierre, quand tu dis :

jpv a écrit :

C'est la raison pour laquelle Accessiweb notamment interdis purement et simplement l'utilisation du pixels pour les tailles de caractères.

Moi, je lis sur la fiche Accessiweb corespondante :

a écrit :
Pour les polices de caractère :
1. Vérifier l'emploi d’attributs de dimensionnement des caractères tels que size ou weight, par exemple ainsi que les unités de valeurs relatives en pourcentage ou "px" adoptées.
2. Ou vérifier les unités de valeurs utilisées dans la feuille de styles, pour les éléments de type font-size, par exemple. Celles-ci peuvent être en pourcentage, en "em" ou en pixel "px", par exemple.

Et, je ne vois pas non plus dans AW1.1 de trace de cela...

sur le sujet, c'était dans les tuyaux depuis pas mal de temps mais c'est finalement en ligne

http://openweb.eu.org/articles/compatibilite_taille_polices/

Bonjour,

Un très bon article pour résumer la situation et donner une direction claire. Cependant, je suis un peu chagriné de ne pas voir mentionné mon article Typographie web : gérer la taille du texte avec les « em », qui me semble être une bonne référence en français sur le sujet, et que je trouve plus intéressante que l'article de Richard Rutter (tu pointes sa traduction par Laurent). En plus je n'aime pas cette approche du body {font-size:62.5%} qui cherche à utiliser la béquille conceptuelle de la référence aux pixels, mais là c'est un jugement très personnel et bien peu objectif.

Il y a aussi cet article de Robert Nyman traduit par Pompage.

Ensuite, je trouve qu'il y a un manque important dans cet article: la question des familles de polices, et des problèmes que peuvent engendrer le passage d'une fonte à l'autre, à corps de texte égal. Ainsi, la famille font-family: "Lucida Grande", Helvetica, Arial, sans-serif; est un mauvais choix, tandis que font-family: "Lucida Grande", Verdana, sans-serif; et font-family: Helvetica, Arial, sans-serif; sont deux choix pertinents.
Pour plus de détails, cf. mon article indiqué ci-dessus.

À propos des tests sur les arrondis, j'en avais fait quelques uns:
http://web.covertprestige.info/test/24-arrondi-taille-du-texte.html

concernant ton article plus un oubli qu'autre chose. Pour l'histoire des arrondis mon but était justement de trouver les valeurs avec le moins de variation possible, c'est pour cela que j'ai testé différente famille de police.

goetsu a écrit :
c'est pour cela que j'ai testé différente famille de police.

Ce que j'avais bêtement omis de faire, d'ailleurs.