Une réponse se construit mot après mot. Pour les personnes voyantes, cela ressemble à une progression. Si chaque fragment est lu immédiatement, la même sortie peut entraîner des interruptions constantes. La question n'est donc pas de savoir si un changement est techniquement visible, mais de quelle information une personne a besoin à ce moment-là.
Dans le critère de succès 4.1.3, les WCAG 2.2 traitent des messages d'état, qui doivent pouvoir être déterminés par programmation sans changement de focus. L'explication du W3C mentionne également le fait d'éviter les interruptions inutiles. Cela n'implique pas une obligation générale d'annoncer individuellement chaque mot nouvellement généré. Pour un chat d'IA, séparer l'état de traitement du contenu de la réponse est particulièrement utile.
Trois états au lieu d'une annonce sans fin
Notre propre modèle de démonstration comporte trois situations compréhensibles : demande reçue, réponse en cours de génération, réponse terminée. Elles offrent une orientation sur le processus. Le texte de la réponse répond lui-même à la question de fond et doit ensuite rester lisible au rythme propre de la personne.
Pendant l'attente, une personne peut revenir à son propre champ de saisie ou lire d'autres parties de la page. L'interface ne doit pas écarter cette activité simplement parce qu'un nouveau morceau de texte est arrivé. Une réponse terminée ne doit pas non plus prendre automatiquement le focus clavier.
Le retour approprié dépend de l'état. Un processus encore en cours est autre chose qu'une erreur qui exige une nouvelle décision. Si tous les messages sont présentés comme également urgents, c'est précisément cette priorité qui disparaît.
Un petit modèle HTML sépare contenu et état
Le fragment suivant est de notre cru et ne contient aucune connexion à une IA. Il montre seulement deux zones aux rôles différents. La zone de réponse contient le texte qui pourra être lu plus tard. La courte ligne d'état indique l'état actuel.
<section aria-labelledby="answer-title">
<h2 id="answer-title">Answer</h2>
<div id="answer"></div>
</section>
<p id="answer-status" role="status" aria-atomic="true"></p>La technique ARIA22 du W3C décrit role=status avec une région live polie et l'annonce de l'intégralité du contenu d'état. Notre aria-atomic explicite rend cette intention visible dans le fragment pédagogique. Ce n'est pas une raison pour placer l'intégralité du texte de réponse, qui ne cesse de s'allonger, dans le même court message d'état.
Une implémentation réelle mettrait à jour la ligne d'état lors de transitions significatives, par exemple une fois au début et une fois après l'achèvement complet. La fréquence à laquelle un message de progression intermédiaire aide réellement doit être testée avec le déroulement concret et avec des technologies d'assistance.
Lors d'une vérification à l'oreille, pensez aussi à une personne qui lit déjà ailleurs pendant la génération de la réponse. Doit-elle sans cesse recommencer sa phrase ? Peut-elle retrouver délibérément la réponse terminée plus tard ? Ces observations testent l'usage du modèle plus précisément que le simple constat qu'une annonce est entendue quelque part.
L'annulation et les erreurs ont besoin de leurs propres mots
Si la sortie est interrompue, « terminé » ne doit pas simplement signifier que plus aucun caractère n'arrive. Un texte délibérément arrêté peut être incomplet. Une erreur technique peut signifier qu'aucun résultat exploitable n'a été produit. Ces différences ont leur place dans le langage de l'interface.
Pour une première vérification, vous pouvez utiliser trois textes d'exemple fixes et déclencher les transitions à la main. Observez ce qui est annoncé pendant que vous continuez à lire, si le focus reste là où il est et comment vous accédez au texte terminé. C'est un exercice que vous pouvez réaliser, mais il n'est pas présenté ici comme un test de lecteur d'écran réussi.
Si vous préparez vos propres HTML et JavaScript dans une page KENJTEC, le mode développeur de KENJTEC WebSiteBuilder ai est disponible à cet effet, avec un aperçu en bac à sable et la publication de votre propre code. Vous transférez vous-même le composant ; cela ne crée pas de service de chat d'IA supplémentaire et intégré.
C'est l'expérience d'écoute réelle qui décide
Une capture d'écran ne peut prouver ni une interruption ni une annonce inattendue. Les tests nécessitent donc un clavier et de véritables technologies d'assistance. Notez l'appareil, le navigateur et le lecteur d'écran utilisés si vous rendez compte ultérieurement d'un résultat précis.
Même un bon modèle d'état ne satisfait pas automatiquement toutes les exigences d'un chat accessible. Il répond à une question limitée : comment l'état de traitement devient-il compréhensible sans imposer le contenu à quelqu'un mot après mot ? Une bonne solution préserve les deux : une orientation fiable et le contrôle de la personne sur son propre rythme de lecture.
Sources et état
Recherche et documentation à la date du 25 octobre 2026. Comprendre le SC 4.1.3 : messages d'état · ARIA22 : utiliser role=status pour présenter des messages d'état.
