Chaque page de votre site commence de la même façon : votre logo, votre navigation principale, peut-être une boîte de recherche, peut-être un bandeau promotionnel. Pour une personne qui clique avec une souris, ce bloc répété est du mobilier invisible - l'œil saute directement au titre. Pour quelqu'un qui navigue au clavier, au lecteur d'écran ou avec un dispositif à commutateur, il n'y a aucun saut possible. Cette personne arrive en haut de la page et doit parcourir chacun de ces liens, un appui à la fois, sur chaque page, avant même d'atteindre le contenu qu'elle est venue chercher. Trente liens de navigation, multipliés par chaque page, multipliés par chaque visite. La réponse de WCAG à cela est l'une de ses règles les plus anciennes et les moins spectaculaires, et aussi l'une des moins coûteuses à satisfaire : donnez aux gens un moyen de contourner le bloc répété. Elle est de niveau A, le palier de conformité le plus fondamental, et elle se trouve à l'intérieur de la norme que l'Ontario applique réellement. La correction classique tient en un seul lien.
Faits essentiels
- Le critère de succès 2.4.1 Contourner des blocs de WCAG (Web Content Accessibility Guidelines) est de niveau A et fait partie de la norme depuis WCAG 2.0 - le palier de conformité le plus fondamental qui soit (W3C).
- La règle exige un mécanisme pour contourner les blocs de contenu répétés sur plusieurs pages, comme la navigation du site. Le W3C énumère trois moyens suffisants d'y parvenir : un lien d'évitement, des points de repère ARIA / régions HTML5 corrects, ou une structure de titres correcte (W3C).
- Le rapport WebAIM Million 2026 a constaté qu'environ 10 % des liens d'évitement qu'il a testés ne fonctionnaient pas réellement pour les utilisateurs au clavier - présents dans le balisage, mais brisés en pratique (WebAIM).
- Le RNAI de l'Ontario (Règlement sur les normes d'accessibilité intégrées, Règl. de l'Ont. 191/11), art. 14, exige des organisations de 50 employés ou plus qu'elles respectent WCAG 2.0 niveau AA sur les sites Web publics, et le niveau AA intègre tous les critères de niveau A (ontario.ca).
- Le prochain RCL (Rapport de conformité en matière d'accessibilité) pour les organisations de 20 employés ou plus est dû le 31 décembre 2026 (ontario.ca).
Qu'exige réellement « Contourner des blocs » ?
Moins que ce que le nom suggère, et plus que ce que la plupart des sites livrent. Le 2.4.1 ne vous demande pas de retirer votre navigation, de la raccourcir ou de changer son apparence. Il demande une seule chose : un moyen de dépasser le bloc qui se répète d'une page à l'autre, afin qu'une personne qui utilise la page sans souris n'ait pas à traverser tout votre menu pour atteindre l'article, le produit ou le formulaire pour lequel elle a ouvert la page.
Le mécanisme le plus familier est le lien d'évitement - le lien « Passer au contenu principal » que vous avez probablement vu apparaître dans le coin supérieur gauche d'un site bien construit dès que vous appuyez sur Tab. Il est habituellement caché jusqu'à ce qu'il reçoive le focus clavier, puis il apparaît, et son activation déplace le focus directement au début du contenu principal. Ce motif « caché jusqu'au focus » est délibéré et permis : le lien n'a pas besoin d'encombrer la conception visuelle, il n'a qu'à être présent pour la personne qui en a besoin.
Mais le lien d'évitement n'est pas le seul moyen de satisfaire la règle, et c'est là que se loge beaucoup de confusion. Les techniques suffisantes du W3C vous offrent trois voies vers la même destination, et un site qui structure bien son contenu peut satisfaire le 2.4.1 sans aucun lien d'évitement visible. Ce qui compte, c'est qu'un mécanisme de contournement existe et fonctionne - pas lequel des trois vous avez choisi.
Pourquoi tant de liens d'évitement échouent-ils auprès de ceux à qui ils sont destinés ?
Parce qu'un lien d'évitement est trompeusement facile à ajouter et étonnamment facile à briser. L'analyse WebAIM Million 2026 - la même vaste enquête que nous avons décortiquée dans le portrait de la raison pour laquelle l'accessibilité a mesurablement empiré cette année - a constaté qu'environ un sur dix des liens d'évitement détectés ne fonctionnait pas. Le lien était dans le HTML, de sorte qu'une case à cocher automatisée le comptait comme « présent », mais l'activer ne faisait rien d'utile.
Les modes de défaillance sont constants. Un lien d'évitement qui pointe vers une ancre qui n'existe plus sur la page n'envoie le focus nulle part. Un lien dont la cible n'est pas réellement focalisable - parce que la région principale n'a pas d'id que le lien peut atteindre, ou parce que la destination ne peut recevoir le focus - déplace la page visible mais laisse le focus du clavier bloqué en haut, de sorte que le Tab suivant ramène l'utilisateur droit dans le menu qu'il tentait de fuir. Et un lien d'évitement caché avec display:none au lieu de la technique correcte « masqué visuellement jusqu'au focus » est invisible pour tout le monde, utilisateurs au clavier compris.
Il y a une défaillance plus discrète, aussi : l'élément flottant « serviable ». Si un en-tête fixe, un bandeau de témoins ou un widget de clavardage se trouve par-dessus l'endroit où le focus atterrit après l'évitement, l'utilisateur a techniquement sauté mais ne peut voir où il est. Cela recoupe le 2.4.11 Focus non masqué, l'un des critères plus récents que nous couvrons dans le guide d'accessibilité au clavier. La leçon, dans tout cela, est la même : un mécanisme de contournement doit être testé en l'utilisant, pas confirmé en le repérant dans le code source.
Points de repère et titres : quels sont les deux autres moyens de satisfaire le 2.4.1 ?
Si un lien d'évitement visible ne convient pas à votre conception, la règle vous offre deux solutions structurelles, et les deux valent la peine d'être présentes de toute façon, car elles aident bien au-delà de ce seul critère.
La première est les points de repère. Envelopper votre page dans les bonnes régions HTML5 - <header>, <nav>, <main>, <footer> - ou leurs équivalents ARIA donne aux technologies d'assistance une carte intégrée. Un utilisateur de lecteur d'écran peut sauter directement à la région main, ou passer d'un point de repère à l'autre, sans aucun lien spécial de votre part. C'est le même travail structurel qui rend un site navigable au départ, et c'est pourquoi il occupe le centre de notre guide sur la structure pour lecteurs d'écran.
La seconde est une structure de titres correcte : un seul <h1>, une descente logique à travers les <h2> et <h3>, et aucun texte décoratif se faisant passer pour un titre. Les utilisateurs de lecteur d'écran affichent couramment une liste de tous les titres et sautent à la section voulue, ce qui est en soi un moyen de contourner le bloc répété. Réussissez de vrais titres et de vrais points de repère, et vous avez satisfait le 2.4.1 deux fois plutôt qu'une - tout en améliorant votre site pour les moteurs de recherche et les utilisateurs au clavier voyants.
Comment le vérifier, et quel est le risque si vous ne le faites pas ?
Vous pouvez tester ceci vous-même en moins d'une minute, sans rien installer :
- Chargez n'importe quelle page intérieure et appuyez une fois sur Tab. Sur un site bien construit, un lien « Passer au contenu principal » devrait apparaître, habituellement en haut à gauche. Appuyez sur Entrée. Puis appuyez de nouveau sur Tab - l'élément focalisable suivant devrait se trouver dans votre contenu principal, pas de retour dans le menu. Si le focus revient à la navigation, votre lien d'évitement est l'un des brisés.
- S'il n'y a pas de lien d'évitement, vérifiez votre structure. La page utilise-t-elle de vraies régions
<main>,<nav>et<header>? A-t-elle un seul<h1>et un ordre de titres sensé ? Si les deux sont solides, vous satisfaites probablement le 2.4.1 structurellement. - Surveillez l'atterrissage masqué. Après l'évitement, voyez-vous où le focus est allé, ou est-il caché sous une barre fixe ou un bandeau ?
Un analyseur automatisé vous dira si un lien d'évitement existe dans le balisage. Il ne peut vous dire si l'activer déplace réellement le focus vers un contenu visible et utilisable - ce qui est précisément pourquoi les propres données de WebAIM montrent tant de liens d'évitement « présents » qui échouent à l'usage. C'est un cas de plus où une analyse n'est pas un audit : la case est verte et l'obstacle est toujours là.
Quant aux enjeux, le portrait honnête est celui qui s'applique à tout obstacle d'accès. En Ontario, la LAPHO (Loi sur l'accessibilité pour les personnes handicapées de l'Ontario) n'a aucun droit d'action privé, donc personne ne vous poursuit directement en vertu de celle-ci ; la voie vivante pour un individu est le TDPO (Tribunal des droits de la personne de l'Ontario) en vertu du Code des droits de la personne de l'Ontario, et voici comment une plainte se déroule réellement. Si vous vendez aux États-Unis, une navigation au clavier bloquée est une allégation courante dans le contentieux Web lié à l'ADA (Americans with Disabilities Act). La réponse durable n'est ni un avertissement ni un module ajouté - une surcouche ne peut ajouter de façon fiable un lien d'évitement fonctionnel à une page qu'elle n'a pas construite. C'est une remédiation documentée : une trace datée de ce que vous avez trouvé et corrigé, ce qu'un RCL honnête devrait refléter d'ici le 31 décembre 2026.
La bonne nouvelle, c'est que de tous les manquements de la liste, celui-ci est parmi les moins coûteux à corriger. Un lien d'évitement fonctionnel, c'est quelques lignes de HTML. De vrais points de repère et de vrais titres sont une structure que vous devriez avoir de toute façon. Il figure sur la liste parce qu'il manque si souvent, pas parce qu'il est difficile.
Voyez si les utilisateurs au clavier peuvent dépasser votre navigation et vérifiez d'autres problèmes d'accessibilité - rapport Vayle gratuit, environ 30 secondes : vayle.art. Il détecte les surcouches, révèle vos véritables manquements à WCAG et vous indique exactement ce qui s'applique légalement à votre organisation en Ontario. Sans engagement.
Vayle est un studio d'ingénierie de l'accessibilité à distance au service de l'Ontario. Renseignements généraux, pas un avis juridique.