Una risposta cresce parola dopo parola. Per le persone vedenti, sembra un progresso. Se ogni frammento viene letto subito, lo stesso output può causare interruzioni continue. La domanda quindi non è se una modifica sia tecnicamente visibile, ma di quali informazioni una persona abbia bisogno in quel momento.
Nel criterio di successo 4.1.3, le WCAG 2.2 trattano i messaggi di stato, che dovrebbero essere determinabili programmaticamente senza uno spostamento del focus. La spiegazione del W3C menziona anche l'esigenza di evitare interruzioni non necessarie. Ciò non implica un obbligo generale di annunciare singolarmente ogni parola appena generata. Per una chat con IA è particolarmente utile separare lo stato di elaborazione dal contenuto della risposta.
Tre stati invece di un annuncio infinito
Il nostro modello dimostrativo prevede tre situazioni comprensibili: richiesta ricevuta, risposta in generazione, risposta completata. Offrono orientamento sul processo. Il testo della risposta, invece, risponde alla domanda nel merito e dovrebbe poi restare leggibile al ritmo della persona.
Durante l'attesa, una persona può tornare al proprio campo di input o leggere altre parti della pagina. L'interfaccia non dovrebbe scavalcare questa attività solo perché è arrivato un altro blocco di testo. Nemmeno una risposta completata deve per forza prendere automaticamente il focus della tastiera.
Il feedback appropriato dipende dallo stato. Un processo ancora in corso è cosa diversa da un errore che richiede una nuova decisione. Se tutti i messaggi vengono presentati come ugualmente urgenti, scompare proprio questa priorità.
Un piccolo pattern HTML separa contenuto e stato
Il frammento seguente è nostro e non contiene alcun collegamento a un'IA. Mostra soltanto due aree con compiti diversi. L'area della risposta contiene il testo che può essere letto in seguito. La breve riga di stato comunica lo stato attuale.
<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 tecnica ARIA22 del W3C descrive role=status con una live region di tipo polite e l'annuncio dell'intero contenuto dello stato. Il nostro aria-atomic esplicito rende visibile questa intenzione nel frammento didattico. Non è un motivo per inserire l'intero testo della risposta, in continua crescita, nello stesso breve messaggio di stato.
Un'implementazione reale aggiornerebbe la riga di stato nei passaggi significativi, per esempio una volta all'inizio e una volta al completamento. Quanto spesso un messaggio di avanzamento intermedio sia davvero utile va verificato con il flusso specifico e con le tecnologie assistive.
Quando verifichi all'ascolto, considera anche una persona che sta già leggendo altrove mentre la risposta viene generata. Deve continuamente ricominciare la frase? Riesce in seguito a trovare deliberatamente la risposta completata? Queste osservazioni verificano l'uso del pattern in modo più preciso rispetto al semplice constatare che un annuncio si sente da qualche parte.
Annullamento ed errori hanno bisogno di parole proprie
Se l'output viene interrotto, «fatto» non deve significare semplicemente che non arrivano più caratteri. Un testo interrotto deliberatamente può essere incompleto. Un errore tecnico può significare che non è stato prodotto alcun risultato utilizzabile. Queste differenze vanno espresse nel linguaggio dell'interfaccia.
Per un primo controllo puoi usare tre testi di esempio fissi e attivare i passaggi a mano. Osserva che cosa viene annunciato mentre continui a leggere, se il focus resta dov'è e come arrivi al testo completato. È un esercizio che puoi svolgere, ma qui non viene presentato come un test con screen reader superato.
Se prepari il tuo HTML e JavaScript in una pagina KENJTEC, puoi usare a questo scopo la modalità sviluppatore di KENJTEC WebSiteBuilder ai , con un'anteprima in sandbox e la pubblicazione del tuo codice. Il componente lo trasferisci tu; ciò non crea un servizio di chat con IA aggiuntivo e integrato.
Decide l'esperienza di ascolto reale
Uno screenshot non può dimostrare né un'interruzione né un annuncio inatteso. Per i test servono quindi una tastiera e tecnologie assistive reali. Annota il dispositivo, il browser e lo screen reader usati se in seguito riferisci un risultato specifico.
Anche un buon pattern di stato non soddisfa automaticamente ogni requisito di una chat accessibile. Risponde a una domanda limitata: come rendere comprensibile lo stato di elaborazione senza imporre il contenuto a qualcuno parola per parola? Una buona soluzione preserva entrambe le cose: un orientamento affidabile e il controllo della persona sul proprio ritmo di lettura.
Fonti e stato
Ricerca e documentazione aggiornate al 25 ottobre 2026. Understanding SC 4.1.3: Status Messages · ARIA22: Using role=status to present status messages.
