Table of Contents
Scopo #
Lo scopo principale di questo test di accessibilità manuale è valutare meticolosamente l’implementazione dei limiti di tempo all’interno di una piattaforma per garantirne la conformità al Criterio di Successo 2.2.1 “Tempistica Regolabile” (A) delle Linee Guida per l’Accessibilità dei Contenuti Web (WCAG) 2.2. Ciò implica la verifica che gli utenti siano adeguatamente informati sui limiti di tempo e che dispongano di meccanismi sufficienti per modificarli, estenderli o disattivarli, prevenendo così la perdita di dati o la disconnessione involontaria. Questo processo manuale si concentra sull’esperienza utente e sulla navigabilità su diversi dispositivi.
Criteri WCAG coperti #
- 2.2.1 Temporizzazione regolabile – A
Il criterio di successo WCAG 2.2 2.2.1 Tempo regolabile (livello A) afferma: “Per ogni limite di tempo impostato dal contenuto, almeno una delle seguenti condizioni è vera:
Spegnere:
All’utente è consentito disattivare il limite di tempo prima di incontrarlo; oppure
Regolare:
All’utente è consentito regolare il limite di tempo prima di incontrarlo su un ampio intervallo che è almeno dieci volte la lunghezza dell’impostazione predefinita; oppure
Estendere:
L’utente viene avvisato prima che scada il tempo e gli vengono dati almeno 20 secondi per estendere il limite di tempo con una semplice azione (ad esempio “premi un tasto qualsiasi”) e gli è consentito estendere il limite di tempo almeno dieci volte; oppure
Eccezione in tempo reale:
Il limite di tempo è una parte obbligatoria di un evento in tempo reale (ad esempio un’asta) e non è possibile alcuna alternativa al limite di tempo; oppure
Eccezione essenziale:
Il limite di tempo è essenziale e la sua proroga invaliderebbe l’attività; oppure
Eccezione di 20 ore:
Il limite di tempo è superiore a 20 ore.”
Questo criterio è rilevante e viene testato nei seguenti modi:
- Visibilità e chiarezza degli avvisi:
Valuteremo se all’utente viene fornito un avviso chiaro, evidente e comprensibile circa l’imminente scadenza del limite di tempo. Ciò include la verifica della tempistica, della persistenza e del contenuto informativo dell’avviso.
- Meccanismo di estensione/regolazione/disabilitazione:
Esamineremo attentamente la presenza, la rilevabilità e la funzionalità dei controlli che consentono agli utenti di estendere, modificare o disattivare completamente i limiti di tempo. Ciò include la verifica che tali controlli siano facilmente utilizzabili tramite tastiera, mouse e touch.
- Periodo di grazia e proroghe multiple:
Per gli scenari “Estendi”, faremo in modo che gli utenti abbiano a disposizione un periodo di tolleranza minimo di 20 secondi per estendere la sessione e che siano possibili più estensioni (almeno 10 volte la durata originale).
- Reattività e coerenza:
Il test verificherà che gli avvisi e i controlli sui limiti di tempo funzionino in modo coerente e siano pienamente reattivi su schermi di diverse dimensioni (desktop, tablet, dispositivi mobili) e orientamenti.
- Giustificazione dell’eccezione (se applicabile):
Se un limite di tempo non è modificabile, verificheremo se rientra effettivamente nelle clausole “Eccezione in tempo reale” o “Eccezione essenziale”, assicurandoci che non esistano limiti di tempo non modificabili non necessari o arbitrari.
Ambiente di prova #
Questo test richiede una varietà di dispositivi e metodi di input per valutare approfonditamente l’accessibilità dell’interazione.
Desktop #
- Sistemi operativi: Windows (ultime due versioni), macOS (ultime due versioni).
- Browser: ultime versioni stabili di Chrome, Firefox, Edge, Safari.
- Metodi di input:
- Mouse standard
- Tastiera (per la navigazione e l’interazione)
- Tecnologie assistive: lettore di schermo (ad esempio, NVDA, JAWS su Windows; VoiceOver su macOS) con configurazioni comuni del browser per la verifica di base degli avvisi annunciati.
Cellulari e tablet #
- Sistemi operativi: iOS (ultime due versioni), Android (ultime due versioni).
- Browser: browser predefiniti (Safari su iOS, Chrome su Android) e altri browser mobili più diffusi.
- Metodi di input:
- Touchscreen (tocchi, scorrimenti, pizzicamento per ingrandire per verificare la reattività).
- Tecnologie assistive: lettori di schermo integrati (VoiceOver su iOS, TalkBack su Android) per la verifica di base degli avvisi annunciati.
- Orientamento: modalità verticale e orizzontale.
Preparazione al test #
Prima di iniziare il test manuale, assicurarsi di aver completato i seguenti passaggi:
- Identificare i componenti sensibili al tempo:
Elencare sistematicamente tutte le aree della piattaforma che incorporano limiti di tempo espliciti o impliciti. Questo può includere: - Documentazione del sistema di revisione:
Se disponibile, consultare la documentazione relativa alla gestione delle sessioni, alla sicurezza e ai limiti di tempo per comprendere il comportamento previsto dalla piattaforma. - Stabilire la funzionalità di base:
Interagisci brevemente con ciascun componente sensibile al tempo identificato per comprenderne il comportamento predefinito senza intervento. Annota la durata predefinita di ciascun limite di tempo. - Preparare account/dati di prova:
Assicurati di disporre degli account di prova o dei dati necessari che consentano l’accesso a tutte le funzionalità sensibili al fattore tempo. - Cancella cache/cookie del browser:
Per garantire un ambiente di test pulito, cancellare la cache e i cookie del browser prima di iniziare i test, in particolare per i limiti di tempo relativi alla sessione. - Familiarizzare con WCAG 2.2.1:
Rileggere e comprendere le sfumature del criterio di successo 2.2.1 e le sue eccezioni.
Processo di test passo dopo passo #
Eseguire i seguenti passaggi per ciascun componente sensibile al fattore tempo identificato, sia su desktop che su dispositivi mobili/tablet. Documentare meticolosamente le osservazioni.
PASSO 1 – Procedura generale per i limiti di tempo #
Osservazione iniziale e trigger di avvertimento: #
- Passare a una pagina o sezione con un limite di tempo noto.
- Lasciare trascorrere il tempo, osservando l’interfaccia per eventuali avvisi.
- Caso di prova:
viene visualizzato un avviso prima della scadenza del limite di tempo? - Caso di prova:
l’avviso è visivamente evidente (ad esempio, non solo una piccola icona facilmente trascurabile o un leggero cambiamento di colore)? - Caso di prova:
l’avviso fornisce tempo sufficiente per reagire (ad esempio, almeno 20 secondi per l’estensione o di più se l’azione richiesta è complessa)? - Caso di prova:
il messaggio di avviso è chiaro, conciso e comprensibile? Indica esplicitamente la scadenza imminente e le opzioni di offerta? - Caso di prova:
l’avviso viene annunciato dagli screen reader? (Breve verifica con AT per un segnale acustico).
Verifica del meccanismo di estensione: #
- Quando viene visualizzato l’avviso, individuare i controlli per estendere la sessione.
- Caso di prova (desktop):
il controllo dell’estensione può essere attivato tramite tastiera (Tab, Invio, barra spaziatrice)? - Caso di prova (desktop):
il controllo dell’estensione può essere attivato tramite clic del mouse? - Caso di test (dispositivo mobile/tablet):
il controllo dell’estensione può essere attivato tramite tocco? Le dimensioni del touch target sono adeguate? - Caso di test:
l’attivazione del controllo estende correttamente il limite di tempo? È presente una conferma visibile (ad esempio, il timer si azzera, un messaggio conferma l’estensione)? - Caso di prova:
il limite di tempo può essere esteso più volte (ad esempio, almeno 10 volte la durata originale)? - Caso di prova:
il meccanismo di estensione funziona correttamente se l’utente tenta di estendere il tempo proprio mentre sta per scadere?
Verifica del meccanismo di regolazione (se applicabile): #
- Se la piattaforma consente agli utenti di modificare il limite di tempo (ad esempio, “mantienimi connesso per X minuti/ore”).
- Caso di prova:
esiste un elemento di interfaccia chiaro per regolare il limite di tempo prima dell’inizio? - Caso di prova:
il controllo della regolazione può essere azionato tramite tastiera, mouse e tocco? - Caso di prova:
la regolazione consente un intervallo ampio (ad esempio, almeno 10 volte l’impostazione predefinita)? - Caso di prova:
il limite di tempo modificato persiste come previsto?
Verifica del meccanismo di disattivazione (se applicabile): #
- Se la piattaforma consente agli utenti di disattivare completamente il limite di tempo (ad esempio, la funzionalità “Ricordami” che ignora il timeout della sessione).
- Caso di prova:
esiste un elemento di interfaccia chiaro per disattivare il limite di tempo prima che inizi? - Caso di prova:
il controllo di disattivazione può essere azionato tramite tastiera, mouse e tocco? - Caso di prova:
la disattivazione del limite di tempo funziona come previsto (ad esempio, non si verifica alcun timeout della sessione)? - Caso di prova:
lo stato disabilitato persiste nelle sessioni successive (se previsto)?
Scadenza del tempo e perdita di dati: #
- Lasciare scadere il limite di tempo senza intervento dopo un avvertimento (se applicabile).
- Caso di prova:
cosa succede allo scadere del limite di tempo? L’utente viene disconnesso, reindirizzato o i dati vengono cancellati? - Caso di prova:
è presente un messaggio chiaro che informa l’utente del motivo per cui la sessione è terminata? - Caso di test:
vengono persi dati inseriti dall’utente? Se i dati vengono persi, ciò indica un errore critico, a meno che non rientri in un’eccezione “essenziale”.
Scenari specifici da testare #
Sessioni di accesso: #
- Accedi e osserva il timeout della sessione.
- Estensione del test durante la fase di avviso.
- Prova a disattivare le opzioni “Ricordami” o “Mantienimi connesso”.
- Verificare cosa accade in caso di timeout (ad esempio, disconnessione graduale o interruzione improvvisa della sessione).
Moduli/transazioni in più fasi: #
- Avviare un processo in più fasi (ad esempio, checkout, modulo di domanda).
- Fai una pausa a metà e lascia che il timer si avvicini alla scadenza.
- Caso di prova:
viene visualizzato l’avviso e l’utente può prolungare la sessione per completare il modulo? - Caso di prova:
i dati dell’utente vengono conservati se la sessione viene estesa? - Caso di prova:
se la sessione scade, esiste un modo per recuperare dati parziali o tutti i progressi vengono persi? (La perdita di dati è un problema importante).
Contenuti interattivi (quiz, giochi): #
- Se il contenuto ha un timer, può essere messo in pausa, esteso o disattivato?
- Caso di prova:
per i quiz a tempo, il timer può essere modificato o esteso? (Potrebbe trattarsi di un’eccezione “essenziale”, ma deve essere chiaramente giustificata).
Caroselli/Presentazioni: #
- Osserva i caroselli che avanzano automaticamente.
- Caso di prova:
esiste un meccanismo per mettere in pausa o interrompere l’avanzamento automatico? - Caso di prova:
gli utenti possono navigare manualmente tra gli elementi al proprio ritmo?
Controlli di gioco: #
- Se un gioco utilizza l’inclinazione o la vibrazione per il controllo, assicurati che siano disponibili pulsanti sullo schermo o controlli da tastiera equivalenti.
- Se le azioni richiedono schemi di scorrimento complessi, fornisci alternative più semplici basate sul tocco.
Reattività e controlli specifici del dispositivo #
Desktop: #
- Ridimensiona la finestra del browser: assicurati che avvisi e controlli rimangano visibili, leggibili e funzionali in tutte le dimensioni della finestra.
- Navigazione tramite tastiera: assicurarsi che tutti gli elementi interattivi relativi ai limiti di tempo siano accessibili tramite scheda e gestibili tramite tastiera.
Cellulare/Tablet: #
- Modifica l’orientamento del dispositivo (da verticale a orizzontale e viceversa): verifica che gli avvisi e i controlli si adattino correttamente e restino utilizzabili.
- Dimensioni del target touch: verificare che i target touch per i controlli di estensione/regolazione siano sufficientemente grandi (ad esempio, 44px×44px) e abbiano una spaziatura sufficiente per evitare tocchi accidentali.
- Funzionalità di zoom: assicurati che avvisi e controlli siano visibili e funzionanti quando la pagina è ingrandita.
Identificazione dei problemi #
Durante il processo di test, identificare e documentare eventuali deviazioni dal comportamento previsto in base alle WCAG 2.2.1. Esempi di problemi includono:
- Nessun avviso:
il limite di tempo scade senza alcuna notifica preventiva. - Tempo di avviso insufficiente:
l’avviso viene visualizzato ma non fornisce almeno 20 secondi per una semplice azione di estensione. - Avviso poco chiaro/invisibile:
il messaggio di avviso è poco chiaro, utilizza solo colori, è troppo piccolo o scompare troppo velocemente. - Nessuna opzione di estensione/regolazione/disabilitazione:
la piattaforma impone un limite di tempo senza alcun controllo da parte dell’utente e non rientra in alcuna eccezione. - Controlli difficili da trovare:
i controlli per la gestione dei limiti di tempo sono nascosti, nascosti nelle impostazioni o non chiaramente etichettati. - Comandi non operativi:
i comandi di estensione/regolazione/disattivazione non possono essere utilizzati tramite tastiera, mouse o tocco, a seconda dei casi. - Estensioni limitate:
all’utente è consentita una sola estensione oppure meno di 10 estensioni quando ne sono necessarie di più. - Perdita di dati al timeout:
i dati immessi dall’utente vengono persi alla scadenza della sessione e non esiste alcun meccanismo di recupero o salvataggio automatico. - Impostazioni non persistenti:
i limiti di tempo modificati o disabilitati non persistono nelle sessioni come previsto. - Elementi non reattivi:
gli avvisi o i controlli diventano illeggibili o inutilizzabili su schermi di dimensioni o orientamenti diversi. - Falsa eccezione “essenziale” o “in tempo reale”:
un limite di tempo viene dichiarato essenziale ma potrebbe essere ragionevolmente reso modificabile o esteso senza compromettere la validità dell’attività (ad esempio, un semplice modulo che scade). - Annunci con AT:
gli screen reader non annunciano la presenza di un avviso di limite di tempo o il tempo rimanente.
Classificazione di gravità #
Assegnare un livello di gravità a ciascun problema identificato in base al suo impatto sull’accessibilità dell’utente:
- Critico:
impedisce agli utenti con disabilità di completare un’attività fondamentale o di accedere a informazioni essenziali. Viola direttamente un criterio di Livello A con un impatto negativo significativo sull’utente (ad esempio, perdita di dati cruciali a causa di un timeout non annunciato, impossibilità di estendere la sessione con conseguente blocco). - Alto:
ostacola significativamente gli utenti con disabilità nel completare le attività o nell’accedere alle informazioni, ma potrebbe esistere una soluzione alternativa. Viola direttamente un criterio di Livello A (ad esempio, l’Avviso è presente ma troppo breve, il meccanismo di estensione è difficile da trovare ma alla fine può essere scoperto). - Medio:
causa un disagio o una frustrazione moderati per gli utenti con disabilità. Potrebbe trattarsi di una violazione indiretta o di un’area di miglioramento che non soddisfa rigorosamente un criterio A, ma che influisce sull’usabilità (ad esempio, il messaggio di avviso è leggermente ambiguo, il touch target è leggermente troppo piccolo). - Basso:
piccolo inconveniente o problema estetico che ha un impatto minimo sull’accessibilità (ad esempio, stile incoerente dei messaggi di avviso nei diversi componenti).
Nota finale #
Questo test di accessibilità manuale funge da complemento fondamentale alla scansione automatizzata, individuando le barriere critiche di usabilità e accessibilità legate ai limiti di tempo. Seguendo scrupolosamente questi passaggi, i team possono garantire che le loro piattaforme offrano un’esperienza solida, inclusiva e intuitiva per tutti, in particolare per coloro che necessitano di più tempo o controllo sulle proprie interazioni con i contenuti digitali. Ricordate, una documentazione completa è fondamentale per una correzione efficace.
