Come verificare l’accessibilità da tastiera e con screen reader di un widget WebChat

Verifica la pagina, il widget e il passaggio dall’uno all’altra

Un widget di chat non funziona isolatamente. Il suo pulsante di apertura si trova all’interno di una pagina che lo ospita, mentre la conversazione aperta può essere visualizzata in un pannello, una finestra di dialogo o un’altra interfaccia. Verifica l’esperienza effettivamente incorporata: la pagina intorno al pulsante di apertura, il widget stesso e ciò che accade quando le persone vi entrano o ne escono.

Prima di iniziare i test, annota l’URL della pagina, la configurazione del widget, il browser e il sistema operativo, la tecnologia assistiva e gli stati dell’interfaccia inclusi. Considera il pulsante di apertura, la chat aperta, gli eventuali moduli pre-chat, lo scambio di messaggi, gli errori di convalida, lo stato ridotto a icona e quello chiuso, quando queste funzionalità sono presenti. Non dare per scontato che ogni widget usi una finestra di dialogo modale: verifica come si comporta quello in esame.

• Ambito: integrazione nella pagina ospitante, controlli del widget e stati pertinenti della conversazione.
• Campione: scegli pagine e flussi rappresentativi, includendo un modulo o uno stato di errore, se disponibile.
• Ambiente: annota browser, sistema operativo, lettore di schermo e metodo di input.
• Responsabilità: indica quali parti sono gestite dal team del sito web, dal fornitore del widget o dal fornitore del canale.

Prepara un piano di test breve e ripetibile

Combina i test con la sola tastiera e quelli con il lettore di schermo. I controlli automatici di accessibilità possono aiutare a individuare alcuni problemi, ma non dimostrano che un widget sia accessibile. WAI sottolinea che nessun singolo strumento di valutazione può determinare se un sito soddisfa gli standard di accessibilità: è necessaria una valutazione umana condotta da persone competenti.

Scegli un piccolo insieme di percorsi utente che il team possa ripetere dopo ogni modifica. Per esempio: aprire il widget, raggiungere e compilare i campi, inviare un messaggio, accorgersi di una risposta, chiudere il widget e continuare a usare la pagina. Includi i passaggi eseguiti con la sola tastiera e una verifica con il lettore di schermo per lo stesso percorso.

• Usa Tab e Maiusc+Tab per spostarti tra i controlli; usa Invio e la barra spaziatrice per attivare i pulsanti.
• Usa i normali comandi di lettura e navigazione dei moduli del lettore di schermo per verificare nomi, ruoli, istruzioni e aggiornamenti.
• Esegui una scansione automatizzata, se opportuno, poi verifica manualmente i risultati e prova i comportamenti che lo strumento non può valutare.
• Usa dati di test non sensibili; durante la verifica, evita di inviare informazioni reali dei clienti.

Verifica l’apertura, la chiusura e il ripristino del focus

Raggiungi il pulsante di apertura senza usare il mouse. Verifica che abbia un nome accessibile utile, che il focus sia visibile e che sia possibile attivarlo con Invio o la barra spaziatrice. Dopo aver aperto la chat, determina dove si sposta il focus e se quella destinazione rende chiara l’azione successiva.

Se la chat si comporta come una finestra di dialogo modale, confrontane il comportamento da tastiera con il pattern per le finestre di dialogo modali delle WAI-ARIA Authoring Practices: il focus entra nella finestra di dialogo, Tab e Maiusc+Tab vi restano all’interno, Esc la chiude e, di norma, il focus torna al controllo che l’ha aperta. Applica questo pattern solo se l’interfaccia è effettivamente modale. Per un pannello non modale, verifica che gli utenti possano spostarsi tra pannello e pagina senza restare intrappolati o perdere il punto in cui si trovavano.

Chiudi la chat usando la tastiera, poi verifica che il focus torni in una posizione logica, di solito il pulsante di apertura, e resti visibile. Riaprila e controlla che lo stato precedente della conversazione e il comportamento del focus siano comprensibili.

• È possibile raggiungere e attivare con la tastiera il pulsante di apertura e il controllo di chiusura?
• Il focus è visibile prima e dopo l’apertura, la chiusura e la riapertura?
• Quando il widget si apre, il focus si sposta su un punto iniziale utile?
• Gli utenti possono uscire dal widget senza puntatore e senza ritrovarsi intrappolati nel focus in modo imprevisto?
• Dopo la chiusura, gli utenti possono riprendere da una posizione sensata nella pagina ospitante?

Controlla l’ordine, i controlli e le istruzioni dei moduli

Spostati con Tab nel widget aperto e tra i controlli vicini della pagina. Il focus dovrebbe seguire un ordine che mantenga il senso e consenta di usare l’interfaccia. Fai attenzione se il focus passa dietro una sovrapposizione, salta un controllo, entra in contenuti nascosti o esce dal widget inaspettatamente. Verifica che ogni controllo che riceve il focus abbia un indicatore visibile.

Esamina pulsanti, link, campi e altri componenti interattivi con un lettore di schermo. I nomi e i ruoli dovrebbero spiegare cosa sono e quale azione svolgono; quando pertinente, dovrebbero essere comunicate anche le variazioni di stato, come espanso, selezionato o disabilitato. Un’icona visiva da sola potrebbe non fornire un nome utile.

Per ogni campo di input, verifica che gli utenti possano capire quali informazioni sono richieste e che l’etichetta o l’istruzione sia associata al campo a livello programmatico, dove necessario. Prova il percorso di errore oltre a quello di inserimento corretto: genera un errore di convalida sicuro e prevedibile, poi verifica che il campo con l’errore e il problema siano identificati in testo. Se è noto e opportuno suggerire una correzione, controlla che venga spiegata.

• Controlla l’ordine di navigazione da tastiera tra pulsante di apertura, conversazione, campo del messaggio, controllo di invio ed eventuale modulo pre-chat.
• Verifica che il focus sia visibile e che si comporti in modo sensato quando appare nuovo contenuto o cambia lo stato di un controllo.
• Controlla nomi, ruoli e stati dei controlli con un lettore di schermo, non basarti solo sull’aspetto.
• Verifica che ogni campo di input abbia un’etichetta o un’istruzione chiara e associata.
• Invia dati di test non validi e verifica che l’errore sia identificato e che, quando opportuno, siano disponibili indicazioni utili per correggerlo.

Verifica gli annunci di messaggi e stati

Invia un messaggio di test e verifica come viene presentato dal lettore di schermo. Poi fai apparire una risposta o un altro aggiornamento mentre il focus resta altrove. Gli utenti dovrebbero poter capire che è arrivata una nuova informazione pertinente senza dover cercare nella conversazione o senza che il focus si sposti inaspettatamente.

Controlla anche le variazioni di stato che non spostano il focus, come i messaggi di convalida o quelli sullo stato della connessione, se fanno parte dell’esperienza verificata. Il criterio di successo 4.1.3 delle WCAG 2.2 riguarda i messaggi di stato determinabili a livello programmatico, in modo che le tecnologie assistive possano presentarli senza ricevere il focus. Evita di annunciare ogni minima variazione visiva: gli annunci devono essere utili e non sovraccaricare la conversazione.

• Una persona che usa un lettore di schermo riesce a riconoscere i messaggi in arrivo e chi li ha inviati?
• Gli aggiornamenti significativi vengono annunciati mentre il focus resta al suo posto?
• I messaggi di convalida e gli altri messaggi di stato raggiungono le tecnologie assistive senza richiedere una ricerca visiva?
• Gli annunci sono comprensibili e tempestivi, senza ripetizioni inutili?

Documenta i problemi e assegna la responsabilità corretta

Descrivi ogni problema in modo che un’altra persona possa riprodurlo. Includi la pagina e lo stato del widget, l’ambiente di test, il punto di partenza, i passaggi precisi con tastiera o lettore di schermo, il risultato osservato e quello atteso. Descrivi l’impatto in termini pratici, per esempio: «Una persona che usa la tastiera non riesce a raggiungere il pulsante di invio», invece di riportare soltanto un riferimento a uno standard.

Distingui i probabili problemi di integrazione nella pagina ospitante da quelli del widget, ma considera l’esperienza incorporata nel suo insieme come il risultato che conta per gli utenti. Se la responsabilità non è chiara, chiedi al team del sito web e al fornitore del widget di riprodurre il problema insieme. Un problema che attraversa il confine, come il focus che si sposta su contenuti nascosti della pagina quando si apre il pannello, potrebbe richiedere un’indagine da parte di entrambi i team.

• Registra: ID del problema, URL, data, browser e sistema operativo, tecnologia assistiva, passaggi, risultato effettivo e risultato atteso.
• Aggiungi: impatto sugli utenti, screenshot o breve registrazione, se opportuno, e responsabile probabile.
• Classifica il problema come relativo alla pagina ospitante, al widget, all’integrazione oppure a una responsabilità condivisa o incerta.
• Dopo una correzione, ripeti gli stessi passaggi e registra il risultato nella pagina con il widget incorporato, non solo nell’anteprima locale di un componente.

Usa le indicazioni WCAG e WAI, poi ripeti i test dopo le modifiche

Usa le WCAG 2.2 come riferimento per valutare l’uso da tastiera, l’ordine e la visibilità del focus, le etichette e le istruzioni, l’identificazione degli errori, i nomi e i ruoli dei componenti e i messaggi di stato. Le WAI-ARIA Authoring Practices offrono indicazioni utili sulle interazioni con finestre di dialogo modali e pulsanti; applica i pattern in base al comportamento effettivo dell’interfaccia, non solo al suo aspetto visivo.

Le indicazioni di WAI sulla valutazione raccomandano di valutare nelle prime fasi e durante tutto lo sviluppo. Ripeti i controlli pertinenti quando cambiano la configurazione del widget, lo stile del sito web, il codice di integrazione o il widget stesso. Mantieni una breve checklist di regressione e conserva i risultati, così i team possono verificare se un problema si è ripresentato.

• WCAG 2.2: https://www.w3.org/TR/wcag/
• Panoramica WAI sulla valutazione dell’accessibilità: https://www.w3.org/WAI/test-evaluate/
• Pattern per finestre di dialogo modali WAI-ARIA APG: https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/
• Pattern per pulsanti WAI-ARIA APG: https://www.w3.org/WAI/ARIA/apg/patterns/button/
• Metodologia di valutazione WCAG-EM: https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/

Offri un canale con una persona quando il widget impedisce l’accesso

Se una persona non riesce a raggiungere o usare la chat, non fare del widget inaccessibile l’unico modo per contattare l’assistenza. Offri un canale di contatto alternativo che sia a sua volta accessibile e spiega chiaramente come raggiungere una persona. I team che usano webchat.vip possono organizzare le conversazioni e configurare flussi che le trasferiscono o passano il contatto a persone; questa funzionalità, da sola, non dimostra che un particolare widget o flusso superi una verifica di accessibilità.

Assegna a un team o a un ruolo specifico il compito di ricevere i problemi di accessibilità, coordinarsi con i responsabili del sito e del widget e confermare le correzioni. Se la causa non è chiara, lascia aperto il problema e riproducilo insieme agli altri team, invece di chiedere alla persona interessata di individuare il confine tecnico.

• Indica agli utenti come contattare l’assistenza tramite un’alternativa accessibile quando non possono usare la chat.
• Indirizza i problemi di accesso non risolti a un contatto umano dell’assistenza e a un responsabile del sito web o dell’accessibilità.
• Verifica sia il canale alternativo sia l’esperienza incorporata dopo la correzione, usando tastiera e lettore di schermo.