Le client, une enseigne spécialisée dans le mobilier de bureau, avait fait développer un widget d’assistance capable de répondre à des questions précises sur son catalogue — disponibilité, dimensions, délais de livraison — en interrogeant directement sa base produit via un serveur MCP. Techniquement impressionnant. Sur le plan de l’accessibilité, c’est resté un chantier classique, avec ses propres subtilités.
Ce cas décrit l’audit mené sur ce widget, les anomalies trouvées, et ce qui distingue vraiment ce type de composant d’un chatbot IA générique déjà traité par ailleurs.
Contexte du widget audité
Le widget s’affiche sur les fiches produit, sous la forme d’un champ de question libre. La réponse est construite en interrogeant, via MCP, un serveur qui expose les données de stock et de logistique en temps réel, puis reformulée en langage naturel par un modèle de génération avant affichage. Contrairement à un chatbot générique, les réponses portent donc sur des données précises et changeantes, ce qui a une conséquence directe sur l’audit : il ne suffit pas de tester une fois, il faut vérifier que le mécanisme d’annonce fonctionne quel que soit le contenu réellement retourné.
Première itération — la structure de base
Le premier passage a porté sur les fondamentaux : champ de saisie correctement étiqueté, bouton d’envoi focusable, zone de réponse identifiée. Le champ de saisie n’avait pas d’étiquette visible ni de <label> associé, remplacé par un simple attribut placeholder — une non-conformité fréquente, corrigée en quelques minutes.
Deuxième itération — l’annonce des réponses dynamiques
Le point le plus délicat concernait l’annonce des réponses. La zone de réponse n’utilisait aucun aria-live, ce qui signifiait qu’un utilisateur de lecteur d’écran ne recevait aucune notification lorsque la réponse générée par le modèle apparaissait à l’écran — il fallait deviner qu’une réponse était arrivée et aller la chercher manuellement. Le correctif a consisté à annoncer la zone en aria-live="polite", avec une attention particulière à ne déclencher l’annonce qu’une fois la réponse complète reçue, pas à chaque fragment de texte streamé par le modèle.
Le piège du texte streamé
Le widget affichait la réponse mot par mot, à mesure de sa génération, un effet visuel courant sur les interfaces d’IA générative. Avec une zone aria-live mal configurée, chaque fragment déclenchait une nouvelle annonce, rendant la lecture au lecteur d’écran totalement incompréhensible — un flot de mots isolés annoncés en boucle. La solution retenue attend la fin du flux avant de mettre à jour le contenu annoncé.
Troisième itération — la latence des données MCP
Dernier point spécifique à ce type de widget : le temps de réponse dépend de la disponibilité du serveur MCP interrogé en coulisses, avec des latences parfois plus longues que celles d’un chatbot purement conversationnel. Un indicateur de chargement visuel existait, mais sans équivalent sonore : un utilisateur de lecteur d’écran n’avait aucune indication qu’une réponse était en cours de préparation. Un message d’attente annoncé une seule fois, du type « Recherche des informations produit en cours », a réglé le problème sans surcharger l’utilisateur d’annonces répétées.
Ce qui distingue ce type d’audit
- Vérifier le comportement d’annonce avec plusieurs types de réponses réelles, pas un seul scénario de démonstration
- Tester des cas de latence longue, en simulant une réponse lente du serveur MCP
- Revoir l’audit à chaque évolution du schéma de données exposé par le serveur, car un nouveau format de réponse peut introduire de nouvelles anomalies
Le protocole utilisé en coulisses pour aller chercher la donnée n’a aucune importance pour l’accessibilité du widget. Ce qui compte, c’est ce qui atterrit dans le DOM et la façon dont c’est annoncé.
En résumé
Un widget assisté par IA branché en MCP n’échappe à aucune des règles d’accessibilité applicables à n’importe quel composant dynamique : étiquetage, gestion du focus, annonces vocales cohérentes. La vraie nouveauté tient à la nature changeante et parfois lente des réponses, qui impose de tester avec des données réelles et des scénarios de latence, plutôt qu’avec une seule démonstration figée.
