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

Hello,

De mémoire, la V1 du RGAA demandait la possibilité de zoomer le texte en taille «La plus grande» dans IE, ou deux niveaux de zoom (via Ctrl+) dans Firefox. Deux niveaux de zoom texte dans Firefox 3.6, ça fait du 120% (me disent Firebug + ma calculatrice). La taille «la plus grande» dans IE n'est pas énorme, on doit être à 130% voire 140%.

Je constate que le RGAA 2.2, en application de WCAG 2.0, demande en niveau AA la capacité d'agrandir à 200%. Les utilisateurs de Firefox 3.6 (et probablement des versions précédentes) peuvent, pour se rendre compte de l'effet, rajouter six niveaux de zoom (en mode zoom texte). Ci-dessous un aperçu visuel de ce que ça donne. Je connais très peu de designs qui peuvent résister à ça, notamment à cause d'éléments ayant une largeur fixe dans les 150-200px (tout mot un peu long dépasse, donc risque de chevauchements ou de disparition en cas de overflow:hidden).



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?

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.

Salut,

Laurent Denis a écrit :
Le test consiste en effet à accroître la taille du texte à 200% à partir de l'affichage de la page, via le zoom texte du navigateur.

Donc tu confirmes que c'est bien 6 fois CTRL+ + sous Firefox (pour citer ce navigateur) ?
Modifié par Ericf (05 Mar 2010 - 11:14)

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)

Laurent Denis a écrit :
Oui. En ayant coché "Zoom texte seulement", bien-sûr.

Bigre... J'ai 2 projets en cours qui doivent être présentés bientôt (pour une labellisation Argent), c'est chaud...
Merci pour ta réponse

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. C'est très désagréable, ça donne l'impression que la synthèse se met à bégayer, et surtout ça peut empêcher la compréhension dans certains cas. Si on lit le texte caractère par caractère, on voit bien les tirets virtuels, jaws n'annonce rien en passant dessus, mais on peut mettre le curseur dessus, et on peut déterminer qu'il s'agit bien du caractère #173 avec le raccourci Insert+pavé numérique 5 trois fois rapidement.

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")

Par contre, aucun souci avec firefox 3.6, le mot est lu correctement et les tirets virtuels sont purement et simplement inexistants à l'affichage.

Rajout :

Dark Star a écrit :

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

125 ou 150% sans doute, mais 200% honnêtement je ne crois pas qu'il y ait beaucoup de monde. Pour avoir été fortement myope avant de perdre totalement ce qui me restait de vue, quand on en est à ce stade, on utilise un logiciel loupe qui agrandit l'écran dans sa globalité, on ne s'emm**** plus avec les paramètres d'affichage de chaque programme. Et puis aujourd'hui, les logiciels agrandisseurs sont suffisament bien conçus pour faire un zoom à moins de 200% si tel est le désir de l'utilisateur. Cette époque où 200% était le minimum date de Windows 98 quand même. On met gentiment dehors IE6, donc à mon avis W98 est déjà enterré depuis longtemps.
Modifié par QuentinC (05 Mar 2010 - 12:29)

QuentinC a écrit :
Si tu as une URL à proposer, je teste volontiers.

Chez Richard Rutter: Page en anglais avec explications et test (H2 «The tests»)
Le mot coupé par des ­ ou ­ est celui-ci: anti­dis­est­ab­lish­ment­arian­ism.

On peut aussi évoquer la question de l'arbitrage entre ergonomie et accessibilité. Si un agrandissement de 200% rend l'utilisabilité/interactivité du site plus problématique que sa consultation proprement dite, peut-être vaut-il mieux faire un peu machine arrière et se satisfaire d'un 150% bien assumé plutôt qu'un 200 plus dévastateur ? Je pense par exemple à des intitulés longs de boutons de formulaire placés en colonne avec un padding important et qui ne supportent pas ces taux d'agrandissement sans rendre l'accès aux contenus qu'ils recouvrent très difficile. Et si on "floate" deux colonnes, une à droite et une à gauche, la page centrale fluide se réduit à un bandeau vertical trop étroit pour être lisible.

(désolé pour le message tronqué pendant quelques minutes, c'est parti tout seul)
Modifié par Arsene (05 Mar 2010 - 20:46)