Zoom 200 % et accessibilité : agrandissement du texte (1.4.4) et redistribution à 320 px (1.4.10)

Zoom 200 % : ce qu'exige le critère 1.4.4

Le critère 1.4.4 s'adresse d'abord aux personnes ayant une déficience visuelle légère, qui peuvent lire un texte simplement agrandi sans recourir à un logiciel de grossissement d'écran. Il couvre le texte rendu visuellement, y compris les contrôles et les étiquettes composés de texte.

Le W3C précise que la mise à l'échelle relève principalement de l'agent utilisateur, c'est-à-dire du navigateur : zoom de la page entière, grossissement, agrandissement du texte seul ou taille de texte configurée par l'utilisateur. La responsabilité de l'auteur est de produire un contenu qui n'empêche pas le navigateur de faire ce travail correctement. Le contenu satisfait le critère s'il peut être agrandi jusqu'à 200 % avec au moins un mécanisme d'agrandissement pris en charge par les agents utilisateurs.

Deux précisions comptent en pratique. D'abord, 200 % signifie jusqu'à deux fois la largeur et la hauteur. Ensuite, si le mécanisme propose des paliers entre 100 % et 200 %, il ne doit y avoir aucune perte de contenu ni de fonctionnalité à ces paliers intermédiaires : tester seulement à 200 % ne suffit donc pas.

• Exclus du critère : les sous-titres et les images de texte (ces dernières relèvent aussi du critère 1.4.5).
• Non couverts : les contenus et éléments d'interface contrôlés par le navigateur ou la plateforme, comme l'infobulle de l'attribut title ou les boîtes de dialogue de fichiers du système.
• Si les navigateurs d'une technologie n'offrent pas de mécanisme comme le zoom pleine page, c'est à l'auteur de le fournir ou de garantir que le contenu fonctionne avec ce qui existe.

Redistribution à 320 px : ce qu'exige le critère 1.4.10

Le critère 1.4.10 demande que le contenu puisse être présenté sans perte d'information ni de fonctionnalité, et sans défilement dans deux dimensions, pour un contenu à défilement vertical à une largeur équivalente à 320 pixels CSS, et pour un contenu à défilement horizontal à une hauteur équivalente à 256 pixels CSS. Pour les langues écrites horizontalement (de gauche à droite ou de droite à gauche), le texte doit se replier dans la largeur de la fenêtre ; pour les langues écrites verticalement, dans sa hauteur.

Le problème visé est concret : quand des lignes dépassent le bord de la fenêtre, la personne qui a agrandi le contenu doit faire défiler la page d'avant en arrière pour lire chaque ligne. Elle perd sa place et doit fournir davantage d'effort. Le W3C note que la redistribution aide aussi les utilisateurs d'appareils mobiles et les personnes qui zooment sur de grands écrans.

Pourquoi 320 px ? Selon la note du critère, 320 pixels CSS équivalent à une fenêtre de départ de 1 280 pixels CSS de large zoomée à 400 %. Le W3C rappelle que ces 400 % s'appliquent à chaque dimension et non à la surface. Cette valeur correspondait aussi aux petites fenêtres mobiles au moment de la rédaction du critère. Dans la réalité, la barre de défilement et l'interface du navigateur réduisent l'espace : sur un écran de 1 280 × 1 024 à 400 %, la fenêtre utile mesure 318 × 236 pixels.

Différence entre zoom 200 % et reflow à 320 px

Le W3C indique que le critère 1.4.4 recoupe l'objectif de la redistribution : il devrait être possible d'agrandir tout le texte à au moins 200 % tout en respectant 1.4.10. À l'inverse, la redistribution n'exige en elle-même aucun niveau d'agrandissement du texte. Les deux critères se complètent donc sans se remplacer.

Le cas des sites responsives illustre bien leur articulation. Le critère 1.4.4 s'applique à chaque variante de mise en page. Le W3C prend l'exemple d'un texte de 20 px dans une fenêtre de 1 280 px : après un zoom de 400 %, la page se redistribue dans une fenêtre de 320 pixels CSS et l'auteur peut décider d'afficher le texte à 10 px. Ce texte reste affiché deux fois plus grand qu'avec le réglage par défaut du navigateur à 100 %, alors que sa taille CSS a été divisée par deux. Il n'est pas exigé d'atteindre 200 % d'agrandissement en restant à l'intérieur d'un même point de rupture.

• 1.4.4 : le texte devient-il deux fois plus grand sans rien perdre, y compris aux paliers intermédiaires ?
• 1.4.10 : à 320 px de large (ou 256 px de haut pour un contenu à défilement horizontal), hors contenus exemptés, peut-on tout lire et tout utiliser, sans perte, avec un seul sens de défilement ?
• Au-delà de 200 %, le W3C observe que le zoom, qui agrandit texte, images et zones de mise en page sur un canevas plus grand, peut être plus efficace que l'agrandissement du texte seul ; une aide technique dédiée au grossissement est alors généralement utilisée.

Les exceptions à connaître

Le critère 1.4.10 exclut les parties du contenu qui nécessitent une mise en page en deux dimensions pour leur usage ou leur sens. La note du critère cite les images nécessaires à la compréhension (cartes, diagrammes), les vidéos, les jeux, les présentations, les tableaux de données (mais pas leurs cellules prises individuellement) et les interfaces où il faut garder une barre d'outils visible pendant la manipulation du contenu. Un défilement dans deux dimensions est alors acceptable pour ces parties.

L'exception ne couvre que la section concernée et ne s'étend pas automatiquement au reste. Autour d'un tableau de données placé dans son propre conteneur défilant, les titres, les champs de recherche, la pagination et plus généralement le reste du contenu doivent toujours se redistribuer. Une double barre de défilement au niveau de la page, due à un contenu exempté, peut être acceptée si le reste du contenu ne défile que dans un sens ; il est toutefois préférable de limiter le défilement bidirectionnel à la section qui en a besoin ; par exemple, max-width: 100% appliqué à une vidéo évite une barre de défilement inutile.

• Code et listes imbriquées : l'indentation porte la hiérarchie et peut être nécessaire au fonctionnement du code ; un texte préformaté dont la disposition a un sens (indentation Python, art ASCII) est exempté.
• Carrousels : un défilement horizontal interne est acceptable si chaque panneau tient dans 320 px.
• Documents à dimensions fixes affichés au format impression : ils peuvent garder leur taille, mais les panneaux associés, comme les commentaires, doivent se redistribuer à 320 px.
• Pour 1.4.4, les étiquettes trop étroites (colonne d'objet d'un webmail, cellule de tableur) peuvent être tronquées si leur contenu complet est disponible au focus ou après activation, et si l'utilisateur est informé qu'il peut y accéder.

Causes d'échec documentées au zoom 200 % et au reflow

Les documents « Understanding » des critères 1.4.4 et 1.4.10 listent quatre échecs (F69, F80, F94 et F102). S'y ajoutent des points de vigilance tirés des règles de test et des recommandations du W3C, qui ne sont pas des échecs répertoriés en tant que tels.

• F69 : agrandir le texte jusqu'à 200 % provoque le rognage, la troncature ou le masquage du texte, d'images ou de contrôles.
• F80 : les champs de formulaire à base de texte ne grossissent pas avec le texte.
• F94 : usage incorrect des unités de viewport pour dimensionner le texte.
• F102 : du contenu disparaît et n'est plus disponible une fois la page redistribuée.
• Point de vigilance : une balise meta viewport qui empêche le zoom ; la règle de test associée vérifie précisément que le meta viewport autorise le zoom.
• Point de vigilance : les contenus fixes ou « sticky », par exemple les en-têtes et pieds de page, qui peuvent rendre la lecture difficile, voire impossible, en petite fenêtre ; le W3C suggère fortement de les rendre statiques en petite fenêtre, ou de permettre à l'utilisateur d'activer ou de désactiver ce comportement, et rappelle qu'ils ne doivent pas masquer l'élément qui a le focus (critère 2.4.11).
• Point de vigilance : une vidéo plus large que la fenêtre peut ajouter une barre de défilement inutile ; max-width: 100% l'évite.

Corriger : techniques recommandées par le W3C

Pour 1.4.4, parmi les techniques suffisantes figurent l'usage d'une technologie dont les navigateurs courants prennent en charge le zoom, la mise en page fluide, et le fait de faire en sorte que les conteneurs de texte s'agrandissent avec le texte (conteneurs dimensionnés en em, tailles de police en pourcentage, nommées ou en em, calcul des tailles et positions qui suit la taille du texte). Une autre voie consiste à proposer sur la page des contrôles permettant d'agrandir progressivement tout le texte jusqu'à 200 %, ou de garantir l'absence de perte de contenu quand le texte grossit sans que ses conteneurs changent de largeur.

Pour 1.4.10, le W3C cite Flexbox pour redistribuer le contenu, les media queries et la grille CSS pour réorganiser les colonnes, la gestion des URL et longues chaînes de texte, et width, max-width et Flexbox pour ajuster étiquettes et champs. En techniques conseillées, il mentionne les media queries pour défiger les en-têtes et pieds de page sticky, et max-width et height pour adapter les images. Pour les longues chaînes comme des clés d'authentification, un affichage tronqué accompagné d'un lien ou d'un mécanisme de révélation est donné en exemple.

Concrètement, la navigation principale peut se replier dans un menu « Plus », puis dans un bouton hamburger, sans perte de fonctionnalité ni défilement horizontal. Une page d'article peut s'empiler en une seule colonne qui tient dans 320 px. Il n'est pas obligatoire de tout empiler : chaque section doit simplement être lisible sans défilement dans deux dimensions. L'exemple de code ci-dessous, propre à cet article, illustre ces principes.

<!-- Ne bloquez pas le zoom -->
<meta name="viewport" content="width=device-width, initial-scale=1">

<style>
  /* Tailles relatives : le texte suit le réglage de l'utilisateur */
  body { font-size: 100%; }
  .encart { padding: 1em; min-height: 3em; } /* pas de hauteur fixe en px */

  /* Redistribution avec Flexbox */
  .cartes { display: flex; flex-wrap: wrap; gap: 1em; }

  /* Médias contenus dans la fenêtre */
  img, video { max-width: 100%; height: auto; }

  /* En petite fenêtre, l'en-tête n'est plus fixe */
  @media (max-width: 30em) {
    header { position: static; }
  }
</style>

Tester le zoom 200 % et le reflow pas à pas

Un test manuel reproduit les situations décrites par le W3C. Complétez-le par une surveillance continue pour détecter les régressions introduites par les mises à jour de vos gabarits.

• Zoomez dans le navigateur par paliers de 100 % à 200 % et vérifiez à chaque palier que tout le texte reste visible, qu'aucun contenu n'est rogné ou superposé et que les champs de formulaire grossissent.
• Essayez aussi l'agrandissement du texte seul, quand le navigateur le propose.
• Réglez une fenêtre de 1 280 px de large et zoomez à 400 % : vérifiez que, hors contenus nécessitant une mise en page en deux dimensions, seul un défilement vertical est nécessaire et que rien n'a disparu.
• Contrôlez la navigation, les en-têtes fixes, les tableaux, les vidéos et les longues URL, puis vérifiez que l'élément qui reçoit le focus n'est pas masqué.
• Certains agents utilisateurs, notamment d'anciens navigateurs mobiles, ne peuvent pas se redimensionner exactement à ces valeurs ; le critère n'exige pas que les appareils le permettent. Testez donc avec un navigateur qui le permet.

Questions fréquentes

À lire aussi sur Conformly

• Guide de correction du zoom 200 % en HTML
• Fiche détaillée du critère RGAA 10.4
• Fiche détaillée du critère RGAA 10.11

Sources

Article appuyé sur les sources officielles citées en fin de page.

• W3C — Comprendre 1.4.4
• W3C — Comprendre 1.4.10