WCAG 1.3.3 : Caractéristiques sensorielles

Ce que signifie cette règle

Le critère de succès 1.3.3 des WCAG — Caractéristiques sensorielles (Niveau A) stipule que les instructions fournies pour comprendre et utiliser le contenu ne doivent pas reposer uniquement sur les caractéristiques sensorielles de composants telles que la forme, la taille, l’emplacement visuel, l’orientation ou le son. En d’autres termes, si votre interface demande à un utilisateur d’interagir avec quelque chose en se référant uniquement à son apparence, à l’endroit où cela apparaît à l’écran ou à ce que cela produit comme son, cette instruction sera dénuée de sens pour les utilisateurs qui ne peuvent pas percevoir ces propriétés sensorielles particulières.

Le mot clé ici est uniquement. Le critère n’interdit pas l’utilisation de références sensorielles — il interdit d’en faire le seul moyen d’identification. Une instruction comme « cliquez sur le bouton rond vert à gauche » échoue lorsqu’un utilisateur ne peut pas distinguer le vert, ne peut pas voir la forme du bouton ou ne peut pas déterminer la gauche de la droite en raison d’une mise en page en reflow. En revanche, « cliquez sur le bouton Envoyer (le bouton rond vert à gauche) » est conforme parce que le libellé textuel « Envoyer » fournit un identifiant non sensoriel qui fonctionne indépendamment de la couleur, de la forme et de la position.

Les instructions concernées par ce critère incluent tout contenu textuel, audio ou visuel qui indique aux utilisateurs qu’ils doivent effectuer une action ou localiser une information. Les schémas d’échec courants incluent :

• « Cliquez sur le bouton à droite pour continuer » — repose uniquement sur l’emplacement visuel.
• « Sélectionnez l’icône carrée pour ouvrir les paramètres » — repose uniquement sur la forme.
• « Les champs obligatoires sont affichés en rouge » — repose uniquement sur la couleur.
• « Lorsque vous entendez le carillon, passez à l’étape suivante » — repose uniquement sur le son.
• « Touchez la grande tuile pour développer la section » — repose uniquement sur la taille.

Une instruction conforme inclut toujours au moins un identifiant non sensoriel — généralement un libellé textuel, un nom programmatique ou un titre — afin que les utilisateurs qui s’appuient sur des technologies d’assistance ou qui se trouvent dans des conditions où les indices sensoriels ne sont pas disponibles puissent tout de même suivre les consignes. Notez que ce critère couvre spécifiquement les instructions ; il n’exige pas que chaque élément d’interface soit repensé, mais il exige que toute consigne textuelle ou orale concernant ces éléments soit perceptible sans discrimination sensorielle.

Il n’existe aucune exception officielle définie dans le 1.3.3 lui-même, bien que le document Understanding précise que le contenu qui utilise des caractéristiques sensorielles en plus d’identifiants non sensoriels est pleinement conforme. Ce critère complète, mais se distingue de 1.4.1 (Utilisation de la couleur), qui traite spécifiquement de la couleur seule ; 1.3.3 a une portée plus large couvrant toutes les modalités sensorielles.

Pourquoi c’est important

Les instructions uniquement sensorielles créent des barrières importantes pour un large éventail d’utilisateurs. Considérez chaque groupe concerné :

Les personnes aveugles ou malvoyantes s’appuient sur des lecteurs d’écran ou des logiciels de grossissement. Lorsqu’une instruction dit « cliquez sur l’icône dans le coin supérieur droit », un utilisateur de lecteur d’écran qui navigue par ordre de tabulation ou par structure de titres n’a aucune notion de « coin supérieur droit » dans la mise en page visuelle. De même, une personne avec une déficience visuelle sévère qui a zoomé à 400 % ne voit peut-être qu’une petite portion de l’écran à la fois, ce qui rend les références positionnelles comme « panneau de gauche » ou « section du bas » totalement peu fiables. Selon l’Organisation mondiale de la santé, environ 2,2 milliards de personnes dans le monde présentent une forme de déficience visuelle, ce qui en fait l’une des populations les plus touchées.

Les personnes daltoniennes — environ 1 homme sur 12 et 1 femme sur 200 — ne peuvent pas distinguer certaines paires de couleurs. Une instruction indiquant « les champs surlignés en rouge sont obligatoires » est invisible en tant qu’indice distinctif pour une personne atteinte de daltonisme rouge-vert. Alors que 1.4.1 traite cet aspect pour l’élément d’interface lui-même, 1.3.3 garantit que le texte d’instruction fournit également une alternative.

Les personnes sourdes ou malentendantes sont impactées par les indices uniquement audio. Si une plateforme d’e-learning demande aux utilisateurs de « continuer lorsque vous entendez la cloche », les utilisateurs qui ne peuvent pas entendre la cloche sont exclus. Ce schéma apparaît dans les présentations interactives, les tutoriels vidéo et les évaluations chronométrées.

Les personnes ayant des handicaps cognitifs ou des troubles d’apprentissage peuvent avoir des difficultés avec le langage directionnel, en particulier lorsque leur technologie d’assistance restitue le contenu sous une forme linéarisée qui supprime le positionnement visuel. Une personne utilisant un dispositif à contacteur ou un système de suivi oculaire navigue également selon des séquences qui peuvent n’avoir aucun rapport avec la mise en page bidimensionnelle imaginée par un concepteur voyant.

Considérez un scénario concret du monde réel : un portail turc de e-services gouvernementaux demande aux citoyens de « remplir les champs encadrés en bleu puis d’appuyer sur le bouton triangulaire pour soumettre votre demande ». Une personne aveugle qui navigue par champs de formulaire entend les libellés de champs via son lecteur d’écran, mais n’a aucun moyen de savoir quels champs sont encadrés en bleu, ni d’identifier un bouton par sa forme triangulaire. Le processus de demande est de fait bloqué. Ajouter les libellés réels des champs (par exemple, « Nom, Numéro d’identification et Date de naissance sont obligatoires ») et le libellé textuel du bouton (« Soumettre la demande ») supprime instantanément la barrière.

Au-delà de l’accessibilité, la suppression des instructions uniquement sensorielles améliore l’ergonomie pour tout le monde. Les conceptions responsives réorganisent le contenu, de sorte que les références positionnelles deviennent inexactes sur mobile. Le mode sombre ou les thèmes à contraste élevé modifient le rendu des couleurs. Les assistants vocaux qui lisent les instructions de la page à voix haute suppriment tout contexte visuel. Construire des instructions autour de libellés programmatiques stables plutôt que de propriétés sensorielles transitoires rend le contenu plus robuste sur tous les appareils et dans tous les contextes — un bénéfice direct en termes de SEO et de maintenance également.

Règles Axe-core associées

WCAG 1.3.3 nécessite des tests manuels car les outils automatisés ne peuvent pas interpréter de manière fiable le sens ou l’intention des instructions en langage naturel. Un moteur d’analyse statique peut détecter qu’un bouton existe ou qu’une couleur est utilisée, mais il ne peut pas lire un paragraphe de texte d’instruction, comprendre qu’il se réfère à un bouton, puis déterminer si cette référence est exclusivement sensorielle. Il s’agit d’un jugement sémantique et contextuel qui nécessite un examen humain.

• Revue manuelle requise — aucune règle axe-core dédiée n’existe pour 1.3.3. Les règles axe-core telles que color-contrast et label peuvent faire apparaître des problèmes connexes (par exemple, un bouton sans nom accessible), mais elles traitent de critères différents. Pour 1.3.3, un testeur humain doit lire chaque phrase d’instruction sur la page, identifier toute référence sensorielle (forme, couleur, taille, emplacement, orientation, son) et vérifier qu’au moins un identifiant non sensoriel accompagne chaque référence. Les outils automatisés ne signaleront pas une phrase comme « cliquez sur le bouton vert ci-dessous » comme une violation, car l’analyse de l’intention en langage naturel dépasse les capacités de l’automatisation basée sur des règles actuelle.
• Pourquoi l’automatisation échoue ici : Considérez que « cliquez sur le grand bouton » contient le mot « bouton », que l’outil automatisé pourrait interpréter comme une référence à un rôle accessible. Mais l’instruction repose toujours uniquement sur la taille (« grand ») pour distinguer ce bouton des autres. Les outils automatisés ne peuvent pas déterminer si « grand » est la seule caractéristique distinctive ou s’il n’y a qu’un seul bouton sur la page (rendant « grand » redondant mais pas nuisible). Le jugement humain est essentiel pour évaluer ces nuances dans leur contexte.
• Règles axe complémentaires à exécuter en parallèle de la revue manuelle : L’exécution des vérifications color-contrast, label, button-name et aria-label aidera à s’assurer que les éléments d’interface référencés dans les instructions ont effectivement des noms programmatiques — un prérequis pour rédiger des instructions non sensorielles. Si un bouton n’a pas de nom accessible, aucune instruction ne peut le référencer de manière significative sans recourir à des indices sensoriels.

Comment tester

1. Commencez par un scan automatisé (axe DevTools ou Lighthouse) : Ouvrez la page dans Chrome, activez l’extension axe DevTools et lancez un scan de page complet. Bien qu’aucune règle ne corresponde directement à 1.3.3, examinez les problèmes signalés dans les catégories « color », « label » et « name ». Ces résultats fournissent une base — si les éléments d’interface n’ont pas de noms accessibles, le texte d’instruction qui s’y réfère repose presque certainement sur des indices sensoriels. Exportez les résultats et notez tous les éléments interactifs dépourvus de libellés programmatiques.
2. Identifiez manuellement tous les textes d’instruction : Lisez chaque phrase de la page qui indique à un utilisateur d’effectuer une action ou de localiser une information. Cela inclut les textes d’aide, les indications de formulaire, les info-bulles, les tutoriels superposés, les messages d’erreur et les parcours d’onboarding. Créez une liste de chaque instruction et mettez en évidence toute référence sensorielle : mots de couleur (rouge, bleu, vert), mots de forme (rond, carré, triangulaire), mots de taille (grand, petit, gros), mots positionnels (gauche, droite, haut, bas, au-dessus, en dessous, coin), mots d’orientation (horizontal, vertical) et références sonores (carillon, bip, son d’alerte).
3. Évaluez chaque référence sensorielle pour vérifier la présence d’identifiants non sensoriels supplémentaires : Pour chaque référence sensorielle trouvée, déterminez si un identifiant non sensoriel est également présent. Un identifiant non sensoriel inclut un libellé textuel correspondant au libellé visible de l’élément ou à son nom accessible, un titre, une étape numérotée, un rôle programmatique unique ou un attribut ARIA label. Si le seul moyen d’identifier l’élément référencé est la perception sensorielle, l’instruction ne respecte pas 1.3.3.
4. Testez avec un lecteur d’écran (NVDA + Firefox) : Naviguez sur la page en utilisant uniquement le clavier et NVDA. Parcourez tous les éléments interactifs avec la touche Tab et écoutez comment NVDA annonce chacun d’eux. Ensuite, lisez le texte d’instruction sur la page et demandez-vous : un utilisateur n’entendant que ces annonces pourrait-il suivre les instructions ? Si une instruction dit « cliquez sur l’icône à droite » mais que NVDA annonce l’élément comme « Paramètres, bouton », alors la référence positionnelle de l’instruction est superflue mais le libellé rend l’instruction exploitable. Si NVDA annonce l’élément comme « bouton » sans nom, l’instruction qui repose sur la position visuelle échoue complètement.
5. Testez avec VoiceOver + Safari (macOS/iOS) : Activez VoiceOver et naviguez sur la page. Utilisez le rotor pour parcourir les boutons, les liens et les contrôles de formulaire. Vérifiez que chaque élément référencé dans une instruction est atteignable et identifiable par son nom annoncé uniquement, sans dépendre de sa position dans la mise en page visuelle.
6. Testez avec JAWS + Chrome : Ouvrez la page dans Chrome avec JAWS activé. Utilisez le mode Forms pour parcourir les champs et écoutez les annonces des champs. Recoupez avec toutes les instructions au niveau du formulaire qui utilisent la couleur ou la position pour indiquer les champs obligatoires.
7. Testez en modes à contraste élevé et sombre : Basculez le système d’exploitation en mode à contraste élevé et rechargez la page. Les instructions codées par couleur qui se réfèrent à des couleurs spécifiques peuvent devenir ambiguës ou invisibles lorsque le rendu des couleurs change. Cela permet de mettre en évidence une dépendance cachée à la couleur comme seul indice sensoriel.
8. Testez sur une vue mobile zoomée ou en reflow : Redimensionnez la fenêtre du navigateur à 320 px de large ou utilisez un appareil mobile. Les instructions utilisant un langage positionnel comme « barre latérale gauche » ou « navigation supérieure » doivent rester compréhensibles lorsque la mise en page a été réorganisée en une seule colonne.

Comment corriger

Instructions de champs de formulaire basées uniquement sur la couleur — Incorrect

<p>Fields shown in red are required.</p>
<label for='email'>Email Address</label>
<input type='email' id='email' style='border-color: red;' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

Instructions de champs de formulaire basées uniquement sur la couleur — Correct

<!-- The instruction now uses a text marker AND color, not color alone.
     The asterisk and the word "required" provide non-sensory identification. -->
<p>Fields marked with an asterisk (*) are required.</p>
<label for='email'>Email Address <span aria-hidden='true'>*</span></label>
<input type='email' id='email' aria-required='true' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

Référence positionnelle à un bouton — Incorrect

<p>To save your work, click the button on the right side of the toolbar.</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

Référence positionnelle à un bouton — Correct

<!-- The instruction now references the button by its visible text label "Save",
     which matches the button's accessible name. Position is still mentioned
     but is no longer the sole identifier. -->
<p>To save your work, click the <strong>Save</strong> button (located on the right side of the toolbar).</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

Navigation par icône basée uniquement sur la forme — Incorrect

<p>Tap the circular icon to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

Navigation par icône basée uniquement sur la forme — Correct

<!-- The button now has an accessible name via aria-label.
     The instruction references "Home" by name, not just by shape. -->
<p>Tap the <strong>Home</strong> button (the circular icon) to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home' aria-label='Home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

Indication de progression basée uniquement sur l’audio — Incorrect

<p>Listen for the beep to know when the upload is complete.</p>
<button type='button' id='upload-btn'>Upload File</button>
<audio id='complete-chime' src='chime.mp3'></audio>

Indication de progression basée uniquement sur l’audio — Correct

<!-- A visible and screen-reader-accessible status message supplements the audio cue.
     Deaf users and users in silent environments now receive the same information. -->
<p>When the upload is complete, you will hear a chime and a <strong>"Upload Complete"</strong> message will appear below.</p>
<button type='button' id='upload-btn'>Upload File</button>
<div role='status' aria-live='polite' id='upload-status'></div>
<audio id='complete-chime' src='chime.mp3'></audio>
<!-- JavaScript sets #upload-status text to "Upload Complete" on success -->

Erreurs courantes

• Écrire « le bouton rouge » ou « le champ vert » comme seul identifiant dans les instructions de formulaire ou les textes d’aide, sans fournir également le libellé visible du bouton ou le nom du champ — cela enfreint à la fois 1.3.3 et 1.4.1.
• Utiliser des expressions positionnelles comme « le menu de gauche » ou « le panneau en haut » dans la documentation d’aide ou les parcours d’onboarding sans nommer le menu ou le panneau, rendant les instructions inutiles après qu’un reflow responsive a réduit la mise en page à une seule colonne.
• Décrire les icônes uniquement par leur forme (« cliquez sur le bouton de lecture triangulaire ») au lieu d’utiliser le nom ou le libellé accessible de l’icône, qu’un utilisateur de lecteur d’écran pourrait effectivement localiser via la navigation au clavier.
• Indiquer les champs de formulaire obligatoires exclusivement par la couleur de bordure ou la couleur de fond dans les instructions en ligne (« les champs orange doivent être remplis ») sans symbole, suffixe de libellé ou attribut aria-required='true' pour transmettre la même information de manière programmatique.
• Fournir un retour uniquement audio pour les processus interactifs (téléversements de fichiers, soumissions de formulaires, expiration de minuteurs) sans mise à jour de statut textuelle correspondante utilisant role='status' ou aria-live='polite'.
• Utiliser la taille comme seul indice distinctif — des instructions comme « cliquez sur la grande carte pour développer » échouent lorsque l’utilisateur zoome, lorsque les cartes sont rendues de taille identique sur des vues plus petites ou lorsqu’un utilisateur de lecteur d’écran n’a aucune notion des tailles relatives des cartes dans le DOM.
• Se fier à des indices d’orientation tels que « balayez horizontalement pour naviguer » sans fournir de méthode d’interaction alternative et un libellé non basé sur l’orientation pour le carrousel ou le slider décrit.
• Oublier que les messages d’erreur sont aussi des instructions — une erreur qui dit « les champs surlignés ci-dessous contiennent des erreurs » repose sur la mise en évidence visuelle et la proximité positionnelle, et sera inutile pour un utilisateur de lecteur d’écran à moins que chaque champ erroné ne soit également nommé explicitement dans le message d’erreur.
• Supposer que l’ajout d’un texte alternatif à une icône corrige l’instruction — si le texte d’instruction continue de dire uniquement « cliquez sur l’icône circulaire », le fait que l’icône ait un texte alternatif sur l’élément image ne rend pas l’instruction textuelle conforme ; le texte d’instruction lui-même doit inclure un identifiant non sensoriel.
• Négliger les instructions injectées dynamiquement dans les applications monopage — les info-bulles, modales et étapes d’assistant injectées via JavaScript contiennent souvent des consignes uniquement sensorielles qui échappent à la revue QA parce qu’elles ne sont pas visibles dans un audit de page statique.

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é web pour un large éventail d’entités publiques et privées opérant en Turquie. La circulaire impose la conformité aux WCAG 2.1 Niveau AA comme norme de base, et WCAG 1.3.3 — en tant que critère de niveau A — est donc pleinement obligatoire pour toutes les entités concernées.

Les entités couvertes par la circulaire 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é, 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). Les institutions publiques doivent atteindre une conformité totale dans l’année suivant la date de publication de la circulaire, tandis que les entités du secteur privé disposent d’un délai de deux ans.

WCAG 1.3.3 est particulièrement pertinent pour les services numériques turcs compte tenu de l’utilisation répandue de guidages de formulaire codés par couleur et de schémas de navigation uniquement par icônes dans les portails turcs de e-gouvernement, les applications bancaires et les parcours de paiement de e-commerce. Par exemple, un formulaire de demande en ligne d’une institution publique qui demande aux citoyens de « remplir les champs marqués en rouge » et de soumettre en « appuyant sur le bouton dans le coin inférieur droit » serait en violation directe de 1.3.3 et constituerait un manquement à la circulaire présidentielle. De même, une interface web mobile d’une banque qui guide les utilisateurs à travers des transactions en plusieurs étapes en utilisant uniquement des indices de position et de couleur devrait être révisée avant l’échéance de deux ans pour le secteur privé.

Le non-respect entraîne des risques réputationnels et juridiques à mesure que l’environnement réglementaire turc autour de l’accessibilité numérique se renforce. Les entités concernées devraient considérer la conformité à 1.3.3 non comme une simple correction éditoriale mineure, mais comme une revue systémique de l’ensemble du contenu d’instruction — y compris les textes d’aide, les messages d’erreur, les parcours d’onboarding et la documentation de support — afin de garantir que les références sensorielles sont toujours accompagnées d’identifiants stables, programmatiques et textuels. Le SDK d’overlay d’Accsible peut aider à faire remonter et à corriger de nombreux problèmes connexes, bien que la revue manuelle du contenu exigée par 1.3.3 doive en fin de compte être effectuée par un auditeur humain qualifié travaillant de concert avec les outils automatisés.