development
Il tuo chatbot è davvero utilizzabile da tutti?
I chatbot sono ormai un canale primario di assistenza clienti — ma la maggior parte è inaccessibile. Ecco i difetti più comuni, perché contano e cosa serve per un chatbot accessibile.
I chatbot hanno un problema di accessibilità
I chatbot di assistenza clienti sono diventati l’opzione di contatto principale — e spesso l’unica — per molti prodotti digitali. L’aspettativa è chiara: se hai bisogno di aiuto, apri la chat. Se la chat non funziona per te, spesso non c’è nient’altro.
Per gli utenti con disabilità, questa situazione è spesso insostenibile. La maggior parte dei chatbot commerciali non soddisfa i requisiti di base dell’accessibilità. Gli utenti di screen reader non riescono a sentire i messaggi man mano che arrivano. Gli utenti da tastiera restano intrappolati all’interno del widget di chat e non riescono a uscirne. Gli utenti con disabilità motorie incontrano bersagli tattili troppo piccoli da toccare in modo affidabile. Gli utenti con disabilità cognitive si trovano di fronte a muri di testo e nessun modo chiaro per recuperare da una richiesta fraintesa.
Questo conta sia sul piano etico sia su quello legale. L’European Accessibility Act, in vigore da giugno 2025, copre i canali digitali di assistenza clienti delle aziende che vi rientrano — il che include le interfacce dei chatbot. L’ADA negli Stati Uniti è stato applicato ai chatbot nel contenzioso sull’accessibilità web. Se un chatbot è un canale di servizio primario, un chatbot inaccessibile è un’esclusione dal servizio.
I sette difetti di accessibilità più comuni nei chatbot
1. Regioni live ARIA mancanti
Quando in una finestra di chat arriva un nuovo messaggio, un utente di screen reader deve poterlo sentire. Ma gli screen reader annunciano solo i contenuti che sono stati indicati come importanti e dinamici. Senza una regione live ARIA che avvolga il contenitore dei messaggi della chat, i messaggi appaiono visivamente ma sono del tutto silenziosi per gli utenti di screen reader.
<!-- Senza regione live: i nuovi messaggi non vengono annunciati -->
<div class="chat-messages">
<!-- I messaggi vengono aggiunti qui dinamicamente -->
</div>
<!-- Con regione live: i nuovi messaggi vengono annunciati man mano che arrivano -->
<div
class="chat-messages"
role="log"
aria-live="polite"
aria-label="Conversazione in chat"
>
<!-- I messaggi vengono aggiunti qui dinamicamente -->
</div>
role="log" è definito specificamente in ARIA per le conversazioni di chat e i flussi di messaggi. aria-live="polite" annuncia i nuovi contenuti dopo che l’utente si è fermato — meno disturbante di assertive per un contesto conversazionale.
2. Trappole da tastiera
Una trappola da tastiera si verifica quando un utente entra in un componente con il tasto Tab e non riesce più a uscirne — resta bloccato. I widget dei chatbot sono tra i punti più comuni in cui compaiono le trappole da tastiera.
La soluzione richiede l’implementazione di una corretta gestione del focus: Tab e Maiusc+Tab devono navigare tra gli elementi interattivi all’interno della chat, ed Esc deve chiudere la chat e riportare il focus all’elemento che l’ha attivata. Il criterio WCAG 2.1.2 Nessuna trappola per la tastiera (Livello A) copre questo requisito.
Testarlo è semplice: apri il tuo chatbot usando solo la tastiera, scorri con Tab tutti gli elementi interattivi al suo interno e verifica di poter uscire usando Esc o un pulsante di chiusura chiaramente visibile.
3. Contrasto cromatico insufficiente
I chatbot vengono spesso resi con i colori del brand, e i colori del brand spesso non sono testati rispetto ai requisiti di contrasto delle WCAG. Difetti comuni:
- Testo dei fumetti di chat che non raggiunge un contrasto di 4,5:1 rispetto allo sfondo del fumetto
- Testo segnaposto dei campi di input al di sotto delle soglie di contrasto
- Testo delle marche temporali in grigio molto chiaro
Il requisito di contrasto si applica all’interfaccia del chatbot esattamente come al resto del tuo sito — non c’è alcuna eccezione per i widget.
4. Campi di input e pulsanti privi di etichetta
Il campo di input della chat — “Scrivi il tuo messaggio…” — deve avere un’etichetta associata a livello di programma, non solo un testo segnaposto. Il testo segnaposto scompare non appena l’utente inizia a digitare e non è un sostituto affidabile di un’etichetta.
Il pulsante di invio, il pulsante di riduzione a icona, il pulsante di chiusura e qualsiasi altro controllo interattivo devono avere nomi accessibili. Un pulsante “invia” solo con icona, senza testo e senza aria-label, viene annunciato dagli screen reader come “pulsante” senza alcuna descrizione della sua funzione.
<!-- Etichetta mancante: fallisce -->
<input type="text" placeholder="Scrivi un messaggio...">
<button><svg><!-- icona invia --></svg></button>
<!-- Con etichetta e aria-label: supera -->
<label for="chat-input" class="sr-only">Scrivi il tuo messaggio</label>
<input type="text" id="chat-input" placeholder="Scrivi un messaggio...">
<button aria-label="Invia messaggio">
<svg aria-hidden="true"><!-- icona invia --></svg>
</button>
5. Bersagli tattili troppo piccoli per gli utenti con disabilità motorie
Le WCAG 2.2 hanno introdotto il criterio 2.5.8 Dimensione del bersaglio (Minimo) al Livello AA, che richiede che gli elementi interattivi abbiano una dimensione minima del bersaglio di 24×24 pixel CSS. Molte interfacce di chatbot collocano i pulsanti di chiusura, riduzione a icona ed emoji a 16–20 pixel — ben al di sotto di questa soglia.
Per gli utenti con disabilità motorie, tremori o ridotto controllo della motricità fine, i bersagli piccoli sono davvero inutilizzabili. I pulsanti d’azione del chatbot sono tra gli elementi dell’interfaccia più frequentemente interessati.
6. Nessun avviso di timeout o estensione della sessione
Molti chatbot terminano una sessione inattiva dopo un periodo prestabilito. Quando questo accade senza preavviso, gli utenti che impiegano più tempo a comporre o leggere i messaggi — compresi molti utenti con disabilità cognitive o motorie — possono perdere la conversazione senza alcuna possibilità di estendere la sessione.
Il criterio WCAG 2.2.1 Regolazione dei tempi (Livello A) richiede che, quando è impostato un limite di tempo, gli utenti possano disattivarlo, prolungarlo, oppure che il limite sia di almeno 20 ore. Un chatbot che termina le sessioni dopo 5 minuti di inattività senza preavviso non è conforme.
7. Linguaggio complesso e nessun recupero dagli errori
I chatbot sono utili solo se gli utenti riescono a comunicare con loro in modo efficace. Per gli utenti con disabilità cognitive, disturbi dell’apprendimento o livelli di alfabetizzazione più bassi, un chatbot che usa un gergo tecnico, presenta lunghi muri di testo senza struttura o fallisce silenziosamente quando non comprende una richiesta è di fatto inaccessibile.
Contenuti di chatbot accessibili:
- Usano un linguaggio semplice (frasi brevi, parole comuni)
- Suddividono le risposte in unità facili da scorrere invece di presentare paragrafi
- Offrono un chiaro recupero dagli errori: quando il bot non comprende, lo dice esplicitamente e propone alternative specifiche
- Aiutano gli utenti a riformulare le richieste invece di limitarsi a dire “Non ho capito”
Nuovi criteri WCAG 2.2 particolarmente rilevanti per i chatbot
Le WCAG 2.2 hanno aggiunto diversi criteri di successo che si applicano con particolare forza alle interfacce di chat:
2.4.11 Focus non oscurato (Minimo) — Livello AA. Quando un widget di chat è aperto, non deve nascondere completamente l’elemento con il focus dietro di sé. Molti widget di chat compaiono sopra il contenuto della pagina e oscurano l’elemento con il focus quando gli utenti scorrono con Tab la pagina sottostante.
2.4.12 Focus non oscurato (Avanzato) — Livello AAA. L’elemento con il focus dovrebbe essere completamente visibile.
2.5.7 Movimenti di trascinamento — Livello AA. Se il tuo widget di chat può essere riposizionato tramite trascinamento, deve esistere un’alternativa con puntatore singolo.
2.5.8 Dimensione del bersaglio (Minimo) — Livello AA, come descritto sopra.
Come testare il tuo chatbot
-
Solo tastiera: apri la chat senza usare il mouse. Scorri con Tab tutti gli elementi. Verifica di poter digitare, inviare messaggi e chiudere il widget usando solo la tastiera. Conferma di poter uscire con Esc.
-
Screen reader: apri NVDA (Windows, gratuito) o VoiceOver (Mac/iOS, integrato) e interagisci con la chat. Verifica che i messaggi vengano annunciati man mano che arrivano. Verifica che i campi di input e i pulsanti siano etichettati correttamente.
-
Zoom al 200%: verifica che l’interfaccia della chat non trabocchi né oscuri il contenuto della pagina quando il testo viene ingrandito.
-
Verifica del contrasto: usa un’estensione del browser come axe DevTools o WAVE per controllare il contrasto nell’interfaccia della chat.
-
Mobile: testa le dimensioni dei bersagli tattili e verifica che la chat funzioni con le funzioni di accessibilità di iOS/Android (VoiceOver, TalkBack).
Se stai integrando un chatbot di terze parti, valuta l’accessibilità del fornitore prima di sceglierlo. Chiedi il loro VPAT (Voluntary Product Accessibility Template) per capire il livello di conformità dichiarato. Testa tu stesso il widget — le dichiarazioni del fornitore non sostituiscono un test diretto.
Integrare l’accessibilità del chatbot fin dall’inizio è molto più economico che adeguarla in un secondo momento. Se stai valutando piattaforme di chatbot, sottoponi ogni candidata a questa checklist prima di impegnarti.
Per una revisione completa del tuo chatbot e del resto della tua esperienza digitale di assistenza clienti, parla con il nostro team o inizia con una scansione gratuita delle tue pagine pubbliche.
Testa il tuo chatbot e l'intero sito per i problemi di accessibilità