Rendre LiipGPT accessible: notre parcours vers la conformité WCAG-AA

Après nous être d’abord concentré·e·s sur l’approche thématique de notre chatbot LiipGPT — présentée récemment lors du relaunch de ZüriCityGPT — nous avons orienté notre attention vers l’accessibilité avec pour objectif d’atteindre la conformité WCAG-AA. Comme pour beaucoup de fonctionnalités, nous avons d’abord observé comment les référence du secteur comme ChatGPT, Perplexity et Claude traitent l’accessibilité. Bien que nous ayons constaté un potentiel d’amélioration partout, cela nous a inspiré·e·s à réfléchir à la manière de faire mieux de notre côté.

Notre parcours vers l’accessibilité s’est articulé autour de quatre étapes principales: des scans automatiques et quick fixes, la navigation au clavier, l’optimisation pour le zoom mobile ainsi que l’optimisation pour les lecteur·rice·s d’écran.

Scans automatiques et quick fixes

Nous avons commencé par des tests automatisés d’accessibilité à l’aide d’extensions de navigateur comme IBM Equal Access Accessibility Checker et axe DevTools. Ces outils nous ont aidé·e·s à identifier des problèmes fréquents: labels manquants, contraste de couleurs insuffisant, HTML sémantique incorrect et attributs ARIA absents. Bien que les scans automatisés ne détectent qu’environ 40 % des problèmes d’accessibilité, ils constituent une base de départ solide.

Navigation au clavier

Une navigation correcte au clavier est fondamentale pour l’accessibilité. Garantir que la navigation de base avec la touche Tab fonctionne dans toute l’application est relativement simple. Des composants plus complexes comme les tabs, les menus et les fenêtres de dialogue nécessitent cependant des interactions clavier plus avancées comme l'utilisation des flèches directionnelles, la gestion de la touche Escape ou encore la gestion du focus selon les directives officielles du W3C. Les utilisateur·rice·s qui dépendent de la navigation au clavier s’attendent à ces schémas spécifiques. S’en écarter provoque confusion et frustration. Plutôt que d’implémenter ces schémas depuis zéro, nous avons utilisé Bits UI, une bibliothèque headless UI qui applique correctement ces directives d’accessibilité.

Au-delà des composants individuels, nous avons également implémenté des boucles de focus et une restauration du focus au niveau de l’application afin que les utilisateur·rice·s restent toujours orienté·e·s en passant d’une zone de l’interface du chat à une autre.

Optimisation pour le zoom mobile

Lors de tests utilisateur pour meinplatz.ch avec des personnes en situation de handicap, nous avons observé quelque chose de frappant: beaucoup naviguent sur les sites web sur mobile avec un zoom de 200 % ou plus et tiennent leur appareil à environ 10 cm de leurs yeux. Cette observation a mis en évidence une lacune critique dans la plupart des implémentations de chatbots.

La majorité des chatbots utilisent des éléments à position fixe: un champ de saisie en bas de l’écran et souvent un en-tête en haut. Lorsque les utilisateur·rice·s zooment fortement, ces éléments fixes peuvent occuper tout le viewport et rendre l’interface inutilisable. Malheureusement, les navigateurs ne permettent pas de détecter de manière fiable le niveau de zoom. Pour résoudre cela, nous utilisons l’Intersection Observer pour détecter lorsque l’en-tête ou le pied de page occupe plus d’espace que prévu. Dans ce cas, nous supprimons dynamiquement leur position fixe afin de rétablir l’utilisabilité.

Expérience avec les lecteurs d’écran

L’accessibilité pour les lecteur·rice·s d’écran n’apparaît pas automatiquement, elle nécessite une conception attentive. Nous nous sommes concentré·e·s sur la fourniture d’un contexte clair grâce à une structure de page propre (landmarks et titres). Les utilisateur·rice·s comprennent ainsi toujours où iels se trouvent et ce qui se passe, tout en disposant de raccourcis vers les zones les plus importantes de l’application.

Fournir du contexte

Nous avons implémenté une structure d’outline complète avec des landmarks pour la navigation principale, les paramètres et les zones de saisie. Chaque message contient des titres et des labels corrects. De plus, nous avons ajouté après le champ de saisie du chat (en bas de page) un skip-link permettant aux utilisateur·rice·s de revenir rapidement en haut de la page.

Défis avec les Web Components

Travailler avec des Web Components a apporté ses propres défis. VoiceOver est particulièrement sensible à la manière dont les bibliothèques sont implémentées. Nous avons travaillé en étroite collaboration avec l’équipe Bits UI (qui réagit très rapidement aux rapports de bugs) et avons par exemple implémenté des portails locaux pour les menus déroulants afin d’éviter des problèmes de navigation avec VoiceOver.

Gestion des annonces

L’un des défis les plus complexes a été la gestion des annonces VoiceOver lorsque plusieurs événements se produisent simultanément. Comme la mise en file des annonces ne fonctionne pas de manière fiable, nous avons soigneusement séquencé les événements et regroupé les annonces liées. Par exemple, lorsqu’un·e utilisateur·rice clique sur « Tout sélectionner » dans une liste d’options, des annonces séparées seraient normalement déclenchées pour chaque option et se remplaceraient mutuellement. À la place, nous annulons ces annonces individuelles et les remplaçons par un seul message clair qui résume la situation (tous les éléments sélectionnés ou désélectionnés, retour à la sélection prédéfinie, etc.).

Comme le chat est une SPA sans rechargement de page, il était également essentiel d’annoncer tous les changements visibles uniquement visuellement, comme par exemple le changement entre mode clair et sombre ou le changement de langue.

Flux du chat pour les lecteur·rice·s d’écran

Nous avons conçu l’expérience du chat spécifiquement pour les utilisateur·rice·s de lecteur d’écran :

• Le champ de saisie contient à la fois un placeholder et un aria-label avec le titre de la page. Cela fournit du contexte lors du chargement de la page, car le champ est automatiquement focalisé et les utilisateur·rice·s peuvent ainsi ignorer le contenu initial.
• Lorsqu’une réponse est générée, nous l’annonçons clairement afin de fournir le même retour qu’un indicateur de chargement visuel.
• Dès qu’une réponse est prête, elle est lue sans formatage Markdown (pas d’italique, pas de liens, etc.) afin de garantir un flux de lecture naturel.
• Après la lecture d’une réponse, nous indiquons que tu peux directement poser une nouvelle question ou naviguer vers les options du dernier message pour donner un feedback ou consulter les références. Nous ajoutons dynamiquement cette section interactive du dernier message à l’outline du document afin de créer un raccourci de navigation rapide.
• L’historique du chat est structuré comme une série d’articles avec des labels afin que les conversations précédentes soient faciles à parcourir.

Teste par toi-même

Tu peux découvrir ces améliorations avec Alva, le chatbot de l’administration du canton de Bâle-Ville. Essaie de naviguer avec VoiceOver (macOS) ou NVA (Windows), d’utiliser uniquement ton clavier ou de zoomer fortement sur un appareil mobile.

Un parcours continu

Notre prochain objectif est d’intégrer des tests automatisés d’accessibilité dans notre pipeline CI. Comme mentionné précédemment, les scans automatisés ne détectent qu’environ 40 % des problèmes d’accessibilité. Cela signifie que nous devons continuer à planifier soigneusement chaque nouvelle fonctionnalité et à la tester manuellement. Rien ne remplace les tests humains lorsqu’il s’agit d’accessibilité. Les outils automatisés peuvent signaler des labels manquants ou des problèmes de contraste, mais ils ne peuvent pas déterminer si une interface est réellement utilisable pour quelqu’un qui navigue avec un lecteur d’écran ou uniquement au clavier.

L’accessibilité est un parcours continu, pas une destination. Nous nous engageons à rendre LiipGPT utilisable par tout le monde et continuerons à faire évoluer notre approche sur la base des retours issus de la pratique.

Besoin d’aide pour l’accessibilité ?

Nous proposons des audits d’accessibilité pour identifier et corriger les problèmes dans tes applications. Si tu souhaites améliorer l’accessibilité de ton produit, contacte-nous, nous serons ravi·e·s de t’aider.