Agrandissement des caractères : énième sujet...

Laurent Denis a écrit :
C'est justement en relisant celle-ci que je suis un peu surpris.

Oui tu as raison

Décision de BrailleNet alors, cela dit ça ne me chiffonne pas plus que ça.
On à pas de technique pour le pixel et franchement je ne vois pas trop quels problèmes seraient insurmontables qui nécessiterait l'usage du pixel.
Au contraire, par expérience, l'utilisation du pixel est souvent signe d'un manque de maitrise de CSS et l'utilisation de em et % permet d'acquérir de très bon réfexes en conception de design.

JP

Disons notamment que la compatibilité WCAG en est un peu écornée, ainsi que la cohérence avec le RGAA, ce qui toujours dommage et confusant pour les gens.
Modifié par Laurent Denis (24 Feb 2010 - 14:21)

Laurent Denis a écrit :
Disons notamment que la compatibilité WCAG en est un peu écornée, ainsi que la cohérence avec le RGAA, ce qui toujours dommage et confusant pour les gens.

Oui... mais sur qu'elle technique t'appuie tu pour passer le SC avec des polices en pixel ?

Sachant que WCAG dans la technique G142 met pt et px dans le même bateau en citant la fonctionnalité de changement d'unité de Firefox 2 par exemple

D'ailleurs je n'ai pas trouvé de références non plus à la notion de taille de police relative dans WCAG

JP

jpv a écrit :


Oui... mais sur qu'elle technique t'appuie tu pour passer le SC avec des polices en pixel ?

Sachant que WCAG dans la technique G142 met pt et px dans le même bateau en citant la fonctionnalité de changement d'unité de Firefox 2 par exemple

Bah, en fait, je m'appuie sur le mauvais usage que nous avons fait, les uns et les autres, de ce document des techniques dans l'élaboration des méthodes d'application :
* Il n'a pas de valeur normative.
* Il est évolutif sans être versionné (la mise à jour annoncée se fait d'ailleurs attendre, à mon goût)
* C'est un outil de proposition de nouvelles techniques, pas un outil qui délimite les techniques autorisées
* il n'interdit rien sauf mention explicite dans une Failure.

Mais nous en avons fait ce que WCAG2.0 ne proposait justement pas : une sorte de liste de pseudo-critères de succès pour les techniques dont nous avions à nous occuper. Bref, le référentiel qui nous manquait à traduire.

Je sais, c'était pratique et il y avait d'excellentes raisons de partir de ce document pour définir des méthodes d'application. Mais cela a un peu dérivé, disons

Et donc, je t'avoue que je bloque sur le raisonnement selon lequel si les techniques ne l'autorisent pas explicitement c'est interdit : je ne vais pas aller chercher dans ce document l'autorisation d'une technique, car ce serait une erreur méthodologique de fond. Surtout pour déclasser une fonctionnalité de base de CSS sur la base d'un bug de navigateur, ce que l'on ne fait pas dans aucun cas à ma connaissance.

<del>J'ai un petit peu la flemme ce soir, mais je tâcherai de résumer la question pour le GTA, si cette question peut être revue à l'occasion des correction du glossaire prévues.</del>J'ai finalement remué ma flemme.

jpv a écrit :

D'ailleurs je n'ai pas trouvé de références non plus à la notion de taille de police relative dans WCAG

JP

Parce que ce n'est pas un problème d'accessibilité, vu le comportement des navigateurs : c'est un problème (mineur) qui n'est pas particulier à l'accessibilité et que celle-ci n'aborde donc plus, tout le monde étant potentiellement pénalisé sans distinction. C'est encore une fois l'histoire du lien sur la goyave

Tiens, pour chipoter (quoi pas tant que cela), l'absence de la question des unités relatives va dans le sens de l'autorisation du pixel:
* le problème unité relative/absolue tient au fait que les unités absolues ne sont pas exploitables par un navigateur graphique pour un rendu screen
* ces navigateurs les traduisent (de manière arbitraire) en pixel, pour pouvoir les gérer sur ce media
* si le problème n'est plus évoqué, c'est que la transcription en pixel n'est pas un souci d'accessibilité...
Modifié par Laurent Denis (24 Feb 2010 - 20:53)

Laurent Denis a écrit :


Bah, en fait, je m'appuie sur le mauvais usage que nous avons fait, les uns et les autres, de ce document des techniques dans l'élaboration des méthodes d'application :
* Il n'a pas de valeur normative.
* Il est évolutif sans être versionné (la mise à jour annoncée se fait d'ailleurs attendre, à mon goût)
* C'est un outil de proposition de nouvelles techniques, pas un outil qui délimite les techniques autorisées
* il n'interdit rien sauf mention explicite dans une Failure.

Je ne suis pas certain que ce soit un mauvais usage, de mon point de vue c'est d'ailleurs la seule position raisonnable.

Sinon comment assurer un minimum d'harmonisation entre les diverses, et nécessaires, méthodes d'application ce qui était un des nombreux problèmes de WCAG 1 ?.

En se fondant sur les techniques nous disposons au moins d'un terrain précis, commun et sans discussion philosophique.

Certes pour le meilleur et pour le pire...

Mais je reconnais que de fait nous donnons via les méthodes d'applications une valeur normatives aux techniques.

<mode private joke>C'est assez à la mode de modifier un document sans le versionner non ?</mode private joke>

Laurent Denis a écrit :


Je sais, c'était pratique et il y avait d'excellentes raisons de partir de ce document pour définir des méthodes d'application. Mais cela a un peu dérivé, disons

Et donc, je t'avoue que je bloque sur le raisonnement selon lequel si les techniques ne l'autorisent pas explicitement c'est interdit : je ne vais aller chercher dans ce document l'autorisation d'une technique, car ce serait une erreur méthodologique de fond. Surtout pour déclasser une fonctionnalité de base de CSS sur la base d'un bug de navigateur, ce que l'on ne fait pas dans aucun cas à ma connaissance.

Humm, je ne dit pas ça, et je suis d'accord sur ta remarque sur les failures (plus bas).
Ma question était plus simplement de savoir comment tu pouvais penser que l'utilisation du pixel était "conforme à WCAG" puisqu'il n'y à aucune référence (dans un sens ou dans un autre) qui nous indique une conformité.

D'ailleurs, si je suis le raisonnement sur le pixel, je peux absolument utiliser le pt comme unité de taille de police puisque :
1. rien ne me l'interdis
2. le redimensionnement en pt fonctionne.

D'où l'idée à mon sens raisonnable de ne s'appuyer que sur des techniques référencées...

Laurent Denis a écrit :

Parce que ce n'est pas un problème d'accessibilité, vu le comportement des navigateurs : c'est un problème (mineur) qui n'est pas particulier à l'accessibilité et que celle-ci n'aborde donc plus, tout le monde étant potentiellement pénalisé sans distinction. C'est encore une fois l'histoire du lien sur la goyave

Je n'ai pas bien compris ce passage

JP
Modifié par jpv (24 Feb 2010 - 21:15)

jpv a écrit :
1. rien ne me l'interdis
2. le redimensionnement en pt fonctionne très bien.

Du point de vue de la conformité et de la réalisation des tests (augmenter de 200%) je n'ai pas de problèmes.

Juste un détail (que tu connais peut-être déjà mais sait-on jamais) sur le point :
contrairement au pixel, si la taille de la police est exprimée en pt, celle-ci varie en fonction de la résolution paramétrée dans l'OS , 96ppp étant le standard, celle-ci peut être augmentée par exemple à 120ppp, ce qui provoque un agrandissement des textes potentiellement problématique pour leur accessibilité. C'est un cas de figure sans doute très rare mais je suis déjà tombé dessus une fois (avec un morceau de texte masqué d'ailleurs)
Modifié par Hermann (24 Feb 2010 - 21:45)

Hermann a écrit :
la résolution paramétrée dans l'OS , 96ppp étant le standard

Sur mon portable sous Ubuntu, je n'ai pas de résolution standard mais bien une résolution réelle communiquée par le système d'exploitation aux logiciels. (Ou plutôt, l'information réelle et un paramétrage «standard» coexistent, si j'ai bien compris.) Du coup, quand une page web demande à afficher du texte en 20pt, Firefox sous Ubuntu affiche bien 20pt (en zoom 1:1), et pas une valeur conventionnelle calculée à partir d'un "standard" à 96ppp.
De mémoire la résolution réelle de mon écran sur ce poste est aux alentours de 113ppp.
Pour Firefox, voir: http://kb.mozillazine.org/Layout.css.dpi

Du coup ça plantait la taille du texte dans les présentations Google Docs, et j'ai dû fixer "layout.css.dpi" à 96.

Hermann a écrit :
celle-ci peut être augmentée par exemple à 120ppp, ce qui provoque un agrandissement des textes potentiellement problématique pour leur accessibilité

Si je te comprends bien, ça ne provoque pas un problème d'accessibilité, mais ça en révèle un comme le ferait un zoom texte.

Florent V. a écrit :

Si je te comprends bien, ça ne provoque pas un problème d'accessibilité, mais ça en révèle un comme le ferait un zoom texte.

Oui Florent.

Bonjour à tous,

Merci Hermann pour cette précision que je ne connaissais pas, ma position sur ce sujet étant, comme vous avez pu le constater assez radicale (em, %, name... point barre)

Cela dit je ne peut que reconnaitre la justesse des arguments de Laurent et des propixeliens ou plutôt des anti antipixeliens.

Le truc c'est que WCAG nous à fait sur ce sujet, comme sur tous les sujets qui dépendent de l'état de l'art et des technologies, un critère suffisamment mal foutu pour que chacun puisse aller à la pêche.

Sur la liste GTA Laurent remarque très justement que l'utilisation d'unités absolues, fixes, relatives ou hydroplanantes n'est pas identifiée comme un problème d'accessibilité, ce qui est parfaitement juste.

La seule chose qui est demandé est de s'assurer de la capacité au redimensionnement des textes sans perte d'information, rien de plus, et à aucun moment WCAG ne dis quoi que ce soit sur les unités.

Deux solutions techniques sont proposées : soit de s'assurer que la technologie utilisée est compatible avec les fonctionnalités de zoom des UA, soit d'utiliser les unités (em,% ou name).

Raison pour laquelle la position de AW2.0, comme celle de RGAA sont identiquement valables et conformes à WCAG.

Il s'agit juste d'un positionnement, AW2.0 décidant de continuer à sanctionner IE, au regard du nombre important de ses utilisateurs et RGAA décidant de maintenir l'ambiguité de WCAG.

D'où ma réflexion sur le pt car je ne vois rien dans RGAA, au niveau du test, qui me permette de sanctionner l'usage d'une unité quelconque, mais j'aurais pu prendre également le mm...

Ce que je n'arrives pas à comprendre c'est qu'à partir du moment où on décide de sanctionner une grande partie des utilisateurs il doit y avoir une raison impérative ou un vrai bénéfice...

Mais j'ai beau chercher, je ne vois pas cette contrainte impérative ou ce fabuleux bénéfice qui permettrais de justifier qu'on sanctionne 50% des utilisateurs.

D'où une position d'AW que je défends sereinement.

JP
Modifié par jpv (01 Mar 2010 - 09:19)

Bonjour JPV,
de toute façon les éventuels défauts d'accessibilité provoqués par ces histoires d'unités sont vraiment mineures comparativement à d'autres critères bien plus handicapants et présents dans
les situations d'utilisation normales (niveau de contraste...).
Question: (je ne peux pas tester mon IE8 ne fonctionne pas bien...) Est ce que le zoom texte d'IE8 est encore verrouillé lors de l'utilisation des pixels?

Hermann a écrit :
Question: (je ne peux pas tester mon IE8 ne fonctionne pas bien...) Est ce que le zoom texte d'IE8 est encore verrouillé lors de l'utilisation des pixels?

Même motif, même punition qu'IE 6 et 7.

Hermann a écrit :
de toute façon les éventuels défauts d'accessibilité provoqués par ces histoires d'unités sont vraiment mineures comparativement à d'autres critères bien plus handicapants et présents dans les situations d'utilisation normales (niveau de contraste...).

Et pourtant, ça m'arrive de devroir quitter un site (ou copier/coller son contenu dans word quand c'est vraiment intéressant) parce que les textes sont trop petits et que je ne peux pas les agrandir sous IE6. Et pourtant j'ai pas une si mauvaise vue que ça (tant que je porte mes lunettes).

Bien sûr le problème est aggravé si, en plus le contraste est trop faible/fort.

Victor BRITO a écrit :

Même motif, même punition qu'IE 6 et 7.

Ok merci Victor.

Juste pour ajouter une chose (toute petite), l'agrandissement des caractères est à mon avis indispensable à prévoir car même sur les navigateurs récents, les personnes présentant une insuffisance quelconque peuvent changer la taille de police par défaut dans les options.

Et avec Webdeveloper pour Firefox, faites CTRL + MAJ + Z pour agrandir (mais pour réinitialiser il faut recharger la page car CTRL + MAJ + X présente apparemment un conflit avec la configuration native de Firefox.