WCAG 2.4.5 : Multiples moyens

Ce que signifie cette règle

WCAG 2.4.5 — Multiple façons est un critère de succès de niveau AA relevant du principe « Utilisable ». Il exige que toute page web faisant partie d’un ensemble plus vaste de pages web soit accessible par au moins deux mécanismes de navigation distincts. En d’autres termes, un utilisateur ne devrait jamais être obligé de dépendre d’un seul chemin pour trouver une page.

Les mécanismes de navigation courants qui satisfont à ce critère incluent : une fonction de recherche sur l’ensemble du site, un plan du site (soit sous forme de page dédiée, soit sous forme de structure intégrée), une table des matières, un menu de navigation ou une barre latérale cohérents, des fils d’Ariane et des liens entre pages connexes. N’importe lesquels de deux de ces mécanismes — ou d’autres mécanismes équivalents — utilisés ensemble satisfont à l’exigence.

Le critère s’applique spécifiquement aux ensembles de pages web. Une page web autonome qui n’appartient pas à un site ou à une application plus vaste est exemptée. De plus, les pages qui sont le résultat ou une étape d’un processus — comme une page de confirmation de commande, un écran de succès d’envoi de formulaire ou une étape d’un assistant — sont également explicitement exemptées. Cela s’explique par le fait que ces pages sont intrinsèquement séquentielles et qu’il serait inapproprié ou préjudiciable de permettre un accès direct à celles-ci hors séquence.

Un succès exige qu’au moins deux mécanismes de navigation indépendants soient présents, fonctionnels et accessibles sur l’ensemble du site. Un échec se produit lorsqu’un seul mécanisme existe — par exemple, un site qui ne fournit qu’un menu de navigation principal sans recherche, sans plan du site et sans autre aide à la navigation. Il y a également échec si le mécanisme secondaire est non fonctionnel ou inaccessible (par exemple, une zone de recherche qui ne renvoie aucun résultat, ou un plan du site caché aux technologies d’assistance).

Il est important de noter que ce critère n’impose aucune combinaison spécifique de mécanismes. Cette flexibilité est intentionnelle : les utilisateurs ont fondamentalement des stratégies différentes pour trouver du contenu, et la norme reconnaît cette diversité en exigeant une redondance plutôt qu’en prescrivant une solution particulière.

Pourquoi c’est important

La navigation est la base de toute expérience web, et les obstacles à la navigation affectent de manière disproportionnée les personnes handicapées. Lorsqu’il n’existe qu’un seul chemin de navigation, les utilisateurs qui ne peuvent pas utiliser ce chemin sont de fait exclus du contenu.

Pour les utilisateurs ayant des troubles moteurs — y compris ceux qui utilisent un accès par contacteur, des dispositifs de suivi oculaire, des logiciels de commande vocale ou une navigation uniquement au clavier — les menus hiérarchiques complexes peuvent être épuisants ou impossibles à parcourir efficacement. Une recherche sur le site leur permet d’accéder directement au contenu sans devoir naviguer à travers plusieurs niveaux de menus. À l’inverse, les utilisateurs ayant certains troubles cognitifs ou de la mémoire peuvent trouver les champs de recherche ouverts déroutants ou difficiles à utiliser efficacement ; pour eux, un plan du site clairement structuré ou un arbre de catégories navigable est bien plus utile.

Pour les utilisateurs aveugles qui s’appuient sur des lecteurs d’écran, un menu de navigation dense peut devenir un obstacle répétitif à chaque visite de page, même avec des liens d’évitement. Un plan du site ou un raccourci vers la recherche réduit considérablement cette charge cognitive et physique. Pour les utilisateurs ayant une basse vision qui utilisent un agrandissement d’écran, les menus de navigation étendus peuvent n’être que partiellement visibles à des niveaux de zoom élevés, ce qui rend une recherche textuelle ou un plan du site essentiel comme solution de repli.

Pour les utilisateurs ayant des troubles cognitifs tels que la dyslexie ou des troubles de l’attention, la possibilité de rechercher en utilisant des termes approximatifs ou partiels — plutôt que de devoir se souvenir ou reconnaître la hiérarchie exacte des menus — peut faire la différence entre trouver un contenu de manière autonome et abandonner complètement.

Un scénario concret : imaginez une personne atteinte de polyarthrite rhumatoïde visitant une plateforme de commerce électronique turque en utilisant uniquement la navigation au clavier. Le méga-menu du site nécessite des interactions de survol de souris précises pour révéler les sous-catégories, et le comportement du focus clavier est peu fiable. Si le site propose également une barre de recherche et un plan du site, cette personne peut tout de même localiser la page produit dont elle a besoin. Sans ces alternatives, le site est de fait inutilisable pour elle — ce qui représente un client perdu et un risque juridique potentiel.

Au-delà de l’accessibilité, la présence de multiples mécanismes de navigation offre des bénéfices mesurables en termes de SEO et d’utilisabilité. Les plans du site améliorent l’exploration par les robots des moteurs de recherche. La fonctionnalité de recherche interne augmente l’engagement des utilisateurs et réduit les taux de rebond. Les fils d’Ariane améliorent les taux de clics dans les pages de résultats des moteurs de recherche lorsqu’ils sont mis en œuvre avec des données structurées. Ces avantages signifient que satisfaire au critère 2.4.5 n’est pas seulement un exercice de conformité — c’est une bonne pratique de conception web.

Règles Axe-core associées

WCAG 2.4.5 nécessite un test manuel car aucun outil automatisé ne peut déterminer de manière fiable si un site offre une variété de mécanismes de navigation suffisante. Les analyseurs automatisés peuvent vérifier si des éléments spécifiques existent et sont syntaxiquement corrects, mais ils ne peuvent pas évaluer l’architecture de navigation à l’échelle du site ni déterminer si une combinaison donnée de mécanismes est réellement adéquate. Les considérations suivantes guident l’évaluation manuelle :

• Présence d’une recherche sur le site (vérification manuelle) : Les outils automatisés ne peuvent pas confirmer si un champ de recherche est fonctionnel, renvoie des résultats pertinents ou est accessible sur l’ensemble du site. Un testeur doit vérifier manuellement qu’un mécanisme de recherche existe, est accessible au clavier et produit des résultats pertinents pour des requêtes représentatives.
• Présence d’un plan du site ou d’un mécanisme de navigation alternatif (vérification manuelle) : Les outils ne peuvent pas déterminer si une page de plan du site existe, si elle est liée depuis toutes les pages ou si elle couvre de manière exhaustive le contenu du site. Un examinateur humain doit confirmer qu’au moins un mécanisme supplémentaire au-delà de la navigation principale est disponible et accessible.
• Cohérence de la navigation (lié à 2.4.3 et 3.2.3, vérification manuelle) : Les outils automatisés peuvent signaler des incohérences dans l’ordre des composants entre les pages, mais ne peuvent pas juger si la stratégie de navigation globale reste cohérente et suffisante pour les utilisateurs handicapés. Un examen manuel de plusieurs types de pages représentatives est nécessaire.
• Accessibilité des mécanismes secondaires (vérification manuelle) : Même si un plan du site ou une recherche existe, une analyse automatisée peut ne pas détecter les cas où ces mécanismes sont inaccessibles au clavier, mal étiquetés pour les lecteurs d’écran ou visuellement masqués d’une manière qui affecte l’utilisabilité. Des tests manuels au clavier et avec lecteur d’écran doivent confirmer que chaque mécanisme fonctionne de bout en bout.

Comment tester

1. Analyse automatisée — établir une base : Exécutez axe DevTools ou Lighthouse sur des pages représentatives du site. Bien qu’aucun de ces outils ne signale directement des violations du critère 2.4.5, utilisez l’audit pour identifier les composants de navigation (menus, champs de recherche, fils d’Ariane) présentant des problèmes d’accessibilité sous-jacents tels que des étiquettes manquantes, des rôles ARIA incorrects ou des problèmes de gestion du focus. Corrigez ces problèmes en premier, car un mécanisme de navigation défaillant ne peut pas être comptabilisé comme une « voie » valide au titre de 2.4.5.
2. Répertorier les mécanismes de navigation : Passez le site en revue manuellement et dressez la liste de chaque mécanisme distinct qu’un utilisateur pourrait utiliser pour atteindre une page donnée : menus de navigation principaux, liens de pied de page, recherche sur le site, pages de plan du site, fils d’Ariane, liens vers du contenu connexe, index de catégories, etc. Confirmez qu’au moins deux de ces mécanismes sont présents, fonctionnels et disponibles sur chaque page qui ne fait pas partie d’un processus séquentiel.
3. Test de navigation au clavier uniquement : En utilisant uniquement les touches Tab, Entrée, les flèches et Échap (sans souris), tentez d’atteindre une page non d’accueil spécifique par deux mécanismes différents. Par exemple, utilisez la barre de recherche pour trouver une page produit, puis utilisez le plan du site ou le menu de navigation pour atteindre la même page. Confirmez que les deux chemins sont entièrement utilisables sans souris.
4. Test avec lecteur d’écran NVDA + Firefox : Ouvrez NVDA, lancez Firefox et accédez à la page d’accueil. Utilisez le mode navigation de NVDA (F6 pour les repères, H pour les titres) pour localiser le repère de recherche et tout lien vers un plan du site ou des éléments de navigation. Confirmez que les deux mécanismes sont correctement annoncés, que les champs de formulaire ont des étiquettes accessibles et que les pages de résultats ou de destination se chargent et sont lisibles.
5. Test avec lecteur d’écran VoiceOver + Safari (macOS/iOS) : Activez VoiceOver (Cmd+F5) et utilisez le Rotor (VO+U) pour inspecter les contrôles de formulaire et les liens de la page. Confirmez que le champ de recherche est listé et étiqueté, et que les liens de navigation menant à un plan du site ou à un index alternatif sont présents et utilisables.
6. Test avec lecteur d’écran JAWS + Chrome : Utilisez les raccourcis de navigation de JAWS (F pour aller aux formulaires, Insert+F7 pour la liste des liens) pour vérifier que le champ de recherche et les liens vers un plan du site sont détectables et utilisables à la fois au clavier et avec le curseur virtuel.
7. Vérification de l’exemption pour les processus séquentiels : Identifiez toutes les pages qui constituent des étapes d’un processus (paiement, formulaires multi-étapes, parcours de connexion). Confirmez que ces pages n’ont pas besoin de satisfaire à l’exigence de multiples façons. Documentez cela dans votre audit d’accessibilité afin d’éviter de faux échecs.
8. Vérification fonctionnelle des résultats de recherche : Effectuez plusieurs recherches représentatives (noms de produits, titres d’articles, sujets d’assistance). Confirmez que des résultats apparaissent, qu’ils sont pertinents et que la page de résultats est accessible et navigable au clavier et avec un lecteur d’écran.

Comment corriger

Recherche sur le site manquante — Incorrect

<!-- Site only has a navigation menu; no search or sitemap provided -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/urunler'>Ürünler</a></li>
    <li><a href='/hakkimizda'>Hakkımızda</a></li>
    <li><a href='/iletisim'>İletişim</a></li>
  </ul>
</nav>
<!-- No search, no sitemap link, no other navigation mechanism -->

Recherche sur le site manquante — Correct

<!-- Navigation menu retained, and a site search is added as a second mechanism -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/urunler'>Ürünler</a></li>
    <li><a href='/hakkimizda'>Hakkımızda</a></li>
    <li><a href='/iletisim'>İletişim</a></li>
  </ul>
</nav>

<!-- Second navigation mechanism: accessible site search -->
<form role='search' action='/arama' method='get'>
  <label for='site-search'>Sitede Ara</label>
  <input
    type='search'
    id='site-search'
    name='q'
    placeholder='Ürün veya konu arayın...'
    aria-label='Site genelinde arama'
  />
  <button type='submit'>Ara</button>
</form>

Plan du site inaccessible — Incorrect

<!-- Sitemap link is present but visually hidden and unreachable by keyboard -->
<footer>
  <a href='/site-haritasi' style='display:none;'>Site Haritası</a>
</footer>
<!-- display:none removes the element from both visual display AND
     the accessibility tree, so screen reader users cannot reach it.
     This sitemap cannot count as a valid second navigation mechanism. -->

Plan du site inaccessible — Correct

<!-- Sitemap link is visible and accessible to all users -->
<footer>
  <nav aria-label='Footer navigation'>
    <ul>
      <li><a href='/site-haritasi'>Site Haritası</a></li>
      <li><a href='/gizlilik'>Gizlilik Politikası</a></li>
      <li><a href='/iletisim'>İletişim</a></li>
    </ul>
  </nav>
</footer>
<!-- The sitemap page itself should list all major sections and pages
     of the site using <nav>, <ul>, and <a> elements. -->

Formulaire de recherche sans étiquette accessible — Incorrect

<!-- Search input has no label; screen readers announce only 'edit text' -->
<form action='/search'>
  <input type='text' name='q' placeholder='Search...' />
  <button type='submit'><img src='search-icon.png' /></button>
</form>

Formulaire de recherche sans étiquette accessible — Correct

<!-- role='search' identifies the landmark; label associates text with input;
     submit button has an accessible name via aria-label -->
<form role='search' action='/arama' method='get'>
  <label for='global-search'>Arama</label>
  <input
    type='search'
    id='global-search'
    name='q'
    autocomplete='off'
  />
  <button type='submit' aria-label='Aramayı başlat'>
    <img src='search-icon.png' alt='' aria-hidden='true' />
  </button>
</form>

Erreurs courantes

• Compter un plan de site XML comme mécanisme de navigation destiné aux utilisateurs : Un plan de site XML soumis aux moteurs de recherche (par exemple, /sitemap.xml) est un fichier lisible par machine et ne peut pas être utilisé par les visiteurs ordinaires. Seule une page de plan de site HTML, navigable par des humains, compte comme un second mécanisme de navigation valide.
• Fournir un formulaire de recherche purement décoratif ou défaillant : Un champ de recherche qui renvoie toujours des résultats vides, génère des erreurs à l’envoi ou redirige vers une page 404 ne satisfait pas au critère 2.4.5. Le mécanisme doit être réellement fonctionnel pour que le critère soit respecté.
• Masquer le lien vers le plan du site derrière du JavaScript qui échoue ou est désactivé : Si le seul lien vers un plan du site se trouve dans une fenêtre modale injectée dynamiquement ou dans un menu déroulant dépendant de JavaScript qui échoue dans certains environnements, les utilisateurs qui ne peuvent pas exécuter ce JavaScript (y compris certaines configurations de technologies d’assistance) perdent l’accès à ce mécanisme de navigation.
• Appliquer display:none ou visibility:hidden à un mécanisme de navigation sur les affichages mobiles : Masquer complètement une barre de recherche ou un lien vers le plan du site dans la mise en page mobile supprime entièrement ce mécanisme pour les utilisateurs mobiles, ce qui constitue un échec — même si la mise en page de bureau est conforme. Replier le mécanisme derrière un bouton de bascule accessible est acceptable ; le retirer du DOM ou de l’arbre d’accessibilité ne l’est pas.
• Considérer les fils d’Ariane comme un second mécanisme autonome sans autre support : Les fils d’Ariane ne montrent que le chemin vers la page actuelle et ne suffisent pas, à eux seuls, à aider un utilisateur à découvrir et à naviguer vers des pages arbitraires d’un site. Ils peuvent compléter d’autres mécanismes mais ne peuvent généralement pas servir seuls comme l’un des deux mécanismes requis.
• Exempter des pages de l’exigence de manière incorrecte : L’exemption pour les processus séquentiels s’applique uniquement aux pages qui sont littéralement des étapes d’un processus (par exemple, étape 2 sur 4 d’un paiement). Les pages de catégorie, les pages de détail produit et les articles de blog ne sont pas exemptés, même si l’utilisateur y est arrivé via un entonnoir.
• Utiliser un champ de recherche avec type='text' au lieu de type='search' et omettre role='search' sur le formulaire : Bien que cela ne constitue pas une violation directe du critère 2.4.5, cela signifie que les utilisateurs de lecteurs d’écran qui parcourent les repères ne peuvent pas trouver la zone de recherche. Le mécanisme existe techniquement mais est pratiquement plus difficile à découvrir, ce qui va à l’encontre de l’intention du critère.
• Fournir deux mécanismes effectivement identiques : Un menu de navigation en haut de page et un menu de navigation en pied de page contenant exactement les mêmes liens dans exactement la même structure ne constituent pas deux mécanismes de navigation significativement différents. L’intention est que les utilisateurs ayant des besoins différents puissent trouver des stratégies alternatives — pas que la même stratégie apparaisse deux fois sur la page.
• Exclure certains types de pages du système de navigation : Certaines configurations de CMS placent les articles de blog, les pages juridiques ou les pages de compte utilisateur en dehors du plan du site principal ou de l’index de recherche. Si les utilisateurs ne peuvent pas trouver ces pages par au moins deux mécanismes, ces pages ne respectent pas le critère 2.4.5, quel que soit le niveau de structuration du reste du site.
• Ne pas tester les mécanismes avec des technologies d’assistance : Étant donné que le critère 2.4.5 nécessite des tests manuels, les équipes qui s’appuient uniquement sur des outils automatisés manqueront les échecs causés par des pièges au clavier dans les formulaires de recherche, des champs non étiquetés ou des plans du site présents dans le DOM mais inaccessibles via la navigation par repères des lecteurs d’écran.

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

La circulaire présidentielle n° 2025/10 de la Turquie, publiée au Journal officiel (Resmî Gazete) n° 32933 le 21 juin 2025, établit des obligations contraignantes en matière d’accessibilité web pour un large éventail d’entités publiques et privées. La circulaire impose la conformité à des normes d’accessibilité reconnues au niveau international, alignant les exigences juridiques turques sur WCAG 2.1 et WCAG 2.2 niveau AA comme attente de base.

WCAG 2.4.5 — Multiple façons est un critère de niveau AA, ce qui signifie qu’il s’inscrit pleinement dans le niveau de conformité exigé par la circulaire. Les entités soumises à la réglementation doivent s’assurer que toutes les pages web appartenant à un ensemble offrent au moins deux mécanismes de navigation, comme décrit dans ce critère. Le non-respect de cette exigence constitue une non-conformité directe au mandat réglementaire.

Les entités couvertes par la circulaire présidentielle 2025/10 comprennent : les institutions publiques et les organismes gouvernementaux à tous les niveaux ; les banques et institutions financières ; les hôpitaux et prestataires de soins de santé ; les plateformes de commerce électronique ; les opérateurs 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 opérant sous l’autorisation du ministère de l’Éducation nationale (Millî Eğitim Bakanlığı, MEB). Chacune de ces catégories d’entités est tenue de maintenir une navigation accessible et multi-chemins sur ses propriétés web.

En plus des exigences de conformité obligatoires, le ministère de la Famille et des Services sociaux (Aile ve Sosyal Hizmetler Bakanlığı) délivre le Erişilebilirlik Logosu (Logo d’accessibilité) aux organisations qui démontrent de bonnes pratiques en matière d’accessibilité. L’obtention de ce logo nécessite une conformité complète au niveau AA, y compris le respect du critère 2.4.5. Pour les entreprises opérant sur le marché numérique compétitif de la Turquie — en particulier les plateformes de commerce électronique, les banques et les prestataires de soins de santé — le Logo d’accessibilité sert à la fois de signal de confiance pour les utilisateurs handicapés et de preuve de bonne foi réglementaire.

Concrètement, les sites web turcs qui servent des populations d’utilisateurs diverses bénéficient considérablement de la mise en œuvre de multiples mécanismes de navigation. La Turquie compte une importante population d’internautes âgés et d’utilisateurs dans des régions à faible littératie numérique, qui tous deux bénéficient de la redondance exigée par le critère 2.4.5. Une recherche sur le site avec prise en charge de la langue turque (y compris la gestion correcte des caractères spécifiques au turc tels que ı, İ, ş, ğ, ü, ö, ç) combinée à un plan de site HTML clairement structuré représente une mise en œuvre accessible et conforme à la réglementation qui sert bien ce public. Les organisations cherchant à obtenir ou à conserver le Erişilebilirlik Logosu devraient considérer la conformité au critère 2.4.5 non pas comme une amélioration facultative, mais comme une exigence fondamentale de leur programme d’accessibilité.