WCAG 1.1.1 : Contenu non textuel

Ce que signifie cette règle

Le critère de succès WCAG 1.1.1 Contenu non textuel est une exigence de niveau A relevant du principe « Perceptible ». Il stipule que tout contenu non textuel présenté à l’utilisateur doit disposer d’une alternative textuelle qui en remplisse un rôle équivalent. Le « contenu non textuel » est défini de manière large : il englobe les images matricielles (JPEG, PNG, GIF, WebP), les graphiques vectoriels (SVG), les boutons et champs de formulaire basés sur des images, les images réactives (image maps), les éléments canvas, les extraits audio, la vidéo, les animations, les CAPTCHAs et les ornements décoratifs.

Une alternative textuelle peut prendre plusieurs formes selon le type d’élément : un attribut alt sur un élément <img>, un aria-label ou aria-labelledby sur un SVG ou un élément porteur de rôle, un élément title à l’intérieur d’un <object>, ou un <figcaption> associé à une figure. L’exigence clé est que le texte de remplacement communique la même information ou la même fonction que le contenu visuel lui‑même — il ne s’agit pas simplement d’un nom de fichier ou d’un texte générique.

Le critère définit plusieurs cas spécifiques qui déterminent à quoi ressemble une alternative textuelle adéquate :

• Commandes et champs de saisie : Si le contenu non textuel est une commande ou accepte une saisie utilisateur (comme un bouton image ou une image utilisée comme lien), l’alternative textuelle doit décrire son objectif ou sa fonction, et non seulement son apparence.
• Médias temporels : Le contenu audio seul ou vidéo seule utilisé comme présentation autonome nécessite au minimum une étiquette descriptive l’identifiant ; les transcriptions complètes et les sous-titres sont traités par des critères ultérieurs (1.2.x).
• Tests et expériences sensorielles : Si le contenu est un test ou un exercice qui ne peut pas être présenté sous forme textuelle sans en annuler la finalité (comme une énigme visuelle), l’alternative textuelle doit seulement identifier et décrire le contenu non textuel.
• CAPTCHAs : Les alternatives textuelles doivent décrire la finalité du CAPTCHA, et une forme alternative de CAPTCHA utilisant une modalité sensorielle différente doit être fournie.
• Décoration, mise en forme et contenu invisible : Si une image est purement décorative, utilisée pour l’espacement ou n’est pas présentée aux utilisateurs, elle doit être implémentée de manière à pouvoir être ignorée par les technologies d’assistance — généralement via un attribut alt="" vide ou role="presentation".

Un succès est atteint lorsque chaque élément non textuel significatif expose soit une alternative textuelle programmatique qui transmet de manière équivalente sa finalité, soit est explicitement marqué comme décoratif afin que les technologies d’assistance puissent l’ignorer. Un échec se produit lorsqu’une image n’a pas d’attribut alt du tout, lorsque la valeur de alt est le nom de fichier (par exemple alt="img_header_logo_v2.png"), lorsqu’un SVG utilisé comme contenu significatif n’a ni élément <title> ni étiquette accessible, ou lorsqu’une image décorative possède à tort un texte alternatif descriptif qui ajoute du bruit pour les utilisateurs de lecteurs d’écran.

Pourquoi c’est important

Selon l’Organisation mondiale de la santé, environ 2,2 milliards de personnes dans le monde présentent une forme de déficience visuelle ou de cécité. Les utilisateurs de lecteurs d’écran — qui s’appuient sur la synthèse vocale ou des afficheurs braille rafraîchissables pour consommer le contenu numérique — dépendent entièrement des alternatives textuelles pour comprendre les images, icônes, graphiques et contrôles graphiques. Sans texte alternatif précis, une page produit sur un site de commerce électronique se réduit à une liste de prix sans contexte visuel ; la navigation d’une banque, chargée de logos, devient une rangée de boutons sans étiquette ; le schéma d’auto‑diagnostic des symptômes d’un hôpital est invisible pour l’utilisateur qui tente de s’auto‑évaluer.

Considérons un scénario concret : une personne aveugle visite une plateforme de commerce électronique turque pour acheter une veste. Le carrousel de produits contient six images montrant différents angles et variantes de couleur de la veste. Si aucune de ces images n’a de texte alternatif significatif, le lecteur d’écran de l’utilisateur annonce seulement « image, image, image » — six fois. Il ne peut pas déterminer quelle variante est bleu marine ou noire, ne peut pas comprendre quelle image montre la poche arrière, et peut abandonner l’achat entièrement. Un collègue voyant, avec le même lien produit, finalise l’achat en moins de deux minutes. Cet écart constitue à la fois un échec en matière d’accessibilité et une perte commerciale.

Au‑delà de la cécité, ce critère bénéficie également aux personnes ayant des troubles cognitifs qui s’appuient sur des outils de synthèse vocale pour compléter la lecture, aux personnes ayant des limitations motrices qui naviguent au clavier et à la voix et ont besoin d’étiquettes claires sur les commandes interactives, ainsi qu’aux utilisateurs à faible bande passante pour lesquels les images peuvent ne pas se charger — dans ces cas, le texte alternatif sert de solution de repli fonctionnelle. De plus, un texte alternatif bien rédigé améliore l’indexation par les moteurs de recherche, car les robots considèrent les attributs alt des images comme des signaux textuels pertinents, soutenant directement les résultats SEO.

Règles Axe-core associées

Le moteur d’accessibilité axe-core applique le WCAG 1.1.1 au moyen de sept règles automatisées distinctes. Comprendre ce que chaque règle vérifie — et où se situent ses limites — est essentiel pour une stratégie de test complète.

• image-alt : Vérifie que chaque élément <img> possède un attribut alt (qui peut être vide pour les images décoratives) ou un nom accessible fourni via aria-label, aria-labelledby ou title. Elle signale les images qui n’ont aucun attribut alt, car le navigateur expose alors le chemin du fichier comme nom accessible.
• input-image-alt : Vérifie que les éléments <input type="image"> possèdent un attribut alt non vide. Les champs image agissent comme des boutons de soumission et doivent transmettre leur fonction, pas seulement leur apparence visuelle. Un alt manquant ou vide sur un champ image rend le bouton pratiquement inutilisable avec un lecteur d’écran.
• area-alt : Vérifie que chaque élément <area> au sein d’une image réactive possède une alternative textuelle non vide via alt, aria-label ou aria-labelledby. Les image maps sont un modèle hérité encore utilisé dans certaines applications d’entreprise et portails du secteur public, et chaque zone cliquable doit décrire de manière indépendante sa destination de lien ou sa fonction.
• object-alt : Vérifie que les éléments <object> possèdent un nom accessible. L’élément <object> est historiquement utilisé pour intégrer du contenu Flash, des PDF ou d’autres médias ; sans étiquette, les lecteurs d’écran n’ont aucun moyen d’identifier le contenu intégré.
• svg-img-alt : Vérifie que les éléments <svg> en ligne avec role="img" possèdent un nom accessible, généralement fourni par un élément enfant <title> (avec un aria-labelledby correspondant) ou un attribut aria-label sur la racine SVG. Les interfaces modernes utilisent largement les SVG pour les icônes et illustrations ; cette règle détecte les SVG non étiquetés qui portent du sens.
• role-img-alt : Vérifie que tout élément avec role="img" — qui peut être appliqué à des éléments non SVG tels que <div> ou <span> utilisés comme conteneurs d’images — possède un nom accessible. Ce modèle est courant dans les systèmes d’icônes personnalisés et les implémentations d’images de fond CSS où aucun élément image natif n’est utilisé.
• image-redundant-alt : Signale les situations où le texte alternatif d’une image duplique un texte visible adjacent, généralement lorsqu’une image apparaît à l’intérieur d’une ancre aux côtés d’une étiquette textuelle. Bien qu’il ne s’agisse pas d’un échec strict, un texte alternatif redondant amène les lecteurs d’écran à annoncer deux fois la même information, dégradant l’expérience d’écoute. Cette règle nécessite un jugement humain pour être résolue correctement, car seule une personne peut déterminer si la duplication est réellement redondante ou intentionnellement additive.

Il est important de noter que les outils automatisés, y compris axe-core, ne peuvent pas évaluer la qualité du texte alternatif — seulement sa présence et sa structure de base. Une règle peut être satisfaite pour une image avec alt="photo" ou alt="decorative border" même si aucun de ces textes n’est significatif. Un examen manuel est donc toujours nécessaire en complément de l’analyse automatisée pour confirmer que le texte alternatif décrit avec précision le contenu et la finalité de chaque image.

Comment tester

1. Analyse automatisée avec axe DevTools ou Lighthouse : Installez l’extension de navigateur axe DevTools (disponible pour Chrome et Firefox). Ouvrez la page à tester, activez l’extension et lancez une analyse de page complète. Filtrez les résultats par les identifiants de règles listés ci‑dessus : image-alt, input-image-alt, area-alt, object-alt, svg-img-alt, role-img-alt et image-redundant-alt. Pour chaque élément signalé, l’outil met en évidence le nœud incriminé dans le DOM et explique la violation. Lighthouse (intégré dans Chrome DevTools sous l’audit Accessibilité) met également en avant les violations image-alt avec un niveau de détail par élément. Enregistrez toutes les violations avec leurs sélecteurs d’élément et le contexte environnant pour la transmission aux développeurs.
2. Inspection manuelle du DOM : Ouvrez l’onglet Elements des DevTools du navigateur et recherchez tous les tags <img>, <input type="image">, <area>, <object> et <svg>. Pour chacun, vérifiez qu’un attribut alt approprié ou une étiquette ARIA est présent et que sa valeur est significative dans le contexte. Portez une attention particulière aux images chargées dynamiquement via des frameworks JavaScript tels que React ou Vue, qui peuvent ne pas apparaître dans un instantané HTML statique.
3. Tests avec lecteur d’écran NVDA et Firefox : Lancez NVDA (gratuit, Windows) et ouvrez la page dans Firefox. Naviguez en utilisant la touche G pour passer d’un graphique à l’autre. NVDA annonce le nom accessible de chaque image ; écoutez les annonces de chemins de fichiers, « image » ou les annonces vides — qui indiquent toutes un échec. Pour les boutons image et les liens, utilisez la touche Tab pour atteindre chaque commande et vérifiez que l’étiquette prononcée décrit l’action effectuée par la commande.
4. Tests avec lecteur d’écran VoiceOver et Safari (macOS/iOS) : Activez VoiceOver (Commande+F5 sur macOS). Utilisez VO+Flèche droite pour parcourir le contenu élément par élément, ou ouvrez le sélecteur d’éléments (VO+U) et sélectionnez Images dans le rotor pour voir la liste de toutes les images et de leurs étiquettes en une fois. Sur iOS, faites glisser le doigt vers la droite à travers la page et écoutez comment chaque image est annoncée.
5. Tests avec lecteur d’écran JAWS et Chrome : Dans JAWS, appuyez sur G pour naviguer par graphique. Chaque image doit produire une description claire et significative. Utilisez la visionneuse virtuelle de JAWS (Insert+F1) pour voir le nom accessible calculé et le rôle de tout élément en question.
6. Vérifier le traitement des images décoratives : Pour les images que vous considérez comme décoratives, confirmez qu’elles ont alt="" et aucun attribut title ni étiquette ARIA qui les réexposerait. Avec un lecteur d’écran, naviguez jusqu’à ces éléments et confirmez qu’ils sont entièrement ignorés dans l’ordre de lecture.

Comment corriger

Image informative sans alt — Incorrect

<!-- Image transmettant des informations produit mais sans attribut alt -->
<img src='jacket-navy-front.jpg'>

Image informative sans alt — Correct

<!-- le texte alt décrit le contenu visuel et sa finalité dans le contexte -->
<img src='jacket-navy-front.jpg' alt='Veste en laine bleu marine, vue de face, avec boutons croisés'>

Image décorative mal étiquetée — Incorrect

<!-- L’image de séparateur décoratif expose un alt descriptif qui ajoute du bruit -->
<img src='divider-ornament.png' alt='Séparateur ornemental décoratif avec motif en volutes'>

Image décorative correctement masquée aux technologies d’assistance — Correct

<!-- Un alt vide indique aux lecteurs d’écran d’ignorer complètement cette image -->
<img src='divider-ornament.png' alt=''>

Icône SVG sans nom accessible — Incorrect

<!-- SVG utilisé comme icône significative avec role="img" mais sans étiquette -->
<svg role='img' xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'>
  <path d='M12 2C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2z'/>
</svg>

Icône SVG avec nom accessible — Correct

<!-- l’élément title fournit le nom accessible ; aria-labelledby l’y associe -->
<svg role='img' aria-labelledby='icon-account-title' xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'>
  <title id='icon-account-title'>Mon compte</title>
  <path d='M12 2C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2z'/>
</svg>

Bouton input image sans alt — Incorrect

<!-- Le bouton de soumission image n’a pas d’attribut alt ; le lecteur d’écran annonce seulement "image" -->
<input type='image' src='btn-search.png'>

Bouton input image avec alt descriptif — Correct

<!-- le alt décrit la fonction du bouton, pas son apparence -->
<input type='image' src='btn-search.png' alt='Rechercher'>

Erreurs courantes

• Utiliser le nom de fichier comme texte alt : Écrire alt="hero_banner_v3_final.jpg" expose le chemin du fichier aux lecteurs d’écran sans contenu significatif. Rédigez toujours un texte alternatif qui décrit ce que l’image montre ou la finalité qu’elle sert.
• Définir le texte alt sur "image" ou "photo" : Des valeurs génériques telles que alt="image" ou alt="photo" passent les vérifications automatisées parce qu’elles ne sont pas vides, mais elles ne transmettent aucune information. Les lecteurs d’écran annoncent déjà le rôle de l’élément comme « image », donc répéter ce mot fait perdre du temps à l’utilisateur.
• Oublier le alt sur les images injectées dynamiquement : Les images insérées dans le DOM via JavaScript (par exemple, un carrousel de produits construit avec React) peuvent ne pas avoir d’attributs alt dans le HTML initial. Assurez-vous que le composant JavaScript rend l’attribut alt en même temps qu’il rend le src.
• Appliquer role="presentation" à des images significatives : Utiliser role="presentation" ou role="none" sur des images qui portent du contenu les retire entièrement de l’arbre d’accessibilité. Ceci n’est approprié que pour les images purement décoratives ; l’utiliser sur des images informatives entraîne une perte totale de contenu pour les utilisateurs de lecteurs d’écran.
• Omettre l’attribut alt sur les images de fond CSS utilisant role="img" : Lorsqu’un <div> est stylé avec une image de fond et reçoit role="img", les développeurs oublient parfois d’ajouter aria-label. Sans étiquette, l’élément figure dans l’arbre d’accessibilité comme une image sans nom — ce qui est tout aussi problématique qu’un alt manquant.
• Rédiger un texte alt qui décrit l’apparence plutôt que le sens : Pour un graphique, écrire alt="Un histogramme bleu" décrit le style visuel mais pas les données. Le texte alternatif doit transmettre l’idée clé, par exemple alt="Histogramme montrant une croissance de 18% du chiffre d’affaires du T3 d’une année sur l’autre".
• Texte alt dupliqué sur plusieurs images d’un ensemble : Lorsqu’une fiche produit affiche six vignettes du même article, attribuer à toutes le même texte alt (par exemple alt="Chaussure de course") ne permet pas de les distinguer. Chaque image d’un ensemble doit décrire son contenu ou son angle unique.
• Omission de alt sur les éléments <area> dans les image maps : Les développeurs qui utilisent des image maps ajoutent souvent un texte alt à l’élément parent <img> mais oublient que chaque zone <area> nécessite également son propre attribut alt décrivant cette destination de lien spécifique.
• Utiliser le texte d’infobulle comme substitut au texte alt : L’attribut title produit une infobulle visuelle et est lu par certains lecteurs d’écran, mais la prise en charge par les navigateurs est incohérente et il n’est pas exposé dans tous les contextes d’accessibilité. Il doit compléter, et non remplacer, un attribut alt approprié.
• Ne pas tester les icônes SVG livrées via des sprites ou des éléments <use> : Les sprites SVG référencés via <use href="#icon-id"> peuvent ne pas exposer leur <title> interne à tous les lecteurs d’écran en raison des limites liées au shadow DOM. Testez toujours les icônes basées sur des sprites avec de vrais lecteurs d’écran et complétez avec aria-label sur l’élément <svg> externe si nécessaire.

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é numérique pour un large éventail d’entités publiques et privées opérant en Turquie. La circulaire fait référence au WCAG 2.2 comme norme technique, rendant tous les critères de succès de niveau A — y compris le WCAG 1.1.1 Contenu non textuel — juridiquement contraignants plutôt que de simples recommandations de bonnes pratiques.

Les entités concernées comprennent : toutes les institutions publiques et organismes gouvernementaux, les banques et institutions financières, les hôpitaux et prestataires de soins de santé, les entreprises de télécommunications comptant 200,000 abonnés ou plus, les plateformes de commerce électronique, les agences de voyage, les entreprises de transport privé et les écoles privées autorisées par le ministère de l’Éducation nationale (MoNE). Pour les institutions publiques, la conformité doit être atteinte dans l’année suivant la date d’entrée en vigueur de la circulaire. Les entités du secteur privé disposent d’un délai de mise en œuvre de deux ans.

Le WCAG 1.1.1 est particulièrement pertinent dans le paysage numérique turc, car de nombreux secteurs à fort trafic couverts par la circulaire — y compris les places de marché de commerce électronique, les portails bancaires et les plateformes de services gouvernementaux — sont fortement dépendants des images. Les photographies de produits sur les sites de commerce électronique, les annonces publiques sous forme d’infographies sur les portails gouvernementaux, les tableaux de bord financiers riches en graphiques dans les applications bancaires et les interfaces basées sur des formulaires dans les portails patients des hôpitaux entrent tous pleinement dans le champ de ce critère.

Le non‑respect des exigences de niveau A au titre de la circulaire expose les entités concernées à un contrôle réglementaire et à d’éventuelles sanctions. Étant donné que le WCAG 1.1.1 est l’un des critères les plus fréquemment violés et les plus faciles à tester — détectable à la fois par des outils automatisés et par de simples parcours avec lecteur d’écran — il est susceptible de figurer en bonne place dans les audits de conformité. Les organisations soumises à la circulaire doivent traiter la correction de toutes les violations liées aux textes alt des images comme une action immédiate et hautement prioritaire, et non comme une amélioration différée. Le déploiement d’un SDK de surcouche d’accessibilité tel qu’Accsible peut aider à mettre en évidence et à corriger partiellement en temps réel les alternatives textuelles manquantes, mais une correction complète au niveau du code source reste la voie la plus robuste et la plus durable vers la conformité.