WCAG 1.4.9 : Images de texte (sans exception)

Ce que signifie cette règle

WCAG 1.4.9 — Images de texte (sans exception) est un critère de niveau AAA qui pousse les exigences de WCAG 1.4.5 (Images de texte, niveau AA) à leur conclusion logique. Là où 1.4.5 autorise les images de texte lorsque l’image est visuellement personnalisable ou lorsqu’une présentation visuelle spécifique est essentielle, 1.4.9 élimine presque toutes ces exceptions. Selon ce critère, le texte doit être rendu en utilisant du texte réel — de vrais caractères dans le DOM — plutôt que sous forme d’images matricielles ou vectorielles contenant du texte.

La seule exception autorisée par 1.4.9 concerne le texte purement décoratif (ne portant absolument aucune valeur informationnelle) ou le texte qui fait partie d’un logo ou d’un nom de marque lorsque le traitement visuel spécifique est indissociable de l’identité transmise. En pratique, cela signifie que les captures d’écran de produits contenant du texte, les bannières graphiques avec du texte promotionnel, les infographies avec des données étiquetées, les images de certificats, les cartes de citations de style réseaux sociaux et les documents numérisés affichés sur le web doivent tous être remplacés par, ou au minimum complétés par, du texte réellement rendu.

Une conformité à 1.4.9 est atteinte lorsque chaque fragment de texte significatif visible pour l’utilisateur est rendu par le moteur de texte du navigateur — que ce soit via des nœuds de texte HTML, du contenu généré par CSS lorsque c’est approprié, ou des éléments SVG <text> — afin que l’agent utilisateur puisse le reflow, le redimensionner, en changer la couleur et l’espacement. Un échec se produit chaque fois qu’une ressource non textuelle comme un <img>, un <canvas>, une image d’arrière-plan CSS, une balise SVG <image>, un PDF intégré ou toute autre ressource non textuelle est utilisée pour afficher du texte porteur de sens, que l’attribut alt soit fourni ou non. Notez qu’un attribut alt bien rédigé répond au critère 1.1.1 (Contenu non textuel) mais ne satisfait pas 1.4.9, car le texte alternatif n’est pas visuellement rendu et l’image d’origine refuse toujours aux utilisateurs voyants la possibilité d’adapter la présentation visuelle du texte.

Le critère affecte les modèles HTML courants suivants : éléments <img> dont les fichiers source contiennent du texte ; propriétés CSS background-image pointant vers des images avec du texte intégré ; éléments <canvas> sur lesquels du texte a été dessiné par programmation ; éléments SVG inline qui utilisent <image> plutôt que <text> ; et contenus intégrés tiers tels que des iframes contenant des images rendues. Même les formats techniquement scalables comme SVG sont examinés lorsque le texte est intégré sous forme de tracé ou d’image plutôt que comme nœud SVG <text>.

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é. Un sous-ensemble significatif de ces personnes — y compris les personnes avec basse vision, déficiences de la vision des couleurs, dyslexie et autres handicaps liés à l’imprimé — s’appuie sur des outils de personnalisation du texte au niveau du navigateur ou du système d’exploitation pour rendre le contenu lisible. Ces outils incluent les fonctions de zoom, la substitution de police, l’augmentation de l’espacement des lettres et des mots, les schémas de couleurs à fort contraste ou personnalisés, et les moteurs de synthèse vocale qui opèrent sur le texte rendu dans le DOM. Lorsque le texte est intégré dans une image, chacune de ces adaptations devient indisponible pour ce contenu.

Considérez une personne avec basse vision qui a configuré son navigateur pour rendre le texte dans une grande police sans empattement avec un contraste élevé jaune sur noir. Lorsqu’elle rencontre une bannière promotionnelle indiquant « Summer Sale — 50% Off » intégrée dans un JPEG, le navigateur ne peut ni recolorer ni reflow ce texte. L’image peut être agrandie avec le zoom de la page, mais elle devient rapidement pixelisée et plus difficile à lire plutôt que plus claire. Si le même message était rendu comme du vrai texte HTML stylé avec CSS, les préférences du navigateur de l’utilisateur s’appliqueraient automatiquement, et le contenu resterait net, ajustable et accessible.

Les personnes dyslexiques installent fréquemment des extensions de navigateur ou appliquent des feuilles de style personnalisées qui remplacent les polices par des polices adaptées à la dyslexie comme OpenDyslexic, et augmentent l’espacement des caractères et des mots pour réduire l’encombrement visuel. Les images de texte contournent complètement ces adaptations. Un bouton d’appel à l’action rendu comme une image plutôt que comme un élément HTML stylé est de fait invisible pour ces personnalisations, pouvant masquer des éléments interactifs critiques aux personnes qui dépendent d’un rendu personnalisé.

Les personnes avec un handicap moteur qui s’appuient sur un accès par contacteur ou un logiciel de suivi oculaire peuvent utiliser intensivement les outils de zoom pour atteindre des cibles précises. Des images de texte floues et de faible résolution à des niveaux de zoom élevés créent une difficulté de ciblage supplémentaire. Les utilisateurs de lecteurs d’écran qui ont encore un reste de vision mais utilisent tout de même un lecteur d’écran pour la compréhension peuvent également constater que les images de texte sont annoncées de manière incohérente selon que l’auteur a pensé ou non à rédiger un attribut alt complet — et même un texte alt parfait ne rétablit pas la présentation visuelle dont ils ont besoin.

Au-delà de l’accès pour les personnes handicapées, l’utilisation de vrai texte plutôt que d’images de texte apporte des avantages significatifs en SEO. Les robots d’indexation des moteurs de recherche indexent le texte du DOM bien plus fiablement qu’ils ne peuvent interpréter le contenu d’images, ce qui signifie que les titres promotionnels, les noms de produits et les libellés de catégories intégrés dans des images peuvent recevoir peu ou pas de poids dans le classement de recherche. Le vrai texte est également plus léger en taille de fichier pour la plupart des usages typographiques, améliorant les scores Core Web Vitals et réduisant la consommation de bande passante pour les utilisateurs sur des connexions de données mobiles — une préoccupation particulièrement importante sur les marchés où la pénétration d’internet mobile est élevée et où le coût des données reste un facteur.

Règles Axe-core associées

WCAG 1.4.9 nécessite des tests manuels car aucun outil automatisé ne peut déterminer de manière fiable si une image contient du texte significatif, si ce texte est purement décoratif, ou si son rendu visuel spécifique est essentiel. Les considérations suivantes s’appliquent lors de l’utilisation d’axe-core ou d’outils associés :

• Inspection manuelle requise (aucune règle axe dédiée) : axe-core n’est pas livré avec une règle qui détecte automatiquement les images de texte au titre de 1.4.9. Les outils automatisés peuvent signaler les éléments <img> dépourvus d’attribut alt (la règle image-alt) et les images d’arrière-plan susceptibles de porter du sens, mais ils ne peuvent pas analyser le contenu pixel d’une image pour déterminer si elle contient du texte, ni juger si ce texte est décoratif. Une personne testeur doit inspecter visuellement chaque image et graphique d’arrière-plan sur la page et décider s’il transmet une information textuelle qui n’est pas également disponible sous forme de vrai texte rendu dans le DOM. Il s’agit d’une limitation inhérente à l’analyse statique : une reconnaissance optique de caractères pourrait théoriquement être appliquée, mais elle produirait un nombre important de faux positifs sur des images qui contiennent fortuitement des lettres ou des traitements de logotype.
• image-alt (règle axe) : Bien qu’il ne s’agisse pas d’un test direct de 1.4.9, la règle image-alt vérifie que tous les éléments <img> ont un attribut alt non vide ou sont explicitement marqués comme décoratifs. L’exécution de cette règle aide les auditeurs à identifier les images qui nécessitent une inspection plus approfondie : toute image avec un attribut alt descriptif qui ressemble à une phrase ou contient du texte promotionnel est un signal fort que l’image elle-même peut être une image de texte et donc un candidat 1.4.9.
• Audit Lighthouse « Image elements do not have [alt] attributes » : À l’instar de image-alt, ce contrôle Lighthouse met en évidence les images qui sont totalement non décrites. Les testeurs doivent examiner manuellement les images signalées pour évaluer si elles représentent du texte.

Comment tester

1. Exécuter une analyse automatisée comme premier passage. Ouvrez axe DevTools, l’extension de navigateur Deque ou Lighthouse dans Chrome DevTools et exécutez un audit de page complet. Examinez tous les problèmes liés aux images signalés. Bien qu’aucune règle automatisée ne couvre directement 1.4.9, cette étape met en évidence tous les éléments <img> et les images d’arrière-plan CSS pour un examen manuel ultérieur. Exportez les résultats et notez chaque image qui comporte un attribut alt non vide ressemblant à une phrase ou que axe signale dans image-alt.
2. Inspecter visuellement toutes les images et graphiques d’arrière-plan. Faites défiler la page et examinez chaque image, arrière-plan CSS, élément canvas et graphique SVG. Demandez-vous : cette image contient-elle du texte ? Si oui, ce texte est-il purement décoratif (il n’ajoute aucune information et pourrait être supprimé sans perte) ? S’agit-il d’un logotype où le style de lettrage spécifique est indissociable de l’identité de la marque ? Si aucune de ces exceptions ne s’applique, l’image constitue un échec 1.4.9.
3. Désactiver les images dans le navigateur. Dans Firefox, allez à about:config et définissez permissions.default.image sur 2, ou utilisez une extension comme « Disable Images ». Rechargez la page. Toute information textuelle qui disparaît et n’est pas remplacée par du texte DOM visible (et pas seulement un attribut alt annoncé par un lecteur d’écran) représente un échec 1.4.9. Réactivez les images après le test.
4. Appliquer une feuille de style utilisateur personnalisée. Dans Firefox, placez un fichier dans le répertoire chrome/userContent.css de votre profil et ajoutez une règle telle que * { font-family: OpenDyslexic, sans-serif !important; color: yellow !important; background-color: black !important; }. Rechargez la page. Le texte rendu comme véritable HTML adoptera ces styles ; le texte intégré dans des images ne changera pas. Tout contenu textuel qui reste visuellement inchangé et illisible sous ces styles forcés constitue un échec.
5. Tester avec NVDA et Firefox. Parcourez la page en utilisant le mode navigation de NVDA. Pour chaque image, notez ce que NVDA annonce. Si NVDA lit un attribut alt qui contient un contenu textuel substantiel, comparez ce contenu à ce qui est visuellement affiché dans l’image. La présence de contenu textuel significatif dans un attribut alt est un indicateur fort que l’image contient du texte — et confirme un échec 1.4.9 même si 1.1.1 est techniquement satisfait.
6. Tester avec VoiceOver et Safari sur macOS. Utilisez VO + Flèche droite pour parcourir le contenu. Écoutez les descriptions d’images qui narrent des phrases complètes, des titres ou du texte promotionnel. Recoupez avec l’inspection visuelle pour confirmer que la source est une image plutôt que du vrai texte.
7. Zoomer à 400 %. WCAG 1.4.4 et 1.4.10 exigent que le texte reste lisible à des niveaux de zoom élevés. Les images de texte deviennent pixelisées lorsqu’elles sont agrandies avec le zoom du navigateur ; le vrai texte rendu par le moteur du navigateur reste net. À 400 % de zoom, tout texte qui apparaît flou ou pixelisé est probablement une image de texte et doit être examiné comme un échec 1.4.9.

Comment corriger

Bannière promotionnelle avec texte intégré — Incorrect

<!-- Une bannière marketing où le titre et le CTA sont intégrés dans l’image.
     Même avec un texte alt, les utilisateurs ne peuvent pas personnaliser le rendu du texte. -->
<a href='/sale'>
  <img src='/images/summer-sale-banner.jpg'
       alt='Summer Sale — Up to 50% off all products. Shop Now.'
       width='1200' height='400'>
</a>

Bannière promotionnelle avec texte intégré — Correct

<!-- La bannière utilise une véritable image d’arrière-plan pour la décoration visuelle,
     tandis que tout le texte est rendu comme du vrai HTML afin que les utilisateurs puissent le redimensionner,
     le recolorer et le reflow indépendamment. -->
<a href='/sale' class='sale-banner'>
  <!-- Image d’arrière-plan définie via CSS : .sale-banner { background-image: url(/images/summer-bg.jpg); } -->
  <h2 class='sale-banner__headline'>Summer Sale</h2>
  <p class='sale-banner__offer'>Up to 50% off all products</p>
  <span class='sale-banner__cta'>Shop Now</span>
</a>

Infographie avec points de données étiquetés — Incorrect

<!-- Une infographie où les libellés de catégories et les pourcentages sont dessinés
     dans le PNG. Les utilisateurs de lecteurs d’écran entendent le texte alt ; les utilisateurs voyants
     avec basse vision ne peuvent pas agrandir ou recolorer les libellés. -->
<img src='/images/market-share-2024.png'
     alt='Market share 2024: Product A 42%, Product B 31%, Product C 27%'
     width='800' height='600'>

Infographie avec points de données étiquetés — Correct

<!-- Un graphique SVG accessible où tous les libellés sont des nœuds SVG <text>.
     Les utilisateurs peuvent zoomer, reflow et appliquer des thèmes à fort contraste au texte.
     Un <table> adjacent fournit les mêmes données sous forme de tableau. -->
<figure>
  <svg viewBox='0 0 800 400' role='img'
       aria-labelledby='chart-title chart-desc'>
    <title id='chart-title'>Market Share 2024</title>
    <desc id='chart-desc'>Pie chart: Product A 42%, Product B 31%, Product C 27%</desc>
    <!-- chart paths -->
    <text x='200' y='150' class='chart-label'>Product A — 42%</text>
    <text x='450' y='200' class='chart-label'>Product B — 31%</text>
    <text x='350' y='320' class='chart-label'>Product C — 27%</text>
  </svg>
  <figcaption>
    <details>
      <summary>View data as table</summary>
      <table>
        <caption>Market Share 2024</caption>
        <thead><tr><th>Product</th><th>Share</th></tr></thead>
        <tbody>
          <tr><td>Product A</td><td>42%</td></tr>
          <tr><td>Product B</td><td>31%</td></tr>
          <tr><td>Product C</td><td>27%</td></tr>
        </tbody>
      </table>
    </details>
  </figcaption>
</figure>

Image d’arrière-plan CSS contenant un en-tête riche en texte — Incorrect

<!-- Le titre de la page est défini comme une image d’arrière-plan CSS plutôt que comme du vrai texte.
     Il s’agit d’un modèle de conception courant de l’ère du remplacement d’images du début des années 2000
     qui ne devrait pas apparaître dans des bases de code modernes. -->
<h1 class='logo-header'></h1>
<!-- CSS : .logo-header {
       background: url('/images/page-title-about-us.png') no-repeat;
       width: 400px; height: 80px; display: block;
       text-indent: -9999px;
     } -->

Image d’arrière-plan CSS contenant un en-tête riche en texte — Correct

<!-- Le vrai texte est rendu par le navigateur. Des polices web personnalisées reproduisent
     le style typographique souhaité sans sacrifier l’adaptabilité.
     L’image d’arrière-plan, si elle est nécessaire, n’est qu’une texture décorative. -->
<h1 class='page-title'>About Us</h1>
<!-- CSS : .page-title {
       font-family: 'BrandTypeface', serif;
       font-size: 3rem;
       color: #1a1a2e;
       letter-spacing: 0.05em;
     } -->

Erreurs courantes

• Supposer qu’un attribut alt complet satisfait 1.4.9. Fournir une alternative textuelle détaillée dans l’attribut alt répond à WCAG 1.1.1 mais ne fait rien pour 1.4.9. Ce critère concerne spécifiquement l’accessibilité de la personnalisation du rendu visuel du texte, et non les équivalents programmatiques pour les lecteurs d’écran.
• Utiliser des techniques CSS de remplacement d’images (text-indent: -9999px ou méthodes clip) sur les éléments <h1> à <h6>. Ces techniques héritées masquent visuellement le vrai texte et le remplacent par une image d’arrière-plan, ce qui signifie que les utilisateurs voyants avec basse vision ne reçoivent que l’image tandis que les utilisateurs de lecteurs d’écran ne reçoivent que le texte masqué — un décalage qui pénalise les deux populations de différentes manières.
• Exporter la typographie web en PNG ou JPEG parce qu’une police personnalisée n’est pas disponible comme police web. Si une police sous licence ne peut pas légalement être servie comme police web, la solution correcte est de négocier des droits de police web ou de choisir une autre police, et non de rasteriser le texte dans des images.
• Considérer les fichiers SVG comme intrinsèquement accessibles. Un SVG qui intègre du texte sous forme d’éléments <path> (sortie courante des outils de conception graphique comme l’option « vectoriser le texte » d’Illustrator) est tout aussi inaccessible qu’un PNG. Le SVG doit utiliser des éléments <text> pour satisfaire 1.4.9.
• Intégrer du texte dans des éléments <canvas> sans solution de repli en vrai texte. Le contenu canvas est rasterisé au niveau du pixel. Tout texte dessiné via ctx.fillText() ne fait pas partie du DOM et ne peut pas être adapté par les agents utilisateurs. Une superposition ou une alternative en vrai texte est nécessaire.
• Laisser des images de documents numérisés (PDF rendus comme images) sans calques de vrai texte basés sur l’OCR. Les documents numérisés présentés dans des balises <img> ou comme PDF uniquement image échouent à 1.4.9. Il est nécessaire d’exécuter une OCR et d’intégrer un calque de texte sélectionnable, ou de convertir le document en HTML correctement balisé.
• Utiliser des images de texte pour des données dynamiques telles que les prix, les quantités de stock ou le contenu généré par les utilisateurs. Chaque fois qu’un serveur génère une image contenant des données textuelles, ces données sont verrouillées dans le format image. Les prix dans les listes de produits, la disponibilité des places sur les plateformes de réservation et les scores sportifs en direct doivent être rendus comme du vrai texte afin que les utilisateurs puissent les redimensionner et les recolorer.
• Ignorer les images de signatures d’e-mails. Les équipes marketing créent souvent des blocs de signature sous forme d’images pour préserver l’identité visuelle. Lorsque ces e-mails sont archivés et liés depuis des sites web, les images de signature deviennent du contenu web soumis à 1.4.9.
• Ignorer le contenu des widgets tiers. Les widgets de chat, les badges de preuve sociale et les carrousels d’avis fournis par des prestataires tiers peuvent injecter des images de texte dans la page. Les propriétaires de sites restent responsables de l’accessibilité de tout le contenu sur leurs pages ; si un prestataire ne peut pas fournir un rendu basé sur du texte, un autre prestataire doit être recherché.
• Confondre les exceptions pour les logotypes avec des exceptions générales de marque. L’exception de logotype couvre uniquement le logo ou le mot-symbole lui-même — le nom de marque stylisé. Elle ne s’étend pas aux slogans, aux libellés de navigation ou à tout autre texte qui apparaît à côté du logo dans la même image.

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 obligations d’accessibilité web obligatoires pour un large éventail d’organisations opérant en Turquie. La circulaire exige que les entités concernées se conforment au minimum à WCAG 2.1 niveau AA. Les entités explicitement couvertes incluent les institutions publiques et organismes gouvernementaux, les plateformes de commerce électronique, les banques et institutions financières, les hôpitaux et prestataires de soins de santé privés, les entreprises 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 autorisées par le ministère de l’Éducation nationale.

WCAG 1.4.9 est un critère de niveau AAA et se situe donc au-dessus du minimum obligatoire établi par la circulaire présidentielle 2025/10. Les entités concernées ne sont pas légalement tenues de se conformer à 1.4.9 pour satisfaire aux obligations de base de la circulaire. Cependant, atteindre le niveau AAA sur les critères applicables démontre un engagement exemplaire en matière d’inclusion et élargit considérablement le public qui peut utiliser efficacement le service.

Plusieurs secteurs couverts par la circulaire ont des incitations particulièrement fortes à poursuivre volontairement la conformité à 1.4.9. Les plateformes de commerce électronique utilisent fréquemment des bannières promotionnelles, des visuels de soldes et des en-têtes de catégories de produits rendus sous forme d’images — autant de modèles d’échec 1.4.9 courants. Pour les personnes avec basse vision ou dyslexie qui s’appuient sur la personnalisation du texte pour prendre des décisions d’achat, ces échecs se traduisent directement par des conversions perdues et une exposition juridique potentielle au regard des cadres plus larges de protection des consommateurs et de lutte contre la discrimination en Turquie. Les banques et institutions financières présentent de la même manière des taux de prêt, des résumés de comptes et des grilles tarifaires ; si une partie de ces informations est intégrée dans des images, les clients avec basse vision ne peuvent pas adapter la présentation pour les lire en toute confiance, ce qui soulève des préoccupations à la fois au titre de la circulaire et des règles de protection des consommateurs de services financiers. Les hôpitaux et prestataires de soins de santé qui affichent des instructions de dosage, des détails de rendez-vous ou des informations patient sous forme d’images créent des risques pour la sécurité des patients pour les personnes qui ne peuvent pas adapter le rendu du texte.

Les organisations qui cherchent à pérenniser leurs propriétés numériques face à l’évolution réglementaire — ou celles qui poursuivent des contrats de marchés publics nécessitant une démonstration de leadership en matière d’accessibilité — ont tout intérêt à auditer et corriger les échecs 1.4.9 dans le cadre d’un programme d’accessibilité complet. Le SDK d’overlay d’Accsible peut aider à l’adaptation du texte à l’exécution pour certains scénarios hérités d’images de texte, mais une correction permanente au niveau du code — en remplaçant les images de texte par du vrai texte HTML stylé via CSS et des polices web — reste la solution la plus robuste et durable pour une conformité à long terme.