WCAG 2.0 / RGAA 2.2: Zoom texte à 200%?

Coucou,

Florent V. a écrit :
WCAG 2.0 n'aurait pas eu les yeux plus gros que le ventre là-dessus? Et quelqu'un connait-il des sites au design pas absolument simpliste (donc pas comme sur ma capture d'écran...) qui peuvent espérer passer ce critère?
Des retours d'expérience à ce sujet?

Pour moi, sans lunettes (donc avec une myopie de 4,75), le texte grossi est tout juste lisible (il faut quand même que je rapproche un peu la tête de mon écran pour déchiffrer. Je pense que ce 200% n'est pas mal, mais j'aurais tendance à penser que ce n'est pas (toujours) suffisant.

Par contre, c'est effectivement un critère difficile à passer, l'utilisation de la césure conditionnelle peut, peut-être, aider (jamais tenté cependant).

Victor BRITO a écrit :
Il me semble (à vérifier et confirmer) que les 200 % doivent se référer à la taille de police par défaut

Je ne pense pas.
Modifié par Laurie-Anne (04 Mar 2010 - 13:52)

Florent V. a écrit :
WCAG 2.0 n'aurait pas eu les yeux plus gros que le ventre là-dessus? Et quelqu'un connait-il des sites au design pas absolument simpliste (donc pas comme sur ma capture d'écran...) qui peuvent espérer passer ce critère?
Des retours d'expérience à ce sujet?

En effet j'en ai fait l'expérience, un site avec une charte graphique un peu sophistiquée voit son design automatiquement explosé avec un agrandissement.
Sur mon site (petite pub ), l'agrandissement des textes à 200% fait sortir les titres des bandeaux, mais le WCAG ne préconise que la lisibilité, donc à partir d'un certain agrandissement, exit le design, l'essentiel c'est qu'il n'y ait pas de texte perdu ou de contraste insuffisant.

Ceci dit il faut considérer l'agrandissement du texte comme une situation "pas normale", et le designer ne décore son site qu'en prévoyant la situation "normale", avec la taille de police réglée à 16px (ou environ). Inutile donc de prévoir des conteneurs énormes pour des textes rikikis, c'est ridicule. Si le texte qui sort disgracieusement de son conteneur après un agrandissement reste lisible, alors tout va bien !

Et inutile de regarder du côté des sites d'inspiration, niveau accessibilité, les "designers freelance" ne sont pas experts en accessibilité (le mot est encore doux) et parfois même pas en ergonomie (ni en compatibilité cross browser), bref.

Et le WCAG a du bien trouver un compromis pour sortir le chiffre 200% car s'il semble avoir les yeux plus gros que le ventre, les yeux des personnes malvoyantes sont encore plus mal fichues et ce 200% sonne un peu juste.
Donc 200% semble vraisemblablement satisfaire (un peu) les exigences des malvoyants, tout en ne demandant pas l'impossible aux développeurs.

Et pour finir en beauté, faites aussi le test sur Alsa si vous z'êtes curieux, vous ne serez pas très surpris du résultat...
Modifié par darkstar2023 (05 Mar 2010 - 00:22)

darkstar2023 a écrit :

Et le WCAG a du bien trouver un compromis pour sortir le chiffre 200% car s'il semble avoir les yeux plus gros que le ventre, les yeux des personnes malvoyantes sont encore plus mal fichues et ce 200% sonne un peu juste.
Donc 200% semble vraisemblablement satisfaire (un peu) les exigences des malvoyants, tout en ne demandant pas l'impossible aux développeurs.

200% est le compromis retenu car :
* il est réputé s'accommoder d'un large éventail de designs courants.
* il compense la limite des anciennes loupes d'écran encore utilisées dont le zoom ne commence qu'à 200%
* au-delà de 200%, il laisse la place aux zooms graphiques alors plus pertinents.

Florent a écrit :
Je connais très peu de designs qui peuvent résister à ça

J'ai écris ci-dessus que le test pouvait être difficile à passer. Mais regardons un peu les raisons de cette difficulté.

La réalisation d'un site conforme à WCAG doit intégrer l'accessibilité dès la phase de conception graphique. Il est fréquent que nous demandions le retoquage léger de maquettes que nous avons à auditer, en prévision des difficultés que rencontrera l'intégrateur. Il est rare qu'un projet graphique soit à revoir entièrement.

Se fixer des objectifs d'accessibilité entraîne d'inévitables contraintes de conception graphique. Mais il serait inutile de retomber pour autant dans les vieilles arguties sur la liberté de conception, l'accessibilité qui bride la créativité et l'innovation, les designs accessibles pauvres et moches etc. Avoir des contraintes liées à un objectif est tout aussi normal avec l'accessibilité qu'avec l'ergonomie (d'ailleurs, combien de designs dits beaux et innovants, en particulier dans les portfolios exposés sur Alsa, sont-ils parfois des erreurs ergonomiques criantes ?) Et surtout: ces contraintes ne sont pas bloquantes, mais... juste contraignantes

D'autre part, lorsque je lis:

darkstar2023 a écrit :
Ceci dit il faut considérer l'agrandissement du texte comme une situation "pas normale", et le designer ne décore son site qu'en prévoyant la situation "normale", avec la taille de police réglée à 16px (ou environ).

Ah... Les "vrais" designers Web, qui ont véritablement conscience de ne pas travailler pour du print ou du multimédia, sont en effet encore très rares. Ne pas leur jeter la pierre, cependant : ils n'ont pas été formés en ce sens, et les ressources sur la conception de designs fluides sont à peu près inexistantes (je parle bien de maquettes graphiques, et non de l'intégration HTML CSS fluide). En outre, en un sens, Photoshop est le pire ennemi du designer Web. Mais qui doit rattraper le coup dans la pratique ? L'intégrateur.

Or, surtout, il y a ensuite les bonnes ou mauvaises habitudes des intégrateurs... J'ai sous les yeux un site public dont les templates avaient été corrigés en particulier pour respecter ce critère. Mais l'intégrateur final n'a pas pu s'empêcher de rajouter un malheureux height:19px inutile dans un menu d'onglets... sans doute pour se rassurer et sans prendre la peine de vérifier le résultat à l'agrandissement.

Une expérience intéressante: visitez les derniers sites labellisés Accessiweb. agrandissez à 200% et regardez de près quelles mauvaises pratiques d'intégration provoquent l'échec à ce test. Vous retrouverez quelques grands classiques :
* utilisation inconsidérée du positionnement absolu,
* utilisation inconsidérée de height
* utilisation inconsidérée de width dans des onglets
* background de taille fixe, non élastiques, ou sans couleur d'arrière-plan complémentaire

Les échecs dus à ces pratiques sont de loin beaucoup plus fréquents que ceux liés aux choix de design ou aux contenus proprement dit (longueur des mots). Autrement-dit, ils pouvaient être évités.

(Attention: ces sites sont labellisés selon le référentiel Accessiweb1.1 (WCAG1.0) dans lequel le critère d'agrandissement n'était pas celui des 200%. Il est donc tout à fait normal qu'ils ne "passent" pas le test : ne vous précipitez pas sur le canal de plainte )

Certes, 150% aurait été un objectif plus proche des pratiques actuelles des intégrateurs les plus soucieux d'accessibilité (d'ailleurs, cette page du forum Alsa se comporte relativement bien à 150% d'agrandissement, même si elle échoue au-delà). 200% est un niveau d'exigence supplémentaire, mais qui n'a rien de castrateur en matière de design, et qui n'a rien de bloquant en matière d'intégration CSS.

Pour reprendre l'exemple de cette page du forum Alsa: en corrigeant quelques-unes des mauvaises pratiques ci-dessus dans le header et le footer, et en corrigeant l'abominable lien Twitter vide-et-rempli-en-css (pour lequel l'intégrateur est voué aux enfers éternels), le test est validé...

Sinon, pour ceux qui en auraient l'usage dans des sites cousus-mains où ils se heurtent au problème des mots devenus trop longs et qui débordent mal : en dernier recours, & shy;­ (soft hyphen) est ton ami. Si même Wikipédia parvient à s'en servir, pourquoi pas vous ?
Modifié par Laurent Denis (05 Mar 2010 - 08:24)

Merci Laurent pour ces réponses détaillées.

À titre personnel le principal point qui m'embête est que l'utilisation raisonnée du positionnement absolu (pour des éléments ayant peu de contenu, avec une marge suffisante pour permettre un agrandissement du texte jusqu'à 150% environ...) ne passe pas. Ça revient à limiter le positionnement absolu à deux cas de figure très restreints:
- positionner un élément décoratif de dimensions fixes;
- positionner un bloc de contenu dans le cas où on n'a aucun autre conteneur placé plus bas.
Mais bon, pourquoi pas.

Pour information, dans ma boite nous ne travaillons pas avec le secteur public et nos clients sont soit indifférents à l'accessibilité, soit sensibles mais pas au point de viser la conformité à un référentiel, un travail d'audit ou de labellisation. De plus je suis le seul intégrateur formé à l'accessibilité, et mon poste actuel implique très peu de production. Du coup je vais continuer à communiqué en interne sur le fait de tester avec un zoom texte léger (120-150%), qui permet surtout de repérer les défauts majeurs d'intégration (hauteurs fixes, dépassement des flottants non prévus, line-height excessif qui rend un titre inesthétique et difficilement lisible dès qu'il passe sur deux lignes, etc.).

À propos du SOFT HYPHEN

J'étais resté sur l'idée que le support de ­ était problématique dans certains navigateurs, notamment Safari et Firefox (tandis qu'il était bon dans Internet Explorer et Opera). Je viens de tester et ça a été corrigé dans ces deux navigateurs, peut-être depuis plusieurs versions. Support ok dans Chrome également. Donc c'est largement utilisable.

J'avais aussi lu chez Jukka Korpela que la définition de ce caractère différait en ISO-8859-1, HTML4 et Unicode. Mais les définitions de HTML4 et d'Unicode sont réconciliables et semblent être celles prises en compte par les navigateurs, donc tout va bien de ce côté.

Le dernier point problématique avec ­ est sa prise en compte par les moteurs de recherche, pour qui "Super­cali­fragili­sticex­piali­docious" n'est pas un seul mot mais une suite de six mots.

Mais les mots trop longs, pour un site en français ou en anglais, sont un point de détail comparés aux erreurs courantes que tu relèves, Laurent.

Et y a-t-il des statistiques quant aux personnes malvoyantes ou qui agrandissent leur police en naviguant sur le net ?

Ceci dit, en supposant que l'écrasante majorité des internautes naviguent avec la police réglée à 16px ou environ, je calque mon design sur ce paramètre.
Si l'on devait adapter son oeuvre à toute épreuve, on passerait 20 fois plus de temps que pour adapter son site aux mauvais navigateurs (je ne citerai pas de nom).

Donc je me contente de rendre mon site juste "lisible" avec des caractères rendus géants.
Et de toute façon dans telle sutuation, je doute que les malvoyants voient l'esthétique comme une priorité absolue. L'essentiel est qu'ils puissent accéder à l'information voulue.
Modifié par darkstar2023 (05 Mar 2010 - 19:14)

QuentinC a écrit :
Le trait d'union virtuel ne fonctionne pas avec IE8 + Jaws 11 + Windows XP SP3

Si j'écris :
Té­lé­char­ge­ment

Le résultat est qu'à la lecture du mot, chaque syllabe est exagérément détachée, comme s'il s'agissait de 5 mots séparés par un espace normal.

Si on utilise l'entité à la place du symbole directement, alors elle n'est pas interprétée et lue en clair (on obtient donc "et comercial shi")

Hum... Je ne rencontre pas ce problème, y compris avec des versions plus anciennes de Jaws (testé jusqu'à la 8). Sur quelle URL as-tu fait le test ?
Modifié par Laurent Denis (05 Mar 2010 - 12:25)

Laurent Denis a écrit :

Hum... Je ne rencontre pas ce problème, y compris avec des versions plus anciennes de Jaws (testé jusqu'à la 8). Sur quelle URL as-tu fait le test ?

Une page de test rapide en local, pas valide "W3C.... mais ça ne peut quand même pas venir de ça ?
Si tu as une URL à proposer, je teste volontiers.