Depuis le début de l’année, presque tous les clients qui passent commande d’un audit RGAA ont ajouté un chatbot IA à leur site dans les mois précédents. C’est devenu un réflexe marketing avant d’être une réflexion produit, et le résultat est souvent le même : un widget séduisant en démonstration, injustifiable dès qu’on débranche la souris.
Ce billet liste les antipatterns qu’on retrouve le plus souvent sur ces intégrations, pourquoi ils posent un vrai problème d’exclusion, et ce qu’il faut exiger de l’éditeur du widget ou corriger soi-même quand c’est possible.
Ce qu’on voit : un bouton flottant invisible au clavier
Le widget de chat s’affiche en bas à droite via un <div> cliquable, sans rôle ni tabindex. À la souris, tout fonctionne. Au clavier, l’utilisateur qui tabule pour atteindre l’assistance n’a tout simplement aucune indication qu’un bouton existe à cet endroit — il n’apparaît jamais dans l’ordre de tabulation.
Pourquoi c’est un problème
Le chatbot est souvent positionné comme le canal d’assistance principal, parfois le seul visible en permanence sur toutes les pages. Un visiteur qui navigue au clavier — parce qu’il ne peut pas utiliser de souris, ou parce qu’il utilise un lecteur d’écran — se retrouve donc privé du canal d’aide justement mis en avant pour les cas difficiles. C’est une double peine : la personne qui a le plus besoin d’assistance est celle à qui l’assistance est fermée.
Le focus qui s’échappe
Deuxième antipattern classique : quand la fenêtre de conversation s’ouvre, le focus clavier n’y est jamais déplacé. L’utilisateur reste focalisé sur le bouton d’origine, ou pire, sur un élément totalement décorrélé de la page. Il doit alors deviner où se trouve la conversation et la retrouver en tabulant à l’aveugle.
Une modale sans piège à focus
Quand la fenêtre s’ouvre bien avec le focus dedans, il manque souvent le piège à focus (focus trap) : en tabulant, on finit par sortir de la fenêtre de chat et se retrouver dans le contenu de la page en dessous, sans avoir fermé la conversation. La touche Échap ne fait rien non plus dans la majorité des widgets testés cette année.
Quoi faire
Voici la liste de vérification qu’on applique désormais systématiquement avant de valider l’intégration d’un widget de chat IA :
- Le déclencheur est un vrai
<button>, focusable et activable au clavier - À l’ouverture, le focus est déplacé dans la fenêtre de conversation, sur le champ de saisie ou le premier élément pertinent
- Le focus reste piégé dans la fenêtre tant qu’elle est ouverte
- Échap ferme la fenêtre et restitue le focus au bouton déclencheur
- Les nouveaux messages de l’IA sont annoncés via une zone
aria-live="polite", sans répéter tout l’historique à chaque réponse
Un correctif possible côté thème
Quand l’éditeur du widget ne corrige pas rapidement, il reste possible d’intervenir depuis le thème ou un plugin maison, en ciblant le conteneur injecté par script :
document.addEventListener('keydown', function (event) {
var chatWindow = document.querySelector('.widget-chat-ouvert');
if (!chatWindow) return;
if (event.key === 'Escape') {
var boutonFermer = chatWindow.querySelector('[data-fermer-chat]');
if (boutonFermer) boutonFermer.click();
}
});
Ce type de correctif reste fragile : il dépend de la structure DOM du widget, susceptible de changer à chaque mise à jour de l’éditeur tiers. Il ne dispense pas d’exiger une correction pérenne auprès du fournisseur.
Un widget de chat IA n’est pas un gadget marketing isolé : c’est un point d’entrée d’assistance. Le traiter avec moins de rigueur qu’un formulaire de contact classique n’a aucun sens.
Notre verdict
Avant d’installer un chatbot IA, la même check-list qui s’applique à une modale classique doit s’appliquer : focus géré à l’ouverture et à la fermeture, piège à focus actif, Échap fonctionnel, annonces vocales maîtrisées. Sur la vingtaine de widgets grand public testés depuis janvier, aucun ne cochait ces cinq cases par défaut — tous nécessitaient soit une configuration avancée, soit un correctif manuel côté client.
