Scanner WCAG, audit manuale e screen reader: Guida ai test

Tre metodi complementari per valutare l'accessibilità

Uno scanner automatico, un audit manuale e un test con screen reader sono tre metodologie diverse che verificano la conformità di accessibilità intervenendo su livelli diversi dell’interfaccia:

Le regole Accessibility Conformance Testing (ACT) classificano i controlli di conformità distinguendo quelli automatizzabili dai controlli semi-automatizzati e da quelli esclusivamente manuali.

Il W3C chiarisce che nessuno strumento automatico è in grado di determinare da solo se un sito sia accessibile nel suo complesso. Per questo si può parlare di complementarietà di questi tre approcci, necessaria per ottenere un quadro completo e fedele allo scenario reale: gli scanner vengono utilizzati per mappare il sito, individuare i problemi tecnici più evidenti e monitorarli nel tempo; gli audit manuali vengono svolti per valutare tutto ciò che richiede giudizio umano, mentre una parte di test viene svolta mediante screen reader, o altre tecnologie assistive, per validare l’esperienza reale di utenti con disabilità su percorsi chiave e per avere feedback sull’usabilità del sito.

Ha senso dunque usare lo scanner come base per monitorare il sito nel tempo, mentre per misurare la reale accessibilità di un sito è preferibile combinare l’automazione a verifiche manuali e all’esperienza d’uso concreta.

Cosa rilevano i test automatici di accessibilità

Tra i principali aspetti che possono rilevare ci sono:

• Contenuti non testuali e testi alternativi;
• Rapporto di contrasto cromatico tra testo e sfondo;
• Uso esclusivo del colore per trasmettere informazioni;
• Struttura gerarchica dei titoli e semantica di base (come l'assenza o l’uso improprio di landmark principali);
• Aspetti relativi ai form e alle etichette, come la mancata corrispondenza tra input e label, pulsanti senza testo accessibile o messaggi di errore non collegati al campo;
• Aspetti tecnici legati alla navigazione da tastiera;
• Attributi ARIA e altri elementi tecnici di accessibilità;

I limiti degli scanner di accessibilità: i falsi positivi e i falsi negativi

perché l'audit manuale resta insostituibile

Uno scanner automatico opera solo leggendo il codice come una sequenza di stringhe e parametri logici, dunque rileva la presenza di un attributo nel markup, ma, non avendo una reale capacità di interpretazione semantica, non può giudicare se le parole utilizzate abbiano senso compiuto o se le istruzioni guidino correttamente una persona verso il completamento di un'operazione.

La conformità di fatto è legata alla trasmissione efficace e accessibile delle informazioni ed è il motivo per cui la metodologia WCAG-EM del W3C prevede l’intervento umano per una corretta valutazione. La verifica umana rimane quindi il pilastro insostituibile di qualsiasi controllo a norma.

Nomi accessibili ed etichette fuori contesto

Uno dei compiti che spetta all’auditor consiste nel verificare che ogni elemento interattivo abbia un nome accessibile chiaro e istruzioni univoche.

Nei moduli online è fondamentale l'associazione esplicita e permanente tra l'etichetta e il suo campo (ad esempio tramite l'attributo for collegato all'identificativo del campo): lo scanner verifica solo la corrispondenza tecnica, accertandosi che un tag di tipo input abbia un corrispettivo label, un attributo aria-label o un placeholder temporaneo. Il problema però rimane per l’utente che usufruisce della navigazione con screen reader, che si ritroverà ad ascoltare nomi non significativi, incomprensibili e privi di indicazioni sul tipo di informazioni da inserire nel campo.

Inoltre, se i campi obbligatori (con l’attributo required o aria-required="true") sono contrassegnati solo da un colore o un asterisco, chi non percepisce le distinzioni cromatiche o chi ascolta la pagina non saprà come inviare il modulo. Ancora più problematico diventa se manca una spiegazione testuale della correzione necessaria o se non viene correttamente letta.

L’ordine logico di lettura e la comprensibilità delle istruzioni

La separazione tra struttura del codice e presentazione visiva crea spesso frizioni invisibili agli scanner automatici:

• Lo scanner può verificare la struttura gerarchica dei titoli e in particolare che non vi siano salti di livello, anche se non riesce a verificare se quei titoli rispecchiano la reale gerarchia concettuale del documento o se siano stati inseriti soltanto per una questione prettamente estetica;
• L'ordine degli elementi può essere modificato da proprietà CSS, risultando completamente diverso dall’ordine in cui sono dichiarati nel DOM e causando frustrazione per gli utenti che navigano usando tasti Tab o per chi esplora le pagine in modo sequenziale: se lo scanner legge il DOM in modo lineare, con la navigazione da tastiera si percepisce subito il disorientamento dell’utente.

Testi alternativi

Nel caso di un’immagine, vi è un divario tra validazione automatica e giudizio critico.
Nella guida Image Alternative Text del W3C si parla dell’importanza di comunicare lo stesso scopo dell'elemento visivo:

Solo una valutazione manuale può stabilire se l'immagine trasmette un contenuto indispensabile o se ha una funzione meramente decorativa. Nel primo caso l’auditor verifica che la descrizione alternativa contenga le informazioni essenziali dell’immagine; nel secondo caso accerta che venga usato un attributo vuoto per consentire agli screen reader di ignorare l’elemento senza sovraccaricare l’utente con elementi superflui.

Test con screen reader e tastiera

Gli scanner automatici analizzano il codice HTML, ma gli utenti interagiscono con percorsi dinamici come filtri, elementi a scomparsa o form a più passaggi.
La metodologia WCAG-EM richiede una valutazione dei processi completi per stabilire l’effettiva conformità: per capire se funziona un servizio è indispensabile testare i percorsi critici end-to-end simulando l’esperienza di chi naviga senza mouse. Solo così emergono le criticità che ostacolano l’accessibilità, anche se invisibili agli scanner automatici.

Focus visibile, ordine di tabulazione e focus trap nei componenti dinamici

La navigazione da tastiera è lo strumento maggiormente usato, sia dagli utenti non vedenti, sia da chi ha disabilità motorie. Il W3C fornisce una linea guida per verificare alcuni aspetti essenziali:

• Mentre si scorrono i contenuti tramite il tasto Tab, l’elemento selezionato deve essere chiarissimo e deve avere un indicatore visibile di focus;
• La sequenza con cui si scorrono i contenuti deve seguire un flusso intuitivo e lineare, coerente con l’ordine visivo. Spesso vengono usati attributi tabindex con valori positivi che alterano il percorso “naturale”, causando salti tra elementi della pagina;
• Widget interattivi e componenti articolati non sono esplorabili tramite tasto Tab, ma necessitano di specifici comandi da tastiera. Se questi controlli personalizzati mancano della corretta gestione script risultano impossibili da comandare;
• Quando si apre un componente dinamico sovrapposto, il focus dovrebbe spostarsi subito all’interno del nuovo elemento e rimanere all’interno di esso finché il popup non viene chiuso o confermato.

"Testare l’accessibilità con uno screen reader significa ascoltare una pagina web e soprattutto capire come il codice viene tradotto all’utente finale attraverso combinazioni consolidate tra browser e tecnologie assistive:

• NVDA (open source, Windows);
• JAWS (Windows);
• VoiceOver (Apple);
• TalkBack (Android)."

Gli esperti di accessibilità fanno notare che non tutte le tecnologie assistive interpretano il codice e gli attributi ARIA allo stesso modo: un flusso che sembra scorrere senza problemi su VoiceOver può incontrare criticità se viene testato su Windows con NVDA, JAWS oppure su Talkback nei dispositivi Android, dunque è sempre bene verificare i flussi con combinazioni realistiche di browser e screen reader per accertarsi che il supporto semantico sia robusto e fruibile.

Quattro livelli per una corretta verifica di conformità WCAG

Nelle linee guida ufficiali, il W3C raccomanda la necessità della cooperazione di ruoli diversi (sviluppatori, designer e esperti dell’accessibilità); inoltre, l’organizzazione delle attività del team dovrebbe basarsi su un modello piramidale distribuito su quattro livelli operativi per ottenere un controllo affidabile, ripetibile e sostenibile a lungo termine:

1. Scansione automatica continua: analisi di ampi volumi di pagine a ogni rilascio o aggiornamento del catalogo, intercettando gli errori deterministici di sintassi del DOM prima della messa in produzione.
2. Valutazione manuale esperta: l’auditor verifica contesto, significato semantico, etichette e conformità ai requisiti delle WCAG che richiedono interpretazione analitica e che non sono certificabili in modo autonomo da regole automatizzate; si accerta inoltre che la gerarchia visiva corrisponda a quella logica e strutturale del DOM, prevenendo discrepanze introdotte da regole CSS.
3. Test operativi con tecnologie assistive: si verifica la fruizione reale dei componenti interattivi e dei processi transazionali con navigazione esclusiva da tastiera e combinazioni standard di screen reader (NVDA, JAWS, VoiceOver).
4. Coinvolgimento di utenti con disabilità permette di validare l'effettiva usabilità sul campo e scoprire blocchi ed ergonomie.

Dimensionare il campione di audit secondo la metodologia WCAG-EM

Valutare frequenza, criticità del servizio e perimetro di rischio

Il controllo di accessibilità deve essere proporzionato alla criticità del servizio e al rischio di esclusione dell’utente. Una verifica superficiale o un rapido controllo automatico su portali ad alta frequentazione crea un pericoloso falso senso di sicurezza: ad esempio, se un banner promozionale o una pagina di contenuto secondaria presentano un’incongruenza grafica risultano fastidiose per l'utente; se invece il difetto si trova nel carrello o nel form di login l’utente è completamente bloccato e non può fruire del servizio.

Per capire quando approfondire il controllo prima di un rilascio è bene analizzare tre aspetti:

• Impatto operativo del task: se si tratta di un flusso che richiede transazioni economiche o l’invio di dati sensibili deve essere controllato manualmente e tramite un test con tecnologia assistiva end-to-end;
• Frequenza d’uso del componente: più è alta, più è alta la probabilità che un’anomalia possa produrre effetti a cascata moltiplicandosi su molte visualizzazioni;
• Dinamicità dell’interfaccia: più un'area fa uso di script asincroni, modali, filtri dinamici o elementi a scomparsa, più richiede una verifica manuale approfondita.

La selezione delle pagine

La metodologia WCAG-EM fornisce precisi criteri per comporre un campione rappresentativo che che rappresenti in modo fedele lo stato del portale senza tralasciare criticità. In particolare, il campione deve includere pagine di accesso e snodi chiave, tutti i template strutturali distinti, i processi transazionali completi (quindi tutti i passaggi di un flusso completo) e pagine con componenti o tecnologie diverse.

Inoltre, secondo le linee guida sarebbe bene affiancare alla selezione mirata una piccola percentuale di pagine scelte casualmente all’interno del dominio per individuare anomalie non previste o contenuti inseriti al di fuori dei pattern standard di sviluppo. In questo modo, si assicura che le risorse destinate all’audit vengano concentrate dove l’impatto reale sulle persone e la tutela della conformità contano davvero.

Un esempio: lo stesso checkout valutato con i tre metodi

Facciamo l’esempio di un modulo di checkout di un e-commerce in cui si devono inserire l’indirizzo di spedizione dei dati di pagamento: avrà un campo di testo con l’etichetta associata e un messaggio di errore dinamico che compare in rosso nel caso di un CAP inserito non valido, oltre al classico bottone per inviare l’ordine.

Usando i tre metodi di analisi descritti, emergono esiti diversi e si comprendono ancora meglio i limiti degli scanner e il ruolo chiave dell’audit manuale:

Dalla checklist operativa alla gap analysis con MyAccessible

Rendere accessibile un sito o un servizio digitale richiede, in una fase precedente alla pubblicazione di nuovi contenuti, un metodo di lavoro chiaro e capace di unire controlli costanti sul codice, verifiche manuali e prove pratiche sui flussi più importanti. Risulta utile quindi avere a portata di mano una lista di controlli pratici in modo da rilevare subito i problemi più evidenti, che solitamente limitano o impediscono l’accessibilità.

Checklist

Il percorso con MyAccessible

MyAccessible confronta lo stato attuale di un sito con i requisiti normativi, identificando i gap tra punto di partenza e punto di arrivo; nella gap analysis questi dati vengono aggregati per pattern ricorrenti, mappati sui requisiti normativi e tradotti in un piano di intervento concreto e dettagliato. La gap analysis diventa così :

• misurabile: si hanno numeri, punteggi e occorrenze precise;
• prioritizzata: si sa cosa è critico, importante o minore;
• ripetibile: si possono rifare le scansioni e vedere i gap chiudersi nel tempo;
• conforme alla normativa: colleghi i gap tecnici ai requisiti EAA/WCAG.

Bisogna ribadire che MyAccessible, come tutti gli scanner automatici, non sostituisce una valutazione completa condotta da esperti e con il coinvolgimento di utenti reali, anche considerando che molti criteri WCAG necessitano di giudizio umano e test contestualizzati.
Per questo, se utilizzato insieme a test manuali e al coinvolgimento di utenti con disabilità, rende il processo WCAG-EM più concreto, efficiente e sostenibile soprattutto per chi gestisce siti e-commerce

Inizia oggi: verifica la conformità del tuo sito

FAQ — Domande frequenti sulla verifica dell'accessibilità e WCAG-EM