Chatbot accessible : le guide RGAA pour votre site web (2026)

Un chatbot peut réussir tous les scans automatiques d'accessibilité et rester inutilisable avec un lecteur d'écran. Nous sommes bien placés pour le dire : nous venons d'auditer en profondeur notre propre assistant, conçu par une équipe qui travaille sur l'accessibilité toute la journée, et l'audit a trouvé des défauts sérieux. Si vous ajoutez un assistant conversationnel à votre site, ou si un prestataire vous en vend un « conforme RGAA », ce guide passe en revue ce qui rend réellement un chatbot accessible : le widget, la conversation, le cas particulier du streaming IA, et la façon de tester le tout avant la mise en ligne.

Un chatbot accessible, c'est quoi ?

Un chatbot accessible est un agent conversationnel utilisable par tous, y compris au clavier seul et avec un lecteur d'écran : son bouton d'ouverture est atteignable, ses réponses sont annoncées aux technologies d'assistance, chaque message identifie son locuteur, et l'utilisateur garde le contrôle du rythme de la conversation.

La difficulté est structurelle. Comme le démontre Silktide dans son analyse des chatbots IA (juillet 2026), un scanner automatique audite une page qui existe déjà. Or un chatbot n'a pas de « page » : son contenu n'existe qu'après la saisie de l'utilisateur. Le DOM initial du widget peut être irréprochable pendant que la conversation, elle, échappe à toute mesure automatique.

Silktide relève trois mécanismes d'exclusion récurrents : le contenu bouge en continu (l'utilisateur de lecteur d'écran perd la carte mentale qu'il s'était construite de la page), les indicateurs de frappe sont purement visuels (rien n'annonce que l'assistant « réfléchit »), et chaque nouvelle réponse peut effacer la position du focus clavier. Aucun de ces trois défauts n'apparaît dans un rapport de scan.

Voilà pour le constat. La suite du guide est la partie constructive : comment faire, critère par critère.

Ce que la loi exige : RGAA, EAA et EN 301 549

Le chatbot n'a pas de statut juridique à part : c'est un composant d'interface comme un autre, soumis aux mêmes textes que le reste du site.

En France, le RGAA 4.1.2 (avril 2023) s'applique aux services publics et aux grandes entreprises soumises à l'obligation d'accessibilité. Depuis le 28 juin 2025, l'European Accessibility Act (directive 2019/882) étend l'exigence à de nombreux services privés : e-commerce, banque, transport, télécommunications. Le référentiel technique européen sous-jacent est la norme EN 301 549. Concrètement : si votre site est concerné, le widget de chat qui s'y affiche l'est aussi, qu'il soit développé en interne ou fourni par un éditeur tiers. Les deux régimes de sanctions sont distincts, mais aucun n'exempte les composants conversationnels.

Un point de vigilance pour les acheteurs : la responsabilité de l'accessibilité du site reste portée par son éditeur. « Notre solution respecte le RGAA » ne vous protège pas si le widget intégré casse la navigation clavier de vos pages. D'où l'intérêt de la checklist de test en fin d'article.

Rendre le widget atteignable : bouton, focus et clavier

Tout commence avant la conversation. Le bouton d'ouverture est le premier point de contact, et c'est déjà là que beaucoup de widgets échouent.

Le critère RGAA 7.1 exige que chaque script soit compatible avec les technologies d'assistance : un vrai <button>, jamais une <div> cliquable, avec un nom accessible explicite et un focus visible (critère RGAA 10.7).

<!-- Mauvais : invisible au clavier et au lecteur d'écran -->
<div class="chat-bubble" onclick="openChat()">
  <img src="chat-icon.svg">
</div>

<!-- Bon : atteignable, nommé, focus visible -->
<button type="button" aria-label="Assistant, ouvrir la discussion"
  class="chat-bubble focus-visible-ring">
  <svg aria-hidden="true"><!-- icône décorative --></svg>
</button>

Une fois le panneau ouvert, la question centrale est sa modalité, et elle demande une décision explicite. Soit le panneau est une boîte de dialogue modale : role="dialog", aria-modal="true", focus déplacé à l'intérieur, piégé pendant l'ouverture, restauré à la fermeture, et arrière-plan inerte. C'est le pattern Dialog (Modal) du guide W3C ARIA Authoring Practices, le même que pour les modales classiques. Soit c'est un panneau non modal qui laisse la page utilisable derrière, et alors le focus ne doit pas y être piégé.

Le piège, nous l'avons rencontré dans notre propre audit : un focus trap actif partout, mais un fond assombri uniquement sur mobile et un rôle de panneau non modal. Trois signaux qui racontent trois histoires différentes. Résultat concret : sur grand écran, l'utilisateur souris interagit librement avec la page pendant que l'utilisateur clavier, lui, tourne en boucle dans le widget. C'est une forme de piège au clavier (critère RGAA 12.9), même quand Échap permet d'en sortir : une échappatoire non documentée n'aide que ceux qui la devinent.

Retenez la règle : sémantique, visuel et comportement clavier doivent affirmer la même chose. Modal partout, ou non modal partout.

Rendre la conversation lisible au lecteur d'écran

C'est le cœur du sujet, et c'est ce qu'aucun scanner ne mesure.

La zone de messages. Le rôle ARIA adapté à un historique de conversation est role="log" : une région live conçue pour une série de messages horodatés, que l'on complète par aria-live="polite" pour que les nouveaux contenus soient annoncés sans interrompre l'utilisateur. Les messages de statut ponctuels (« recherche en cours ») relèvent, eux, d'un role="status" séparé (critère RGAA 7.5).

Qui parle. C'est le défaut le plus sournois que notre audit interne a relevé, parce qu'il est invisible tant qu'on n'écoute pas l'interface. Les bulles de conversation, alignées à gauche pour l'assistant et à droite pour l'utilisateur, avec deux couleurs et deux formes distinctes, sont irréprochables visuellement. Mais rien de tout cela n'existe dans l'arbre d'accessibilité : un lecteur d'écran restitue une succession de blocs de texte anonymes. Sur une conversation à plusieurs tours, l'utilisateur perd le fil de qui a dit quoi.

La correction tient en un attribut par message :

<div role="log" aria-live="polite" aria-label="Messages de la conversation">
  <div role="group" aria-label="Vous avez écrit">
    <p>Comment rendre mon formulaire accessible ?</p>
  </div>
  <div role="group" aria-label="Réponse de l'assistant">
    <p>Chaque champ doit être associé à une étiquette...</p>
  </div>
</div>

Le champ de saisie. Comme tout champ de formulaire, il doit être associé à une étiquette (critère RGAA 11.1), même visuellement masquée. L'envoi doit fonctionner au clavier, et l'indicateur « l'assistant écrit » doit avoir un équivalent textuel annoncé (un role="status" avec un libellé fait l'affaire).

Les détails qui excluent. Deux exemples tirés de notre audit : un horodatage de message en gris clair de 10 pixels tombait à un ratio de contraste d'environ 2,3:1, loin du seuil du critère RGAA 3.2 ; et la boîte de confirmation de suppression rendait le focus à nulle part une fois fermée. Aucun de ces défauts n'est spécifique aux chatbots. C'est justement le point : un widget conversationnel cumule les exigences de tous les composants qu'il embarque.

Chatbot IA : les pièges spécifiques du streaming

Les assistants IA ajoutent une couche de complexité que les guides d'accessibilité historiques ne couvrent pas : la réponse arrive en flux, fragment par fragment.

Le réflexe naturel est de mettre à jour la région live à chaque fragment reçu. Ne le faites pas. Chaque mutation d'une région aria-live est une candidate à l'annonce : en retransmettant le flux brut, vous transformez la réponse en avalanche de fragments lus de façon hachée, voire répétée selon le lecteur d'écran. Nous avons documenté ce défaut chez nous, alors même que la structure de base (role="log", indicateur d'attente séparé) était correcte.

Il n'existe pas de solution parfaite, seulement un compromis à choisir consciemment. Annoncer trop tôt et trop souvent noie l'utilisateur ; n'annoncer qu'à la fin donne l'impression que rien ne se passe. L'approche la plus robuste : afficher le flux visuellement au fil de l'eau, annoncer le début de la génération via le statut (« l'assistant répond »), puis n'exposer le texte à la région live qu'en fin de réponse, en une seule annonce complète.

Trois compléments indispensables pour un chatbot IA :

• Un bouton d'arrêt de la génération, atteignable au clavier. L'utilisateur doit garder le contrôle du rythme, ce qui exclut aussi le défilement automatique forcé et les délais d'expiration de session non ajustables.
• Le champ de saisie désactivé et annoncé pendant la génération. Notre audit a trouvé le cas inverse : un champ actif dont l'envoi était silencieusement ignoré pendant que l'assistant répondait. L'utilisateur croit avoir posé sa question, elle n'est jamais partie. Un disabled pendant la génération, et l'état devient perceptible pour tout le monde.
• Un rendu sémantique des réponses. Les modèles génèrent du Markdown : titres, listes, tableaux. Rendez-les avec de vraies balises HTML de liste et de tableau (jamais du texte brut stylé), et gardez les liens soulignés et explicites.

Si le sujet des interfaces IA grand public vous intéresse, nous avons aussi évalué l'accessibilité de ChatGPT, Claude et Gemini : les éditeurs les plus puissants du monde trébuchent sur les mêmes obstacles.

Tester votre chatbot avant la mise en ligne

Un scan automatique du site détecte une partie des anomalies du widget au repos : bouton non sémantique, contraste insuffisant, champ sans étiquette. Le comportement conversationnel, lui, se teste à la main. Comptez une heure pour ce parcours :

• Ouvrir le chatbot au clavier seul, depuis la page, sans souris.
• Vérifier que le focus entre dans le panneau à l'ouverture et revient au déclencheur à la fermeture (Échap compris).
• Envoyer une question, puis vérifier au lecteur d'écran (NVDA ou VoiceOver) que la réponse est annoncée, en entier, une seule fois.
• Vérifier que l'on sait qui parle en parcourant l'historique au lecteur d'écran.
• Pendant la génération : l'état est-il annoncé ? Peut-on arrêter ? Le champ indique-t-il qu'il est indisponible ?
• Zoomer à 200 % : la conversation reste-t-elle lisible et utilisable ?
• Vérifier les contrastes des bulles, horodatages et éléments d'interface avec un outil de mesure.

Si le chatbot vient d'un éditeur tiers, ajoutez quatre questions au dossier avant de signer : quels critères RGAA ou WCAG ont été testés, et par qui ? Le test a-t-il porté sur une conversation réelle ou sur le widget fermé ? Le streaming est-il annoncé aux lecteurs d'écran, et comment ? Existe-t-il une déclaration d'accessibilité du composant ? Une réponse vague à ces questions est une réponse.

Conclusion

Un chatbot accessible ne se décrète pas dans une fiche produit : il se construit sur des fondations classiques (bouton sémantique, focus maîtrisé, étiquettes, contrastes) et se joue sur des points propres au format conversationnel, l'annonce des réponses et l'identification du locuteur en tête. Le streaming des assistants IA ajoute un compromis à trancher, pas une fatalité.

Commencez par vérifier la gestion du focus de votre widget avec notre testeur de focus gratuit, puis lancez un scan de votre site pour cartographier les anomalies détectables. Le reste, vous savez désormais le tester vous-même, au clavier et à l'oreille.