Con l’avvicinarsi delle scadenze normative, il tema dell’Accessibilità dei siti web sta assumendo una rilevanza sempre più forte e moltissime aziende si stanno muovendo o intendono muoversi nel breve periodo per adeguare i propri touchpoint digitali.
Ma, nel concreto, come possiamo eseguire un’analisi di accessibilità del sito web per capire come ottemperare alla normativa?
Gung propone un metodo strutturato, per la verifica di accessibilità del sito web, utile a individuare gli errori, suggerire le soluzioni in base alle buone pratiche di Accessibilità derivanti dalle linee guida internazionali del W3C.
Approfondisci il nostro approccio leggendo come abbiamo supportato un nostro cliente attraverso questo caso studio.
In questa pagina:
Accessibilità Web: le linee guida di riferimento
Un sito web per essere considerato Accessibile deve presentare alcuni requisiti per esempio:
- I contenuti della pagina devono essere organizzati in modo strutturato. Organizzare i tag <h> in maniera gerarchica in modo che sia possibile comprendere facilmente la struttura del testo. È consigliabile utilizzare un solo tag <h1> (titolo principale) all’interno della pagina
- Deve essere garantito un contrasto minimo sufficiente tra il testo e il suo sfondo
- I collegamenti ipertestuali devono avere una descrizione testuale del loro scopo. La situazione ideale è quella in cui il testo stesso del link chiarisce lo scopo del link/la destinazione.
- Tutte le funzionalità del contenuto sono utilizzabili tramite un’interfaccia di tastiera senza richiedere tempi specifici per la pressione dei singoli tasti.
Questi requisiti sono definiti dalle WCAG, lo standard universale delle linee guida necessarie a definire specifiche tecniche per rendere i contenuti web accessibili alle persone con disabilità.
Le WCAG poggiano le proprie basi su 4 pilastri fondamentali che devono essere rispettati affinché i contenuti web possano considerarsi accessibili. Stiamo parlando dei cosiddetti principi POUR (Perceivable, Operable, Unserstandable, Robust). Un contenuto web per essere considerato accessibile deve essere:
- Percepibile: riguarda i sensi di percezione che le persone utilizzano durante la navigazione sul web (eventuale utilizzo di tecnologie assistive).
- Utilizzabile: i contenuti e la navigazione devono essere utilizzabili per semplificare l’interazione dell’utente.
- Comprensibile: i termini utilizzati in un sito web devono essere chiari, avere istruzioni semplici e spiegare o guidare nella comprensione di attività complesse
- Robusto: il contenuto deve poter essere interpretato in maniera affidabile da una grande varietà di programmi utente, comprese le tecnologie assistive.
Verifica di Accessibilità sito web: come fare
Hai ottenuto una panoramica su quelli che sono i principi e le linee guida in materia di Accessibilità a questo punto, come condurre un’analisi di accessibilità del sito web in concreto?
In Gung per validare l’Accessibilità del sito web partiamo da una navigazione strutturata del touchpoint secondo una checklist da noi sviluppata che guida le verifiche di dettaglio in relazione a ogni linea guida WCAG.
Cosa includono le verifiche tecniche per l’accessibilità? Le verifiche di accessibilità che svolgiamo interessano:
1. L’organizzazione dei contenuti nella pagina come ad esempio
- Verifica della corretta struttura della titolazione
- Verifica della corretta organizzazione dei form
- Verifica della collocazione degli strumenti di supporto, se presenti
2. La struttura del codice HTML della pagina, come ad esempio
- correttezza delle lingua impostata a livello di codice
- utilizzo di attributi WAI-ARIA per l’estensione della semantica della pagina
- impostazione corretta dei collegamenti e delle relazioni tra gli elementi nella pagina
3. La corretta gestione di elementi multimediali come immagini, video, audio
4. Viene inoltre condotto un test di accessibilità di eventuali documenti in formato .PDF che possono essere scaricati dall’utente.
A valle di questa prima fase, ne viene svolta una seconda in cui viene eseguita la navigazione del sito con l’utilizzo di tecnologie assistive, come la tastiera e lo screen reader. Questo ci aiuta a verificare se le tecnologie assistive interpretano correttamente il contenuto del touchpoint analizzato.
Definizione Checklist per le verifiche di accessibilità
La checklist di controllo che abbiamo elaborato in Gung parte dall’elenco di tutte le linee guida WCAG (versione 2.1) e definisce, per ognuna di esse, i controlli di accessibilità da fare per valutarne la conformità. Di seguito un estratto della nostra checklist:
| Tipo di verifica di accessibilità | Principio | Requisito | Criterio | Livello | Scopo | Verifica di accessibilità |
|---|---|---|---|---|---|---|
| Verifiche ad alta priorità | Percepibile | 1.4 Distinguibile | 1.4.3 “Contrasto Minimo” | AA | Fornire un contrasto sufficiente tra il testo e il suo sfondo (minimo di 4.5:1) | Verifica puntuale dei contrasti tra testi e sfondo con https://webaim.org/resources/contrastchecker/ |
| Verifiche trasversali | Utilizzabile | 2.4 Navigabile | 2.4.1 ” Salto di Blocchi” | A | Consentire alle persone che navigano tra i diversi contenuti, un accesso più diretto al contenuto principale della pagina Web. Grazie al salto di blocco presente nella parte superiore della pagina, l’utente può saltare al contenuto principale. | Verificare tramite navigazione da tastiera se esiste il salto di blocchi, viene mostrato come primo elemento alla pressione del tab |
| Verifiche trasversali | Comprensibile | 3.1 Leggibile | 3.1.1 “Lingua della pagina” | A | Garantire che gli sviluppatori di contenuti forniscano nella pagina Web le informazioni di cui gli utenti hanno bisogno per percepire correttamente un testo e altri contenuti linguistici. | Verificare con ispeziona <html lang = “it” |
| Verifiche relative a form o campi di input | Comprensibile | 3.2 Prevedibile | 3.2.2 “All’input” | A | Garantire che l’inserimento dei dati o la selezione di un controllo di un modulo sia prevedibile. I cambiamenti di contesto sono appropriati solo quando è chiaro che tale cambiamento avverrà in risposta all’azione dell’utente. | Verificare che i form siano sempre seguiti da un button di conferma, verificare che non ci siano casi in cui i dati immessi fanno variare il contesto della pagina (es. conferma di dati immessi senza la selezione del button). Verificare che l’utente sia avvisato se al suo input corrisponde l’apertura di una nuova finestra del browser. |
Le linee guida sono state raggruppate per tipologia di verifica in modo da rendere più efficaci i controlli:
- Verifiche trasversali: identificano degli errori che, se presenti in una singola pagina, possono essere ritenuti trasversali su tutto il sito.
- Verifiche ad alta priorità: verifiche che interessano le linee guida su cui, in genere, si rileva la maggiore numerosità di errori
- Verifiche relative a immagini
- Verifiche relative a form o campi di input
- Verifiche relative a contenuti audio/video
- Verifiche relative a contenuti dinamici
- Etichette e informazioni aggiuntive
- Navigazione da tastiera / Screen reader
- Utilizzo del puntatore
Come vediamo dall’esempio sopra riportato, per ogni tipo di verifica viene specificato:
- Principio POUR di riferimento
- Requisito della linea guida
- Linea guida WCAG
- Livello di conformità di riferimento
- Scopo della linea guida
- Tipologia di verifica da svolgere
Grazie alla checklist saremo in grado di avere una visione chiara delle verifiche di accessibilità da svolgere su tutti i contenuti del touchpoint in esame.
Definizione del campione da verificare
Strutturata la checklist di controlli passeremo alla definizione dei contenuti da analizzare. In questo caso è possibile procedere con due diversi approcci
- Verifica di accessibilità dell’intero sito web, consigliato in caso di siti esclusivamente redazionali e composti da un numero limitato di pagine
- Verifica di accessibilità di un campione di pagine che rappresentano dei template ricorrenti all’interno del sito (es. template di una pagina prodotto oppure template di una pagina di categoria, in caso di un sito eCommerce)
Verifica di Accessibilità dei siti web: guida all’utilizzo della Checklist
Definite le verifiche di accessibilità da svolgere, prendendo come riferimento le linee guida WCAG e definito il campione da analizzare, come procediamo in concreto?
Di seguito ti mostriamo come poter sfruttare la nostra checklist di accessibilità per eseguire un controllo preliminare dell’accessibilità del tuo sito web.
Scaricata la nostra checklist quello che dovrai fare è verificare l’accessibilità del tuo sito in relazione a tutte le linee guida indicate al suo interno. Partiamo per esempio dalla prima verifica che troverai all’interno del file:
| Tipo di verifica di accessibilità | Principio | Requisito | Criterio | Livello | Scopo | Verifica di Accessibilità |
|---|---|---|---|---|---|---|
| Verifiche ad alta priorità | 1. Percepibile | 1.4 Distinguibile | 1.4.3 “Contrasto minimo” | AA | Fornire un contrasto sufficiente tra il testo e il suo sfondo (minimo di 4.5:1) | Verifica puntuale dei contrasti tra testi e sfondo con https://webaim.org/resources/contrastchecker/ |
Esistono diversi strumenti che possono essere utilizzati per eseguire un controllo dell’accessibilità di un sito web.
In questo caso specifico, quello che dovrai fare è verificare il contrasto minimo dei tuoi contenuti attraverso un’indagine qualitativa ovvero, una navigazione manuale del sito ricorrendo all’uso della tecnologia assistiva WebAIM Contrast Checker.
In generale, la navigazione strutturata dal sito può essere condotta:
- Attraverso un’indagine qualitativa: navigazione manuale coadiuvata da tecnologie assistive
- Attraverso un’indagine quantitativa: navigazione del sito con il supporto di strumenti automatici
Una volta rilevato l’errore, all’interno della nostra checklist troverai anche una sezione dedicata al tracciamento delle non conformità così strutturata:
| Tipo di device | Pagina | Url | Elemento | Errore | Soluzione | Principio | WCAG 2.2 | Livello |
|---|---|---|---|---|---|---|---|---|
| Identifica se l’errore è generico (si presenta su tutti i device) o solamente da Desktop o da Mobile | Titolo Pagina | URL Pagina | Elemento su cui si rileva l’errore es. button, link, immagine (ecc…) | Errore rilevato | Soluzione suggerita in termini di codice o di comportamento | Principio POUR di riferimento | Criterio WCAG di riferimento | Livello di conformità (A,AA) |
quello che dovrai fare è compilare la seguente sezione, tenendo traccia di tutti gli errori rilevati e andando ad indicare:
- Il tipo di device ovvero, indicare se l’errore è rilevabile su tutti i device oppure solamente da Desktop o solamente da mobile
- Il titolo della pagina su cui è stato rilevato l’errore
- L’URL della pagina su cui è stato rilevato l’errore
- L’elemento su cui viene rilevato l’errore: button, link, immagine
- Una descrizione dell’errore rilevato
- La soluzione suggerita per far fronte alla non conformità
- Il Principio POUR di riferimento: Percepibile, Utilizzabile, Comprensibile, Robusto
- Il criterio WCAG di riferimento
- Il livello di conformità soddisfatto: A,AA
Di seguito un esempio di compilazione relativamente al nostro sito web:
| Tipo di device | Pagina | Url | Elemento | Errore | Soluzione | Principio | WCAG 2.2 | Livello |
|---|---|---|---|---|---|---|---|---|
| Tutti | Homepage | https://companyexample/home | Contrasto minimo | Non c’è un contrasto sufficiente tra il testo e lo sfondo (minimo di 4.5:1, nel sito è di 2.41:1 oppure di 2.59:1) | Modificare il colore testo/sfondo in modo che il contrasto minimo venga rispettato | Percepibile | 1.4.3 | AA |
nell’esempio sopra riportato facciamo riferimento all’errore relativo alla linea guida 1.4.3 (Contrasto minimo) rilevato sulla Homepage del nostro sito web.
Una volta aver definito il tipo di device su cui l’errore viene rilevato, la pagina e l’url del sito, andiamo ad inserire una descrizione dell’errore. In questo caso specifico abbiamo riscontrato una mancanza di contrasto minimo sufficiente tra testo e sfondo.
La soluzione proposta è stata ovviamente quella di individuare una combinazione di colori diversa per il testo e lo sfondo del nostro contenuto in modo da far si che il contrasto minimo definito dalla linea guida WCAG di riferimento venga rispettato.
Nell’Assessment completo che consegniamo ai nostri clienti, oltre al documento con la rilevazione degli errori viene fornita una sintesi della numerosità degli errori rilevati suddivisi come segue:
- Errori web/ non web
Errori rilevati su pagine web oppure su documenti in formato PDF - Errori relativi ai principi POUR
Errori suddivisi per principio di riferimento (Percepibile, Utilizzabile, Comprensibile, Robusto) - Errori relativi ai livelli di conformità
Errori suddivisi per livello di conformità (A, AA) - Errori con impatti sul codice o sul design
Errori che hanno impatto solo sul codice HTML oppure sul design della pagina
Tra gli errori più frequenti abbiamo quelli relativi a:
- Contrasto insufficiente: le linee guida WCAG prescrivono un rapporto di contrasto minimo di 4.5:1 tra il testo e lo sfondo. Nel caso in cui tale rapporto non sia rispettato, la palette di colori dovrà essere modificata per consentire la corretta visione del testo a tutti gli utenti
- Testo alternativo: le linee guida WCAG indicano che tutte le immagini che contribuiscono al contenuto della pagina debbano avere un testo alternativo in modo da poter essere lette dagli screen reader. Nel caso in cui ci siano immagini significative senza testo alternativo o con un testo alternativo inefficace, questo dovrà essere corretto per rendere il contenuto fruibile a tutti gli utenti
Se vuoi ottenere una verifica di accessibilità completa, ricevendo il supporto di un team di esperti, non esitare a contattarci per capire i prossimi passi da compiere.
OpenCode per l’automazione dei controlli di Accessibilità Web
Dai paragrafi precedenti emerge la complessità del processo necessario per verificare l’Accessibilità dei siti web.
Per far fronte ad uno dei problemi principali che le aziende oggi si trovano ad affrontare in fase di verifiche di accessibilità ovvero, mancanza di tempo per eseguire analisi approfondite e controlli manuali su molte pagine, abbiamo deciso di valutare l’utilizzo di Open Code come strumento di supporto all’automazione dei controlli di accessibilità sui siti web.
Nello specifico, lo strumento è stato impiegato per analizzare il codice HTML e CSS di siti non conformi alle WCAG 2.2, rilevare le anomalie presenti e classificarle in modo strutturato all’interno di un file Excel di output.
Metodo di utilizzo di OpenCode per le verifiche di Accessibilità
Il metodo adottato si è articolato in un processo iterativo.
- Lancio Prompt 1: In una prima fase è stato predisposto un prompt iniziale contenente le istruzioni necessarie affinché OpenCode si comportasse come un esperto di accessibilità web, applicando regole definite per l’analisi e per la compilazione del file Excel. Ogni prompt era riferito inizialmente a tre criteri WCAG. Una volta ricevuto il prompt, OpenCode chiedeva quale sito dovesse essere analizzato, valorizzando la variabile relativa al sito da esaminare. Ricevuta questa informazione, procedeva con l’analisi del sito e con la generazione del file Excel contenente gli errori rilevati.
- Secondo Check sito: Durante i test è emerso che una sola esecuzione non era sempre sufficiente per intercettare tutte le anomalie relative ai criteri inseriti nel prompt iniziale. Per questo motivo è stato introdotto un secondo check sullo stesso sito, finalizzato a verificare se fossero presenti ulteriori errori non emersi nella prima analisi.
- Prompt Update: Quando il secondo controllo individuava nuove anomalie, ciò indicava che il prompt o lo script utilizzato potevano essere migliorati. In questi casi, OpenCode veniva quindi impiegato anche per aggiornare prompt e script, con l’obiettivo di ridurre il rischio di omissioni nelle esecuzioni successive.
- Reset del ciclo: Dopo ogni aggiornamento, il ciclo ripartiva da capo: lettura del prompt aggiornato, nuova analisi del sito e ulteriore verifica tramite secondo check sul sito oggetto di prima analisi.
- Nuovo Prompt: Se, al termine del ciclo, non emergevano nuovi errori per i tre criteri considerati, veniva aggiunto un nuovo prompt relativo ad altri tre criteri WCAG. Il processo è quindi proseguito in modo incrementale, fino a coprire progressivamente il maggior numero possibile di criteri di interesse.
Nel complesso, il processo è stato ripetuto per 8 prompt, ciascuno dedicato a 3 criteri WCAG, per un totale di 24 criteri analizzati su 55 complessivi, pari al 43,64% del totale considerato rilevante ai fini della sperimentazione.
Valutazioni relative all’utilizzo di OpenCode
L’analisi ha portato al rilevamento di 219 errori complessivi sul sito esaminato. Di questi, 126 sono risultati di livello A e 93 di livello AA.
Dalla revisione finale emerge che 197 errori possono essere considerati confermati con sufficiente certezza, mentre 22 presentano una natura probabilistica e richiedono quindi una verifica manuale. In altri termini, circa il 10% delle anomalie rilevate necessita di conferma umana.
Questa distinzione è particolarmente importante perché, durante i controlli di verifica sul risultato prodotto da OpenCode, si è osservato che alcune anomalie non erano pienamente certe, ma solo probabili. In questi casi lo strumento individuava elementi sospetti senza riuscire a interpretarli in modo del tutto affidabile.
Si stima, nel complesso, un risparmio di effort umano pari a circa il 25%. Il beneficio è significativo, ma non elimina la necessità di revisione da parte di un operatore, soprattutto nei casi in cui il giudizio dipende da aspetti percettivi o contestuali.
Nel complesso, la sperimentazione consente di formulare le seguenti valutazioni:
1. OpenCode legge senza particolari difficoltà HTML e CSS dei siti indicati, senza che l’utente debba fornire manualmente il codice sorgente;
2. il rilevamento degli errori HTML risulta generalmente corretto, con descrizioni chiare e indicazioni utili all’interno del file Excel;
3. le verifiche relative al CSS e agli aspetti visivi o percettivi sono invece piuù deboli e richiedono spesso un controllo umano;
4. i tempi di elaborazione sono molto contenuti: OpenCode analizza 10 pagine del sito Il Budellino in meno di 5 minuti e genera il file Excel in tempi rapidi;
5. il file prodotto non presenta criticità strutturali: intestazioni, colonne e organizzazione generale risultano coerenti con le istruzioni fornite;
6. i campi valorizzati all’interno della tabella Excel sono stati compilati in modo generalmente corretto;
7. non sono state riscontrate duplicazioni significative, salvo alcuni errori ripetuti su piuù pagine ma comunque appartenenti alla medesima tipologia.