WCAG 1.4.4 : Redimensionner le texte

Ce que signifie cette règle

WCAG 1.4.4 Redimensionnement du texte (Niveau AA) stipule que le texte doit pouvoir être redimensionné jusqu’à 200 pour cent sans recourir à une technologie d’assistance et sans perte de contenu ni de fonctionnalité. En termes simples, lorsqu’un utilisateur zoome son navigateur à 200 % ou augmente la taille de police de base via les paramètres du navigateur ou du système d’exploitation, tout le texte de la page doit rester lisible et toutes les fonctionnalités doivent rester intactes.

Ce critère s’applique largement à tout le texte rendu sur une page web, y compris le corps du texte, les titres, les libellés, le texte des boutons, le texte d’espace réservé à l’intérieur des champs de formulaire, les liens de navigation, le contenu des tableaux et les légendes. Il ne s’applique pas au texte qui fait partie d’un logo ou d’un nom de marque, ni au texte décoratif qui ne transmet aucune information et est présenté uniquement comme contenu d’image (par exemple une photographie scannée d’une note manuscrite lorsque le texte lui-même n’est pas le contenu accessible).

Pour réussir, il faut qu’à 200 % de zoom — obtenu soit via le zoom de page intégré du navigateur (Ctrl/Cmd + touche plus ou le menu Affichage > Zoom), soit via le paramètre de taille de police minimale du navigateur — les conditions suivantes soient remplies : aucun texte n’est tronqué ou masqué par son conteneur, aucun texte ne chevauche d’autre texte ou des éléments interactifs, aucune barre de défilement horizontale n’apparaît à la largeur complète de la fenêtre d’affichage (sauf pour le contenu qui nécessite réellement un défilement bidimensionnel, comme les cartes ou les tableaux de données), et toutes les commandes interactives restent opérables.

Un échec est constaté lorsque des valeurs de pixels fixes verrouillent le texte dans une taille qui ne peut pas augmenter, lorsque des conteneurs utilisent des hauteurs fixes qui tronquent le texte débordant, lorsque des balises meta viewport utilisent user-scalable=no ou maximum-scale=1.0 pour bloquer le pincement‑pour‑zoomer sur mobile, ou lorsque JavaScript intercepte les gestes de zoom pour empêcher la mise à l’échelle. Le critère est explicitement indépendant de la technologie : que la mise en œuvre utilise du texte CSS, du texte SVG ou du texte rendu sur canvas, c’est le résultat pour l’utilisateur qui compte. Notez que le texte SVG et le texte rendu sur canvas sont intrinsèquement difficiles à redimensionner et nécessitent souvent une attention technique supplémentaire.

Pourquoi c’est important

Environ 2,2 milliards de personnes dans le monde présentent une forme de déficience visuelle, selon l’Organisation mondiale de la santé. Parmi elles, une très grande proportion présente une basse vision — une condition où la vision ne peut pas être entièrement corrigée avec des lunettes ou des lentilles de contact, mais où la personne n’est pas totalement aveugle. Les utilisateurs malvoyants règlent couramment le zoom de leur navigateur à 150 %, 200 % ou plus, ou configurent leur système d’exploitation pour afficher le texte avec une taille de base plus grande. Lorsque les sites web bloquent ou perturbent ce comportement, ces utilisateurs sont entièrement exclus du contenu.

Au-delà des diagnostics de basse vision, des facteurs situationnels affectent pratiquement tous les internautes à un moment donné : petits écrans, forte luminosité, fatigue, vieillissement de la vue ou lecture dans une langue peu familière peuvent tous rendre le texte de petite taille plus difficile à déchiffrer. Les personnes âgées en particulier — un groupe démographique en forte croissance à l’échelle mondiale et en Turquie — s’appuient fréquemment sur le zoom comme première mesure d’accessibilité avant de recourir à une technologie d’assistance spécialisée.

Considérez un scénario concret : un patient d’une soixantaine d’années essaie de lire sur son smartphone la confirmation de son rendez-vous en ligne sur le portail d’un hôpital. La feuille de style mobile de l’hôpital définit la taille de police du corps de texte à 12px à l’aide d’une valeur de pixels fixe et la balise meta viewport inclut maximum-scale=1.0. Le patient tente de pincer pour zoomer mais l’interface se verrouille. Il ne peut pas lire la date ni le nom du service avec suffisamment de clarté pour être sûr de lui. Il appelle le service d’assistance de l’hôpital, ce qui mobilise du temps de personnel et crée de l’anxiété pour le patient — un résultat entièrement évitable si le critère avait été respecté.

D’un point de vue purement commercial, une taille de texte accessible est corrélée à des améliorations plus larges de l’ergonomie qui bénéficient à tous les utilisateurs. Les moteurs de recherche récompensent également les sites qui affichent un texte lisible aux tailles normale et agrandie, car Googlebot évalue les signaux de lisibilité dans le cadre des Core Web Vitals et des facteurs de classement liés à l’expérience de page. Corriger les problèmes de redimensionnement améliore donc simultanément le SEO, réduit la charge du support et élargit le public potentiel.

Règles Axe-core associées

WCAG 1.4.4 est principalement un critère de test manuel. Les outils automatisés peuvent signaler un ensemble restreint de conditions connues pour empêcher le redimensionnement du texte, mais ils ne peuvent pas simuler et évaluer de manière fiable tous les résultats de mise en page à 200 % de zoom. Les conditions suivantes sont celles que les outils automatisés tentent de détecter et qui nécessitent un suivi manuel :

• Balise meta viewport bloquant le zoom (vérification manuelle requise) : Axe-core inclut la règle meta-viewport, qui signale toute balise <meta name='viewport'> qui définit user-scalable=no ou maximum-scale à une valeur de 1,0 ou moins. C’est le seul scénario où une détection entièrement automatisée est possible, car la violation est déclarative et ne dépend pas du résultat de la mise en page. Cependant, même cette règle ne peut pas déterminer si un site utilise JavaScript pour empêcher le zoom de manière programmatique, de sorte qu’une vérification manuelle est toujours nécessaire.
• Tailles de police fixes en pixels (vérification manuelle requise) : Les outils automatisés peuvent signaler lorsque les valeurs CSS de font-size sont définies en unités de pixels absolues (px) plutôt qu’en unités relatives (em, rem, % ou unités relatives à la fenêtre d’affichage). Cependant, les navigateurs modernes remplacent les tailles de police en pixels absolus lorsque l’utilisateur modifie la taille de police par défaut de son navigateur, de sorte qu’une valeur en pixels seule ne constitue pas un échec garanti — cela dépend du comportement du navigateur et du respect par le site de l’héritage de font-size. Une inspection manuelle des styles calculés et une vérification visuelle sont nécessaires pour confirmer un échec réel.
• Débordement de contenu et rognage à 200 % de zoom (manuel uniquement) : Aucun outil automatisé ne peut rendre de manière fiable une page à 200 % et évaluer si tout le texte reste visible et si tous les éléments interactifs restent opérables. Cela nécessite qu’un testeur humain règle le niveau de zoom du navigateur, fasse défiler la page et vérifie chaque zone de contenu. Les outils automatisés n’ont pas accès à l’état rendu après zoom.
• Texte dans les images et le canvas (manuel uniquement) : Le texte intégré dans des images matricielles (balises <img> contenant des captures d’écran de texte) ou rendu dans un élément <canvas> ne peut pas être redimensionné par le navigateur. Les outils automatisés peuvent signaler la présence d’éléments canvas pour examen manuel, mais ils ne peuvent pas déterminer si ces éléments canvas contiennent un texte significatif que l’utilisateur doit lire.

Comment tester

1. Commencez par lancer une analyse automatisée. Ouvrez la page dans Chrome ou Firefox et exécutez axe DevTools (extension de navigateur) ou Lighthouse (Chrome DevTools, onglet Lighthouse). Recherchez spécifiquement la violation de la règle meta-viewport. Si elle est signalée, notez-la comme un échec critique. Vérifiez également l’audit CSS pour toute déclaration de font-size en unités px qui apparaît dans les avertissements de bonnes pratiques axe.
2. Vérifiez la balise meta viewport dans le code source. Ouvrez DevTools (F12), allez dans l’onglet Éléments et recherchez meta name='viewport'. Lisez attentivement l’attribut content. S’il contient user-scalable=no, user-scalable=0 ou maximum-scale=1 (ou toute valeur inférieure à 2), il s’agit d’un échec direct de 1.4.4.
3. Réglez le zoom du navigateur à 200 %. Dans Chrome ou Firefox, appuyez plusieurs fois sur Ctrl + Plus (Windows/Linux) ou Cmd + Plus (macOS) jusqu’à ce que l’indicateur de zoom du navigateur affiche 200 %. Vous pouvez aussi aller dans Affichage > Zoom avant. Sur Safari macOS, utilisez Affichage > Zoom avant. N’utilisez pas le réglage de mise à l’échelle de l’affichage au niveau du système d’exploitation pour ce test — utilisez spécifiquement le zoom du navigateur.
4. Faites défiler toutes les sections de la page à 200 % de zoom. Faites défiler systématiquement de haut en bas. Recherchez : du texte coupé ou masqué par son conteneur, du texte qui déborde de sa boîte et chevauche le contenu adjacent, des libellés de formulaire qui disparaissent derrière leurs champs, des boutons dont le texte est tronqué, des menus déroulants qui s’étendent hors écran et ne peuvent pas être défilés dans la vue, et des boîtes de dialogue modales qui dépassent la fenêtre d’affichage et ne peuvent pas être défilées.
5. Testez toutes les fonctionnalités interactives à 200 % de zoom. Activez chaque menu de navigation, ouvrez chaque fenêtre modale, soumettez les formulaires, déclenchez les info-bulles et popovers, et interagissez avec tous les carrousels ou accordéons. Vérifiez que tout cela reste pleinement opérable — pas seulement visuellement présent.
6. Testez avec NVDA + Firefox (Windows). Activez NVDA et ouvrez Firefox à 200 % de zoom. Naviguez à l’aide de la touche Tab et des touches fléchées. Confirmez que les éléments focalisables reçoivent le focus, que les indicateurs de focus sont visibles (chevauchement avec WCAG 2.4.7, mais utile à vérifier) et que l’ordre de lecture correspond à l’ordre visuel à la taille agrandie.
7. Testez avec VoiceOver + Safari (macOS/iOS). Activez VoiceOver. Sur iOS, allez dans Réglages > Accessibilité > Affichage et taille du texte et activez Texte plus grand. Parcourez la même page et vérifiez l’intégrité du contenu. Utilisez également le geste de pincement‑pour‑zoomer pour confirmer qu’il n’est pas bloqué.
8. Testez le paramètre de taille de police minimale du navigateur. Dans Firefox, allez dans Paramètres > Général > Polices et couleurs et définissez la taille de police minimale sur 24px. Rechargez la page et vérifiez que tout le texte respecte ce minimum et que la mise en page ne se casse pas. Cela teste un vecteur différent du même critère.
9. Testez avec JAWS + Chrome (Windows). Ouvrez la page dans Chrome à 200 % de zoom avec JAWS actif. Utilisez les commandes de lecture de JAWS (Insert + Flèche bas pour lire à partir du curseur) pour confirmer que tout le contenu textuel est annoncé et qu’aucun contenu n’est ignoré en raison d’un rognage par débordement.

Comment corriger

Balise meta viewport bloquant le zoom — Incorrect

<!-- WRONG: user-scalable=no prevents pinch-to-zoom on mobile,
     directly violating WCAG 1.4.4 -->
<meta name='viewport' content='width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no'>

Balise meta viewport bloquant le zoom — Correct

<!-- CORRECT: Remove user-scalable=no and do not cap maximum-scale below 2.
     Allowing zoom to at least 2 (200%) satisfies WCAG 1.4.4. -->
<meta name='viewport' content='width=device-width, initial-scale=1.0'>

Tailles de police en pixels fixes — Incorrect

<!-- WRONG: font-size in px ignores the user's browser font-size preference.
     If the user sets a larger default, px values override that preference. -->
<style>
  body {
    font-size: 14px;
  }
  h1 {
    font-size: 24px;
  }
  .caption {
    font-size: 11px;
  }
</style>
<p>Your appointment is confirmed.</p>

Tailles de police en pixels fixes — Correct

<!-- CORRECT: Use rem units relative to the root font size (typically 16px browser default).
     1rem = 16px by default, but scales with user preference.
     Setting font-size on :root in % rather than px also respects user settings. -->
<style>
  :root {
    font-size: 100%; /* inherits browser default, typically 16px */
  }
  body {
    font-size: 0.875rem; /* ~14px at default, but scales with user preference */
  }
  h1 {
    font-size: 1.5rem; /* ~24px at default */
  }
  .caption {
    font-size: 0.75rem; /* ~12px at default — still scalable */
  }
</style>
<p>Your appointment is confirmed.</p>

Conteneurs à hauteur fixe qui rognent le texte — Incorrect

<!-- WRONG: A fixed height with overflow:hidden will clip enlarged text.
     At 200% zoom, the text grows but the box does not, hiding content. -->
<style>
  .card {
    height: 120px;
    overflow: hidden;
  }
</style>
<div class='card'>
  <h2>Flight Confirmation</h2>
  <p>Your flight TK0001 to Istanbul departs at 09:30 on 15 July 2025. Gate B12.</p>
</div>

Conteneurs à hauteur fixe qui rognent le texte — Correct

<!-- CORRECT: Use min-height instead of height so the container grows
     with the content when text is enlarged. -->
<style>
  .card {
    min-height: 7.5rem; /* sets a minimum but allows growth */
    overflow: visible; /* or remove overflow:hidden entirely */
  }
</style>
<div class='card'>
  <h2>Flight Confirmation</h2>
  <p>Your flight TK0001 to Istanbul departs at 09:30 on 15 July 2025. Gate B12.</p>
</div>

Texte intégré dans des images — Incorrect

<!-- WRONG: A banner image containing text cannot be resized by the browser.
     Even with alt text, the visual text is inaccessible at high zoom levels. -->
<img src='promo-banner-with-text.jpg' alt='50% indirim — sadece bu hafta sonu'>

Texte intégré dans des images — Correct

<!-- CORRECT: Use real HTML text over a background image so the browser
     can resize it. The image is decorative background; text is live HTML. -->
<div class='promo-banner' role='region' aria-label='Promosyon'>
  <p class='promo-text'>50% İndirim &mdash; Sadece Bu Hafta Sonu</p>
</div>
<!-- CSS sets the background image on .promo-banner, while .promo-text
     uses rem font-size and contrasts safely against the background. -->

Erreurs courantes

• Ajouter user-scalable=no à la balise meta viewport pour empêcher la « casse de la mise en page » sur mobile — il s’agit d’une violation directe et testable de 1.4.4 et cela ne doit jamais être utilisé. Corrigez la mise en page au lieu de supprimer la capacité de l’utilisateur à zoomer.
• Définir maximum-scale=1.0 ou toute valeur inférieure à 2.0 — même sans user-scalable=no, limiter le zoom à 1,0 ou 1,5 empêche les utilisateurs d’atteindre 200 % et ne respecte pas le critère.
• Utiliser des écouteurs d’événements JavaScript pour appeler event.preventDefault() sur les événements de pincement‑pour‑zoomer ou de molette — bloquer le zoom natif par programmation est fonctionnellement équivalent à l’approche via la balise meta viewport et enfreint le même critère.
• Définir font-size en pixels sur l’élément <html> ou <body> puis utiliser des unités em pour tout le reste — si la taille de police racine est fixée en px, tous les descendants en em/rem sont également effectivement fixes et ne répondront pas à la préférence de taille de police du navigateur de l’utilisateur.
• Utiliser height au lieu de min-height sur les composants de type carte, les barres latérales ou le corps des modales — à 200 % de zoom, le texte agrandi déborde des boîtes à hauteur fixe et est rogné par overflow: hidden, masquant un contenu critique.
• Placer du texte important exclusivement à l’intérieur d’éléments <canvas> — le texte rendu sur canvas est un bitmap rasterisé et ne peut pas être mis à l’échelle par les mécanismes de redimensionnement du texte ou de zoom du navigateur. Tout texte significatif que l’utilisateur doit lire doit être disponible sous forme de vrai texte HTML ou au minimum sous forme de texte alternatif accessible.
• Utiliser des éléments SVG <text> avec des coordonnées absolues et sans mise à l’échelle viewBox — le texte SVG peut être scalable lorsque le SVG utilise un viewBox et est dimensionné avec des unités relatives, mais le texte SVG avec des attributs x, y, font-size définis en pixels à l’intérieur d’un SVG avec une width et une height fixes ne se redimensionne pas avec le zoom du navigateur dans tous les navigateurs.
• Supposer que le zoom du navigateur gère automatiquement le critère et sauter les tests manuels — le zoom du navigateur met à l’échelle toute la page, y compris les images et la mise en page, mais le texte qui était déjà trop petit, tronqué ou chevauchant à 100 % devient un problème plus grave à 200 %. Une vérification manuelle au niveau de zoom est toujours nécessaire.
• Oublier de tester les widgets embarqués tiers — les widgets de chat, les iframes de paiement, les bannières de consentement aux cookies et les superpositions d’analytique sont souvent développés par des tiers utilisant des tailles en px fixes et peuvent bloquer le zoom. Même si le code est tiers, le critère s’applique à l’ensemble de la page telle qu’elle est livrée à l’utilisateur.
• Corriger la mise en page de bureau pour le zoom mais négliger le point de rupture mobile — de nombreuses équipes testent le zoom sur bureau et déclarent la réussite, mais les fenêtres d’affichage mobiles à 200 % de zoom présentent un ensemble distinct de défis de mise en page, en particulier pour les menus de navigation, les en-têtes fixes et les barres de navigation inférieures qui dépendent de hauteurs en pixels fixes.

Lien avec la réglementation d’accessibilité de la Turquie

La circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des exigences obligatoires en matière d’accessibilité web et mobile pour un ensemble défini d’organisations opérant en Turquie. La circulaire fait référence à des normes d’accessibilité reconnues au niveau international — alignant de fait les exigences turques sur WCAG 2.1 et WCAG 2.2 Niveau AA comme référence de conformité.

WCAG 1.4.4 Redimensionnement du texte est un critère de Niveau AA, et la conformité de Niveau AA est le seuil requis pour obtenir le logo d’accessibilité (Erişilebilirlik Logosu) délivré par le ministère de la Famille et des Services sociaux (Aile ve Sosyal Hizmetler Bakanlığı). Le logo d’accessibilité est à la fois un signal de confiance publique et un point de contrôle réglementaire — les organisations soumises à la circulaire qui souhaitent afficher le logo ou démontrer leur conformité auprès des auditeurs doivent satisfaire à tous les critères de Niveau AA, y compris 1.4.4.

Les catégories d’entités couvertes par la circulaire présidentielle 2025/10 comprennent : les institutions et organismes publics à tous les niveaux de gouvernement ; les plateformes de commerce électronique et les places de marché en ligne ; les banques et prestataires de services financiers réglementés par l’Agence de régulation et de supervision bancaires (BDDK) ; les hôpitaux, centres de santé et autres organisations de soins de santé disposant de services numériques destinés aux patients ; les opérateurs de télécommunications comptant 200 000 abonnés ou plus ; les agences de voyage et plateformes de voyage en ligne ; les entreprises de transport privé proposant des services de billetterie ou de réservation numériques ; et les écoles privées et établissements d’enseignement autorisés par le ministère de l’Éducation nationale (Millî Eğitim Bakanlığı, MoNE).

Pour chacune de ces catégories d’entités, la portée pratique de 1.4.4 est significative. Le portail de banque en ligne d’une banque qui bloque le pincement‑pour‑zoomer sur mobile n’est pas seulement un échec d’ergonomie — c’est une non‑conformité réglementaire qui peut entraîner des constats d’audit ou l’exclusion du programme de logo d’accessibilité. Un système de prise de rendez-vous hospitalier qui utilise des tailles de police en pixels fixes à l’intérieur de conteneurs qui rognent le contenu ne répond pas aux besoins des patients malvoyants et ne respecte pas simultanément ses obligations au titre de la circulaire. La plateforme d’inscription d’une école privée qui intègre du texte dans des images plutôt que d’utiliser du texte HTML scalable est tout aussi non conforme.

Les organisations devraient considérer WCAG 1.4.4 non pas comme une simple case technique à cocher, mais comme une attente de base en matière de respect des utilisateurs ayant une déficience visuelle — une attente sur laquelle convergent le droit turc, les meilleures pratiques internationales et l’ergonomie de base. Le SDK de superposition d’Accsible prend en charge la conformité au redimensionnement du texte en fournissant des contrôles de mise à l’échelle de police configurables qui permettent aux utilisateurs finaux d’augmenter la taille du texte indépendamment du zoom du navigateur, offrant une couche d’adaptation supplémentaire par‑dessus les exigences de base que les sites eux‑mêmes doivent mettre en œuvre.