Chat en direct et chatbot accessibles
En bref
- La bulle de chat en bas à droite est l'un des widgets les plus répandus du e-commerce — et l'un des plus souvent inaccessibles.
- Le lanceur doit être un vrai bouton nommé (« Ouvrir le chat »), atteignable et activable au clavier — WCAG 2.1.1 · 4.1.2.
- Une fois ouvert, le chat ne doit pas piéger le clavier : on doit pouvoir le fermer (Échap) et en sortir — 2.1.2 · 2.4.3.
- Le champ de saisie doit avoir une étiquette explicite, pas un simple placeholder — 3.3.2 · 4.1.2.
- Chaque message entrant (agent ou bot) doit être annoncé au lecteur d'écran via
aria-live— sinon il passe inaperçu — 4.1.3. - Le texte des bulles doit respecter le contraste (≥ 4,5:1) et le widget ne doit jamais masquer le contenu de la page — 1.4.3.
Pourquoi le chat est un angle mort de l'accessibilité
Le chat en direct et les chatbots se sont généralisés : presque chaque boutique en ligne affiche une bulle de support en bas à droite. C'est devenu un canal de vente et d'aide à part entière — mais c'est aussi un composant chargé en JavaScript après coup, souvent fourni par un tiers, et rarement testé au clavier ou au lecteur d'écran.
Résultat : un lanceur qui n'est qu'une <div> cliquable invisible au clavier, une fenêtre de conversation qui aspire le focus sans pouvoir en sortir, des réponses de l'agent qui s'affichent visuellement mais ne sont jamais annoncées à qui n'a pas l'écran. Pour un utilisateur aveugle ou qui navigue au clavier, le chat « marche » pour tout le monde sauf pour lui — alors que c'est précisément le canal censé l'aider.
La bonne nouvelle : rendre un chat accessible ne demande presque jamais de renoncer au design du widget. Ce sont des patterns connus — bouton nommé, gestion du focus, région aria-live. Voici les six règles qui couvrent l'essentiel.
Les 6 règles à appliquer
Un lanceur qui est un vrai bouton nommé
La bulle qui ouvre le chat doit être un vrai bouton (<button> ou élément en role="button"), atteignable au Tab et activable au clavier (Entrée/Espace). Elle doit porter un nom accessible explicite — « Ouvrir le chat », « Discuter avec le support » — car une icône de bulle seule est muette pour le lecteur d'écran (4.1.2).
Si l'état ouvert/fermé est porté par le bouton, exposez-le avec aria-expanded. À fuir : le lanceur en <div onclick> sans rôle ni focus, et l'icône sans aria-label (« bouton » tout court).
<button aria-label="Ouvrir le chat">
✓ Atteignable au Tab, activable à Entrée/Espace
✗ <div class="chat-bubble" onclick>
✗ Icône de bulle sans nom accessible
Pas de piège au clavier : on doit pouvoir fermer et sortir
Une fois le chat ouvert, l'utilisateur au clavier doit pouvoir circuler dans la fenêtre puis en ressortir sans rester coincé. Le critère 2.1.2 (Pas de piège au clavier) est ici central : trop de widgets capturent le focus dans la zone de saisie sans offrir d'issue. Prévoyez une fermeture au clavier — un bouton « Fermer » nommé, et idéalement la touche Échap.
Soignez aussi l'ordre du focus (2.4.3) : à l'ouverture, déplacer le focus vers la fenêtre de chat (par ex. son titre ou le champ de saisie) est utile ; à la fermeture, le focus doit revenir au lanceur, pas se perdre en haut de la page.
Un champ de saisie réellement étiqueté
La zone où l'on tape son message doit avoir une étiquette programmatique : un <label> associé, ou à défaut un aria-label (« Votre message »). Un simple placeholder (« Écrivez ici… ») ne suffit pas : il disparaît dès qu'on tape et n'est pas un label fiable pour l'assistance (3.3.2).
Le bouton d'envoi doit lui aussi être nommé (« Envoyer »), pas une icône d'avion en papier sans texte. Si l'envoi se fait avec Entrée, gardez quand même un bouton « Envoyer » visible et atteignable.
<label for="msg">Votre message</label>
✓ Bouton « Envoyer » nommé (pas qu'une icône)
✗ Champ avec un placeholder pour seul label
✗ Bouton d'envoi en icône sans nom accessible
Annoncer les messages entrants au lecteur d'écran
C'est le point critique du chat. Quand l'agent ou le bot répond, le message apparaît à l'écran — mais pour qui n'a pas l'écran, rien ne se passe : pas de son, pas d'annonce, le focus ne bouge pas. La conversation devient à sens unique. La solution est une région aria-live : placez le fil de conversation (ou la zone des nouveaux messages) dans un conteneur aria-live="polite" (ou role="log"), pour que chaque nouveau message soit lu automatiquement, sans voler le focus — c'est l'objet de 4.1.3 (Messages d'état).
Signalez aussi les états intermédiaires utiles : « L'agent est en train d'écrire… », « Message envoyé », « Vous êtes en file d'attente » gagnent à être annoncés (politely) plutôt que montrés en image seule.
aria-live="polite" / role="log"
✓ « Agent en train d'écrire » annoncé sobrement
✗ Réponses qui s'affichent sans aucune annonce
✗ aria-live="assertive" sur tout (interruptions)
Contraste des bulles, et ne pas masquer la page
Le texte des bulles de conversation doit respecter le contraste minimal de 4,5:1 (1.4.3) — attention aux bulles grises clair sur fond blanc, fréquentes côté « visiteur ». Les éléments d'interface porteurs d'information (bordures de champ, icône d'état) visent ≥ 3:1 (1.4.11).
Veillez aussi à ce que le widget ne recouvre pas en permanence du contenu ou des contrôles de la page, en particulier en mobile et au zoom 200 % (1.4.10 Reflow) : une bulle qui masque le bouton « Ajouter au panier » ou un lien de pied de page bloque l'usage. Le lanceur doit pouvoir être réduit/fermé.
Chatbot : laisser une issue humaine et ne pas imposer de rythme
Pour un chatbot (réponses automatiques), deux pièges supplémentaires. D'abord les délais : si la session expire ou si une réponse n'est attendue qu'un court instant, prévoyez de pouvoir prolonger ou ne pas couper l'utilisateur qui tape lentement (2.2.1). Ensuite, laissez toujours une porte de sortie vers un humain ou un autre canal (email, téléphone) : un bot qui ne comprend pas et boucle sans alternative enferme l'utilisateur.
Évitez aussi tout changement de contexte brutal au simple focus (3.2.1) : ouvrir le chat ou rediriger sans action volontaire de l'utilisateur désoriente, en particulier au lecteur d'écran.
Récapitulatif des critères
| Critère WCAG | Niveau | Application au chat / chatbot |
|---|---|---|
| 1.4.3 — Contraste (minimum) | AA | Texte des bulles de conversation ≥ 4,5:1 |
| 1.4.10 — Reflow | AA | Le widget ne masque pas le contenu au zoom 200 % / en mobile |
| 2.1.1 — Clavier | A | Lanceur et tous les contrôles utilisables au clavier |
| 2.1.2 — Pas de piège au clavier | A | On peut fermer le chat et sortir de la fenêtre (Échap / bouton) |
| 2.4.3 — Parcours du focus | A | Focus géré à l'ouverture et rendu au lanceur à la fermeture |
| 3.3.2 — Étiquettes ou instructions | A | Champ de saisie et bouton d'envoi étiquetés (pas qu'un placeholder) |
| 4.1.2 — Nom, rôle, valeur | A | Lanceur = vrai bouton nommé ; état ouvert exposé (aria-expanded) |
| 4.1.3 — Messages d'état | AA | Messages entrants annoncés via aria-live / role="log" |
aria-live="polite" (ou role="log") pour que chaque nouveau message soit lu — sans rien changer à l'apparence du widget.
Comment vérifier
- Clavier seul : atteignez le lanceur au Tab, ouvrez le chat à Entrée, tapez et envoyez un message, puis fermez-le (Échap ou bouton) — sans souris, et sans rester piégé.
- Lecteur d'écran (NVDA / VoiceOver) : le lanceur doit s'annoncer « Ouvrir le chat, bouton » ; le champ doit avoir un nom ; et surtout une réponse entrante doit être lue automatiquement.
- Zoom 200 % : vérifiez que la bulle ne masque ni le contenu, ni les boutons clés (« Ajouter au panier », liens de pied de page), et qu'elle reste fermable.
- Contraste : contrôlez le texte des bulles (notamment côté visiteur) avec un vérificateur de contraste ou l'audit axe-core.
Questions fréquentes
Le chat fait partie de mon site : est-il vraiment soumis à l'accessibilité ?
Oui. Tout ce qui est servi sur votre site et participe au service (information, achat, support) entre dans le périmètre de l'accessibilité. Un chat de vente ou d'aide est une fonctionnalité du site : s'il est inutilisable au clavier ou au lecteur d'écran, c'est une non-conformité, qu'il soit développé en interne ou fourni par un prestataire.
J'utilise un widget tiers (Crisp, Intercom…). Suis-je couvert ?
Pas automatiquement. Les solutions de chat ont des niveaux d'accessibilité variables, et l'intégration sur votre thème peut dégrader des points (contraste, couleurs, options). La responsabilité de la conformité reste celle de l'éditeur du site, pas du fournisseur du widget. Testez le chat réellement rendu sur votre site avant de le considérer conforme, et demandez au fournisseur sa documentation d'accessibilité.
Dois-je utiliser aria-live="polite" ou "assertive" pour les messages ?
Dans la quasi-totalité des cas, polite. Il fait annoncer le nouveau message après que le lecteur d'écran a fini ce qu'il disait, sans interrompre l'utilisateur. assertive coupe la parole et doit être réservé aux alertes vraiment urgentes ; l'employer pour chaque message rendrait la conversation pénible. Le rôle log est aussi adapté à un fil de discussion.
Un chatbot doit-il forcément proposer de parler à un humain ?
Du point de vue de l'accessibilité et de l'UX, c'est fortement recommandé. Un bot qui ne comprend pas et boucle sans issue enferme l'utilisateur ; offrir une bascule vers un conseiller, un email ou un téléphone garantit que personne ne se retrouve bloqué. Veillez aussi à ne pas couper brutalement l'utilisateur qui tape lentement (critère 2.2.1 sur les délais).
Le scanner gratuit de DeclareAccess détecte-t-il ces problèmes ?
Partiellement. Le scanner basé sur axe-core repère fiablement un lanceur sans nom accessible, un champ sans étiquette et les contrastes insuffisants. En revanche, il ne peut pas tester le parcours clavier réel (piège au clavier), ni vérifier qu'un message entrant est bien annoncé via aria-live, ni juger la présence d'une issue humaine — ces points exigent un test manuel au clavier et au lecteur d'écran.
Lancez le scan automatisé de votre boutique
DeclareAccess analyse une page de votre site selon les WCAG 2.1 AA, vous renvoie un rapport chiffré des non-conformités (avec les éléments concernés), puis génère la déclaration d'accessibilité prête à publier — modèle français (RGAA) ou allemand (BFSG). Audit gratuit, sans carte bancaire.
Rapport WCAG par e-mail sous 24 h ouvrées.
C'est noté. Votre demande d'audit est enregistrée — vous recevrez votre rapport WCAG par e-mail sous 24 h ouvrées.