Votre chatbot est-il vraiment utilisable par tout le monde ?

Les chatbots ont un problème d’accessibilité

Les chatbots de service client sont devenus l’option de contact principale — et souvent la seule — de nombreux produits numériques. L’attente est claire : si vous avez besoin d’aide, ouvrez le chat. Si le chat ne fonctionne pas pour vous, il n’y a souvent rien d’autre.

Pour les utilisateurs en situation de handicap, cette situation est fréquemment intenable. La plupart des chatbots commerciaux échouent aux exigences d’accessibilité les plus élémentaires. Les utilisateurs de lecteurs d’écran ne peuvent pas entendre les messages à mesure qu’ils arrivent. Les utilisateurs au clavier se retrouvent piégés à l’intérieur du widget de chat sans pouvoir en sortir. Les utilisateurs ayant des handicaps moteurs rencontrent des cibles tactiles trop petites pour être touchées de façon fiable. Les utilisateurs ayant des handicaps cognitifs font face à des murs de texte et à aucun moyen clair de se remettre d’une requête mal comprise.

Cela compte à la fois sur le plan éthique et sur le plan juridique. La directive européenne sur l’accessibilité, en vigueur depuis juin 2025, couvre les canaux numériques de service client des entreprises concernées — ce qui inclut les interfaces de chatbot. L’ADA aux États-Unis a été appliquée aux chatbots dans le cadre de litiges relatifs à l’accessibilité web. Si un chatbot est un canal de service principal, un chatbot inaccessible constitue une exclusion du service.

Les sept défaillances d’accessibilité les plus fréquentes des chatbots

1. Absence de régions live ARIA

Lorsqu’un nouveau message arrive dans une fenêtre de chat, un utilisateur de lecteur d’écran doit pouvoir l’entendre. Or les lecteurs d’écran n’annoncent que le contenu qu’on leur a indiqué comme important et dynamique. Sans une région live ARIA enveloppant le conteneur des messages du chat, les messages apparaissent visuellement mais restent totalement silencieux pour les utilisateurs de lecteurs d’écran.

<!-- Sans région live : les nouveaux messages ne sont pas annoncés -->
<div class="chat-messages">
  <!-- Les messages sont ajoutés ici dynamiquement -->
</div>

<!-- Avec région live : les nouveaux messages sont annoncés à mesure qu'ils arrivent -->
<div
  class="chat-messages"
  role="log"
  aria-live="polite"
  aria-label="Conversation de chat"
>
  <!-- Les messages sont ajoutés ici dynamiquement -->
</div>

role="log" est spécifiquement défini dans ARIA pour les conversations de chat et les flux de messages. aria-live="polite" annonce le nouveau contenu après que l’utilisateur a marqué une pause — moins perturbant que assertive dans un contexte conversationnel.

2. Pièges au clavier

Un piège au clavier survient lorsqu’un utilisateur entre dans un composant à l’aide de la tabulation et ne peut plus en sortir — il est coincé. Les widgets de chatbot figurent parmi les endroits les plus fréquents où apparaissent des pièges au clavier.

La correction exige la mise en place d’une gestion du focus appropriée : Tab et Maj+Tab doivent parcourir les éléments interactifs à l’intérieur du chat, et Échap doit fermer le chat et rendre le focus à l’élément qui l’a déclenché. Le critère WCAG 2.1.2 Pas de piège au clavier (niveau A) couvre cette exigence.

Le tester est simple : ouvrez votre chatbot en utilisant uniquement le clavier, parcourez avec la tabulation tous les éléments interactifs qu’il contient et vérifiez que vous pouvez en sortir à l’aide d’Échap ou d’un bouton de fermeture clairement visible.

3. Contraste de couleurs insuffisant

Les chatbots sont souvent rendus dans les couleurs de la marque, et ces couleurs ne sont souvent pas testées au regard des exigences de contraste des WCAG. Défaillances courantes :

Un texte de bulle de chat qui n’atteint pas un contraste de 4,5:1 par rapport à l’arrière-plan de la bulle
Un texte d’invite (placeholder) de champ de saisie en deçà des seuils de contraste
Un texte d’horodatage dans un gris très clair

L’exigence de contraste s’applique à l’interface du chatbot exactement comme au reste de votre site — il n’y a aucune exception pour les widgets.

4. Champs de saisie et boutons non étiquetés

Le champ de saisie du chat — « Saisissez votre message… » — doit disposer d’une étiquette associée par programmation, et pas seulement d’un texte d’invite. Le texte d’invite disparaît dès que l’utilisateur commence à taper et ne constitue pas un substitut fiable à une étiquette.

Le bouton d’envoi, le bouton de réduction, le bouton de fermeture et tout autre contrôle interactif doivent avoir des noms accessibles. Un bouton « envoyer » composé uniquement d’une icône, sans texte ni aria-label, est annoncé par les lecteurs d’écran comme « bouton », sans aucune description de sa fonction.

<!-- Étiquette manquante : échec -->
<input type="text" placeholder="Saisissez un message...">
<button><svg><!-- icône d'envoi --></svg></button>

<!-- Avec étiquette et aria-label : réussite -->
<label for="chat-input" class="sr-only">Saisissez votre message</label>
<input type="text" id="chat-input" placeholder="Saisissez un message...">
<button aria-label="Envoyer le message">
  <svg aria-hidden="true"><!-- icône d'envoi --></svg>
</button>

5. Cibles tactiles trop petites pour les utilisateurs ayant un handicap moteur

Les WCAG 2.2 ont introduit le critère 2.5.8 Taille de la cible (minimum) au niveau AA, exigeant que les éléments interactifs aient une taille de cible minimale de 24 × 24 pixels CSS. De nombreuses interfaces de chatbot placent les boutons de fermeture, de réduction et d’émojis à 16-20 pixels — bien en dessous de ce seuil.

Pour les utilisateurs ayant des handicaps moteurs, des tremblements ou une motricité fine réduite, les petites cibles sont réellement inutilisables. Les boutons d’action du chatbot figurent parmi les éléments d’interface les plus souvent concernés.

6. Aucun avertissement de délai ni prolongation de session

De nombreux chatbots mettent fin à une session inactive au bout d’une période déterminée. Lorsque cela se produit sans avertissement, les utilisateurs qui mettent plus de temps à rédiger ou à lire les messages — dont de nombreux utilisateurs ayant des handicaps cognitifs ou moteurs — peuvent perdre leur conversation sans aucune possibilité de prolonger la session.

Le critère WCAG 2.2.1 Délai modifiable (niveau A) exige que lorsqu’une limite de temps est fixée, les utilisateurs puissent la désactiver, la prolonger, ou que cette limite soit d’au moins 20 heures. Un chatbot qui interrompt les sessions après 5 minutes d’inactivité sans avertissement n’est pas conforme.

7. Langage complexe et absence de récupération d’erreur

Les chatbots ne sont utiles que si les utilisateurs peuvent communiquer efficacement avec eux. Pour les utilisateurs ayant des handicaps cognitifs, des troubles de l’apprentissage ou un niveau de littératie plus faible, un chatbot qui emploie du jargon, présente de longs murs de texte sans structure ou échoue silencieusement lorsqu’il ne comprend pas une requête est concrètement inaccessible.

Un contenu de chatbot accessible :

Emploie un langage simple (phrases courtes, mots courants)
Décompose les réponses en unités faciles à parcourir plutôt que de présenter des paragraphes
Fournit une récupération d’erreur claire : lorsque le bot ne comprend pas, il le dit explicitement et propose des alternatives précises
Aide les utilisateurs à reformuler leurs requêtes plutôt que de se contenter de dire « Je n’ai pas compris »

Nouveaux critères WCAG 2.2 particulièrement pertinents pour les chatbots

Les WCAG 2.2 ont ajouté plusieurs critères de succès qui s’appliquent avec une force particulière aux interfaces de chat :

2.4.11 Focus visible non masqué (minimum) — niveau AA. Lorsqu’un widget de chat est ouvert, il ne doit pas masquer entièrement l’élément ayant le focus derrière lui. De nombreux widgets de chat s’affichent par-dessus le contenu de la page et masquent l’élément ayant le focus lorsque les utilisateurs parcourent la page sous-jacente à la tabulation.

2.4.12 Focus visible non masqué (amélioré) — niveau AAA. L’élément ayant le focus doit être entièrement visible.

2.5.7 Mouvements de glissement — niveau AA. Si votre widget de chat peut être repositionné par glissement, une alternative à pointeur unique doit exister.

2.5.8 Taille de la cible (minimum) — niveau AA, comme évoqué ci-dessus.

Comment tester votre chatbot

Clavier uniquement : ouvrez le chat sans utiliser de souris. Parcourez tous les éléments à la tabulation. Vérifiez que vous pouvez taper, envoyer des messages et fermer le widget en utilisant uniquement le clavier. Confirmez que vous pouvez en sortir avec Échap.
Lecteur d’écran : ouvrez NVDA (Windows, gratuit) ou VoiceOver (Mac/iOS, intégré) et interagissez avec le chat. Vérifiez que les messages sont annoncés à mesure qu’ils arrivent. Vérifiez que les champs de saisie et les boutons sont correctement étiquetés.
Zoom à 200 % : vérifiez que l’interface du chat ne déborde pas et ne masque pas le contenu de la page lorsque le texte est agrandi.
Vérification du contraste : utilisez une extension de navigateur comme axe DevTools ou WAVE pour vérifier le contraste dans l’interface du chat.
Mobile : testez la taille des cibles tactiles et vérifiez que le chat fonctionne avec les fonctionnalités d’accessibilité iOS/Android (VoiceOver, TalkBack).

Si vous intégrez un chatbot tiers, évaluez l’accessibilité du fournisseur avant de le choisir. Demandez son VPAT (Voluntary Product Accessibility Template) pour comprendre le niveau de conformité revendiqué. Testez le widget vous-même — les affirmations du fournisseur ne remplacent pas un test direct.

Intégrer l’accessibilité du chatbot dès le départ revient bien moins cher que de la rétro-adapter par la suite. Si vous évaluez des plateformes de chatbot, faites passer chaque candidate par cette liste de contrôle avant de vous engager.

Pour un examen complet de votre chatbot et du reste de votre expérience de service client numérique, parlez à notre équipe ou commencez par une analyse gratuite de vos pages publiques.