Quand on parle d’accessibilité web, on pense souvent aux normes et aux check-lists. Mais en pratique, certaines fonctionnalités comme les filtres personnalisés, les cartes ou les menus déroulants posent des défis bien plus complexes. 

Chez Evolving Web, nous avons souvent été confrontés à ces obstacles. Dans cet article, nous partageons des approches concrètes que nous avons développées pour relever ces défis d’accessibilité.

Le rôle des outils de test d'accessibilité

Pour répondre aux normes WCAG AA et garantir une expérience accessible à tous, nous utilisons régulièrement des outils comme Axe DevTools, DubBot, SortSite et Siteimprove. Mais détecter les problèmes d’accessibilité en phase de développement ou d’assurance qualité arrive souvent trop tard. D’où l’importance d’anticiper les fonctionnalités qui poseront problème. Concepteurs, stratèges, chefs de projet et experts QA ont tous un rôle à jouer pour repérer ces zones sensibles dès le départ.

Fonctionnalités à signaler pour une revue d'accessibilité

Rendre les mégamenus accessible

Un mégamenu va souvent bien au-delà d’une simple liste de liens : titres, visuels, contenus mis en avant, résumés ou zones interactives comme des boutons et champs de recherche peuvent s’y intégrer. Mais sans une gestion rigoureuse de l’interaction au clavier et avec les lecteurs d’écran, ces éléments deviennent vite problématiques sur le plan de l’accessibilité.

Problématique

Lorsque du contenu s’ajoute aux liens principaux d’un mégamenu, les utilisateurs au clavier ou avec un lecteur d’écran peuvent rencontrer plusieurs obstacles :

• Ne pas pouvoir accéder à l’ensemble du contenu à l’aide de la touche Tab si le focus n’est pas correctement géré.
• Être bloqué dans le menu à cause de boucles de pièges clavier, notamment en cas de mauvaise utilisation de l’attribut tabindex.
• Perdre leurs repères, car les sections du menu ne sont pas clairement annoncées.
• Utiliser aria-expanded="true" sur l'élément parent du menu lorsque le menu est ouvert, et aria-controls pour faire référence au conteneur du sous-menu.

Solution

Pour rendre le mégamenu entièrement accessible — pas seulement les liens — nous appliquons quelques techniques spécifiques :

• Assurer que tous les éléments accessibles au focus à l’intérieur du menu ouvert (liens, boutons, champs de formulaire) sont atteignables dans un ordre logique avec la touche Tab.
• Utiliser aria-expanded="true" sur l'élément parent du menu lorsque le menu est ouvert, et aria-controls pour faire référence au conteneur du sous-menu.
• Ajouter aria-hidden="false" au conteneur du menu ouvert, afin que les lecteurs d'écran sachent quand le contenu du menu est disponible.
• Déplacer le focus sur le premier élément accessible à l’intérieur du panneau lors de l’ouverture du menu et utiliser des écouteurs de clavier (comme la touche Échap et la navigation par flèches) pour permettre aux utilisateurs de sortir ou de naviguer proprement entre les éléments.
• S’assurer que les styles de focus visibles sont présents pour les titres supplémentaires et les boutons dans les menus déroulants.

Exemple

Le site Web du musée ROM ouvre un mégamenu sous l’onglet « Visite ». Le menu affiche trois colonnes de contenu : une liste de liens tels que « Renseignements aux visiteurs » et « Accessibilité », une tuile visuelle pour « Plans et visites du musée » avec une image, et une autre pour « Emplacement et stationnement ». Complètement à droite, un panneau présente les heures d’admission par date. La mise en page reflète les bonnes pratiques en matière d’accessibilité, en regroupant le contenu de façon logique, en assurant un ordre de tabulation clair et en offrant une structure visuelle pouvant être enrichie de rôles ARIA tels que aria-expanded et aria-hidden, afin d’assurer la compatibilité avec les lecteurs d’écran et une navigation fluide au clavier.
 

Commutation du menu de navigation principal

Dans de nombreuses conceptions de navigation de site web, notamment sur desktop, les éléments du menu de premier niveau agissent à la fois comme des liens et comme des bascules pour les menus déroulants. Mais combiner ces deux fonctions dans un seul élément peut troubler les utilisateurs au clavier et les lecteurs d'écran. Pour simplifier l’expérience, nous concevons souvent la navigation de sorte que les éléments du premier niveau avec des sous-menus agissent uniquement comme des boutons de bascule, et non comme des liens.

Problème

Lorsqu’un élément de premier niveau fonctionne à la fois comme un lien et comme un bouton de bascule de menu déroulant, cela peut entraîner :

• Une confusion pour les utilisateurs de clavier : Est-il nécessaire d'appuyer sur la touche Entrée pour activer le lien ou dérouler le menu ?
• Un comportement disparate entre les lecteurs d'écran en fonction de la structuration du code.
• Un défi à maintenir correctement le focus et les états ARIA, particulièrement lors de l'imbrication de plusieurs niveaux.

Solution

 Pour offrir une expérience plus claire et accessible, nous :

• Nous transformons l'élément parent du menu en un bouton (ou lien avec rôle="button") qui a uniquement pour fonction de changer la visibilité du sous-menu, au lieu de diriger vers une nouvelle page.
• Employons le premier lien du menu déroulant pour créer un lien vers la page principale de cette section du site internet (qui est parfois une page de section).
• Nous utilisons aria-expanded="false" sur le bouton de commutation et nous le passons à true lorsque le menu déroulant est ouvert.
• Ajoutons aria-controls qui fait référence à l'identifiant du conteneur du sous-menu pour une meilleure compréhension contextuelle avec un lecteur d'écran.
• Veillons à ce que le sous-menu soit caché par défaut (en utilisant aria-hidden="true" et/ou display: none), et qu'il soit dévoilé lorsqu'une action de basculement est effectuée.
• Organisons les éléments accessibles dans le sous-menu dans une séquence logique pour la touche Tab, et assurons-nous que la navigation se fasse exclusivement au clavier à travers tous les éléments avant de rétablir le focus sur la navigation parente.

Exemple

Nous avons déployé ce modèle sur le site web du Georgia Center, où les éléments de menu de premier niveau avec des sous-menus fonctionnent uniquement comme des interrupteurs. Cela donne la possibilité aux utilisateurs de clavier d'examiner tous les éléments du sous-menu sans le danger d'une navigation accidentelle, tout en fournissant aux utilisateurs de lecteurs d'écran des indications précises sur le contenu extensible.

Rendre les filtres de recherche AJAX accessibles aux lecteurs d'écran

Nous apprécions l'emploi d'AJAX pour assurer que les filtres de recherche soient rapides et réactifs — le contenu se met à jour en temps réel sans nécessité de recharger la page. Cependant, même si cela optimise l'expérience visuelle et les performances, cela pose des défis pour les usagers de lecteurs d'écran, qui pourraient ne pas percevoir que certains éléments de la page ont été modifiés.

Problématique

Lorsque les résultats sont mis à jour de manière dynamique (par le biais d'AJAX), les lecteurs d'écran ne perçoivent pas automatiquement ou n'informent pas ces modifications :

• Il se peut que les utilisateurs ne soient pas en mesure de déterminer si leur choix de filtre a eu un impact.
• La section des résultats peut changer visuellement sans être annoncée aux utilisateurs non-visuels.
• En l'absence d'indications appropriées, les utilisateurs pourraient se sentir perdus ou croire que le filtre « n'a pas marché ».

Solution

Pour garantir que les mises à jour dynamiques soient communiquées aux technologies d’assistance, nous:

• Ajoutons une région aria-live="polite" autour de la zone de contenu qui se met à jour (par exemple, résultats de recherche ou comptages).
• Insérons un message explicite tel que « 12 résultats trouvés » suite à l’application des filtres.
• Utilisons JavaScript pour activer des mises à jour dans cette zone une fois la requête AJAX terminée.
• Testons l’implémentation avec des lecteurs d’écran pour vérifier que la région en direct est réellement lue.

Exemple

Sur le site web du Georgia Gwinnett College, nous avons ajouté une annonce pour les lecteurs d’écran dans les vues Drupal qui nécessitent un rechargement de page. Nous avons ajouté le compteur au lien « passer au contenu principal » à l’aide de JavaScript afin qu’il soit lu en premier après le chargement de la page.

 

Rendre les menus de sélection personnalisés accessibles

Les concepteurs apprécient beaucoup les éléments de formulaire sur mesure, particulièrement lorsqu'un projet exige une présentation plus personnalisée ou raffinée. Toutefois, substituer les contrôles de formulaire natifs tels que les éléments <select> par des versions JavaScript pose des problèmes en matière d'accessibilité. Bien que les éléments HTML natifs soient par défaut les plus accessibles, ils n'offrent pas la souplesse de conception désirée par les clients et les designers.

 Problème

 Les menus de sélection personnalisés ont souvent :

• Des problèmes de navigation clavier (Tab, flèches, Échap) s’ils ne sont pas entièrement implémentés.
• Un déficit de prise en charge pour les lecteurs d'écran, particulièrement en ce qui concerne les annonces de focus, les modifications de sélection et les états ouvert/fermé.
• Des obstacles pour les utilisateurs dans le champ, ou des échecs à restituer correctement le focus après une sélection.

Solution

Pour équilibrer l’accessibilité avec la personnalisation visuelle, nous utilisons souvent Select2—une bibliothèque JavaScript qui imite les sélections natives tout en offrant un meilleur style et support des fonctionnalités. 

Voici notre méthode pour assurer son bon fonctionnement :

• Exploiter les fonctions d'accessibilité intégrées de Select2, y compris le soutien ARIA et les schémas de navigation par clavier.
• Adaptateur au besoin le comportement—par exemple, en veillant à ce que la mise au point retourne sur l'élément adéquat après une sélection, ou que la technologie d'assistance indique correctement les états ouverts/fermés.
• Vérifions chaque mise en œuvre manuellement à l'aide de lecteurs d'écran et d'un clavier pour identifier les scénarios particuliers.

Rendre les modales (lightboxes) accessibles au clavier et aux lecteurs d’écran

Pour présenter du contenu visuel — des galeries d'images, des échantillons de produits, des expositions — les créateurs ont fréquemment recours aux modales ou lightboxes. Bien que ces expériences soient visuellement captivantes, elles risquent de devenir des entraves à l'accessibilité si elles ne sont pas méticuleusement pensées pour les utilisateurs qui utilisent un clavier et les lecteurs d'écran.

Problème

 Les bibliothèques de lightbox/carrousel standard présentent souvent les limitations suivantes :

• Le focus du clavier n'est pas correctement verrouillé dans la modale, ce qui permet aux utilisateurs d'accéder au contenu caché en arrière-plan.
• L'absence de rôles ARIA ou d'étiquettes adéquates empêche les lecteurs d'écran de saisir le contexte de la modale.
• Aucune méthode intuitive pour fermer la modale à l'aide du clavier.

Solution

Nous employons Parvus, une bibliothèque lightbox configurable, afin de créer des modales accessibles pour les galeries d'images. Si la modale est employée pour présenter du contenu ou un menu, nous créons une modale sur mesure en JavaScript. 

Voici quelques recommandations utiles :

• Incorporer role="dialog" et aria-modal="true" au conteneur de la fenêtre modale pour signaler aux lecteurs d’écran qu’ils doivent lui prêter attention.
• Ajoutez un bouton de fermeture muni d'une étiquette explicite (par exemple : aria-label="Fermer la modale").
• Utilisez aria-hidden="true" pour cacher le contenu de fond aux lecteurs d’écran tant que la modale reste ouverte.

Exemple

Sur le site web du Musée royal de l'Ontario, nous employons la bibliothèque Parvus pour concevoir les lightboxes modales pour les expositions. Lorsqu'un utilisateur clique sur l'icône d'information d'une image, une fenêtre modale s'ouvre avec un contenu détaillé et des illustrations. 

Dans la fenêtre modale : 

• Les utilisateurs de clavier peuvent naviguer à travers tous les éléments interactifs, y compris les textes, les images et le bouton de fermeture à l'aide de la touche Tab.
• Après le dernier élément, l'indicateur de focus revient au premier élément à l'intérieur de la fenêtre modale.
• Les utilisateurs peuvent appuyer sur Échap pour fermer la boîte de dialogue et continuer la navigation à partir de l'endroit où ils se sont arrêtés.
   

Éviter les pièges de clavier dans les sliders

On a souvent recours aux sliders et carrousels pour mettre en lumière le contenu essentiel, en particulier dans les sections « héro » ou pour les produits. Cependant, des bibliothèques telles que Swiper.js peuvent engendrer des problèmes d'accessibilité au clavier en enfermant les utilisateurs dans le carrousel.

Problème

Le mécanisme de boucle de Swiper reproduit les diapositives pour faciliter un défilement sans fin. Cela engendre des conséquences imprévues :

• Les éléments répétitifs demeurent dans le DOM et sont accessibles via le focus, bien qu’ils soient invisibles.
• Cela engendre un cycle interminable pour les utilisateurs au clavier, incapables de quitter le curseur.

Solution

Le mécanisme de boucle de Swiper reproduit les diapositives pour faciliter un défilement sans fin. Cela engendre des conséquences imprévues :

• Nous attribuons dynamiquement tabindex="-1" à toutes les diapositives invisibles et le supprimons uniquement des éléments visibles.
• Nous identifions les modifications de diapositive en utilisant les événements Swiper (slideChange, etc.) et actualisons les éléments sur lesquels on peut focaliser en direct.
• Cela assure que seuls les éléments en vue peuvent être navigués au moyen du clavier, facilitant pour les utilisateurs la transition vers le contenu suivant après le diaporama.
• Nous procédons aussi à l'essai du curseur avec des éléments concrets (liens, boutons) afin d'assurer une interaction sans accroc.

Exemple

Dans un projet utilisant Swiper.js, chaque section comportait un article ou une nouvelle associée. Avec le mode de répétition activé, tous les liens demeuraient focalisables, même lorsqu'ils étaient hors de vue, générant ainsi une boucle de tabulation sans fin. Pour remédier à cette situation, nous avons incorporé du JavaScript sur mesure afin de rendre uniquement les éléments visibles accessibles.

Ce simple ajustement a permis aux utilisateurs au clavier de naviguer dans le slider une seule fois, puis de poursuivre leur parcours sur le reste de la page.


 

Gérer les cartes SVG non essentielles de manière accessible

Les cartes SVG peuvent servir d'outil visuel et interactif pour guider les utilisateurs dans l'exploration du contenu, notamment pour les annuaires régionaux ou les instruments de filtrage. Cependant, lorsque ces cartes ne sont pas indispensables pour la navigation, elles peuvent entraver l'accessibilité.

Problème

 Souvent, les cartes SVG :

• Comprennent de multiples zones interactives qui exigent des étiquettes ARIA et une navigation adéquate au clavier.
• Ne sont pas intrinsèquement utilisables au clavier, demandant une personnalisation poussée pour le focus, l'interaction et la compatibilité avec les logiciels de lecture d'écran.

Solution

 Lorsque la carte n’est pas essentielle à l’expérience utilisateur, nous :

• Masquons les technologies d'assistance en utilisant aria-hidden="true" ou une méthode similaire.
• Proposons une option accessible - telle qu'une liste organisée ou un menu à défilement.

Exemple

Nous avons utilisé une carte régionale en SVG sur le site de l'Agence des médicaments du Canada pour orienter les utilisateurs vers les programmes en fonction de leur province. Cependant, garantir une accessibilité totale pour chaque région (étiquettes, mise au point, clavier) aurait requis un développement complexe. Au lieu de cela, nous avons inséré un lien vers un « Tableau des données » accessible qui fournit les mêmes informations sous une forme organisée.

Rendre les icônes significatives pour les lecteurs d’écran et les éditeurs

Les icônes sont omniprésentes sur les sites modernes. Elles servent à alléger le contenu, transmettre un message rapidement ou renforcer une identité visuelle. Mais lorsqu’une icône est utilisée comme seule manière de transmettre une information, elle devient du contenu — et doit donc être accessible.

Problème

 Les icônes utilisées comme contenu doivent :

• Être étiqueté avec des descriptions claires pour les lecteurs d'écran.
• Facilement administrables dans le CMS par les rédacteurs de contenu.
• Éviter les répétitions ou les messages déconcertants entre l'icône et le texte.

Autrement, un lecteur d'écran pourrait omettre l'icône ou ne fournir qu'un message standard tel que « image » ou « graphique ».

Solution

Pour garantir l’accessibilité des icônes et leur gestion éditoriale :

• Nous associons chaque icône à un texte uniquement perceptible par les lecteurs d'écran (par exemple : « Sans gluten ») en utilisant des éléments HTML invisibles.
• Nous autorisons les éditeurs à entrer ce texte directement dans le CMS, sans avoir besoin de le coder “en dur”.
• Nous mettons en œuvre des rôles ARIA afin que les lecteurs d'écran perçoivent les icônes comme des étiquettes appropriées plutôt que comme de simples éléments décoratifs.

Exemple

Nous avons mis en place cette solution sur le site web de l'Université de Géorgie (UGA) pour le menu du restaurant, où des icônes transmettent des informations diététiques essentielles. En structurant le balisage pour inclure du texte descriptif caché et en permettant un contrôle éditorial dans le CMS, nous avons rendu l'interface à la fois accessible et durable pour les mises à jour de contenu continues.
 

Assurer la visibilité des états de focus en mode sombre

L'option de mode sombre s'est imposée comme une tendance de design prisée sur les sites internet contemporains. Cela diminue la fatigue oculaire, conforme aux préférences de l'utilisateur et présente un aspect soigné. Cependant, l'activation d'un mode sombre complique l'accessibilité, notamment en termes de contraste des couleurs et de visibilité du focus clavier.

Problème

• Les différences de couleur conformes aux normes en mode clair peuvent échouer en mode sombre, surtout lors de l'interaction par survol ou focus.
• Les indicateurs de focalisation peuvent s'effacer ou devenir trop discrets sur des fonds sombres.
• Si les styles de focus ne sont pas vérifiés dans l'ensemble des thèmes, les utilisateurs qui naviguent au clavier peuvent perdre leurs repères visuels.

Solution

• Tester tous les états (par défaut, survol, focus, actif) en mode clair et sombre.
• Respecter les ratios de contraste WCAG :
  • 4.5:1 pour le texte
  • 3:1 pour les composants de l’interface (bordures, contours, anneaux de focus)
• Personnaliser les styles pour assurer des indicateurs de focus visibles en mode sombre (par exemple, en utilisant des box-shadows ou des outlines contrastants).

Points clés : Ce que les équipes devraient surveiller

Peu importe que vous soyez développeur, designer ou chef de projet, voici quelques éléments à prendre en considération :

• Assurez-vous de la compatibilité avec le clavier et le lecteur d'écran dès les premières étapes du développement, notamment pour les éléments interactifs.
• N'ayez pas une confiance exclusive dans les instruments automatisés. Il est indispensable de réaliser des tests manuels en adoptant des scénarios d'utilisation.
• Envisagez des options accessibles, comme une reproduction textuelle d'une carte ou un filtre statique.

Conclusion

L'accessibilité ne se limite pas à respecter des critères ou à appliquer des normes : il s'agit de concevoir des expériences numériques véritablement inclusives. En repérant les fonctionnalités difficiles dès le début, votre équipe est en mesure de mieux organiser, évaluer et concevoir en gardant l'accessibilité à l'esprit - réduisant ainsi les retouches ultérieures et améliorant l'expérience pour tous les utilisateurs.

À Evolving Web, nous assistons les organisations à surmonter ces challenges avec confiance. Que ce soit pour des audits d'accessibilité, la création de composants sur mesure ou des conseils stratégiques, nous assistons les équipes à concevoir des sites web qui ne sont pas seulement conformes, mais véritablement accessibles.  Si vous souhaitez optimiser l'accessibilité de votre site internet ou relever un challenge particulier, n'hésitez pas à nous joindre. Nous sommes présents pour vous apporter de l'aide.