Testez séparément l’agrandissement du texte et le reflow de la mise en page
WCAG 2.2 distingue plusieurs besoins. Le critère Resize Text demande que le texte puisse être agrandi jusqu’à 200 % sans perte de contenu ou de fonctionnalité, avec les exceptions prévues. Le critère Reflow traite la présentation lorsque la zone d’affichage devient très étroite, notamment l’équivalent de 320 pixels CSS pour du contenu vertical.
Ces seuils ne doivent pas être mélangés. Un test à 200 % ne remplace pas le contrôle de reflow, et un passage à 400 % de zoom utilisé pour simuler une largeur de 320 pixels CSS ne signifie pas que toutes les interfaces doivent simplement « supporter 400 % » de la même manière. Un contrôle manuel utile garde les objectifs séparés.
Commencez par agrandir le texte jusqu’à 200 %
Dans un navigateur standard, augmentez la taille du texte ou le zoom selon la méthode de test choisie et observez les zones contenant informations et actions. Les paragraphes, boutons, menus, libellés de formulaire et messages importants doivent rester lisibles et utilisables. Un texte qui déborde hors d’une boîte fixe ou disparaît derrière un autre composant est un signal à examiner.
Ne regardez pas seulement la page d’accueil. Testez une page de contenu longue, un formulaire, une navigation, une fiche produit ou service et les composants récurrents. Les défauts viennent souvent de hauteurs fixes, de conteneurs trop contraints ou d’éléments positionnés de façon absolue.
Contrôlez ensuite le reflow avec une largeur équivalente à 320 pixels CSS
Pour le contenu qui doit se réorganiser, l’objectif est d’éviter d’imposer un défilement dans deux dimensions pour lire ou utiliser l’interface. À fort zoom sur un écran de bureau, la largeur CSS disponible diminue ; les blocs doivent généralement passer les uns sous les autres et le texte doit rester dans une colonne exploitable.
Regardez particulièrement les tableaux, cartes horizontales, barres d’outils, modales et zones avec plusieurs colonnes. Certains contenus intrinsèquement bidimensionnels bénéficient d’exceptions documentées ; ne concluez donc pas qu’un seul défilement horizontal suffit à rendre tout le site non conforme sans examiner le type de contenu.
Repérez les pertes de contenu et de fonctionnalité, pas seulement les imperfections visuelles
Une interface peut devenir moins élégante à fort zoom sans perdre son usage. Le problème prioritaire apparaît lorsque du texte devient inaccessible, qu’un bouton sort définitivement de la zone visible, qu’une modale masque son bouton de fermeture ou qu’un champ ne peut plus être atteint. Ces défauts ont un impact concret sur la navigation.
Notez chaque cas avec l’URL, le niveau de zoom ou la taille de texte, le navigateur et le composant. Cette trace rend la correction reproductible. Évitez les jugements vagues comme « la page casse » : indiquez précisément quelle information ou fonction disparaît.
Les causes fréquentes sont les dimensions fixes et les composants qui refusent de se réorganiser
Des hauteurs en pixels sur des cartes contenant du texte, des largeurs minimales trop élevées, des grilles sans point de rupture ou des éléments positionnés par-dessus le contenu peuvent provoquer des chevauchements. Les composants tiers peuvent également créer des fenêtres trop larges ou des boutons inaccessibles.
Corrigez d’abord le composant source plutôt que chaque occurrence. Une variable de design system, un style de carte ou un template de formulaire corrigé proprement peut résoudre des dizaines de pages. Testez toutefois les variations de contenu, car un composant fonctionne parfois avec une phrase courte mais échoue avec une traduction plus longue.
Complétez le test par des contenus et langues qui prennent plus de place
Le zoom n’est pas uniquement un problème de taille d’écran. Une interface qui tolère mal l’agrandissement échoue souvent aussi lorsque les libellés sont plus longs, quand l’utilisateur utilise une police personnalisée ou lorsque la traduction augmente la longueur du texte. Ces situations révèlent les mêmes contraintes rigides.
Testez donc au moins un contenu long, un état d’erreur et une traduction plus verbeuse si le site est multilingue. Vous ne cherchez pas à couvrir toutes les combinaisons possibles, mais à confirmer que le système peut absorber une variation normale sans masquer les fonctions essentielles.
Corrigez en privilégiant des mises en page flexibles
Utilisez des dimensions qui s’adaptent au contenu, autorisez le retour à la ligne, revoyez les conteneurs qui imposent une hauteur fixe et vérifiez les points de rupture CSS. Pour les zones de navigation, prévoyez une version qui reste atteignable lorsque les libellés grandissent au lieu de simplement cacher les éléments qui ne tiennent plus.
Après chaque correction, rejouez exactement le test qui avait échoué. Le but n’est pas de gagner un score automatique mais de restaurer l’accès au contenu et aux actions. Conservez les captures ou notes avant/après pour faciliter les régressions futures.
Un test manuel réussi ne certifie pas l’accessibilité globale
Le zoom et le redimensionnement ne couvrent qu’une partie des WCAG. Un site peut réussir ce contrôle et conserver des problèmes de clavier, contraste, structure, alternatives textuelles ou formulaires. Ne présentez donc jamais ce test comme une certification WCAG ou comme une preuve que tout le site est accessible.
Limpi peut aider à organiser ces contrôles sans dépasser leur portée. Lancer un audit Limpi permet d’identifier des points techniques à revoir, tandis que notre approche explique pourquoi nous distinguons contrôle ciblé, revue humaine et conformité complète.
Références utilisées pour cette page
Continuer à comprendre votre visibilité
À lire ensuite