WCAG 1.4.5 : Images de texte

Ce que signifie cette règle

WCAG 1.4.5 — Images de texte (Niveau AA) stipule que si la même présentation visuelle peut être obtenue en utilisant du vrai texte, vous devez utiliser du vrai texte plutôt qu’une image contenant du texte. Une image de texte est toute image dans laquelle les caractères textuels constituent le contenu principal transmis — par exemple, un JPEG d’un titre, une bannière PNG avec un slogan, ou un logo GIF qui écrit un nom de marque dans une police stylisée.

La distinction entre conformité et non-conformité est simple : si l’information pourrait être transmise en balisant de vrais caractères en HTML et en les stylisant avec du CSS pour obtenir le même rendu, alors utiliser une image à la place constitue un échec. La règle ne concerne pas les images décoratives ni les photographies qui contiennent du texte dans la scène (comme un panneau de rue sur une photo). Elle vise les images où le texte lui-même est le contenu visé.

WCAG définit deux exceptions officielles où les images de texte sont autorisées :

• Exception essentielle : La présentation visuelle particulière est essentielle à l’information transmise. L’exemple classique est un logotype — lorsque le rendu spécifique des formes de lettres est indissociable de l’identité de la marque. Un logo d’entreprise où les formes de lettres stylisées SONT la marque peut rester une image.
• Exception personnalisable : L’image de texte peut être personnalisée visuellement selon les besoins de l’utilisateur. Cela signifie que l’utilisateur peut modifier la police, la taille, la couleur et l’arrière-plan du texte dans l’image. En pratique, cette exception est presque jamais remplie par les implémentations réelles, car la plupart des images ne peuvent pas être re-rendues dynamiquement selon les préférences de l’utilisateur.

Il est important de noter ce que ce critère n’exige PAS : il n’interdit pas toutes les images contenant du texte. Une photographie d’un document historique, une capture d’écran utilisée comme preuve, ou un graphique image où les étiquettes d’axes font partie de la visualisation de données ne sont pas la cible principale de cette règle, même si un texte alternatif (WCAG 1.1.1) doit toujours décrire leur contenu. L’accent est mis sur les cas où un designer a choisi de rendre du texte stylisé sous forme d’image matricielle ou vectorielle pour des raisons purement esthétiques alors que le CSS pourrait obtenir le même résultat.

Les éléments HTML le plus souvent impliqués dans des échecs incluent les balises <img> utilisées pour des titres, des bannières, des boutons d’appel à l’action, des libellés de navigation, des citations mises en avant et du texte promotionnel. Les fichiers SVG qui intègrent du texte sous forme de tracés (plutôt que d’éléments <text>) posent également problème, car ces caractères ne peuvent pas être sélectionnés, redimensionnés ou reflowés par le navigateur.

Pourquoi c’est important

Lorsque le texte est intégré dans une image matricielle, il devient un bitmap fixe. Le navigateur peut agrandir ou réduire l’image, mais il ne peut pas reflow le texte, changer sa police, augmenter son épaisseur ou modifier son contraste de couleur au-delà de ce qui est déjà figé dans les pixels. Cela crée des obstacles importants pour plusieurs groupes de personnes handicapées.

Les utilisateurs avec une basse vision s’appuient généralement sur le zoom du navigateur, le redimensionnement du texte au niveau du système d’exploitation ou des logiciels de grossissement dédiés. Le vrai texte s’agrandit de manière nette à tout niveau de zoom ; une image de texte devient floue et pixellisée, la rendant illisible à fort grossissement. Environ 2,2 milliards de personnes dans le monde ont une forme de déficience visuelle, et beaucoup d’entre elles utilisent le zoom ou la magnification comme stratégie principale plutôt qu’un lecteur d’écran.

Les utilisateurs avec une dyslexie ou d’autres troubles de la lecture utilisent fréquemment des extensions de navigateur ou des technologies d’assistance pour remplacer les polices, augmenter l’espacement des lettres et passer à des schémas de couleurs à fort contraste. Aucune de ces personnalisations ne fonctionne sur les images de texte — les pixels sont immuables. Un utilisateur qui a besoin d’OpenDyslexic ou d’une police sans empattement à large espacement ne peut tout simplement pas l’appliquer à un titre rendu en PNG.

Les utilisateurs qui dépendent de schémas de couleurs personnalisés — y compris ceux qui ont une photophobie, des troubles migraineux ou des sensibilités au contraste — peuvent configurer leur système d’exploitation en mode à fort contraste ou en couleurs inversées. Le texte CSS répond à ces substitutions au niveau du système ; le texte image n’y répond pas, et peut même devenir plus difficile à lire lorsque les couleurs sont inversées de manière inattendue.

Considérez un scénario concret : un site e-commerce turc rend les titres de ses campagnes promotionnelles sous forme d’images JPEG pour préserver la police d’affichage personnalisée utilisée dans le guide de style de la marque. Un utilisateur avec une basse vision zoome son navigateur à 200 %. Les images de produits s’agrandissent de manière acceptable, mais le titre de la campagne — une image — devient une tache floue de pixels. L’utilisateur ne peut pas lire la promotion et manque la réduction. Si la même police avait été fournie via @font-face et appliquée à un véritable élément <h2>, le texte serait resté net à tout niveau de zoom, car le rendu vectoriel des polices est infiniment scalable.

Au-delà de l’accessibilité, l’utilisation de vrai texte présente des bénéfices SEO mesurables. Les robots d’indexation des moteurs de recherche indexent directement les nœuds de texte ; ils ne peuvent pas extraire de manière fiable le contenu textuel des images sans OCR. Un titre intégré dans un PNG est invisible pour l’algorithme de classement de Google. Passer à du vrai texte peut améliorer l’indexation des mots-clés et le classement de la page pour le même contenu.

Règles Axe-core associées

WCAG 1.4.5 nécessite des tests manuels. Il n’existe pas de règle axe-core automatisée unique qui détecte de manière fiable les images de texte, pour les raisons expliquées ci-dessous.

• Test manuel requis — aucune règle automatisée dédiée : Les outils automatisés peuvent détecter qu’un élément <img> existe et qu’il possède un attribut alt, mais ils ne peuvent pas déterminer si le contenu visuel de cette image est principalement du texte rendu. Le faire nécessiterait une reconnaissance d’image / OCR sur chaque image de la page, ce qui est coûteux en calcul et dépendant du contexte. Un outil qui scanne une page ne peut pas distinguer entre une photographie qui contient incidemment un panneau avec des mots et un titre délibérément rendu sous forme d’image. Un jugement humain est nécessaire pour évaluer si une image donnée existe dans le but de présenter du texte stylisé qui pourrait à la place être balisé comme vrai texte HTML avec un style CSS.
• Signal partiel provenant des règles de contraste de couleur : Les règles axe-core telles que color-contrast ne se déclenchent pas sur le texte intégré dans des images, car elles opèrent sur les nœuds de texte du DOM et les valeurs de couleur CSS calculées. Si une image de texte a un contraste insuffisant, la vérification automatisée du contraste la manquera silencieusement. Cela signifie que les images de texte peuvent simultanément enfreindre 1.4.5 et 1.4.3 (Contraste minimum) sans aucun signal automatisé — une raison forte de réaliser des audits manuels approfondis.
• Texte SVG converti en tracés : Lorsque du texte dans un SVG est exporté sous forme de tracés de contours (éléments <path>) plutôt que d’éléments <text>, axe-core n’a aucun moyen de savoir que ces tracés forment des mots. Une inspection manuelle du code source SVG est nécessaire pour déterminer si le texte a été converti en contours et s’il devrait à la place être un véritable élément <text> avec une police web appliquée.

Comment tester

1. Exécuter un scan automatisé comme base de référence. Utilisez axe DevTools (extension de navigateur) ou Lighthouse dans Chrome DevTools pour identifier les problèmes signalés sur la page. Bien qu’aucun de ces outils n’ait de règle 1.4.5 dédiée, les résultats du scan peuvent faire apparaître des problèmes connexes tels que l’absence de texte alt sur les images ou un contraste de couleur insuffisant sur les nœuds de texte. Notez toutes les images signalées — elles deviennent des candidates pour un examen manuel.
2. Inspecter visuellement toutes les images de la page. Ouvrez la page dans un navigateur et examinez systématiquement chaque élément <img>, chaque SVG inline, chaque image d’arrière-plan CSS et chaque élément canvas. Demandez-vous pour chacun : le but principal de cette image est-il d’afficher du texte ? Si oui, passez à l’étape suivante.
3. Vérifier si le CSS pourrait obtenir le même résultat. Pour toute image identifiée à l’étape 2, demandez-vous : une police web (@font-face) combinée à des propriétés CSS (couleur, ombre portée, espacement des lettres, arrière-plan en dégradé) pourrait-elle produire un résultat visuel équivalent ? Si la réponse est oui, l’image de texte constitue un échec, sauf si l’exception de logotype s’applique.
4. Vérifier les exceptions de logotype. Si un site invoque une exception de logotype, confirmez que l’image est réellement un logo de marque où le design des formes de lettres est indissociable de l’identité de la marque, et non simplement un titre composé dans la police de la marque.
5. Tester avec le zoom du navigateur. Zoomez le navigateur à 200 % et 400 % (en utilisant Ctrl/Cmd + ou les paramètres du navigateur). Observez si le texte de la page reste net. Les images de texte deviennent floues ou pixellisées ; le vrai texte reste net. Ce test vérifie simultanément les violations de 1.4.5 et les problèmes de reflow associés (WCAG 1.4.4 et 1.4.10).
6. Inspecter le code source SVG. Faites un clic droit sur tout SVG et choisissez « View Source » ou utilisez les DevTools du navigateur pour inspecter le DOM du SVG. Confirmez que le contenu textuel utilise des éléments <text> plutôt que des éléments <path> qui tracent les contours des lettres. Si tout le texte a été converti en tracés, le SVG présente le même problème qu’une image matricielle de texte.
7. Tester avec un lecteur d’écran pour comprendre l’impact cumulatif. Utilisez NVDA avec Firefox, VoiceOver avec Safari sur macOS/iOS, ou JAWS avec Chrome. Naviguez jusqu’aux images de texte et confirmez que l’attribut alt transmet fidèlement le contenu textuel. Bien qu’un attribut alt pertinent réponde à WCAG 1.1.1 (Contenu non textuel), il ne résout pas l’échec 1.4.5 — le texte n’est toujours pas personnalisable par l’utilisateur. Documentez les deux problèmes séparément.
8. Appliquer une feuille de style utilisateur personnalisée ou une extension de navigateur. Installez une extension de navigateur telle que Stylus ou utilisez la fonctionnalité de feuille de style utilisateur intégrée de Firefox pour remplacer globalement les familles de polices et augmenter la taille de la police. Le vrai texte changera ; le texte image ne changera pas. Cela simule directement ce que vivent les utilisateurs avec des troubles de la lecture lorsqu’ils appliquent leurs polices préférées.

Comment corriger

Titre de bannière décorative — Incorrect

<!-- Échec : Un titre marketing est rendu en JPEG pour préserver une police personnalisée -->
<div class='hero'>
  <img src='summer-sale-heading.jpg' alt='Summer Sale — Up to 50% Off' />
</div>

Titre de bannière décorative — Correct

<!-- Correction : La même police personnalisée est fournie via @font-face et appliquée à un vrai titre.
     Le texte est désormais sélectionnable, scalable et personnalisable par l’utilisateur. -->
<style>
  @font-face {
    font-family: 'BrandDisplay';
    src: url('/fonts/brand-display.woff2') format('woff2');
    font-display: swap;
  }
  .hero-heading {
    font-family: 'BrandDisplay', sans-serif;
    font-size: clamp(2rem, 5vw, 4rem);
    color: #c0392b;
    text-shadow: 2px 2px 4px rgba(0,0,0,0.3);
  }
</style>

<div class='hero'>
  <h1 class='hero-heading'>Summer Sale — Up to 50% Off</h1>
</div>

SVG avec texte converti en contours — Incorrect

<!-- Échec : Le texte a été converti en tracés lors de l’export SVG,
     rendant les caractères inaccessibles et non scalables en tant que texte -->
<svg viewBox='0 0 400 80' xmlns='http://www.w3.org/2000/svg'>
  <!-- Des dizaines d’éléments <path> qui tracent les lettres de 'Accsible' -->
  <path d='M10 60 L20 20 L30 60 ...' fill='#003087' />
</svg>

SVG avec texte converti en contours — Correct

<!-- Correction : Le SVG utilise un véritable élément <text> avec une police web.
     Le texte est désormais indexable, sélectionnable et scalable. -->
<svg viewBox='0 0 400 80' xmlns='http://www.w3.org/2000/svg'
     role='img' aria-label='Accsible'>
  <defs>
    <style>
      .svg-label {
        font-family: 'BrandDisplay', sans-serif;
        font-size: 48px;
        fill: #003087;
      }
    </style>
  </defs>
  <text class='svg-label' x='10' y='60'>Accsible</text>
</svg>

Image d’arrière-plan CSS avec texte intégré — Incorrect

<!-- Échec : Le libellé du bouton fait partie de l’image d’arrière-plan,
     et non d’un vrai nœud de texte -->
<a href='/shop' class='cta-button'></a>

<style>
  .cta-button {
    display: block;
    width: 200px;
    height: 60px;
    background: url('shop-now-button.png') no-repeat center;
    background-size: cover;
  }
</style>

Image d’arrière-plan CSS avec texte superposé — Correct

<!-- Correction : Le bouton utilise un vrai nœud de texte stylisé avec CSS.
     L’image d’arrière-plan est purement décorative (dégradé ou texture). -->
<a href='/shop' class='cta-button'>Shop Now</a>

<style>
  .cta-button {
    display: inline-block;
    padding: 1rem 2rem;
    background: linear-gradient(135deg, #e74c3c, #c0392b);
    color: #ffffff;
    font-family: 'BrandDisplay', sans-serif;
    font-size: 1.25rem;
    font-weight: 700;
    text-decoration: none;
    border-radius: 4px;
  }
</style>

Logotype — Exception acceptable

<!-- Acceptable : Un logotype où le design spécifique des formes de lettres
     EST l’identité de la marque. Le texte alternatif transmet fidèlement le contenu textuel.
     Le CSS ne peut pas reproduire les formes de lettres dessinées à la main. -->
<a href='/' aria-label='Accsible — Home'>
  <img src='accsible-logo.svg'
       alt='Accsible'
       width='160'
       height='48' />
</a>

Erreurs courantes

• Utiliser un JPEG ou un PNG pour les titres de page parce que la maquette de design utilise une police non disponible sur Google Fonts — la correction appropriée consiste à auto-héberger la police au format WOFF2 en utilisant @font-face, et non à intégrer le titre dans une image.
• Exporter des sections hero entières comme une seule image plate à partir d’outils de design comme Figma ou Photoshop, ce qui intègre tout le texte, les boutons et les libellés dans un seul fichier matriciel. Chaque élément de texte doit être un nœud HTML distinct.
• Convertir le texte SVG en tracés lors de l’export pour éviter les dépendances de chargement de polices sur le serveur. Cela supprime l’accessibilité et la recherchabilité du texte. Utilisez plutôt des éléments <text> avec une police CSS.
• Placer du texte promotionnel ou juridique (comme des conditions générales, des tarifs ou des règles de concours) dans une image pour préserver un contrôle précis de la mise en page. Tout texte que les utilisateurs doivent lire doit être du vrai texte HTML.
• Invoquer l’exception de logotype pour chaque élément de texte de marque — l’exception s’applique uniquement au logo lui-même, et non à tout titre ou libellé composé dans la police de la marque. Un titre en Helvetica Neue n’est pas un logotype.
• Fournir un attribut alt pertinent et supposer que cela résout l’échec 1.4.5 — ce n’est pas le cas. Le texte alternatif satisfait WCAG 1.1.1 (Contenu non textuel) mais ne rend pas le texte image personnalisable par l’utilisateur, ce qui est l’exigence distincte de 1.4.5.
• Utiliser des éléments HTML5 <canvas> pour rendre du texte stylisé à des fins visuelles sans fournir d’alternative en vrai texte dans le DOM. Le texte rendu dans un canvas présente les mêmes inconvénients que le texte image.
• Intégrer du texte dans les images d’aperçu Open Graph ou de partage social et oublier que ces images apparaissent aussi sur la page (par exemple, comme image à la une dans un article de blog). Si l’image à la une est un contexte décoratif, cela peut être acceptable — mais si elle constitue le titre principal de l’article, c’est un échec.
• Ignorer les modèles de newsletters par e-mail — bien que les clients de messagerie soient hors du champ d’application WCAG pour les navigateurs, de nombreuses organisations publient leurs newsletters sous forme de pages web. Le texte dans les images d’en-tête d’e-mail intégré comme contenu web déclenche toujours 1.4.5.
• Supposer que les images haute résolution Retina résolvent le problème — une image de texte en résolution 2× ou 3× est plus nette qu’une image 1× mais enfreint toujours 1.4.5, car le texte reste non personnalisable, non reflowable et invisible pour les moteurs de recherche et les technologies d’assistance.

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 normes obligatoires d’accessibilité web et mobile pour un large éventail d’entités opérant en Turquie. La circulaire fait explicitement référence à WCAG 2.2 comme norme technique normative, et la conformité au niveau AA — qui inclut WCAG 1.4.5 — est requise pour être éligible au Erişilebilirlik Logosu (Logo d’accessibilité), délivré par le Ministère de la Famille et des Services sociaux (Aile ve Sosyal Hizmetler Bakanlığı). Ce logo sert de marque de certification officielle indiquant qu’un produit numérique répond aux exigences d’accessibilité définies dans la circulaire.

Les entités couvertes par la circulaire couvrent un large pan de l’économie numérique turque. Les institutions publiques et organismes gouvernementaux à tous les niveaux sont tenus de se conformer, tout comme les banques et institutions financières réglementées par la BDDK (Banking Regulation and Supervision Agency). Les hôpitaux et prestataires de soins de santé, publics et privés, sont concernés. Dans le secteur privé, les plateformes d’e-commerce, les opérateurs de télécommunications comptant 200,000 abonnés ou plus, les agences de voyage, les entreprises de transport privé et les écoles privées et établissements d’enseignement autorisés par le Ministry of National Education (MoNE / Milli Eğitim Bakanlığı) entrent tous dans le champ d’application de la circulaire.

Pour ces organisations, WCAG 1.4.5 a des implications directes et pratiques. De nombreux sites e-commerce et institutionnels turcs utilisent des visuels promotionnels, des bannières avec polices personnalisées et des en-têtes de campagne qui intègrent le texte sous forme d’images matricielles — une pratique courante dans les flux de travail de conception web issus d’outils de design visuel. En vertu de la Circulaire présidentielle, de telles implémentations constituent une non-conformité de niveau AA et disqualifieraient le site pour l’obtention ou le maintien de l’Erişilebilirlik Logosu. Des banques affichant des tableaux de taux d’intérêt sous forme d’images, des hôpitaux listant les noms de services dans des bannières PNG, ou des opérateurs télécoms présentant des tarifs promotionnels sous forme d’images plates seraient tous en violation de ce critère.

Les organisations souhaitant se conformer devraient auditer toutes les images de leurs propriétés web pour y détecter du contenu textuel intégré, donner la priorité à la conversion des pages à fort trafic (pages d’accueil, pages produits, pages de services) en premier, et établir un flux de travail de la conception au développement qui interdit la livraison de contenu textuel à l’intérieur de fichiers image. Investir dans une stratégie de polices web utilisant @font-face avec le format WOFF2 et des valeurs font-display appropriées permettra aux designers d’atteindre la même richesse typographique exigée par les directives de marque tout en restant pleinement conformes à WCAG 2.2 niveau AA et au mandat d’accessibilité 2025 de la Turquie.