WCAG 3.2.6 : Aide cohérente

Ce que signifie cette règle

Le critère de succès WCAG 3.2.6 Aide cohérente (niveau AA, introduit dans WCAG 2.2) stipule : « Si une page Web contient l’un des mécanismes d’aide suivants, et que ces mécanismes sont répétés sur plusieurs pages Web, ils apparaissent dans le même ordre relatif par rapport au reste du contenu de la page, sauf si un changement est initié par l’utilisateur. » Les mécanismes d’aide couverts par ce critère sont : des coordonnées de contact humain (comme un numéro de téléphone, une adresse e-mail ou des horaires d’ouverture), un mécanisme de contact humain (comme un widget de chat en direct ou un formulaire de contact), une option d’auto-assistance (comme une page de questions fréquentes, un centre d’aide ou une base de connaissances), et un mécanisme de contact entièrement automatisé (comme un chatbot ou un assistant virtuel).

L’exigence clé est la cohérence de l’ordre relatif, et non un placement identique au pixel près. Si un bouton de chat en direct apparaît dans le coin inférieur droit de la page d’accueil, il doit apparaître dans la même position en bas à droite sur toutes les autres pages où il est affiché. Si un lien « Aide » est le troisième élément dans la barre de navigation supérieure sur une page, il doit rester le troisième élément — ou au moins conserver la même relation relative avec le contenu environnant — sur toutes les autres pages où cette barre de navigation apparaît.

Une page répond à ce critère lorsque : (a) aucun mécanisme d’aide n’existe sur le site, ou (b) un mécanisme d’aide n’existe que sur une seule page, ou (c) partout où un mécanisme d’aide est répété sur plusieurs pages, il apparaît dans le même ordre relatif au sein de la mise en page. Une page échoue lorsque un mécanisme d’aide présent sur plusieurs pages change de position dans l’ordre de la page d’une page à l’autre sans que l’utilisateur ait initié ce changement — par exemple, un widget de chat qui flotte en bas à droite sur la page de liste de produits mais se déplace en bas à gauche sur la page de paiement.

Le critère inclut une exception explicite : l’ordre peut changer si le changement est initié par l’utilisateur. Par exemple, si un utilisateur fait glisser et repositionne un widget d’aide flottant, ou si une préférence utilisateur bascule le panneau d’aide d’un côté à l’autre, ce repositionnement est initié par l’utilisateur et ne constitue pas un échec. Cette exception reflète la même logique d’action initiée par l’utilisateur que l’on trouve dans le critère 3.2.2 (À la saisie).

Il est important de noter que ce critère n’exige pas que chaque page dispose d’un mécanisme d’aide, ni que le mécanisme d’aide soit efficace ou facile à utiliser. Il régit uniquement la cohérence de position lorsque le mécanisme est présent sur plusieurs pages.

Pourquoi c’est important

Le placement cohérent de l’aide est principalement conçu pour bénéficier aux utilisateurs ayant des déficiences cognitives, y compris les personnes ayant des troubles de la mémoire, des difficultés d’attention, des troubles d’apprentissage comme la dyslexie, et des affections telles que le TDAH ou une démence à un stade précoce. Pour ces utilisateurs, localiser un élément d’interface familier demande un effort cognitif délibéré. Lorsque un bouton d’aide ou un lien de contact apparaît à un endroit différent sur chaque page, ils doivent fournir cet effort à répétition, ce qui augmente la charge cognitive et le risque de frustration, de désorientation ou d’abandon de la tâche.

Les utilisateurs qui sont nouveaux sur le web ou qui ont une littératie numérique limitée — une population significative en Turquie et dans le monde — s’appuient également fortement sur un placement prévisible. Selon l’Organisation mondiale de la Santé, plus de 1,3 milliard de personnes dans le monde vivent avec une forme de handicap, et les affections cognitives et neurologiques représentent une part substantielle de cette population. Concevoir pour la cohérence de position sert donc un large public, bien au-delà des personnes ayant un handicap diagnostiqué cliniquement.

Considérons un scénario concret : une utilisatrice atteinte de la maladie d’Alzheimer à un stade précoce essaie de finaliser une réservation de vol en ligne. Elle se souvient que le site de la compagnie aérienne propose une option de chat en direct qu’elle peut utiliser lorsqu’elle est confuse. Sur la page de résultats de recherche, l’icône de chat apparaît dans le coin inférieur droit. Mais lorsqu’elle passe à la page de sélection des sièges, le widget de chat a été déplacé dans le coin supérieur droit, à l’intérieur d’un tiroir d’aide rétractable. Elle ne parvient pas à le trouver, se sent dépassée et abandonne complètement la réservation. Il s’agit d’un échec direct et évitable du critère 3.2.6.

Pour les utilisateurs ayant une déficience motrice qui naviguent avec un accès par contacteur, un logiciel de suivi oculaire ou des pointeurs de tête, le repositionnement d’un mécanisme d’aide implique de rebalayer et de viser une nouvelle zone de l’écran — un processus exigeant et chronophage que le placement cohérent permet d’éliminer.

Les utilisateurs de lecteurs d’écran qui ont mémorisé l’ordre de tabulation ou la structure des titres d’un site pour atteindre rapidement la section d’aide sont tout autant affectés lorsque l’ordre DOM de ce mécanisme change d’une page à l’autre, même si la position visuelle semble similaire.

Au-delà de l’accessibilité, il existe un bénéfice clair en termes d’utilisabilité et de performance commerciale : les utilisateurs qui peuvent trouver rapidement de l’aide sont moins susceptibles d’abandonner une transaction, ce qui réduit les taux d’abandon et les coûts de support. Des modèles d’interface cohérents renforcent également la confiance dans la marque et le professionnalisme.

Règles axe-core associées

WCAG 3.2.6 est classé comme nécessitant uniquement des tests manuels et ne dispose pas d’une règle axe-core automatisée correspondante capable de signaler les violations de manière programmatique. C’est intentionnel, et comprendre pourquoi aide les testeurs à apprécier la nature de ce critère.

• Inspection manuelle requise — aucune règle axe disponible : Les outils automatisés tels qu’axe-core, Lighthouse ou IBM Equal Access Checker analysent une seule page isolément. Ils n’ont aucune compréhension intrinsèque de ce qu’est un « mécanisme d’aide », aucune capacité à comparer la position DOM relative d’un élément à travers plusieurs chargements de page ou URL, et aucun moyen de déterminer si un élément donné remplit la fonction de fournir de l’aide. Un widget de chat, par exemple, peut être implémenté comme un simple <div>, un composant shadow DOM, un <iframe> ou un script injecté par un tiers — aucun de ces éléments ne pouvant être identifié de manière fiable comme un « mécanisme d’aide » par un moteur de règles sans jugement humain. Axe-core aurait besoin d’une conscience d’état inter-pages et d’une reconnaissance de l’intention sémantique pour signaler cela, des capacités qui dépassent le cadre d’une analyse statique d’une seule page. C’est pourquoi WCAG 2.2 lui-même qualifie 3.2.6 de critère nécessitant une évaluation humaine via des audits manuels structurés et une comparaison entre pages.

Comment tester

1. Recenser les mécanismes d’aide : Avant de tester des pages individuelles, créez une liste de tous les mécanismes d’aide présents sur le site — widgets de chat en direct, numéros de téléphone de contact, liens e-mail, liens vers la FAQ, lanceurs de chatbot, formulaires de contact et liens vers le centre d’aide. Notez sur quelles pages chaque mécanisme apparaît. Si un mécanisme n’apparaît que sur une seule page, il est hors du champ de ce critère.
2. Lancer une analyse automatisée pour un contexte de base : Utilisez axe DevTools (extension de navigateur) ou Lighthouse sur des pages représentatives pour capturer des instantanés de l’ordre DOM et identifier la position structurelle des éléments liés à l’aide. Bien qu’aucune règle axe ne cible directement le critère 3.2.6, l’ordre DOM rapporté par ces outils peut être comparé manuellement entre les pages. Exportez ou capturez l’arbre d’accessibilité pour chaque page contenant un mécanisme d’aide.
3. Comparer les positions relatives entre les pages : Ouvrez côte à côte (ou successivement) deux pages ou plus qui partagent le même mécanisme d’aide. Pour chaque mécanisme, identifiez sa position par rapport aux zones de repère environnantes (<header>, <main>, <footer>, <nav>). Notez si le mécanisme apparaît dans la même zone de repère et dans le même ordre relatif (avant ou après les éléments adjacents) sur chaque page. Un changement de position constitue un échec potentiel.
4. Tester avec la navigation au clavier (tous navigateurs) : Parcourez chaque page contenant un mécanisme d’aide avec la touche Tab. Comptez le nombre d’arrêts de tabulation nécessaires pour atteindre le mécanisme d’aide depuis le début de la page. Comparez ce nombre entre les pages. Une différence significative — par exemple, atteignable en 5 tabulations sur la page d’accueil mais en 47 tabulations sur la page de paiement — indique un changement dans l’ordre DOM même si la position visuelle semble similaire.
5. Tester avec NVDA + Firefox : Ouvrez la liste des éléments NVDA (touche NVDA + F7) et passez à la vue Liens ou Boutons. Repérez le mécanisme d’aide dans la liste. Notez sa position par rapport aux autres éléments listés. Répétez l’opération sur chaque page où le mécanisme apparaît et comparez les positions.
6. Tester avec VoiceOver + Safari (macOS/iOS) : Utilisez le rotor VoiceOver (VO + U) pour ouvrir la liste des Liens ou des Contrôles de formulaire. Naviguez jusqu’au mécanisme d’aide et notez sa position dans la liste. Comparez entre les pages.
7. Tester avec JAWS + Chrome : Utilisez la liste des liens JAWS (Insert + F7) pour localiser le mécanisme d’aide. Notez sa position ordinale et les éléments adjacents. Répétez l’opération sur plusieurs pages.
8. Vérifier les exceptions initiées par l’utilisateur : Si le site permet aux utilisateurs de repositionner ou de masquer des mécanismes d’aide (par exemple, un widget de chat déplaçable), vérifiez que le repositionnement est déclenché par une action explicite de l’utilisateur et que la préférence persiste de manière logique. Documentez cela comme une exception valide au titre du critère.
9. Vérifier sur les affichages mobiles : Les mises en page responsives réorganisent parfois les éléments DOM à différents points de rupture. Testez à la fois sur des affichages de bureau et mobiles (largeurs de 375px et 1440px au minimum) pour confirmer que le mécanisme d’aide conserve un placement relatif cohérent à toutes les tailles d’écran courantes.

Comment corriger

Widget de chat flottant — Incorrect

<!-- Page A (page d’accueil) : bouton de chat en bas à droite -->
<div class='chat-widget' style='position:fixed; bottom:20px; right:20px;'>
  <button>Chat with Us</button>
</div>

<!-- Page B (paiement) : bouton de chat déplacé en bas à gauche -->
<div class='chat-widget' style='position:fixed; bottom:20px; left:20px;'>
  <button>Chat with Us</button>
</div>
<!-- FAIL: The widget changes its fixed position between pages,
     breaking consistent help placement. -->

Widget de chat flottant — Correct

<!-- Pages A et B : bouton de chat toujours en bas à droite -->
<div class='chat-widget chat-widget--bottom-right'>
  <button type='button' aria-label='Open live chat support'>
    Chat with Us
  </button>
</div>
<!-- PASS: The widget appears in the same corner on every page.
     Use a CSS class defined in a shared stylesheet rather than
     inline styles, so the position is controlled centrally and
     applied consistently across all templates. -->

Lien d’aide dans la navigation — Incorrect

<!-- Page A : Help est le 4e élément de navigation -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/pricing'>Pricing</a></li>
    <li><a href='/help'>Help</a></li>
  </ul>
</nav>

<!-- Page B (détail produit) : lien Help retiré de la navigation,
     placé à la place dans une section de pied de page -->
<footer>
  <a href='/help'>Help Center</a>
</footer>
<!-- FAIL: The Help link has moved from the main navigation
     to the footer, changing its relative order significantly. -->

Lien d’aide dans la navigation — Correct

<!-- Les pages A et B partagent le même modèle de navigation -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/pricing'>Pricing</a></li>
    <li><a href='/help'>Help</a></li>
  </ul>
</nav>
<!-- PASS: The Help link is the 4th item in the main nav
     on every page where the nav is present. Using a shared
     navigation component or server-side include ensures
     this is maintained automatically. -->

Affichage conditionnel de l’aide — Incorrect

<!-- Sur les pages non connectées : numéro de téléphone dans l’en-tête -->
<header>
  <p>Need help? Call <a href='tel:+908501234567'>0850 123 45 67</a></p>
</header>

<!-- Sur les pages connectées : numéro de téléphone retiré de l’en-tête,
     uniquement disponible dans un menu déroulant de compte -->
<header>
  <nav aria-label='Account menu'>
    <details>
      <summary>My Account</summary>
      <ul>
        <li><a href='/orders'>Orders</a></li>
        <li><a href='/contact'>Contact: 0850 123 45 67</a></li>
      </ul>
    </details>
  </nav>
</header>
<!-- FAIL: The contact number changes its relative position
     dramatically depending on authentication state,
     making it unpredictable for returning users. -->

Affichage conditionnel de l’aide — Correct

<!-- Pages non connectées et connectées : téléphone à la même place dans l’en-tête -->
<header>
  <div class='header-support'>
    <a href='tel:+908501234567' aria-label='Call support: 0850 123 45 67'>
      <svg aria-hidden='true' focusable='false'><!-- phone icon --></svg>
      0850 123 45 67
    </a>
  </div>
  <nav aria-label='Account menu'>
    <!-- account links here -->
  </nav>
</header>
<!-- PASS: The contact mechanism is always in the same position
     within the header regardless of authentication state.
     Additional account-specific links can appear elsewhere
     without moving the help mechanism. -->

Erreurs courantes

• Placer le widget de chat dans des coins différents selon les modèles de page : Les équipes de développement appliquent souvent un positionnement fixe pour les widgets de chat au niveau de chaque modèle plutôt que via une feuille de style globale, ce qui fait apparaître le widget en bas à droite sur les pages marketing et en bas à gauche sur les pages applicatives. Utilisez un composant global unique inclus partout avec une classe de position verrouillée.
• Retirer le lien d’aide de la navigation sur les pages de paiement pour réduire l’encombrement : Certains modèles UX épurent volontairement la navigation sur les pages de paiement pour optimiser la conversion. Si un mécanisme d’aide fait partie de cette navigation, le retirer de ce modèle de page rompt la cohérence. Conservez plutôt le lien d’aide dans un en-tête minimal même sur les parcours de paiement épurés.
• Injecter des mécanismes d’aide via des scripts tiers qui se chargent avec des positions DOM imprévisibles : De nombreux SDK de chat en direct injectent leur widget dans le DOM de manière asynchrone, et leur point d’insertion peut varier selon l’ordre de chargement des scripts. Cela peut amener le widget à apparaître à une position différente dans l’arbre d’accessibilité d’une page à l’autre. Configurez les widgets tiers pour qu’ils soient toujours ajoutés à un élément d’ancrage DOM fixe et connu.
• Utiliser la propriété CSS order ou le réordonnancement flexbox/grid pour déplacer visuellement l’élément d’aide sans changer l’ordre DOM, puis modifier ce CSS par page : Même si la position visuelle peut sembler cohérente, des surcharges CSS par page qui modifient l’ordre visuel d’un mécanisme d’aide changent tout de même l’ordre perceptible par l’utilisateur et peuvent perturber les utilisateurs de lecteurs d’écran dont l’ordre de lecture suit le DOM.
• S’appuyer sur des outils d’A/B testing qui échangent la position de l’élément d’aide entre variantes de test : Si les utilisateurs de la variante A voient le bouton d’aide dans la barre supérieure et ceux de la variante B le voient dans le pied de page, ces utilisateurs vivront un placement d’aide incohérent d’une page à l’autre au sein de leur session, à mesure que le framework d’A/B testing applique différentes variantes sur différentes pages. Assurez-vous que les tests A/B qui affectent le placement des mécanismes d’aide appliquent la même variante sur toutes les pages d’une session.
• Considérer les états authentifié et non authentifié comme des « sites » différents et appliquer des mises en page d’aide différentes : Les utilisateurs qui se connectent en cours de session trouveront soudainement le mécanisme d’aide à un nouvel emplacement. Le changement d’état d’authentification n’est pas une action initiée par l’utilisateur dans le contexte du placement de l’aide, il s’agit donc toujours d’un échec du critère 3.2.6. Appliquez une mise en page d’aide cohérente pour tous les états d’authentification.
• Intégrer le numéro de téléphone d’aide uniquement dans un texte dense de pied de page sur certaines pages et dans une barre d’en-tête dédiée sur d’autres : Même si le numéro de téléphone est techniquement présent sur toutes les pages, un changement significatif de sa position relative (du premier élément interactif dans l’en-tête à un élément enfoui dans le pied de page après des centaines de liens) constitue un échec de cohérence d’ordre.
• Supposer que, parce qu’une icône d’aide est toujours visuellement « dans le coin », le critère est respecté : Le critère mesure l’ordre relatif dans le contenu de la page, et pas seulement les coordonnées en pixels. Une icône de chat qui est toujours visuellement en bas à droite mais qui apparaît à un point très différent dans l’ordre DOM selon les pages (par exemple, immédiatement après la balise <body> sur une page et juste avant la balise de fermeture </body> sur une autre) peut tout de même échouer pour les utilisateurs au clavier et les utilisateurs de lecteurs d’écran.
• Oublier d’auditer les points de rupture responsives : Un mécanisme d’aide qui est cohérent aux largeurs d’affichage de bureau peut être masqué ou déplacé dans un menu hamburger mobile sur des affichages étroits, ce qui entraîne une position différente sur mobile. Si les utilisateurs mobiles rencontrent une position relative différente de celle des utilisateurs de bureau, cela doit être évalué au regard du critère — en particulier si le mobile est le principal moyen d’accès pour le public cible.
• Ne pas documenter l’emplacement des mécanismes d’aide dans les systèmes de design : Sans standard documenté sur l’emplacement des mécanismes d’aide, les développeurs et designers prendront des décisions indépendantes qui produiront des incohérences au fil du temps. Ajoutez des règles de placement des mécanismes d’aide explicitement à la documentation de votre système de design ou de votre bibliothèque de composants.

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 un cadre national complet pour l’accessibilité numérique. La circulaire impose la conformité au niveau AA de WCAG 2.2 comme norme d’accessibilité de base pour un large éventail de services numériques opérant en Turquie. Le critère WCAG 3.2.6 Aide cohérente, en tant que critère de niveau AA introduit dans WCAG 2.2, relève directement du champ de cette obligation légale.

Les types d’entités couverts par la circulaire présidentielle 2025/10 incluent : les institutions et organismes publics aux niveaux de l’administration centrale et locale ; les banques et prestataires de services financiers réglementés par l’Agence de régulation et de supervision bancaire (BDDK) ; les plateformes de commerce électronique et les places de marché en ligne ; les hôpitaux et prestataires de soins de santé offrant des services numériques destinés aux patients ; les entreprises de télécommunications comptant 200,000 abonnés ou plus ; les agences de voyage disposant de systèmes de réservation en ligne ; les entreprises de transport privé exploitant des services réguliers ; et les écoles privées et établissements d’enseignement autorisés par le ministère de l’Éducation nationale (MoNE). Pour toutes ces entités, l’ensemble complet des critères WCAG 2.2 niveau AA — y compris le critère 3.2.6 — constitue la norme applicable.

Le respect du critère WCAG 3.2.6 est également une condition préalable à l’obtention du Erişilebilirlik Logosu (Logo d’accessibilité) délivré par le ministère turc de la Famille et des Services sociaux (Aile ve Sosyal Hizmetler Bakanlığı). Ce logo sert de marque officielle de conformité en matière d’accessibilité et est de plus en plus reconnu par les consommateurs turcs et les responsables des achats comme un signe de qualité. Les organisations souhaitant obtenir ce logo doivent démontrer une conformité complète au niveau AA de WCAG 2.2 sur l’ensemble de leurs propriétés numériques, ce qui signifie qu’un placement incohérent de l’aide — même apparemment mineur — peut disqualifier une candidature.

D’un point de vue pratique de conformité, le critère 3.2.6 est particulièrement pertinent pour les fournisseurs turcs de services de commerce électronique et de services financiers, dont les sites web et applications web mobiles proposent généralement des widgets de chat en direct, des liens de contact WhatsApp et des sections FAQ comme principaux canaux de support client. Garantir que ces mécanismes d’aide apparaissent à des positions cohérentes sur les pages de liste de produits, les pages de panier, les parcours de paiement et les sections de gestion de compte est à la fois une obligation légale au titre de la circulaire et une bonne pratique UX pour servir la base diversifiée d’utilisateurs d’Internet en Turquie — qui comprend une importante population d’utilisateurs débutants et à faible littératie numérique, qui bénéficient le plus de modèles d’interface prévisibles.

Les organisations soumises à la circulaire qui n’ont pas encore audité le placement de leurs mécanismes d’aide devraient prioriser un audit de cohérence inter-pages dans le cadre de leur feuille de route de conformité à WCAG 2.2. Étant donné que ce critère nécessite des tests manuels, il doit être inclus à la fois dans les audits de conformité initiaux et dans les cycles de contrôle qualité continus, en particulier après des refontes majeures ou des changements de modèles susceptibles de déplacer involontairement la position des éléments d’aide.