WCAG 3.1.4 : Abréviations

Ce que signifie cette règle

Le critère de succès 3.1.4 des WCAG — Abréviations (Niveau AAA) exige que chaque fois qu’une abréviation, un acronyme ou un sigle apparaît dans un contenu web, il existe un mécanisme permettant aux utilisateurs d’en découvrir la forme développée ou la signification. Une abréviation, au sens des WCAG, est une forme raccourcie d’un mot, d’une expression ou d’un nom — cela inclut les abréviations traditionnelles (par ex. « approx. » pour « approximately »), les acronymes (par ex. « NASA » pour « National Aeronautics and Space Administration ») et les sigles (par ex. « HTML » pour « HyperText Markup Language »).

Le critère ne prescrit pas une technique unique obligatoire. Il exige plutôt qu’il existe un mécanisme permettant aux utilisateurs qui rencontrent une forme abrégée inconnue de déterminer ce qu’elle signifie. Les mécanismes acceptables incluent le développement de l’abréviation dans le texte lors de sa première utilisation (par ex. « HyperText Markup Language (HTML) »), l’utilisation de l’élément HTML <abbr> avec un attribut title qui fournit le développement, la mise à disposition d’un glossaire lié depuis la page, ou l’inclusion de la forme complète dans le contexte environnant de sorte que la signification soit sans ambiguïté.

Un succès se produit lorsque chaque abréviation dans le contenu dispose d’au moins un de ces mécanismes : la forme complète apparaît dans le texte à côté de l’abréviation ou immédiatement avant celle-ci lors de sa première utilisation ; l’élément <abbr> avec un attribut title informatif entoure l’abréviation ; un glossaire ou une liste de définitions accessible depuis la page définit le terme ; ou le contexte environnant rend la signification entièrement claire et sans ambiguïté. Un échec se produit lorsqu’une abréviation apparaît sans aucun de ces supports — l’utilisateur voit un raccourci comme « MoNE » ou « SCR » sans aucune indication de ce qu’il signifie, sans info-bulle, sans développement préalable et sans glossaire lié.

Les WCAG prévoient une exception étroite : si l’abréviation est considérée comme faisant partie de la langue elle-même — c’est-à-dire qu’elle est si largement comprise qu’elle fonctionne comme un mot autonome (par ex. « laser » ou « radar », qui étaient à l’origine des acronymes) — alors le développement n’est pas requis. De même, les abréviations qui sont définies par les termes définis du contenu lui-même et utilisées de manière cohérente dans ce contexte avec un glossaire clairement accessible sont considérées comme conformes. Le test clé est toujours de savoir si un utilisateur qui ne connaît pas l’abréviation peut en trouver la signification grâce aux mécanismes disponibles dans le contenu.

Pourquoi c’est important

Les abréviations sont omniprésentes dans le contenu web — les portails gouvernementaux, les systèmes de santé, les plateformes de commerce électronique et les sites éducatifs s’appuient tous fortement sur les formes abrégées. Bien que familières aux experts du domaine, ces formes raccourcies constituent des obstacles importants pour plusieurs groupes d’utilisateurs.

Les personnes ayant des troubles cognitifs et d’apprentissage tels que la dyslexie, des déficiences intellectuelles ou des troubles de l’attention peuvent avoir du mal à décoder des abréviations inconnues, ce qui les oblige à quitter la page pour en rechercher la signification ou à abandonner complètement. Pour les utilisateurs ayant des troubles de la mémoire, même les abréviations qu’ils ont déjà rencontrées peuvent ne pas être retenues de manière fiable d’une session à l’autre, de sorte que les mécanismes présents dans la page fournissent un soutien continu essentiel.

Les utilisateurs de lecteurs d’écran — y compris les personnes aveugles ou ayant une basse vision sévère — sont directement affectés, car les lecteurs d’écran peuvent prononcer les abréviations de manière phonétique, d’une façon déroutante ou dénuée de sens. Par exemple, un lecteur d’écran peut prononcer « SCR » comme une suite de lettres incompréhensible plutôt que « Sustainable Corporate Responsibility ». Lorsque l’élément <abbr> est correctement utilisé avec un attribut title, certaines configurations de lecteurs d’écran peuvent prononcer la forme développée plutôt que le sigle, ce qui améliore considérablement la compréhension. Selon l’Organisation mondiale de la Santé, environ 2,2 milliards de personnes dans le monde présentent une forme de déficience visuelle, dont une grande proportion dépend des technologies d’assistance pour accéder au contenu numérique.

Les locuteurs non natifs constituent un autre groupe concerné. Un utilisateur turc lisant un document technique en anglais — ou un anglophone naviguant sur un portail gouvernemental turc — peut maîtriser la langue tout en étant totalement étranger aux abréviations spécifiques à un domaine ou à une culture. Fournir les développements respecte la diversité des origines et des bases de connaissances des utilisateurs.

Considérons un scénario concret : un patient visitant le portail en ligne d’un hôpital lit son rapport de diagnostic et rencontre « KOAH » sans aucun développement. Un clinicien turc reconnaît immédiatement qu’il s’agit de « Kronik Obstrüktif Akciğer Hastalığı » (Chronic Obstructive Pulmonary Disease), mais un patient ou un aidant qui ne connaît pas la terminologie médicale reste sans compréhension de son propre diagnostic. Fournir le développement — soit en ligne lors de la première utilisation, soit via un élément <abbr title='Kronik Obstrüktif Akciğer Hastalığı'>KOAH</abbr> — transforme un terme déroutant en information compréhensible et soutient la prise de décision éclairée.

Au-delà de l’accessibilité, il existe des bénéfices mesurables en termes d’utilisabilité et de SEO. Les moteurs de recherche indexent les formes développées des abréviations, améliorant la découvrabilité du contenu pour les utilisateurs qui recherchent en utilisant les termes complets. Un langage clair et sans ambiguïté réduit également les demandes d’assistance, augmente les taux d’achèvement des tâches et renforce la confiance des utilisateurs, quel que soit leur niveau de littératie.

Règles axe-core associées

Le critère 3.1.4 des WCAG nécessite des tests manuels, car aucun outil automatisé ne peut déterminer de manière fiable si une abréviation donnée est suffisamment expliquée dans le contexte d’une page. Les analyseurs automatisés peuvent détecter la présence d’éléments <abbr> mais ne peuvent pas juger si chaque abréviation sur une page a reçu un développement accessible. Voici un résumé du contexte axe-core pertinent :

• Test manuel requis (aucune règle axe-core dédiée) : Axe-core n’inclut pas de règle automatisée spécifiquement pour le critère 3.1.4 des WCAG. Cela s’explique par le fait que déterminer quelles chaînes de texte constituent des abréviations, si elles sont suffisamment développées quelque part sur la page, et si un glossaire lié est accessible, nécessite un jugement humain et une lecture contextuelle. Un outil automatisé ne peut pas distinguer entre « IT » (Information Technology), « it » (le pronom) et « It » (un nom propre) sans une compréhension approfondie du langage naturel. Les testeurs doivent lire manuellement le contenu de la page, identifier toutes les abréviations, acronymes et sigles, puis vérifier que chacun dispose d’un mécanisme de développement accessible.
• Vérification associée — <abbr> sans title : Bien qu’il ne s’agisse pas d’une règle axe-core autonome mappée à 3.1.4, certains outils de vérification d’accessibilité et extensions de navigateur signalent les éléments <abbr> dépourvus d’attribut title comme un avertissement de bonne pratique. Si vous utilisez <abbr> comme mécanisme de développement, l’attribut title doit être présent et contenir la forme complète ; un title vide ou absent va à l’encontre de l’objectif de l’élément et constituerait un échec au regard de ce critère.

Comment tester

1. Analyse automatisée de base : Exécutez axe DevTools ou Lighthouse sur la page. Bien qu’aucun de ces outils ne dispose d’une règle dédiée pour 3.1.4, axe DevTools peut faire remonter des avis de bonnes pratiques concernant les éléments <abbr> dépourvus d’attribut title. Notez-les comme points de départ, mais gardez à l’esprit qu’ils ne détecteront pas les abréviations qui n’utilisent pas du tout la balise <abbr>.
2. Audit manuel du contenu : Lisez l’intégralité du contenu de la page — y compris les titres, le corps du texte, les tableaux, les libellés de formulaires, les libellés de boutons, les éléments de navigation et le texte du pied de page. Surlignez chaque mot ou séquence de caractères qui pourrait être une abréviation, un acronyme ou un sigle. Pour chacun, vérifiez si : (a) il a été développé plus tôt sur la même page ; (b) il est entouré d’un élément <abbr> avec un attribut title non vide ; (c) la page renvoie à un glossaire qui le définit ; ou (d) le contexte environnant rend sa signification sans ambiguïté.
3. Vérification avec lecteur d’écran NVDA + Firefox : Ouvrez la page dans Firefox avec NVDA activé. Parcourez le contenu à l’aide des touches fléchées. Lorsque NVDA rencontre un élément <abbr> avec un title, il doit annoncer le texte du titre. Vérifiez que les développements sont bien énoncés. Notez que le comportement de NVDA avec les attributs title sur les éléments <abbr> peut varier selon la version et les paramètres — testez d’abord avec la configuration par défaut de NVDA.
4. Vérification avec lecteur d’écran VoiceOver + Safari (macOS/iOS) : Activez VoiceOver et naviguez dans la page. VoiceOver sur macOS lit les attributs title sur les éléments <abbr>. Utilisez VO+A pour lire la page de manière linéaire et écoutez si les abréviations reçoivent leurs développements. Sur iOS, balayez le contenu et vérifiez le même comportement.
5. Vérification avec lecteur d’écran JAWS + Chrome : Avec JAWS activé, naviguez dans la page à l’aide des touches fléchées. JAWS gère <abbr title='...'> en annonçant le titre. Testez que le développement est correctement lu à voix haute pour chaque abréviation balisée.
6. Vérification clavier et visuelle des info-bulles de développement : Si la mise en œuvre repose sur des modèles d’info-bulles CSS ou des info-bulles pilotées par JavaScript liées aux états de survol de <abbr>, placez le focus sur l’élément à l’aide du clavier (ou focalisez-le par programmation) et vérifiez que l’info-bulle apparaît. Les WCAG exigent que le mécanisme soit accessible, et pas seulement accessible à la souris — une info-bulle qui n’apparaît qu’au survol échoue pour les utilisateurs au clavier.
7. Vérification des liens vers le glossaire : Si la page s’appuie sur un glossaire lié, suivez le lien et confirmez que chaque abréviation utilisée dans le contenu source possède une entrée correspondante avec une définition claire. Vérifiez que le lien vers le glossaire est bien visible et accessible au clavier.

Comment corriger

Abréviation non marquée lors de la première utilisation — Incorrect

<p>The WHO reported that NCDs account for 74% of all deaths globally each year.</p>

Abréviation non marquée lors de la première utilisation — Correct

<!-- Expand on first use inline, then use abbr for subsequent references -->
<p>The World Health Organization (WHO) reported that non-communicable diseases
(<abbr title='non-communicable diseases'>NCDs</abbr>) account for 74% of all
deaths globally each year.</p>

Élément abbr sans attribut title — Incorrect

<!-- abbr element present but title is missing — provides no expansion -->
<p>Submit your <abbr>VAT</abbr> registration number to proceed.</p>

Élément abbr sans attribut title — Correct

<!-- title attribute supplies the full expansion for assistive technologies -->
<p>Submit your <abbr title='Value Added Tax'>VAT</abbr> registration number to proceed.</p>

Info-bulle au survol uniquement pour une abréviation — Incorrect

<!-- CSS tooltip only appears on mouse hover; keyboard users and touch users cannot access it -->
<span class='tooltip-trigger'>KVKK
  <span class='tooltip-text'>Kişisel Verilerin Korunması Kanunu</span>
</span>

Info-bulle au survol uniquement pour une abréviation — Correct

<!-- Using abbr with title ensures the expansion is available to all users,
     including keyboard and screen reader users, without relying on hover -->
<abbr title='Kişisel Verilerin Korunması Kanunu'>KVKK</abbr>

Abréviation dans un en-tête de tableau sans développement — Incorrect

<table>
  <thead>
    <tr>
      <th>SKU</th>
      <th>MoQ</th>
      <th>ETA</th>
    </tr>
  </thead>
</table>

Abréviation dans un en-tête de tableau sans développement — Correct

<!-- abbr with title inside th provides context for all users, including screen reader users -->
<table>
  <thead>
    <tr>
      <th><abbr title='Stock Keeping Unit'>SKU</abbr></th>
      <th><abbr title='Minimum Order Quantity'>MoQ</abbr></th>
      <th><abbr title='Estimated Time of Arrival'>ETA</abbr></th>
    </tr>
  </thead>
</table>

Erreurs courantes

• Utiliser <abbr> sans attribut title : Entourer du texte avec des balises <abbr> seules ne fournit aucune valeur sémantique ni aucun développement — l’attribut title est obligatoire pour que l’élément remplisse son objectif d’accessibilité au regard de ce critère.
• Développer une abréviation uniquement après sa première utilisation : Si une abréviation apparaît avant son développement dans l’ordre de lecture (par ex. dans un titre avant le paragraphe de corps de texte qui la développe), les utilisateurs qui rencontrent d’abord le titre n’ont aucun mécanisme pour la comprendre à ce moment-là. Développez toujours lors de la première utilisation ou avant.
• Se reposer exclusivement sur des info-bulles au survol de la souris : Les info-bulles CSS ou JavaScript qui n’apparaissent qu’au moment du :hover sont inaccessibles aux utilisateurs uniquement au clavier, aux utilisateurs d’écrans tactiles et à la plupart des configurations de lecteurs d’écran. Le modèle <abbr title> est préférable, ou les info-bulles doivent également être déclenchées sur :focus.
• Fournir un glossaire lié mais rendre le lien difficile à trouver : Si votre mécanisme de développement est un glossaire, le lien doit être clairement libellé, placé de manière visible et accessible au clavier. Enfouir un lien vers le glossaire dans un pied de page en petits caractères ou derrière une section repliée peut ne pas satisfaire à l’exigence d’un mécanisme utilisable.
• Développer les abréviations de manière incohérente — seules certaines occurrences sont balisées : Si vous utilisez <abbr title> pour un acronyme dans une section mais laissez des occurrences non balisées ailleurs sur la même page, les utilisateurs qui accèdent directement à ces sections via la recherche ou les repères rencontreront des formes abrégées inexpliquées.
• Supposer que toutes les abréviations sont universellement comprises : Les abréviations spécifiques à un domaine qui semblent évidentes aux praticiens (« EBITDA » en finance, « API » en développement logiciel, « BKT » dans les contextes gouvernementaux turcs) peuvent être totalement opaques pour les utilisateurs en dehors de ces domaines, y compris les personnes utilisant des technologies d’assistance ou visitant la page pour la première fois.
• Placer le développement uniquement dans le texte alternatif des images plutôt que dans le texte : Si une abréviation apparaît dans le texte alternatif d’une image sous forme développée mais que le texte visible n’affiche que l’abréviation, le mécanisme peut ne pas être accessible à tous les utilisateurs (par ex. ceux qui utilisent les modes de lecture du navigateur). Les développements doivent être disponibles dans le texte programmatique du document lui-même.
• Utiliser des valeurs de title incorrectes ou abrégées : L’attribut title d’un élément <abbr> doit contenir le développement complet, et non une autre abréviation ou une explication partielle. Écrire title='HTML lang' au lieu de title='HyperText Markup Language' ne satisfait pas au critère.
• Ne pas tenir compte des abréviations dans le contenu dynamique : Le contenu chargé via AJAX, le défilement infini ou le routage d’applications monopage peut introduire de nouvelles abréviations après le chargement initial de la page. Tout contenu dynamique injecté dans le DOM doit également être conforme — les abréviations dans les sections rendues dynamiquement ont besoin des mêmes mécanismes de développement que le contenu statique.
• Considérer que les acronymes devenus des mots courants sont toujours exemptés : L’exception pour les abréviations qui fonctionnent comme des mots (« laser », « radar ») est étroite. Des termes comme « URL » ou « PDF » sont très largement connus dans les contextes technophiles mais peuvent rester opaques pour des personnes âgées, des personnes ayant des troubles cognitifs ou des utilisateurs issus de milieux culturels différents. En cas de doute, fournissez le développement — cela ne nuit jamais aux utilisateurs qui connaissent déjà le terme.

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 obligatoires en matière d’accessibilité numérique alignées sur les WCAG 2.2. La circulaire couvre un large éventail de types d’entités : institutions publiques et organismes gouvernementaux à tous les niveaux, plateformes de commerce électronique, banques et institutions financières, hôpitaux et prestataires de soins de santé, entreprises de télécommunication comptant 200,000 abonnés ou plus, agences de voyage agréées, entreprises de transport privées et écoles privées autorisées par le Ministry of National Education (MoNE).

La circulaire impose principalement la conformité au niveau AA des WCAG 2.2. Le critère 3.1.4 des WCAG — Abréviations — est un critère de niveau AAA et n’est donc pas une exigence légale directe dans le texte actuel de la circulaire présidentielle 2025/10. Cependant, la conformité de niveau AAA n’est pas simplement ambitieuse — elle revêt un poids pratique et réputationnel significatif dans le paysage numérique turc.

Pour les entités du secteur public, les hôpitaux et les établissements d’enseignement qui servent des populations diverses — dont beaucoup peuvent avoir une familiarité limitée avec les abréviations bureaucratiques ou médicales — la mise en œuvre du critère 3.1.4 est une question de véritable qualité de service. Le langage administratif et juridique turc est riche en sigles (« SGK » pour Sosyal Güvenlik Kurumu, « KDV » pour Katma Değer Vergisi, « ÖTV » pour Özel Tüketim Vergisi) qui sont naturels pour les fonctionnaires mais déroutants pour le grand public, en particulier les personnes âgées, les utilisateurs ruraux ou les visiteurs d’un portail pour la première fois.

Les banques, les fournisseurs de télécommunications et les plateformes de commerce électronique soumises à la circulaire renforceraient leur posture en matière d’accessibilité — et la confiance dans leur marque — en développant les abréviations utilisées dans les descriptions de produits financiers, les résumés de contrats, les tableaux de tarifs et les conditions de service. Les documents financiers en particulier sont denses en abréviations qui peuvent masquer des informations essentielles aux consommateurs qui doivent prendre des décisions éclairées.

Les organisations qui visent une déclaration formelle de conformité WCAG 2.2 AAA — que ce soit pour démontrer un leadership sur le marché, satisfaire aux exigences d’achats de partenaires internationaux ou répondre aux attentes de contrats spécialisés dans la santé publique ou l’éducation — devraient mettre en œuvre le critère 3.1.4 comme pratique standard. Le SDK d’overlay d’Accsible aide les équipes à mettre en œuvre et à auditer les modèles de développement d’abréviations, et peut être configuré pour faire remonter des recommandations pendant les flux de travail de création de contenu, aidant les organisations à maintenir la conformité à grande échelle pour le contenu mis à jour dynamiquement.