Accessibilité d’un chatbot IA : recette avant publication

Un chatbot peut donner des réponses utiles et rester inutilisable pour une personne qui navigue au clavier ou avec un lecteur d’écran. L’accessibilité se juge dans le parcours entier : ouvrir l’interface, comprendre où l’on se trouve, envoyer une question, percevoir la réponse, corriger une erreur et quitter la conversation. Un score automatique ou une démonstration à la souris ne couvre pas ces gestes.

La recette proposée ici transforme ce parcours en douze tests observables. Elle s’adresse à l’équipe qui commande, construit ou reçoit un chatbot intégré à un site. Elle ne prétend pas certifier une conformité réglementaire. Elle fournit une base de vérification que l’on peut reproduire, documenter et compléter par des essais avec des personnes concernées.

Réponse en bref

Avant de publier un chatbot IA, testez-le sans souris puis avec un lecteur d’écran, sur ordinateur et sur mobile. Vérifiez que l’entrée dans la fenêtre, chaque message nouveau, l’attente, les erreurs et la fermeture restent perceptibles sans déplacer le focus de façon inattendue. Faites le même parcours avec une réponse longue, une réponse interrompue et un échec réseau. Si une étape empêche de poursuivre ou masque une information essentielle, corrigez-la avant la mise en ligne.

La prochaine action est simple : ouvrez votre interface sur une page de test, débranchez la souris et exécutez les douze parcours ci-dessous. Consignez pour chacun le résultat attendu, le résultat observé, le navigateur, la technologie d’assistance utilisée et la correction décidée.

Définir le périmètre de la recette

Une conversation n’est pas un seul composant. Elle comporte un bouton d’ouverture, parfois une fenêtre superposée, un historique, un champ de saisie, un bouton d’envoi, des messages d’état, des liens, des éventuelles pièces jointes et un bouton de fermeture. Certaines interfaces ajoutent une génération en continu, des suggestions, un bouton de copie ou un transfert à une personne. Chaque ajout crée un nouveau comportement à tester.

Commencez par dessiner le parcours le plus court : « ouvrir, poser une question, lire, poursuivre, fermer ». Notez ensuite les variantes réellement livrées. Une équipe ne peut pas déclarer « le chatbot est accessible » si elle n’a testé que le bouton d’ouverture. De même, un chatbot qui s’ouvre dans une fenêtre modale doit être traité comme une fenêtre modale ; une zone non modale, intégrée à la page, appelle une gestion de focus différente. Le guide WAI sur les dialogues modaux décrit le comportement attendu du clavier et du focus pour ce motif, mais ne dit pas que tout chatbot doit être modal.

La décision de conception précède donc le code. L’utilisateur doit-il pouvoir consulter la page pendant la conversation ? Si oui, une fenêtre qui enferme le focus peut contredire le besoin. Si non, l’ouverture doit annoncer le dialogue et son titre, empêcher réellement l’interaction avec le fond et rendre le focus au déclencheur à la fermeture. Écrire aria-modal="true" sans obtenir ce comportement ne suffit pas.

Préparer une matrice d’essai reproductible

Choisissez au moins un navigateur sur ordinateur, un sur mobile, un lecteur d’écran représentatif de chaque environnement testé et un parcours clavier seul. Inscrivez les versions et la date : un défaut peut dépendre d’une combinaison précise. Testez sur une page réelle du site, avec son en-tête, ses panneaux fixes, ses formulaires et son bandeau éventuel. Une maquette isolée ne révèle pas toujours un bouton caché derrière une barre collante.

Préparez trois questions sans donnée personnelle : une question courte avec réponse courte, une question dont la réponse comporte un titre, une liste et un lien, puis une question qui déclenche une erreur contrôlée en environnement de test. Pour la génération longue, utilisez un contenu de test déterministe si possible. Il ne s’agit pas de juger la qualité factuelle du modèle dans cette recette ; le protocole d’évaluation d’un assistant avant déploiement traite cet autre risque.

Sur téléphone, faites défiler le tableau suivant horizontalement pour lire les trois colonnes.

Dimension	État de départ	Action	Preuve attendue
Entrée	page chargée	ouvrir au clavier	intitulé compréhensible, focus prévisible
Conversation	champ actif	envoyer une question	question et état d’attente perceptibles
Réponse	génération terminée	lire et activer un lien	contenu structuré, lien atteignable
Incident	requête échouée	corriger ou réessayer	erreur expliquée, aucun piège de focus
Sortie	fenêtre ouverte	fermer	retour au bon endroit dans la page

Parcours 1 à 3 : entrer sans perdre sa place

1. Trouver le déclencheur

Parcourez la page avec Tab et Shift + Tab. Le bouton doit être atteignable et avoir un nom qui annonce sa fonction, par exemple « Ouvrir l’assistant ». Un pictogramme seul sans nom accessible ne donne pas cette information. Son contour de focus doit rester visible, y compris si le bouton est fixé au bas de la fenêtre. Vérifiez aussi l’ordre : un bouton placé visuellement en premier mais atteignable après tout le pied de page crée une navigation déroutante.

2. Ouvrir et comprendre le contexte

Activez le bouton avec Entrée, puis avec Espace lors d’un second essai. Si l’interface est modale, le focus entre dans la fenêtre et un titre identifiable explique où l’on se trouve. Si elle est non modale, l’interface annonce son ouverture sans créer une prison de focus. La recommandation WAI pour un dialogue modal précise que le focus initial dépend du contenu : un dialogue riche peut commencer sur un titre statique pour que sa structure soit lue avant les commandes.

3. Revenir à la page

Fermez avec le bouton visible, puis avec Échap si le composant se présente comme un dialogue modal. Le focus doit revenir au déclencheur, sauf si le parcours a logiquement remplacé celui-ci. Essayez également de fermer après avoir tabulé sur un lien dans une réponse : le retour doit rester cohérent. Si l’ouverture provoque un saut de défilement ou si la fermeture renvoie en haut de page, consignez le défaut.

Parcours 4 à 6 : écrire et envoyer

4. Comprendre le champ

Le champ de saisie doit porter un libellé persistant et explicite. Un texte indicatif qui disparaît pendant la frappe n’est pas une aide suffisante. Vérifiez la langue de l’interface, la touche qui envoie et celle qui crée un retour à la ligne. Un raccourci doit être annoncé près du champ s’il n’est pas évident. Si une limite de caractères existe, elle doit être compréhensible avant qu’elle ne bloque l’envoi.

5. Envoyer sans ambiguïté

Saisissez une question puis activez l’envoi au clavier. Le bouton d’envoi doit exprimer son état lorsqu’il est indisponible. L’historique doit montrer que la question a été prise en compte. Ne videz pas le champ avant qu’une éventuelle erreur de soumission puisse être récupérée. Vérifiez la réponse à une double activation rapide : l’interface ne devrait pas créer silencieusement deux conversations identiques.

6. Rester maître du focus

Après l’envoi, observez où se trouve le focus. Le déplacer systématiquement sur chaque nouveau mot généré rend la saisie d’une seconde question impossible et peut faire lire le même contenu plusieurs fois. Le laisser sans aucun retour rend l’application muette. La bonne solution dépend du fonctionnement retenu, mais elle doit être stable et testée : le message d’état est annoncé, la réponse complète est navigable et l’utilisateur décide quand la lire. Le guide WAI de navigation au clavier rappelle que le focus doit rester visible et prévisible.

Parcours 7 à 9 : percevoir les réponses dynamiques

7. Signaler l’attente sans bruit

Une animation seule ne suffit pas à indiquer qu’une réponse arrive. Fournissez un état textuel comme « Réponse en cours » et testez son annonce par le lecteur d’écran. La compréhension du critère WCAG 4.1.3 explique que certains changements d’état doivent être déterminables par les technologies d’assistance sans recevoir le focus. role="status" est une technique possible pour un message non urgent ; il ne faut pas interpréter cette technique comme l’unique façon valide de satisfaire le critère.

8. Lire une réponse complète

La réponse longue doit conserver ses titres, listes, paragraphes et liens dans un ordre logique. Un bloc de texte injecté avec des marques Markdown non rendues peut être pénible à parcourir. À l’inverse, une mise en forme visuelle qui ne crée aucun titre sémantique prive le lecteur d’écran de navigation. Vérifiez le texte sélectionnable, la taille à zoom élevé et l’absence de débordement horizontal sur téléphone. Si l’assistant donne un tableau, les en-têtes et l’ordre de lecture doivent rester interprétables.

9. Contrôler la génération en continu

Lisez une réponse produite progressivement. Un lecteur d’écran ne doit pas être interrompu à chaque jeton par une nouvelle annonce. Testez deux stratégies : annoncer seulement le début et la fin, ou annoncer des étapes utiles et espacées. Choisissez à partir de l’essai réel, pas d’une intuition technique. Une région de statut peut convenir à « réponse terminée » ; transformer tout l’historique en région vivante risque de produire un flux sonore incontrôlable.

Parcours 10 à 12 : gérer l’échec et la sortie

10. Rendre l’erreur actionnable

Provoquez un échec réseau ou un délai dépassé dans une version de test. Le message doit dire ce qui s’est passé en termes compréhensibles, ce qui a été conservé et quelle action est possible. « Une erreur est survenue » sans autre issue ne permet pas de continuer. Vérifiez que l’erreur apparaît dans l’ordre de lecture et qu’elle est annoncée, sans déplacer le focus vers un endroit inattendu.

11. Garder une solution hors du chatbot

Un assistant conversationnel ne devrait pas être le seul accès à une information ou à une démarche essentielle. Si le bot ne comprend pas la demande, si le service tombe ou si l’utilisateur préfère une navigation classique, une page, un formulaire ou un contact pertinent doit rester disponible. Cette issue ne compense pas un bot inaccessible, mais elle évite qu’un défaut du composant ferme entièrement le service.

12. Reprendre après une interruption

Fermez et rouvrez la conversation, rechargez la page, changez l’orientation du téléphone et augmentez le zoom. Le comportement de conservation doit correspondre à ce qui est annoncé. Si l’historique disparaît, l’utilisateur doit le savoir avant d’y placer un long message. Si l’historique persiste, la politique de conservation doit être claire. Une session reprise ne doit pas ouvrir seule une fenêtre qui capture le clavier.

Une fiche d’anomalie qui aide réellement à corriger

Pour chaque défaut, notez un identifiant, le parcours, l’étape exacte, le résultat attendu, le résultat observé, la combinaison navigateur et assistance, la sévérité et la preuve de reprise. Une capture peut aider, mais ne remplace pas la description des touches pressées et des annonces entendues. Ne joignez pas de vraie conversation contenant des données personnelles à un ticket public.

La sévérité dépend de l’effet. Un bouton d’envoi inaccessible au clavier bloque la tâche. Un état d’attente peu clair gêne l’usage, mais peut laisser la tâche possible. Un double message annoncé pendant une seconde peut être moins grave qu’une erreur silencieuse qui efface la saisie. Évitez de classer toutes les anomalies sous « cosmétique » parce que l’interface paraît correcte à la souris.

Proposez une règle de sortie avant les tests : aucune tâche principale bloquée, aucun piège de focus, aucune erreur non récupérable, et un test manuel refait après correction. Le chiffre de critères automatisés réussis n’est pas une preuve suffisante de ce résultat. Les critères WCAG 2.2 servent à relier les défauts aux exigences pertinentes ; le protocole de parcours vérifie l’expérience concrète.

Passer de la recette au cahier des charges

Une équipe qui achète un chatbot peut intégrer cette matrice dans sa réception. Demandez une démonstration clavier, une description des annonces d’état, la liste des environnements réellement testés et un canal de correction. L’accessibilité doit porter sur les réponses produites, pas uniquement sur la coquille. Un fournisseur ne peut pas garantir que tous les contenus générés auront toujours une structure parfaite ; il peut en revanche définir le rendu, les contrôles et la correction des défauts récurrents.

Pour les usages où le bot peut agir, ajoutez une validation distincte des permissions et des décisions humaines. Le guide sur la validation humaine dans un workflow IA couvre cette frontière. La présente recette vérifie surtout que chacun peut comprendre et utiliser l’interface qui expose ces décisions.

Limites

Les douze parcours servent à repérer des obstacles concrets ; ils ne couvrent pas toutes les pages, tous les composants ni les réponses que le chatbot peut générer. Complétez-les par des essais avec les personnes concernées et les technologies d’assistance réellement utilisées. Un défaut absent dans une combinaison navigateur et lecteur d’écran peut apparaître dans une autre. La conformité WCAG demande un examen plus large que cette recette.

Historique des mises à jour

• 26 septembre 2026 : Précision du périmètre de la recette d’accessibilité.
• 24 septembre 2026 : première publication de la recette, après vérification des références W3C citées.

Articles liés

• Évaluer un assistant IA avant déploiement pour la qualité des réponses et les critères d’acceptation.
• Human in the loop IA pour le contrôle des décisions et des actions sensibles.