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

Bonjour,

Mes questions concernent encore une fois de plus l'agrandissement des caractères.
Après avoir effectué plusieurs recherches, j'ai vu une réponse de Victor BRITO

"Victor BRITO, tiré du WCAG" a écrit :
Redimensionnement du texte : à l'exception des sous-titres et du texte sous forme d'image, le texte peut être redimensionné jusqu'à 200 pour cent sans l'aide d'une technologie d'assistance et sans perte de contenu ou de fonctionnalité. (Niveau AA)
Afin que le redimensionnement du texte soit aisé, la taille de police doit être fixée au moyen d'une unité relative

Mais (c'est là mes questions)... il arrive à un moment ou un autre qu'un tel agrandissement ruine l'esthétique voire la lisibilité.

Qu'entend-t-on par "perte de contenu ou de fonctionnalité" ? Je compte mettre du texte sur un bandeau image placé en background : mon texte débordera du bandeau s'il est trop agrandi ! Ceci est-il une perte de fonctionnalité ?
Ou dans l'hypothèse où une petite partie du texte sera masqué lors de l'agrandissement de 200%, du moment que la signification n'est pas affectée ?

http://img41.imageshack.us/img41/2369/sanstitreql.png

Et concernant les textes de (très) grande taille, sommes-nous vraiment obligés de permettre leur agrandissement par des unités de taille relatives ?
Certains textes peuvent être assez grands pour être vus par tout le monde.
Modifié par darkstar2023 (04 Mar 2010 - 12:32)

Bonjour,

A partir du moment où tout ou partie du texte n'est plus lisible (overflow:hidden; manque de contraste...) il y a un problème d'accessibilité.

L'utilisation des unité relatives n'a une importance que pour IE 6 et 7 ; les autres navigateurs étant capable d'agrandir les polices dont la taille est donnée en unité fixe.

Oui, il est nécessaire que tout puisse être agrandi : 1. pour que la différence entre les titres et le contenu puisse encore se faire ; 2. parce que ce n'est pas parce que tu considère que c'est assez grand que cela va l'être pour le visiteur mal voyant (perso, 200%, si j'enlève mes lunettes, c'est rarement suffisant pour que je puisse lire confortablement).

darkstar2023 a écrit :
il arrive à un moment ou un autre qu'un tel agrandissement ruine l'esthétique

ce n'est pas un problème en soit et pas du tout un problème d'accessibilité ni une exigence à aucun point de vue. cela dit, dans les limites imposées par les chartes graphiques, il possible de rester graphiquement correct à de forts taux d'agrandissements de la taille de caractères. cela demande que le graphiste ait certaines notions sur l'élasticité inhérente au Web, c'est à dire qu'il connaisse très bien son métier. Et c'est encore plus le cas pour l'intégrateur, qui n'a aujourd'hui pas la partie facile avce les moyens limités offerts par CSS2.1 (un constat: 40% du travail de reprise et de correction d'intégrations en vue d'accessibilité que je suis amené à faire concerne exclusivement ce problème de rendu en taille de caractère agrandie).

darkstar2023 a écrit :
voire la lisibilité.

Dans ce cas, c'est simple: ce n'est pas accessible et c'est à refaire.

darkstar2023 a écrit :
Qu'entend-t-on par "perte de contenu ou de fonctionnalité" ?

Que je dois pouvoir consulter et utiliser visuellement les pages avec une taille de caractères agrandie à 200% (agrandissement typograhique, pas graphique). Si un texte, une image ou un objet est en tout ou partie rogné, s'il se chevauche avec un autre, s'il déborde sur un autre arrière-plan qui le rend invalide quand aux contrastes; si je ne peux plus, du coup, naviguer au clavier... c'est perdu.

Par contre, si deux blocs de contenus originellement à côté l'un de l'autre se retrouvent l'un après l'autre, ce n'est évidemment pas invalidant.

darkstar2023 a écrit :

* : mon texte débordera du bandeau s'il est trop agrandi ! Ceci est-il une perte de fonctionnalité ?

si le texte reste entièrement perceptible et qu'il continue à respecter les critères liés au contraste avec ses arrière-plan, il n'y aura pas de perte de contenu. S'il comporte un lien et que celui-ci continue à respecter les règles liées aux liens (règle spécifique de contraste du texte d'un lien par rapport à son contexte, règle de l'accessibilité clavier, règle du focus visuel, etc.), il n'y aura pas de perte de fonctionnalité.

Il serait vain de tenter d'énumérer ici tous les cas possibles : il faut prendre un par un les critères d'accessibilité des méthodes d'application de WCAG (RGAA, AW), les appliquer et voir le résultat. Ce n'est pas particulièrement compliqué, même si cela demande d'être formé.

Les méthodes d'application en accessibilité n'ont pas été faites pour rien .

darkstar2023 a écrit :
Ou dans l'hypothèse où une petite partie du texte sera masqué lors de l'agrandissement de 200%, du moment où la signification n'est pas affectée ?

Les exemple qui suivent seront invalidés lors d'une évaluation d'accessibilité.

darkstar2023 a écrit :

Et concernant les textes de (très) grande taille, sommes-nous vraiment obligés de permettre leur agrandissement par des unités de taille relatives ?

Excellente question, mais oui, nous y sommes obligés pour au moins deux raisons :
*On ne sait pas où commence la notion de grande taille de texte
*A l'usage, le mécanisme de base le plus efficace, qui demande le moins à l'intégrateur et qui laisse l'utilisateur assumer son handicap avec son aide technique est celui qui exige que toute taille de caractère soit extensible

L'un des problèmes de fond que vous rencontrez apparemment est bien connu: faire accessible nécessite de lâcher prise sur le rendu, ou de prendre conscience que le rendu Web est de toute façon non maîtrisable.

<edit>Ce sont des questions très intéressantes et très bien posées</edit>
Modifié par Laurent Denis (21 Feb 2010 - 17:05)

Laurie-Anne a écrit :
L'utilisation des unité relatives n'a une importance que pour IE 6 et 7 ; les autres navigateurs étant capable d'agrandir les polices dont la taille est donnée en unité fixe.

Evitons de tout mélanger, s'il vous plaît, et en particulier "pixel" dans E6-7" et "accessibilité" :
* la notion d'unité fixe n'existe pas. Il y en a des relatives et des absolues.
* les unités absolues (point, pouce, centimètre, millimètre) sont invalidantes dans une CSS screen du point de vue WCAG et ses méthodes d'application (RGAA, AW, etc.)
* Quels que soient ses aléas dans IE, le pixel n'est pas une unité absolue. Il n'est pas invalidant pour WCAG, à l'exception très spécifique des éléments de formulaire (voir RGAA, le critère sur le sujet et la technique WCAG correspondante). Hormis ce cas, il n'est pas invalidant pour le RGAA ni pour Accessiweb.

En d'autres termes: l'utilisation d'unités relatives est essentielle quelque-soit le navigateur, mais encore faut-il savoir ce que recouvre ce terme.

Tiens, je vais ajouter à ma signature, après javascript et Flash: "le pixel non plus"
Modifié par Laurent Denis (21 Feb 2010 - 17:25)

Laurent Denis a écrit :
Tiens, je vais ajouter à ma signature, après javascript et Flash: "le pixel non plus"

Intéressant. Est-ce que tu recommanderais l'utilisation de px pour le dimensionnement du texte, en lieu et place des calculs savants à base d'em qui conduisent à spécifier des font-size: 0,8456432em? Ou bien tu garderais l'utilisation de em/% comme solution idéale, qui permet notamment d'afficher la page directement au niveau de grossissement souhaité si l'utilisateur a configuré la taille par défaut du texte dans les préférences du navigateur? Ou rien de tout ça?

Laurie-Anne a écrit :

L'utilisation des unité relatives n'a une importance que pour IE 6 et 7 ; les autres navigateurs étant capable d'agrandir les polices dont la taille est donnée en unité fixe.

Le pixel est une unité relative car sa taille varie en fonction de la taille de l'écran pour une résolution donnée

Laurent Denis a écrit :

Il n'est pas invalidant pour WCAG, à l'exception très spécifique des éléments de formulaire (voir RGAA, le critère sur le sujet et la technique WCAG correspondante). Hormis ce cas, il n'est pas invalidant pour le RGAA ni pour Accessiweb.

Il n'est pas invalidant pour qu'elle raison? Est-ce uniquement parce qu'on peut avoir recours dans la config d'IE (via les options d'accessibilités) à un déverrouillage de la taille du texte défini par l'auteur? Mais qui connait cette option? D'autre part il me semble qu'à
ce moment là, le pourcentage d'agrandissement est excessif.
Concernant le zoom texte, j'imagine qu'il est encore en vigueur sur les navigateurs pour éviter d'élargir exagérément l'interface utilisable et éviter le scrolling horinzontal sur les petits écrans?
Modifié par Hermann (21 Feb 2010 - 17:56)

Je vais tenter de répondre brièvement aux réponses très détaillées (merci) de Laurent Denis.

Effectivement, je suis pas webmaster de formation, donc la liste exhaustive des critères untel, des recommandations & Cie, ... me sont inconnues.
Et du fait de l'infinité des cas possibles, les réponses apportées à un certain nombre de cas semblables aident souvent bien mieux que la théorie (valable dans la plupart des domaines), et c'est d'ailleurs ainsi qu'existent les forums

Passons au vif du sujet : sur mon site j'ai un bandeau jaune avec un texte dessus dont le contraste satisfait le niveau AAA (si je me trombe sur les termes, n'hésitez pas me le signaler ^^). Si j'agrandis le texte à 200%, une partie du texte déborde sur l'arrière plan noir et le contraste du texte par rapport au noir satisfait encore le niveau AAA.
Est-ce accessiblement correct ? Sachant qu'entre la couleur jaune du bandeau et le noir du fond peut "choquer"...
Modifié par darkstar2023 (21 Feb 2010 - 18:27)

Sous réserve d'erreurs d'évaluation, c'est apparemment on ne peut plus satisfaisant.

WCAG2.0 apporte un outil outil simple de validation de ces questions de contrastes (il est très criticable par ailleurs, mais c'est une toute autre question) : l'outil te dit que tu es conforme, que vas-tu chercher de plus ?

S'il n'existe pas de critère WCAG parlant de combinaisons de couleurs accidentelles qui pourraient "choquer", ce n'est pas pour rien : l'accessibilité, quand on traite ses critères comme on doit le faire, n'a rien d'ésotérique. Elle est même plutôt binaire et simple. Quand elle te dit "ok", elle te dit simplement "ok".
Modifié par Laurent Denis (21 Feb 2010 - 18:48)

Florent V. a écrit :

Intéressant. Est-ce que tu recommanderais l'utilisation de px pour le dimensionnement du texte, en lieu et place des calculs savants à base d'em qui conduisent à spécifier des font-size: 0,8456432em? Ou bien tu garderais l'utilisation de em/% comme solution idéale, qui permet notamment d'afficher la page directement au niveau de grossissement souhaité si l'utilisateur a configuré la taille par défaut du texte dans les préférences du navigateur? Ou rien de tout ça?

Rien. C'est une série de questions stupides, désolé : je peux donner un avis sur les résultats au cas par cas dans des exemples précis, mais cet avis portera sur l'usage local de tel ou tel choix, pas sur le choix lui-même. Il n'y a rien à recommander :le pixel en tant que taille de caractère est une unité conforme et un choix compatible avec WCAG, on ne peut parler que de l'usage qui en est fait.

Je sais, Opquast 2.0 dit: La taille des polices destinées à l'affichage écran est exprimée en taille variable et non en taille fixe. en visant précisément le pixel. On ne l'a pas encore buttée, celle-là, mais il n'est pas du tout sûr qu'elle passe le filtre final du référentiel opquast. Il y a même assez peu de chances, à vrai dire.
Modifié par Laurent Denis (21 Feb 2010 - 19:26)

Hermann a écrit :
Mais qui connait cette option?

L'idée générale de WCAG2.0, est que l'utilisateur a la dernière version du navigateur, la dernière version de l'aide technique et qu'il sait se servir du tout.

Bon, évidemment, ça laisse un peu des gens sur le carreau. Le genre de chose à balayer furtivement sous le tapis, rien de grave.

Plus sérieusement, ça se défend, il y a d'excellents arguments pour, et un prestaire spécialisé dans ce domaine, s'il es honnête, ne peut que les partager. Sachant que rien n'empêche de faire des recommandations différentes à un moment donné dans un cas donné.
Modifié par Laurent Denis (21 Feb 2010 - 19:41)

Bon.

Je vais essayer de formuler une question pas stupide, si darkstar2023 veut bien me pardonner de pirater son sujet.

Je constate qu'à l'époque ou IE6 était le navigateur ultra-majoritaire, on a déconseillé l'usage de l'unité px pour dimensionner le texte dans les CSS. La logique était qu'IE6 avait fait le choix de bloquer par défaut l'agrandissement du texte dimensionné en pixels, ce qui empêchait les utilisateurs non avertis (presque tous) d'avoir recours à la fonctionnalité d'agrandissement du texte sur de nombreux sites, pour leur confort ou pour un accès sans aide technique spécifique.

Le RGAA dit d'ailleurs (version 2.2.1, dans l'explication du critère de succès 1.4.4: «Evitez également d'utiliser des px (pixels) pour dimensionner les caractères car ils ne pourraient pas être agrandis ou diminués dans Internet Explorer sans l'accès aux options avancées.»

Avec la popularité grandissante des zooms graphiques, et la disparition programmée d'IE6, on pourrait considérer que ce conseil, éviter les px pour ne pas bloquer le zoom du texte, est obsolète. D'où une première question:

Ce conseil (non testé formellement) dans l'explication du critère 1.4.4 du RGAA est-il une survivance du passé? Quelle était la motivation des auteurs du RGAA pour inclure cette recommandation à la portée apparemment générale?

Ma deuxième question concerne les fluctuations de la taille du texte par défaut. C'est un sujet complexe avec des casses-tête à venir (écrans en 200 dpi ou plus...), mais je vais m'arrêter au cas de figure où un utilisateur a réglé la taille du texte par défaut sur une autre valeur que 16px (quasi-standard de fait). Spécifier les tailles de texte en pixels fait que ce réglage est ignoré. C'est donc une perte de confort (pas d'accessibilité) pour l'utilisateur, qui doit zoomer à chaque nouveau site qu'il croise ou presque.

La question est donc: est-ce que l'utilisation des em/% pour le texte te semble être une bonne pratique d'ergonomie web, recommandable de manière générale en tant que telle?
(Et là je reprendrais bien ton «Sachant que rien n'empêche de faire des recommandations différentes à un moment donné dans un cas donné.» en disclaimer pour éviter un scud.)
Modifié par Florent V. (21 Feb 2010 - 19:51)

Laurent Denis a écrit :
On ne l'a pas encore buttée, celle-là

Même explication pour le paragraphe cité du critère 1.4.4 du RGAA2?
Modifié par Florent V. (21 Feb 2010 - 19:53)

Pour moi le seul avantage que comporte le pixel est d'éviter des légers problèmes d'arrondi
lors du calcul de corp de police qui peut exister dans des navigateurs comme Opera avec des unités em ou % même si certains pourcentages précis (77%, 82%) qu'avait relevées Aurélien permettent d'écarter ce problème.

Laurent Denis a écrit :

L'idée générale de WCAG2.0, est que l'utilisateur a la dernière version du navigateur, la dernière version de l'aide technique et qu'il sait se servir du tout.

Étonnant venant d'une recommandation sur l'accessibilité mais les contributeurs ont sans doute de bonnes raisons. Les WCAG tiennent d'avantage compte des UAAG et donc de ce les navigateurs sont censés respecter que des usages?

Hermann a écrit :

Étonnant venant d'une recommandation sur l'accessibilité mais les contributeurs ont sans doute de bonnes raisons. Les WCAG tiennent d'avantage compte des UAAG et donc de ce les navigateurs sont censés respecter que des usages?

Non, les WCAG sont simplement issues de l'industrie, ou si tu préfère de l'état de l'art, qui cherche des solutions. Celle-ci est à peu près la seule qui soit viable.

Laurent Denis a écrit :


Autant pour moi (pour rebondir sur une discussion menée ailleurs, ce point du glossaire me semblait également avoir été corrigé suite aux discussions initiales)

Je vérifierais mais il me semble bien que c'est une décision du groupe d'expert référent.

JP

C'est justement en relisant celle-ci que je suis un peu surpris.