Accessibilité d'un chatbot : tests RGAA et WCAG

Un chatbot est un composant interactif posé sur le site : il doit être aussi accessible que le reste du site. En pratique, cinq points concentrent les difficultés. Il faut pouvoir ouvrir, utiliser et fermer la fenêtre au clavier. Le focus doit rester visible. Les réponses doivent être annoncées aux lecteurs d'écran. La fenêtre doit tenir à 200 % de zoom et sur un écran étroit. Et le texte doit être assez contrasté. Ces points se testent en une heure, avant la mise en ligne.

Le cadre en quelques repères

• RGAA. Le référentiel général d'amélioration de l'accessibilité est en version 4.1.2, avec 106 critères de contrôle. Le site officiel annonce une version 5 en cours de rédaction, avec une publication prévue fin 2026.
• WCAG. Les règles internationales WCAG 2.2 (règles pour l'accessibilité des contenus web) sont une recommandation du W3C depuis le 12/12/2024. Les critères cités plus bas en sont tirés.
• Commerce en ligne. Le décret n° 2023-931 du 09/10/2023 rend des exigences d'accessibilité applicables aux services fournis après le 28/06/2025. La liste des services concernés comprend le commerce électronique (article D. 412-50 du Code de la consommation). Le texte prévoit des allègements pour les entreprises employant moins de dix personnes sur certaines obligations. Savoir si le site d'un client entre dans ce champ est une question juridique : renvoyez-le vers ses conseils pour son cas précis.
• Mention IA. Le règlement européen sur l'IA impose d'informer les personnes qu'elles échangent avec une IA, et précise que cette information doit respecter les exigences d'accessibilité (article 50, paragraphe 5). Le message d'accueil du chatbot doit donc lui-même être lisible par un lecteur d'écran.

Les tests à faire, critère par critère

L'annonce des réponses, en détail

C'est le point le plus souvent raté. Une réponse qui s'affiche sans être annoncée est invisible pour un utilisateur de lecteur d'écran.

La documentation MDN décrit le rôle ARIA log comme adapté à un historique de « chat ». Ce rôle se comporte déjà comme une zone qui annonce ses changements, et MDN conseille d'ajouter un aria-live="polite" redondant pour maximiser la compatibilité. Le mode polite fait lire les changements quand l'utilisateur est inactif. Le mode assertive interrompt toute lecture en cours : MDN le réserve aux alertes critiques. Pour un chat, c'est donc polite.

La page du W3C qui explique le critère 4.1.3 cite d'ailleurs la technique ARIA23, qui consiste à utiliser role=log pour des mises à jour successives.

Si le widget est fourni par un éditeur, vous ne contrôlez pas son code : vérifiez ce comportement avec un lecteur d'écran (NVDA sous Windows, VoiceOver sur Mac ou iPhone), puis signalez les défauts à l'éditeur.

Ce que vaut la déclaration de l'éditeur

Certains éditeurs publient une déclaration d'accessibilité pour leur widget. Lisez-la pour son périmètre autant que pour son résultat. Exemple : Crisp indique que son widget de chat est conforme au RGAA 4.1.2, avec une déclaration établie le 30/06/2026. La même page précise que cette déclaration ne couvre ni sa messagerie, ni ses applications mobiles, ni le site entier de ses clients.

Autrement dit, même avec un widget audité :

• vos personnalisations (couleurs, taille, position) peuvent faire baisser le contraste ou masquer le focus ;
• l'interaction avec le site (bandeau cookies, en-tête collant, autre bulle) peut créer un piège au clavier ;
• le contenu des réponses (liens « cliquez ici », tableaux, images sans texte de remplacement) relève de la configuration, donc de vous.

Ce que vous pouvez régler vous-même

• Couleurs. Choisissez des couleurs de marque qui gardent le rapport de 4,5:1 pour le texte des bulles.
• Position. Évitez que la bulle recouvre un bouton important ou le lien « Gérer mes cookies ».
• Message d'accueil. Court, en texte (pas en image), il dit qu'il s'agit d'une IA et comment joindre un humain.
• Réponses. Demandez à l'assistant des liens explicites (« Voir nos tarifs ») plutôt que « ici ».
• Ouverture automatique. Une fenêtre qui s'ouvre seule peut déplacer le focus et désorienter : préférez l'ouverture à la demande.

Liste de contrôle à joindre à la recette

1. Bulle atteignable et activable au clavier.
2. Sortie de la fenêtre possible au clavier, focus rendu au bouton d'ouverture à la fermeture.
3. Focus visible partout, jamais caché par la bulle.
4. Réponses annoncées par un lecteur d'écran sans déplacer le focus.
5. Zoom à 200 % et largeur de 320 pixels CSS sans perte.
6. Contrastes vérifiés avec vos couleurs.
7. Message d'accueil textuel qui signale l'IA.
8. Déclaration de l'éditeur archivée, avec son périmètre.

Ces tests se refont après une mise à jour importante du widget ou une refonte graphique : inscrivez-les dans le contrat de maintenance.