Invio di moduli e gestione degli errori per le tecnologie assistive

Scopo #

Lo scopo principale di questo test di accessibilità manuale è valutare meticolosamente l’accessibilità di tutti i moduli, i relativi processi di invio e, in particolare, i meccanismi di gestione degli errori all’interno di una piattaforma digitale. Questo test è progettato per essere eseguito dopo una scansione di accessibilità automatizzata e mira a scoprire problematiche complesse e incentrate sull’utente relative all’etichettatura degli input, alla comunicazione degli errori, all’operatività della tastiera e al comportamento prevedibile che gli strumenti automatizzati spesso non rilevano. Garantire che i moduli siano utilizzabili e che gli errori siano comunicati in modo chiaro e accessibile è fondamentale per tutti gli utenti, in particolare per quelli con disabilità cognitive, visive o motorie, prevenendo frustrazione, perdita di dati e incapacità di completare attività critiche.

Criteri WCAG coperti #

Questo test affronta specificamente i seguenti criteri di successo WCAG 2.2 relativi all’invio di moduli e alla gestione degli errori:

• 2.1.1 Tastiera – A

Tutti i controlli del modulo devono essere azionabili solo tramite tastiera.

Rilevanza/Test:
Verificheremo che tutti i campi, i pulsanti e gli altri elementi interattivi dei moduli siano attivabili e utilizzabili tramite tastiera (Tab, Maiusc + Tab, Invio, barra spaziatrice, tasti freccia). Questo include campi dinamici, controlli personalizzati e pulsanti di invio.

• 1.3.1 Informazioni e relazioni – A

Le informazioni, la struttura e le relazioni trasmesse attraverso la presentazione devono essere determinabili a livello di programmazione.

Rilevanza/Test:
Ci assicureremo che i campi del modulo siano associati programmaticamente alle rispettive etichette (ad esempio, ). Per i moduli complessi, i set di campi e le legende dovrebbero raggruppare gli input correlati. I messaggi di errore dovrebbero essere collegati programmaticamente ai rispettivi campi di input e lo stato generale del modulo (ad esempio, riuscito/errore) dovrebbe essere comunicato tramite ARIA.

• 3.3.1 Identificazione degli errori – A

Se viene rilevato automaticamente un errore di inserimento, l’elemento in errore viene identificato e l’errore viene descritto all’utente tramite testo.

Rilevanza/Test:
Provocheremo intenzionalmente errori di convalida. Verificheremo che ogni campo di input errato sia chiaramente identificato (ad esempio, evidenziando visivamente, con un’icona) e che venga fornita una descrizione testuale concisa dell’errore. Gli annunci dello screen reader saranno controllati per confermare che i messaggi di errore siano stati trasmessi.

• 4.1.2 Nome, ruolo, valore – A

Tutti i componenti dell’interfaccia utente (campi dei moduli, pulsanti) devono avere un nome e un ruolo determinabili a livello di programmazione e i loro stati/valori devono essere esposti.

Rilevanza/Test:
Esamineremo ogni elemento del modulo per assicurarci che abbia un nome accessibile e accurato (da <label>, aria-label o aria-labelledby), il ruolo semantico corretto (ad esempio, role=”textbox”, role=”checkbox”) e che il suo valore e stato attuali (ad esempio, aria-invalid=”true”, aria-required=”true”, aria-checked=”true”) siano annunciati correttamente dagli screen reader.

• 2.4.6 Titoli ed etichette – AA

I titoli e le etichette descrivono l’argomento o lo scopo.

Rilevanza/Test:
Verificheremo che tutti gli input del modulo abbiano etichette chiare, descrittive e persistenti che ne descrivano accuratamente lo scopo. Le intestazioni (<h1> – <h6>) dovrebbero essere utilizzate per strutturare logicamente le sezioni del modulo.

• 1.3.5 Identificare lo scopo dell’input – AA

Lo scopo dei campi di input che raccolgono informazioni sull’utente può essere determinato a livello di programmazione.

Rilevanza/Test:
Per i campi di input comuni che raccolgono informazioni sull’utente (ad esempio nome, email, indirizzo, numero di telefono), ci assicureremo che l’attributo di completamento automatico venga utilizzato correttamente (ad esempio, autocomplete=”name”, autocomplete=”email”). Questo facilita la funzionalità di completamento automatico e fornisce un significato semantico alle tecnologie assistive.

• 3.2.4 Identificazione coerente – AA

I componenti che hanno la stessa funzionalità all’interno di un insieme di pagine Web vengono identificati in modo coerente.

Rilevanza/Test:
Verificheremo che le etichette, i nomi e le rappresentazioni visive per i campi o i pulsanti dei moduli identici (ad esempio, il pulsante “Invia”, il campo “Indirizzo e-mail”) vengano applicati in modo coerente sull’intera piattaforma.

• 3.2.2 In ingresso – A

La modifica dell’impostazione di un componente dell’interfaccia utente non determina automaticamente una modifica del contesto, a meno che l’utente non sia stato informato del comportamento prima di utilizzare il componente.

Rilevanza/Test:
Interagiremo con i campi del modulo (ad esempio, selezionando un’opzione a discesa, digitando in un campo di testo) e verificheremo che queste interazioni non inviino automaticamente il modulo, aggiornino la pagina o spostino il focus su una sezione diversa senza l’esplicito intervento dell’utente (ad esempio, cliccando su un pulsante di invio).

• 3.2.6 Aiuto coerente – A

Se per un campo di input è disponibile del contenuto della guida, questo viene fornito in una posizione o in un modo coerente.

Rilevanza/Test:
Se i moduli forniscono testo di aiuto o istruzioni, verificheremo che la loro presenza e il loro posizionamento siano coerenti in tutti i campi pertinenti del sito.

• 3.3.2 Etichette o istruzioni – A

Le etichette o le istruzioni vengono fornite quando il contenuto richiede l’input dell’utente.

Rilevanza/Test:
Tutti gli input richiesti devono avere etichette chiare. Le istruzioni per input complessi (ad esempio, requisiti per la password, formati di data specifici) devono essere fornite prima o al momento dell’inserimento.

• 1.4.1 Uso del colore – A

Il colore non è utilizzato come unico mezzo visivo per trasmettere informazioni, indicare un’azione, sollecitare una risposta o distinguere un elemento visivo.

Rilevanza/Test:
Per la convalida del modulo, faremo in modo che gli errori vengano indicati non solo tramite colore (ad esempio, testo rosso), ma anche tramite un’icona, un messaggio di testo in chiaro o uno stile di bordo diverso, consentendo agli utenti che non riescono a percepire i colori di identificare i problemi.

• 3.3.3 Suggerimento di errore – AA

Se viene rilevato automaticamente un errore di inserimento e viene suggerita una correzione, tale suggerimento viene fornito all’utente, a meno che non comprometta la sicurezza o lo scopo del contenuto.

Rilevanza/Test:
Per gli errori più comuni (ad esempio, formato data errato, dominio e-mail scritto male), verificheremo che il sistema offra suggerimenti specifici e attuabili per la correzione (ad esempio, “Intendevi example@domain.com?” o “Inserisci la data nel formato MM/GG/AAAA”).

• 3.3.7 Voce ridondante – A

Nelle pagine in cui agli utenti viene richiesto di reinserire le informazioni precedentemente inserite nello stesso processo, il contenuto viene popolato automaticamente oppure all’utente viene offerta la possibilità di selezionare le informazioni inserite in precedenza.

Rilevanza/Test:
Nei moduli o flussi di lavoro composti da più fasi in cui le stesse informazioni (ad esempio, indirizzo di fatturazione, dati personali) vengono richieste più volte, verificheremo se i dati sono precompilati o se è previsto un meccanismo (ad esempio, casella di controllo “Uguale all’indirizzo di fatturazione”) per evitare immissioni ridondanti.

• 3.3.8 Autenticazione accessibile (minimo) – AA

Per un processo di autenticazione, è disponibile almeno un metodo che non si basa su un test delle funzioni cognitive (ad esempio, ricordare un nome utente e una password), a meno che non venga fornito un metodo di autenticazione alternativo che non si basa su un test delle funzioni cognitive.

Rilevanza/Test:
Per i moduli di accesso/autenticazione, cercheremo alternative all’inserimento tradizionale di nome utente/password che riducano al minimo il carico cognitivo, come opzioni di accesso senza password (ad esempio, collegamento e-mail, autenticazione biometrica) o processi di recupero/reimpostazione della password chiari e intuitivi.

• 3.3.4 Prevenzione degli errori (legali, finanziari, dati) – AA

Per le pagine Web che comportano impegni legali o transazioni finanziarie per l’utente, che modificano o eliminano dati controllabili dall’utente in un sistema di archiviazione dati o che inviano risposte di test utente, almeno una delle seguenti condizioni è vera:

• Gli invii sono reversibili.
• I dati immessi dall’utente vengono controllati per individuare eventuali errori di immissione e all’utente viene data la possibilità di correggerli.
• È disponibile un meccanismo per rivedere, confermare e correggere le informazioni prima dell’invio finale.

Rilevanza/Test:
Per i moduli che incidono su dati o transazioni sensibili (ad esempio, checkout, eliminazione dell’account, invio di test), verificheremo la presenza di passaggi di conferma, chiari meccanismi di correzione degli errori o opzioni di annullamento prima dell’impegno finale.

• 3.3.6 Aiuto – AAA

È disponibile una guida contestuale.

Rilevanza/Test:
Per i moduli o i campi complessi, cercheremo meccanismi di aiuto sensibili al contesto (ad esempio, piccole icone informative che mostrano il testo della guida al passaggio del mouse/focus, oppure testo della guida in linea) che siano facili da accedere e forniscano assistenza pertinente e tempestiva senza interrompere il flusso dell’utente.

• 3.3.9 Autenticazione accessibile (migliorata) – AAA

Per un processo di autenticazione, è disponibile almeno un metodo di autenticazione che non si basa su un test delle funzioni cognitive, oppure è disponibile un meccanismo per assistere l’utente nel completamento di un test delle funzioni cognitive. Questa è una versione più restrittiva della 3.3.8.

Rilevanza/Test:
Verificheremo che i processi di autenticazione offrano alternative che minimizzino il carico cognitivo oltre al semplice ricordare le password, come robuste opzioni senza password, o forniscano un supporto significativo per qualsiasi test cognitivo (ad esempio, CAPTCHA molto facili da risolvere, o che offrano molteplici alternative molto intuitive). Ciò significa che il test cognitivo stesso viene aggirato o reso molto semplice.

• 2.5.6 Meccanismi di input simultanei – AAA

I contenuti web non limitano l’uso delle modalità di input disponibili su una piattaforma, salvo nei casi in cui la restrizione sia essenziale o per impedire interferenze.

Rilevanza/Test:
Verificheremo la possibilità di utilizzare più metodi di input contemporaneamente o in modo intercambiabile senza conflitti all’interno dei moduli. Ad esempio, garantiremo che un utente possa digitare con una tastiera fisica mentre sono attivi i gesti touch di uno screen reader, o che i comandi vocali non interferiscano con l’input del mouse, a meno che non siano esplicitamente progettati per questo. Questo garantisce che gli utenti possano sfruttare la loro combinazione preferita di metodi di input.

Ambiente di prova #

Questo test richiede l’uso completo della navigazione da tastiera, dell’interazione con lo screen reader e degli strumenti per sviluppatori su vari dispositivi.

Desktop #

• Sistemi operativi: Windows (ultime due versioni), macOS (ultime due versioni).
• Browser: ultime versioni stabili di Chrome, Firefox, Edge, Safari (con solidi strumenti di sviluppo per l’ispezione di HTML, attributi ARIA e albero di accessibilità).
• Metodi di input:
  • Tastiera standard (metodo di input principale per tutte le interazioni),
  • Mouse standard (per osservare il comportamento ma non per l’interazione durante il test)
  • Software di controllo vocale (ad esempio, Riconoscimento vocale di Windows, Controllo vocale di macOS) per la verifica 2.5.6.
• Tecnologie assistive: Lettore di schermo (ad esempio, NVDA, JAWS su Windows; VoiceOver su macOS) per confermare ruoli, nomi, stati, valori e in particolare messaggi di errore e spostamenti di focus 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:
  • Tastiera fisica esterna (USB o Bluetooth) collegata al dispositivo (essenziale per un test completo della tastiera).
  • Touchscreen (per il caricamento iniziale della pagina, ma tutte le interazioni per il test stesso dovrebbero avvenire solo tramite tastiera)
  • Controllo vocale (ad esempio, Controllo vocale iOS, Accesso vocale Android) per la verifica 2.5.6.
• Tecnologie assistive: lettori di schermo integrati (VoiceOver su iOS, TalkBack su Android) per verificare gli annunci e il comportamento di messa a fuoco.
• Strumenti per sviluppatori: funzionalità di debug remoto (ad esempio, Chrome DevTools per Android, Safari Web Inspector per iOS) per l’ispezione di HTML e ARIA su dispositivi mobili.
• Orientamento: modalità verticale e orizzontale (per valutare come i moduli si adattano e mantengono l’accessibilità).

Preparazione al test #

Prima di iniziare il test manuale, assicurarsi di aver completato i seguenti passaggi:

1. Identifica tutte le forme:
   Elencare sistematicamente tutti i moduli sulla piattaforma, inclusi:
   • Moduli di accesso, registrazione e reimpostazione della password.
   • Moduli di contatto, moduli di feedback.
   • Moduli di pagamento/checkout.
   • Moduli di ricerca.
   • Moduli di abbonamento.
   • Qualsiasi modulo che raccoglie e invia l’input dell’utente.
     
     Comprendere il comportamento e la convalida del modulo
     Per ogni forma identificata, determinare:
   • Quali sono le regole di convalida per ciascun campo (ad esempio, formato e-mail, lunghezza minima della password, solo valori numerici)?
   • Quali sono i campi obbligatori?
   • Esistono convalide lato server oltre a quelle lato client?
   • Come vengono visualizzati gli errori?
   • Esistono moduli multi-step o campi condizionali?
   • Cosa succede se l’invio è andato a buon fine?
2. Revisione delle specifiche/documentazione di progettazione:
   Se disponibile, consultare la documentazione relativa alla progettazione del modulo, alla logica di convalida, alla messaggistica di errore e all’implementazione dell’accessibilità (incluso l’utilizzo di ARIA e gli attributi di completamento automatico).
3. Familiarizzare con i criteri WCAG e i modelli di modulo ARIA:
   Rileggere e assimilare i requisiti specifici di tutti i criteri WCAG elencati. Comprendere l’uso corretto di , aria-labelledby, aria-describedby, aria-invalid, aria-required e delle regioni live per i messaggi di errore.
4. Configurare i lettori dello schermo e il controllo vocale:
   Assicurati che il software di lettura dello schermo e di controllo vocale sia installato e configurato correttamente. Esercitati a compilare moduli, inviarli con errori e osservare gli annunci. Esegui test utilizzando combinazioni di metodi di input.
5. Preparare dati/scenari di prova:
   Creare un set di dati di prova che includa:
   • Input valido per tutti i campi.
   • Input non valido per ciascun campo singolarmente (per testare messaggi di errore specifici).
   • Mancano i campi obbligatori.
   • Casi limite (ad esempio, input molto lunghi, caratteri speciali).
   • Scenari che attivano suggerimenti di errore (se applicabili).
   • Scenari che richiedono voci ridondanti per 3.3.7.
6. Disabilitare l’uso del mouse (disciplina mentale):
   Per tutta la durata del “Processo di test passo dopo passo”, impegnatevi a utilizzare solo la tastiera per la navigazione e l’interazione all’interno dei moduli.
7. Cancella cache/cookie del browser:
   Per garantire un ambiente di test pulito, cancellare la cache e i cookie del browser secondo necessità.

Processo di test passo dopo passo #

Eseguire i seguenti passaggi per ciascun elemento interattivo identificato, sia su desktop che su dispositivi mobili/tablet. Documentare meticolosamente le osservazioni.

PASSO 1 – Procedura generale per l’accessibilità dell’input (WCAG 2.1.1, 4.1.2, 2.4.6, 1.3.5, 3.3.2, 3.2.4) #

Navigazione e operatività tramite tastiera (WCAG 2.1.1): #

• Caso di test:
  utilizzare Tab e Maiusc + Tab per navigare tra tutti i campi e i pulsanti del modulo. Ogni elemento interattivo riceve il focus della tastiera?
• Caso di prova:
  è possibile digitare in ogni campo e modificarne il valore tramite tastiera (ad esempio, barra spaziatrice per le caselle di controllo, tasti freccia per i pulsanti di opzione/selezione)?
• Caso di prova:
  i pulsanti possono essere attivati ​​con Invio o barra spaziatrice?
• Caso di prova:
  per i controlli dei moduli personalizzati, assicurarsi che siano completamente utilizzabili tramite tastiera (ad esempio, un selettore di data personalizzato si apre quando si attiva il focus e le date possono essere selezionate tramite tastiera).

Etichette e istruzioni (WCAG 2.4.6, 3.3.2): #

• Caso di prova:
  per ogni campo di input è presente un’etichetta chiara, persistente e visibile che ne descriva lo scopo?
• Caso di test:
  l’etichetta visibile è associata a livello di programmazione al suo campo di input (utilizzando <label for=”id”> o aria-labelledby)? (Verificare con gli strumenti per sviluppatori).
• Caso di prova:
  per i campi obbligatori, lo stato “obbligatorio” viene comunicato visivamente (ad esempio, asterisco) e a livello di programmazione (aria-required=”true”)?
• Caso di prova:
  per input complessi (ad esempio, criteri di password, formato di data specifico), le istruzioni vengono fornite prima o al momento dell’input, non solo come messaggio di errore?

Nome, ruolo, valore accessibili (WCAG 4.1.2): #

• Attiva uno screen reader.
• Passare a ciascun campo del modulo.
• Caso di prova:
  lo screen reader annuncia correttamente il nome accessibile del campo (l’etichetta), il suo ruolo (ad esempio, “modifica testo”, “casella di controllo”, “pulsante di scelta”) e il suo valore corrente (se presente)?
• Caso di prova:
  per le caselle di controllo/pulsanti di scelta, viene annunciato lo stato selezionato o deselezionato?
• Caso di prova:
  per i campi visualizzati dinamicamente (ad esempio, la casella di testo “Altro” per un gruppo di opzioni “Genere”), assicurarsi che vengano visualizzati nell’ordine di tabulazione corretto e che vengano annunciati correttamente.

Scopo dell’input (riempimento automatico – WCAG 1.3.5): #

• Utilizzando gli strumenti per sviluppatori, ispeziona i campi di input che raccolgono le informazioni dell’utente (ad esempio nome, indirizzo, e-mail, telefono).
• Caso di prova:
  gli attributi di completamento automatico vengono utilizzati correttamente per questi campi (ad esempio, autocomplete=”email”, autocomplete=”given-name”, autocomplete=”street-address”)?

Identificazione coerente (WCAG 3.2.4): #

• Naviga tra i diversi moduli o pagine della piattaforma.
• Caso di prova
  i campi del modulo identici (ad esempio, il campo “Indirizzo e-mail”) sono etichettati e identificati in modo coerente (testo <etichetta>, nome accessibile) in tutte le istanze?
• Caso di prova:
  i pulsanti di azione con la stessa funzione (ad esempio, “Invia”, “Annulla”) sono etichettati in modo coerente?

All’input (nessun cambiamento inaspettato di contesto – WCAG 3.2.2): #

• Interagisci con vari controlli del modulo (ad esempio, seleziona un’opzione da un menu a discesa, digita un campo di testo, seleziona una casella di controllo).
• Caso di prova:
  la modifica del valore di un campo di input non invia automaticamente il modulo, non porta a una nuova pagina o non provoca un cambiamento significativo e disorientante del contenuto/focus, a meno che l’utente non sia stato esplicitamente avvisato prima di utilizzare il componente?

Aiuto coerente (WCAG 3.2.6): #

• Se un campo del modulo fornisce testo di aiuto o suggerimenti (ad esempio, un suggerimento, testo sotto l’input).
• Caso di prova:
  il metodo e la posizione in cui viene fornita questa guida sono coerenti nell’intero modulo e nell’intera piattaforma in cui tale guida è disponibile?

PASSO 2 – Procedura generale per la gestione degli errori (WCAG 3.3.1, 3.3.3, 1.4.1) #

Navigazione e operatività tramite tastiera (WCAG 2.1.1): #

• Errori di attivazione:
  Inviare intenzionalmente il modulo con uno o più errori di convalida (ad esempio, lasciare vuoto un campo obbligatorio, inserire un indirizzo email non valido, utilizzare una password debole).

Identificazione degli errori (WCAG 3.3.1): #

• Esaminare attentamente tutto il contenuto testuale, inclusi titoli, paragrafi, voci di elenco, etichette e testo all’interno di pulsanti/link.
• Caso di prova (descrizione testuale):
  ogni campo che contiene un errore è chiaramente identificato visivamente (ad esempio, un bordo rosso distinto, un’icona di errore, non solo testo rosso)?
• Caso di test (riepilogo generale degli errori):
  nella parte superiore del modulo è presente un riepilogo generale degli errori, idealmente con collegamenti per passare a ciascun campo di errore?
• Caso di prova (nessuna indicazione solo a colori – WCAG 1.4.1):
  il colore non è l’unico indicatore visivo di un errore? (ad esempio, se un campo diventa rosso, viene visualizzato anche un bordo rosso, un’icona di errore o un messaggio di errore associato?).

Annuncio di errori tramite lettore di schermo (WCAG 3.3.1, 4.1.3 – implicito): #

• Attiva uno screen reader.
• Invia il modulo con errori.
• Caso di test:
  viene annunciato un messaggio di errore generale subito dopo l’invio, senza che sia necessario spostare l’attenzione sul messaggio? (Utilizzando aria-live=”assertive” in un’area di riepilogo).
• Caso di test:
  lo screen reader annuncia il messaggio di errore quando il focus si sposta sul campo di input errato? (Utilizzando aria-describedby per collegare l’input al suo messaggio di errore).
• Caso di test:
  l’attributo aria-invalid=”true” è impostato correttamente nei campi di input con errori? Lo screen reader segnala questo stato (ad esempio, “Voce non valida”)?

Suggerimento di errore (WCAG 3.3.3): #

• Per errori comuni o prevedibili (ad esempio, errore di battitura nell’indirizzo email, formato data errato, problemi di sicurezza della password):
• Caso di prova:
  il messaggio di errore fornisce un suggerimento specifico e attuabile per la correzione? (ad esempio, “Intendevi example@domain.com?” o “La password deve essere lunga almeno 8 caratteri”).

Persistenza dell’errore: #

• Caso di prova:
  i messaggi di errore rimangono visibili finché l’errore non viene corretto o l’utente non abbandona la pagina?

PASSO 3 – Procedura generale per la prevenzione degli errori e l’immissione ridondante (WCAG 3.3.4, 3.3.7) #

Applica sostituzioni di spaziatura del testo: #

• Navigare attraverso moduli o processi composti da più fasi in cui vengono richieste ripetutamente le stesse informazioni (ad esempio, indirizzo di fatturazione e indirizzo di spedizione).
• Caso di prova:
  esiste un’opzione per precompilare o selezionare le informazioni immesse in precedenza (ad esempio, la casella di controllo “Uguale all’indirizzo di fatturazione”) per evitare di doverle digitare nuovamente?
• Caso di prova:
  se i dati vengono reinseriti, vengono automaticamente riportati oppure presentati come opzione?

Prevenzione degli errori per azioni sensibili (WCAG 3.3.4): #

• Per i moduli che implicano impegni legali, transazioni finanziarie, modifiche/eliminazioni di dati utente o invii di test (ad esempio, pulsante “Elimina account”, pulsante “Acquista”):
• Caso di prova (reversibilità):
  dopo l’invio, esiste un’opzione immediata per annullare o invertire l’azione (ad esempio, “Annulla eliminazione”, “Annulla ordine entro 5 minuti”)?
• Caso di prova (controllo e correzione degli errori):
  i dati vengono controllati attentamente per individuare eventuali errori di input prima dell’invio finale e all’utente vengono fornite chiare opportunità di correggerli?
• Caso di prova (revisione/conferma/correzione):
  è presente una fase di revisione in cui l’utente può confermare tutte le informazioni immesse prima dell’invio finale, con opzioni chiare per tornare indietro e correggere gli errori?

PASSO 4 – Procedura generale per l’autenticazione accessibile (WCAG 3.3.8, 3.3.9) #

Processo di autenticazione (accesso/registrazione/reimpostazione password): #

• Caso di prova (minimo – WCAG 3.3.8):
  oltre a ricordare un nome utente e una password, è disponibile almeno un metodo di autenticazione alternativo? (ad esempio, accesso senza password tramite collegamento e-mail, autenticazione biometrica come impronta digitale/Face ID, accesso federato con provider affidabili come Google/Apple).
• Caso di test (migliorato – WCAG 3.3.9):
  per un processo di autenticazione che si basa su un test di funzionalità cognitiva (ad esempio, ricordare un nome utente e una password o un CAPTCHA):
  • Esiste almeno un metodo di autenticazione disponibile che non si basi affatto su un test delle funzioni cognitive?
  • OPPURE, se viene utilizzato un test delle funzioni cognitive, è disponibile un meccanismo per aiutare l’utente a completarlo (ad esempio, CAPTCHA molto semplici o un processo di recupero robusto che non si basa sul ricordo di informazioni passate)?
• Caso di prova:
  se si fa affidamento sulla memorizzazione delle credenziali, il processo di recupero/reimpostazione della password è chiaro, accessibile e intuitivo? Fornisce passaggi chiari e input accessibili?
• Caso di test (CAPTCHA/Test cognitivi):
  se vengono utilizzati CAPTCHA o altri test cognitivi, offrono più formati accessibili (ad esempio, un’alternativa audio al CAPTCHA visivo)? Sono facili da risolvere senza dover ricorrere a funzioni cognitive complesse o è presente un meccanismo di bypass/assistenza?

PASSO 5 – Procedura generale per l’assistenza (WCAG 3.3.6) #

Disponibilità della guida contestuale (WCAG 3.3.6): #

• Per moduli complessi o singoli campi che potrebbero richiedere spiegazioni aggiuntive (ad esempio, “Cos’è un CVV?”, “Perché ci serve il tuo numero di telefono?”).
• Caso di prova:
  è disponibile una guida contestuale per questi campi? Potrebbe essere:
  • Una piccola icona informativa che mostra un suggerimento quando si passa il mouse sopra o ci si concentra.
  • Testo di aiuto in linea che appare dinamicamente.
  • Un collegamento a una sezione di aiuto specifica relativa a quel campo.
• Caso di prova:
  il meccanismo di aiuto è facile da scoprire e da utilizzare (ad esempio, icona chiaramente visibile, tastiera attivabile)?
• Caso di prova:
  il contenuto della guida fornisce assistenza pertinente e tempestiva senza interrompere il flusso dell’utente (ad esempio, non aprendo una nuova finestra per un semplice suggerimento)?

PASSO 6 – Procedura generale per i meccanismi di input simultanei (WCAG 2.5.6) #

Test di input simultaneo nei moduli: #

Test di input simultaneo nei moduli:

• Caso di prova (tastiera + touch/gesti dello screen reader):
  attiva uno screen reader su un dispositivo mobile. Utilizza una tastiera fisica esterna per digitare in un campo di un modulo. Contemporaneamente, prova a utilizzare i gesti touch dello screen reader (ad esempio, sfiorando per navigare, toccando per attivare) su altri elementi.
  • Previsto: l’input dalla tastiera non deve essere limitato o interferire con i gesti dello screen reader e viceversa, a meno che la restrizione non sia essenziale (ad esempio, un input di disegno specifico).
• Caso di prova (controllo vocale + tastiera/mouse):
  attiva il software di controllo vocale. Prova a navigare e interagire con gli elementi del modulo utilizzando i comandi vocali, utilizzando anche la tastiera o il mouse.
  • Previsto: le diverse modalità di input dovrebbero funzionare contemporaneamente senza conflitti, consentendo all’utente di passare dall’una all’altra senza problemi.
• Caso di prova (nessuna restrizione non necessaria):
  assicurarsi che il modulo non imponga restrizioni artificiali sui metodi di input (ad esempio, forzando solo l’input touch o disabilitando l’input da tastiera quando viene rilevato un mouse).

Identificazione dei problemi #

Durante il processo di test, identificare e documentare eventuali deviazioni dal comportamento previsto in base ai criteri WCAG pertinenti. Esempi di problemi comuni includono:

• Etichette mancanti o errate (WCAG 2.4.6, 3.3.2 Failure):
  gli input del modulo non hanno etichette visibili o associazione programmatica (<label for=”id”>).
• Etichette solo segnaposto:
  si basano esclusivamente sul testo segnaposto come etichetta, che scompare durante l’input e non viene annunciato dagli screen reader.
• Moduli non utilizzabili tramite tastiera (errore WCAG 2.1.1):
  i campi o i pulsanti dei moduli non possono essere raggiunti, attivati ​​o manipolati tramite tastiera.
• Nessuna identificazione dell’errore (errore WCAG 3.3.1):
  gli errori sono presenti ma non sono chiaramente indicati visivamente (ad esempio, nessun bordo/icona rossa) o testualmente.
• Errori non annunciati dallo screen reader (WCAG 3.3.1, 4.1.3 Failure):
  i messaggi di errore non vengono annunciati immediatamente dopo l’invio o quando il focus si sposta sul campo errato (aria-live mancante, aria-describedby, aria-invalid).
• Nome/ruolo/valore accessibile mancante (errore WCAG 4.1.2):
  i controlli del modulo non dispongono di nomi o ruoli accessibili appropriati oppure non riescono a comunicare il loro stato/valore alle tecnologie assistive.
• Ordine di messa a fuoco illogico (WCAG 2.4.3 – implicito):
  la messa a fuoco della tastiera salta in modo irregolare tra i campi o le sezioni del modulo.
• Cambiamento imprevisto del contesto durante l’input (errore WCAG 3.2.2):
  selezionando un’opzione o digitando in un campo, il modulo viene automaticamente inviato o si esce senza preavviso.
• Attributi di completamento automatico mancanti (errore WCAG 1.3.5):
  i campi di input comuni che raccolgono dati utente non dispongono di attributi di completamento automatico appropriati.
• Etichettatura/identificazione incoerente (errore WCAG 3.2.4):
  le etichette o i nomi per campi/pulsanti di moduli identici sono incoerenti tra moduli o pagine diversi.
• Nessun suggerimento di errore (errore WCAG 3.3.3):
  per gli errori rilevabili, non viene fornito alcun suggerimento specifico per la correzione.
• Nessuna esclusione di voci ridondanti (errore WCAG 3.3.7):
  gli utenti sono costretti a reinserire manualmente le stesse informazioni più volte in un processo in più fasi.
• Nessuna prevenzione degli errori per i moduli critici (errore WCAG 3.3.4):
  i moduli che comportano modifiche/cancellazioni legali, finanziarie o di dati non dispongono di meccanismi di revisione, conferma o annullamento.
• Autenticazione inaccessibile (errore WCAG 3.3.8 AA):
  l’accesso si basa esclusivamente sulla memorizzazione di credenziali complesse, senza alternative accessibili o solide opzioni di ripristino. I CAPTCHA sono inaccessibili.
• Autenticazione inaccessibile (errore WCAG 3.3.9 AAA):
  il processo di autenticazione si basa su un test delle funzioni cognitive senza fornire un’alternativa che non si basi su tale test o senza fornire assistenza sufficiente per il test.
• Aiuto contestuale mancante (errore WCAG 3.3.6 AAA):
  per campi o attività complessi, l’aiuto contestuale non è disponibile o è difficile da accedere/utilizzare.
• Input simultaneo limitato (errore WCAG 2.5.6 AAA):
  la piattaforma limita l’uso di più meccanismi di input simultaneamente o in modo intercambiabile (ad esempio, disabilitando l’input da tastiera quando il controllo vocale è attivo o i gesti tattili interferiscono con l’input da tastiera fisica) senza una giustificazione essenziale.

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 di completare moduli o transazioni essenziali (ad esempio, campi critici inaccessibili, blocchi della tastiera non saltabili, errori non comunicati, perdita irreversibile di dati). Violazione diretta del Livello A.
• Alto:
  ostacola significativamente gli utenti nel compilare i moduli o nel comprendere gli errori, causando notevole frustrazione e alti tassi di errore (ad esempio, etichette mancanti in molti campi, errori solo per colore, nessun suggerimento di errore per gli errori più comuni). Violazione diretta del Livello A o AA.
• Medio:
  causa disagi o frustrazioni moderati. Alcune etichette o messaggi di errore potrebbero essere più chiari. Lievi incongruenze nell’identificazione degli elementi del modulo.
• Basso:
  piccoli problemi estetici o lievi inefficienze (ad esempio, etichette leggermente dettagliate, completamento automatico mancante nei campi non critici).

Nota finale #

Un’accessibilità solida dei moduli e una gestione efficace degli errori sono assolutamente essenziali per consentire agli utenti di completare le attività e interagire con successo con una piattaforma digitale. Questo test manuale fornisce una metodologia completa per andare oltre i controlli automatici, individuando le problematiche specifiche e incentrate sull’utente che incidono direttamente sull’usabilità per individui con esigenze diverse. Affrontando meticolosamente queste problematiche, i team possono garantire che i moduli siano intuitivi, tolleranti agli errori e accessibili a tutti.