Come effettuare l'analisi di accessibilità di un sito web
Analizzare un sito web per i requisiti di accessibilità
Abbiamo visto alcuni strumenti utili per svolgere queste analisi, in modo tale da puntare alla piena confermità ai diversi livelli delle WCAG. Questo infatti ci servirà in particolare da Giugno 2025, data a partire dalla quale entreranno in vigore nuovi obblighi per i privati in merito all’accessibilità web. Avremo bisogno infatti di compilare la dichiarazione di accessibilità.
Vediamo dunque come si può effettuare nella pratica una analisi di accessibilità.
Anzitutto apriamo il sito web che ci interessa e scansioniamolo con WAVE o con IBM Equal Accessibility Checker che sono entrambi disponibili come estensioni per il browser.
Probabilmente vedremo alcuni errori, come in questo caso:
La scansione con WAVE ha restituito degli errori
Con IBM Accessibility Checker possiamo generare dei veri a propri report, questo strumento in genere si attiva dall’Inspector del browser e si effettua una scansione della pagina:
La scansione con IBM Accessibility Checker ha restituito degli errori
Assicuriamoci di aver impostato lo strumento per effettuare le scansioni secondo le WCAG:
Su IBM Accessibility Checker impostiamo l’uso delle guidelines WCAG 2.2
A questo punto possiamo individuare i primi problemi di accessibilità presenti nel sito. Come possiamo vedere, i due strumenti forniscono suggerimenti e segnalazioni molto diverse, anche per questo motivo è bene usarne più di uno. Iniziamo dunque a compilare la tabella del modulo di autovalutazione provando a capire quali criteri vengono rispettati e quali no.
Se vogliamo semplificarci il lavoro, IBM Accessibility Checker ci permette di cliccare su Export XLS ed esportare così un file HTML con la tabella dei vari criteri, che possiamo verificare e riportare di conseguenza:
Rapporto in versione HTML degli errori rilevati da IBM AC
Potremmo ad esempio marcare come “Non soddisfatti” i criteri 1.4.3 Contrasto Minimo e 2.4.1 Salto di blocchi, se abbiamo verificato che effettivamente la conformità non venga rispettata. Ecco un esempio:
Tabella di conformità del modello di autovalutazione AGID
Questa tabella potrebbe essere un inizio per chi si occupa dell’aspetto tecnico dell’accessibilità: ad esempio si potrebbe inviare agli sviluppatori web del sito chiedendo di verificare cosa si può fare per conformarsi ai criteri non soddisfatti.
Analisi automatiche periodiche
Possiamo anche programmare delle analisi periodiche con strumenti quali MAUVE o simili. In questo modo riceveremo dei rapporti a frequenze stabilite che ci potrebbero servire per rimanere aggiornati sullo stato dell’accessibilità del sito.
Infatti, con il tempo e con l’inserimento di nuovi contenuti testuali, immagini, video e altro, potrebbe capitare che alcune pagine diventino più o meno accessibili. Pensiamo al caso in cui chi si occupa di gestire i contenuti si dimentichi di inserire il testo alternativo alle immagini, o usi dei tag HTML errati tramite editor di testo WYSIWYG come TinyMCE o CKEditor.
Analisi manuali
In ogni caso, avremo bisogno di effettuare delle verifiche manuali per casi più particolari, ad esempio la verifica del contrasto colore. Facciamo un esempio: abbiamo un sito con sfondo bianco e un pulsante (button) con bordo e testo gialli.
Vediamo che il contrasto è insufficiente e risulta di solo 1.07, quindi questo pulsante non è accessibile. Un utente ipovedente o che non riesce a distinguere bene i colori potrebbe non riuscire a leggere il testo del pulsante.
Questo è un esempio di verifica manuale, ma possiamo fare anche altro: verificare i form e le label degli input, controllare che i video abbiano i sottotitoli, verificare che non vi siano animazioni che si avviano in automatico e non possono essere fermate manualmente, controllare la grandezza dei caratteri e la leggibilità dei font.
Verifica dei pattern e del flusso di navigazione
Nelle sue linee guida dell’accessibilità, l’AGID ha definito dei Criteri di Valutazione che sono essenziali per la verifica soggettiva e al momento sono: percezione, comprensibilità, operabilità, coerenza, salvaguardia della salute, sicurezza, trasparenza, apprendibilità, aiuto e documentazione, tolleranza agli errori, gradevolezza, flessibilità.
Per esempio, dovremo valutare che i vari componenti, come la navigazione a briciole di pane (breadcrumbs) siano facilmente comprensibili e utilizzabili.
Oppure, i componenti che si ripetono più volte in una serie di pagine web e condividi la stessa funzionalità, dovrebbero essere coerenti e apparire allo stesso modo. Questo riguarda il criterio 3.2.4 Consistent Identification (Livello AA).
Test con utenti reali
Se possibile, dovremmo effettuare anche dei test con persone affette da disabilità visive, auditive o motorie, ad esempio con persone cieche che usano tecnologie assistive come gli screen reader o il BrailleNote Touch. In questo modo, otterremo dei feedback e capiremo come comportarci di conseguenza e quali modifiche apportare al sito.
Questo è meglio spiegato al punto b) Costituzione del gruppo di valutazione, del paragrafo 3.2.2.1. Verifica soggettiva delle linee guida AGID sull’accessibilità.
Chiaramente questo potrebbe richiedere dei costi importanti e dovrebbe essere previsto, preventivato e concordato con il nostro committente, sia esso una Pubblica Amministrazione o una azienda privata.
In genere si cerca di svolgere un test con un numero dispari di partecipanti e che sia il più possibile imparziale, alla fine del quale si chiede agli utenti di compilare un questionario per misurare la soddisfazione (o insoddisfazione) percepita durante le varie fasi di navigazione del sito web.
Conclusioni
Abbiamo visto alcune azioni che possiamo intraprendere per l’analisi di accessibilità delle pagine web. Questa è sicuramente una buona partenza ma il lavoro poi dovrebbe essere continuativo e distribuito nel tempo. Gli strumenti automatici sono ottimi alleati per aiutarci nel lavoro, ma non possono essere sufficienti, è opportuno infatti svolgere attività manuali per verificare di essere realmente conformi (o meno).
Dopo le verifiche più strettamente tecniche relative al codice HTML in particolare, dovremo controllare anche il flusso di navigazione e i vari pattern, per assicurarci che siano consistenti e intuitivi per l’utente.
Infine dovremmo, se possibile, svolgere dei test reali con persone affette da forme di disabilità in modo da verificare se, nella pratica, il sito che abbiamo realizzato sia davvero ben utilizzabile dagli utenti più interessati.
