WCAG 3.1.3 : Mots inhabituels

Ce que signifie cette règle

WCAG 3.1.3 — Mots inhabituels est un critère de succès de niveau AAA relevant du principe Compréhensible. Il exige que tout contenu web utilisant des mots ou expressions dans un sens inhabituel, spécialisé ou restreint fournisse un mécanisme permettant aux utilisateurs de consulter ou d’accéder aux définitions de ces termes. Cela s’applique à trois catégories d’usage de la langue : le jargon (vocabulaire spécialisé propre à un métier, une profession ou un domaine), les idiomes (expressions dont le sens ne peut pas être déduit du sens littéral des mots, comme « break a leg » ou « hit the ground running »), et les mots utilisés dans un sens restreint ou inhabituel (mots courants auxquels on attribue un sens spécialisé ou non standard dans un contexte particulier).

Le critère n’impose pas une seule approche de mise en œuvre. Les mécanismes acceptables incluent des définitions en ligne, un glossaire lié depuis la page, des info-bulles ou des définitions extensibles déclenchées par l’interaction de l’utilisateur, des définitions fournies dans le texte environnant, ou l’utilisation de l’élément HTML <dfn> associé à un contexte accessible. L’exigence clé est que le mécanisme de définition doit être disponible — les utilisateurs doivent pouvoir y accéder sans effort excessif.

Un succès est atteint lorsque chaque occurrence de jargon, d’idiome ou de mot utilisé de manière inhabituelle sur la page est accompagnée d’un mécanisme de définition accessible. Un échec se produit lorsque des termes spécialisés ou ambigus apparaissent sans aucun mécanisme de ce type — par exemple, un site juridique qui utilise des termes comme « tortfeasor » ou « subrogation » sans glossaire ni explication en ligne.

WCAG définit une exception limitée : si un mot est utilisé de manière inhabituelle uniquement dans un passage spécifique, il suffit de fournir la définition pour ce passage plutôt que globalement sur l’ensemble du site. De plus, les noms propres (noms de personnes, de lieux ou d’organisations) ne sont généralement pas soumis à ce critère, sauf s’ils servent également de termes techniques dans le contexte.

Pourquoi c’est important

Les obstacles à la compréhension de la langue affectent un éventail remarquablement large d’utilisateurs. Les personnes ayant des handicaps cognitifs — y compris la dyslexie, les déficiences intellectuelles et les lésions cérébrales acquises — peuvent avoir du mal à déduire le sens à partir du contexte lorsque des termes inconnus apparaissent. Selon l’Organisation mondiale de la Santé, environ 1 personne sur 6 dans le monde vit avec une forme de handicap, et les déficiences cognitives représentent l’une des plus grandes catégories. Pour ces utilisateurs, rencontrer un jargon non défini peut rendre une page par ailleurs accessible totalement inutilisable.

Les locuteurs non natifs représentent un autre groupe majeur affecté par ce critère. Rien qu’en Turquie, la population comprend des millions de personnes dont la langue maternelle est le kurde, l’arabe ou une autre langue régionale, et qui lisent le turc comme langue seconde. Lorsqu’un portail de santé du gouvernement turc utilise une terminologie médicale comme « anjiyoplasti » ou « antikoagülan » sans explication, ces utilisateurs — et même de nombreux locuteurs natifs du turc — peuvent être incapables de comprendre des informations de santé critiques.

Les utilisateurs de lecteurs d’écran sont également affectés de manière subtile mais significative. Lorsqu’un terme est défini via une info-bulle visible ou un glossaire, les utilisateurs voyants peuvent le repérer rapidement. Cependant, si ce mécanisme n’est pas accessible au clavier et déterminable de manière programmatique, les utilisateurs aveugles qui s’appuient sur des technologies d’assistance peuvent ne jamais atteindre la définition. Fournir des définitions en ligne bien structurées ou un glossaire correctement lié garantit une égalité d’accès.

Considérons un scénario concret : une plateforme de e-commerce turque vend des produits financiers et utilise le terme « faiz oranı bileşimi » (intérêt composé) sans explication. Un utilisateur ayant une déficience intellectuelle, ou une personne âgée peu familière avec la finance, qui tente de comparer des produits de prêt peut prendre une décision financièrement préjudiciable simplement parce que la terminologie n’a jamais été clarifiée. Fournir un glossaire lié ou une info-bulle accessible avec une définition en langage simple réduit directement ce risque.

Au-delà de l’accessibilité, ce critère présente des avantages mesurables en termes d’utilisabilité et de SEO. Les pages de glossaire indexées par les moteurs de recherche augmentent l’autorité thématique et peuvent capter le trafic de recherche de longue traîne. Des définitions claires réduisent également la charge du support client, améliorent les taux de conversion et contribuent à la qualité globale du contenu — autant de résultats pertinents pour les opérateurs commerciaux.

Règles Axe-core associées

WCAG 3.1.3 appartient à la catégorie des critères qui nécessitent un test manuel. Il n’existe aucune règle axe-core automatisée capable de détecter si des mots inhabituels sont définis, car cela exigerait que l’outil comprenne le sens sémantique et le contexte de domaine de chaque mot sur une page — une tâche qui dépasse les capacités actuelles d’analyse automatisée.

• Évaluation manuelle requise — Mots inhabituels : Les analyseurs d’accessibilité automatisés tels qu’axe-core, Lighthouse et IBM Equal Access Checker ne peuvent pas identifier quels mots relèvent du jargon, des idiomes ou de termes utilisés de manière inhabituelle, car cette détermination dépend de la connaissance du domaine, du contexte du public et de l’interprétation linguistique. Un analyseur ne peut pas savoir que « token » signifie un justificatif de sécurité dans un contexte et un bon dans un autre, ou que « cloud » fait référence à une infrastructure de calcul distribuée plutôt qu’à la vapeur d’eau atmosphérique. Des évaluateurs humains — idéalement incluant des membres du public cible — doivent lire le contenu et évaluer si une terminologie nécessite une définition. L’évaluateur doit ensuite vérifier qu’un mécanisme de définition accessible existe pour chaque terme signalé.
• Vérifications automatisées complémentaires : Bien qu’axe-core ne puisse pas évaluer directement ce critère, les auditeurs peuvent utiliser des outils automatisés pour vérifier que les mécanismes de définition utilisés (tels que les éléments <dfn>, les info-bulles ou les glossaires liés) sont eux-mêmes accessibles. Par exemple, les règles axe-core couvrant l’objectif du lien (link-name), l’accessibilité au clavier (tabindex) et l’utilisation d’ARIA (aria-allowed-attr) peuvent confirmer qu’un lien de glossaire ou un composant d’info-bulle est correctement implémenté — même si l’outil ne peut pas juger de l’exhaustivité du glossaire.

Comment tester

1. Pré-analyse automatisée : Exécutez axe DevTools ou Lighthouse sur la page pour confirmer qu’il n’y a pas d’échecs d’accessibilité de base susceptibles d’interférer avec les tests (liens cassés, indicateurs de focus manquants, etc.). Notez tout composant interactif de définition (info-bulles, termes extensibles) signalé pour des problèmes ARIA ou de clavier. Ces échecs secondaires peuvent empêcher les utilisateurs d’atteindre les définitions même lorsqu’elles existent.
2. Audit de contenu — identifier les termes inhabituels : Lisez attentivement le contenu de la page. Signalez chaque occurrence de jargon, de terminologie technique, d’idiome ou de mot utilisé dans un sens non standard. Il est utile d’imaginer que vous expliquez la page à un utilisateur sans aucune connaissance préalable du sujet. Créez une liste des termes signalés avant de vérifier l’existence de définitions.
3. Vérifier les mécanismes de définition : Pour chaque terme signalé, confirmez qu’un mécanisme de définition existe et est accessible. Recherchez : des définitions en ligne dans le texte environnant, un élément <dfn> visible avec un <abbr title> associé ou une description liée, une page de glossaire liée depuis le contenu, ou des info-bulles/définitions extensibles. Si le mécanisme est une info-bulle ou un composant extensible, passez à l’étape 4.
4. Test de navigation au clavier : En utilisant uniquement le clavier (Tab, Entrée, Espace, touches fléchées), tentez d’atteindre et d’activer chaque mécanisme de définition sur la page. Vérifiez que les info-bulles ou définitions extensibles peuvent être déclenchées sans souris. Dans Firefox avec NVDA, naviguez jusqu’aux termes définis et confirmez que la définition est annoncée. Dans Safari avec VoiceOver sur macOS, utilisez VO+Droite pour parcourir le contenu et vérifiez que le contexte de la définition est disponible. Dans Chrome avec JAWS, testez que les entrées de glossaire liées reçoivent le focus et que l’objectif du lien est clair.
5. Test de l’ordre de lecture avec lecteur d’écran : Avec NVDA dans Firefox, activez le mode Parcourir et lisez la page de manière linéaire. Confirmez que lorsqu’un terme de jargon apparaît, soit la définition est lue en ligne, soit le lien/bouton vers la définition est immédiatement adjacent et clairement étiqueté. Assurez-vous que l’utilisateur n’est pas obligé de quitter la page et de perdre le contexte pour accéder à une définition.
6. Vérification de l’exhaustivité du glossaire : Si le site utilise un glossaire centralisé, recoupez la liste des termes inhabituels signalés avec les entrées du glossaire. Confirmez que chaque terme signalé possède une entrée correspondante. Vérifiez que la page de glossaire elle-même est accessible (structure de titres correcte, navigation au clavier, lisible par les lecteurs d’écran).

Comment corriger

Jargon technique sans définition — Incorrect

<p>
  The system uses OAuth2 for authorization, issuing a JWT
  that expires after 3600 seconds. Refresh tokens are stored
  in an HttpOnly cookie to mitigate XSS vectors.
</p>

Jargon technique avec définitions en ligne — Correct

<!-- Using dfn elements with title attributes and a linked glossary -->
<p>
  The system uses
  <dfn><abbr title='OAuth 2.0: An open authorization protocol that allows
  third-party applications to access user data without exposing
  credentials.'>OAuth2</abbr></dfn>
  for authorization, issuing a
  <dfn><abbr title='JWT (JSON Web Token): A compact, URL-safe token
  format used to transmit claims between parties.'>JWT</abbr></dfn>
  that expires after 3600 seconds. See our
  <a href='/glossary#security-terms'>Security Glossary</a>
  for full definitions.
</p>

Langage idiomatique sans explication — Incorrect

<p>
  Our customer support team will go the extra mile to ensure
  your issue is resolved. We believe in burning the midnight
  oil so you never have to.
</p>

Langage idiomatique réécrit en langage simple — Correct

<!-- Plain language replacement is the most robust fix for idioms.
     If idioms must be retained for brand voice, provide a
     parenthetical explanation or tooltip. -->
<p>
  Our customer support team will make every effort to ensure
  your issue is resolved. We work extended hours so you
  receive help whenever you need it.
</p>

Contenu médical ou juridique avec termes spécialisés non définis — Incorrect

<p>
  Patients diagnosed with dyslipidemia may be prescribed
  statins to manage LDL cholesterol levels and reduce the
  risk of atherosclerosis.
</p>

Contenu médical avec liens vers un glossaire accessible — Correct

<!-- Each technical term links to the relevant glossary anchor.
     The glossary page contains plain-language definitions. -->
<p>
  Patients diagnosed with
  <a href='/glossary#dyslipidemia'>dyslipidemia</a>
  (abnormal levels of lipids in the blood) may be prescribed
  <a href='/glossary#statins'>statins</a>
  to manage
  <a href='/glossary#ldl'>LDL cholesterol</a>
  levels and reduce the risk of
  <a href='/glossary#atherosclerosis'>atherosclerosis</a>
  (hardening and narrowing of the arteries).
</p>

Mot utilisé dans un sens restreint ou spécifique à un domaine — Incorrect

<p>
  Submit your token at the kiosk to claim your reward.
  Tokens expire at the end of each session.
</p>

Mot à sens restreint avec définition contextuelle — Correct

<!-- The first use of the term in the restricted sense is
     marked with dfn and explained. Subsequent uses are clear
     by context. -->
<p>
  Submit your
  <dfn id='def-token'>token</dfn>
  (a single-use digital voucher issued when you complete
  a qualifying purchase) at the kiosk to claim your reward.
  Tokens expire at the end of each session.
</p>

Erreurs courantes

• Définir un terme dans le glossaire sans jamais y faire de lien depuis le contenu : Un glossaire n’est utile que si les utilisateurs savent qu’il existe et peuvent y accéder. Ne pas lier les termes inhabituels à leurs définitions — ou omettre un lien de glossaire bien visible dans la navigation — signifie que de nombreux utilisateurs ne découvriront jamais cette ressource.
• Utiliser <abbr title='...'> pour des mots entiers plutôt que pour des abréviations : L’attribut title sur <abbr> est souvent détourné comme info-bulle générique pour n’importe quel terme. Les lecteurs d’écran gèrent title de manière incohérente, et il est invisible pour les utilisateurs au clavier par défaut dans la plupart des navigateurs. Utilisez <dfn> avec une description liée accessible ou un texte adjacent pour les mots entiers.
• Fournir des définitions sous forme d’info-bulles qui ne sont pas accessibles au clavier : Les info-bulles uniquement en CSS ou JavaScript qui s’activent uniquement au survol de la souris excluent totalement les utilisateurs au clavier et sur écran tactile. Toute info-bulle utilisée pour transmettre une définition doit pouvoir être déclenchée via le focus clavier et ne doit pas disparaître lorsque l’utilisateur déplace le focus à l’intérieur pour la lire.
• Supposer que les termes standard du secteur n’ont pas besoin de définition pour un public général : Des termes comme « bandwidth », « uptime », « SLA » ou « API » peuvent être évidents pour les équipes techniques mais opaques pour le grand public visitant un site de télécommunications ou de services cloud. Évaluez toujours la terminologie du point de vue du membre le moins expérimenté du public visé.
• Définir un terme uniquement lors de sa première occurrence dans un document mais pas sur les pages où il apparaît sans introduction préalable : Si un utilisateur arrive sur le site via un article profond qui fait référence à un jargon défini uniquement sur une autre page, il n’a pas accès à la définition. Chaque page doit être autonome ou fournir une navigation vers la définition quel que soit le point d’entrée.
• Utiliser du jargon dans les libellés de formulaire, le texte des boutons ou les messages d’erreur sans définitions : Les mots inhabituels dans les éléments d’interface interactifs — comme « Autoriser l’accès délégué » sur un bouton, ou « Votre jeton de session est invalide » dans un message d’erreur — sont particulièrement nuisibles car les utilisateurs doivent les comprendre pour accomplir des tâches critiques. Ils sont fréquemment négligés lors des audits de contenu.
• Rédiger des définitions de glossaire en utilisant un jargon supplémentaire : Une entrée de glossaire qui définit « amortization » comme « the systematic allocation of an intangible asset's cost over its useful life » n’aide pas un utilisateur profane. Les définitions doivent elles-mêmes être rédigées dans un langage simple, accessible au public visé.
• Ignorer les idiomes spécifiques à une langue dans le contenu multilingue ou traduit : Lorsque le contenu est traduit de l’anglais vers le turc (ou inversement), les expressions idiomatiques sont fréquemment traduites littéralement, produisant des phrases absurdes ou déroutantes dans la langue cible. Chaque version localisée doit être relue par un locuteur natif pour en vérifier l’exactitude idiomatique et la compréhensibilité.
• Considérer <dfn> comme purement sémantique sans définition visible pour l’utilisateur : L’élément HTML <dfn> marque l’occurrence où un terme est défini, mais il ne fournit pas lui-même la définition aux utilisateurs. Il doit toujours être associé à un texte adjacent, à une association aria-describedby ou à une définition visible dans le paragraphe environnant.
• Omettre les mots inhabituels des listes de contrôle d’audit automatisé parce qu’aucune règle axe ne les signale : Comme ce critère nécessite une évaluation manuelle, il est facile de le reléguer au second plan lors des audits techniques. Les équipes devraient établir un processus de révision manuelle documenté pour la langue et la terminologie comme étape formelle de leur flux de travail QA en accessibilité, et non comme une réflexion après coup.

Lien avec la réglementation turque en matière d’accessibilité

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 alignées sur WCAG 2.2 pour un large éventail d’entités publiques et privées opérant en Turquie. Les entités couvertes incluent les institutions et agences publiques, les plateformes de e-commerce, 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 (MoNE).

La circulaire impose la conformité à WCAG 2.2 niveau AA comme exigence légale de base. WCAG 3.1.3 — Mots inhabituels est un critère de niveau AAA et n’est donc pas légalement requis par cette réglementation. Cependant, cela ne diminue en rien son importance pratique pour les organisations turques. Les entités qui servent des populations linguistiquement diverses — y compris les portails de santé publique, les plateformes d’éducation nationale et les entreprises de services financiers — ont de fortes incitations éthiques et réputationnelles à mettre en œuvre des critères AAA tels que 3.1.3.

Pour certains services spécialisés, la conformité de niveau AAA peut devenir de fait nécessaire. Les établissements de santé qui servent des patients ayant des niveaux variés de littératie en santé, les plateformes éducatives opérées sous l’autorisation du MoNE qui servent des élèves ayant des handicaps cognitifs, et les portails gouvernementaux tenus de communiquer clairement avec tous les citoyens bénéficieraient grandement de la mise en œuvre de ce critère. Le cadre turc des droits des personnes handicapées, renforcé par la ratification par la Turquie de la Convention des Nations Unies relative aux droits des personnes handicapées, établit un mandat plus large pour l’égalité d’accès à l’information que les critères AAA contribuent à remplir dans l’esprit, même lorsqu’ils ne sont pas strictement imposés par la loi.

Les organisations qui cherchent à démontrer une accessibilité de premier plan — que ce soit pour un avantage concurrentiel, l’accès aux marchés internationaux, l’éligibilité aux marchés publics ou un engagement réel en faveur de la conception inclusive — devraient considérer WCAG 3.1.3 comme faisant partie d’un programme d’accessibilité global qui va au-delà du minimum réglementaire. Mettre en œuvre un système de glossaire structuré, former les auteurs de contenu à reconnaître et définir la terminologie inhabituelle, et intégrer l’accessibilité linguistique dans les flux de travail éditoriaux sont des mesures pratiques qui servent les utilisateurs turcs et s’alignent sur les objectifs plus larges de la circulaire présidentielle 2025/10.