Se cerchi “WCAG” su Google in italiano, ti capitano due tipi di articoli.
Quelli tecnici, scritti da sviluppatori per sviluppatori, dove ogni paragrafo contiene almeno un acronimo incomprensibile e la voglia di approfondire è la stessa che hai di quando devi stirare.
E quelli generalisti, scritti da chi non ha mai visto costa c’è sotto il cofano di un sito web, ma ti dicono «Eh l’accessibilità è importante» senza mai entrare nel merito. «Eeehgraziealc****o»
Questo articolo è una via di mezzo, o almeno prova ad esserlo! E l’ho scritto per chi solitamente è in quella situazione in cui deve decidere come fare un sito, ma non si occupa direttamente del codice.
Spoiler: gli sviluppatori odieranno questo articolo, ma hey, alla fine saprai cosa pretendere da loro, cosa controllare quando ti presenteranno il sito nuovo, e cosa significa esattamente la frase “il sito è conforme alle WCAG 2.2 livello AA” quando te lo diranno durante il prossimo Meet sperando di usare paroloni che non conosci.
Ti prometto che cercherò di non parlare di codice e di usare acronimi non spiegati.
Intanto, cosa sono le WCAG (in tre frasi)
WCAG sta per Web Content Accessibility Guidelines.
Sono lo standard internazionale sull’accessibilità dei contenuti web, gestito dal W3C, che è l’organizzazione che di base decide come funziona internet.
La versione 2.2 è stata pubblicata a ottobre 2023 e ancora oggi è il riferimento ufficiale a cui rimandano sia la legge italiana (D.Lgs. 82/2022) sia la direttiva europea (European Accessibility Act). Quando AgID controlla l’accessibilità di un sito, guarda se rispetta le WCAG 2.2.
Tradotto: se qualcuno ti dice che il tuo sito è “accessibile” senza nominare le WCAG e senza specificare la versione e il livello, ti sta vendendo tanta fuffa.
I tre livelli: A, AA, AAA (cosa pretendere quando firmi un contratto)
Le WCAG sono organizzate in tre livelli di conformità.
Tipo le stelle Michelin: il minimo è A, il massimo è AAA.
Livello A. Il minimo indispensabile. Esempio: un video senza nessuna alternativa testuale per chi non sente.
Livello AA. Il livello richiesto dalla legge italiana per il settore pubblico e dall’European Accessibility Act per il settore privato.
Quando senti dire “il sito è a norma”, di solito il riferimento è quasi sempre questo.
Esempio: i testi e lo sfondo hanno un contrasto minimo adeguato che ne garantisce la lettura (non il “grigio chiaro” che va di moda).
Livello AAA. Il livello ideale in cui è tutto ottimizzato. Attenzione però, pochissimi siti riescono a rispettarlo su tutte le pagine, e il W3C stesso scrive che non è ragionevole pretenderlo sull’intero sito. Quindi non ti preoccupare se il tuo sito non ha una tripla A ovunque.
Ok, quindi cosa significa per te?
Quando metti a contratto un sito nuovo o un restyling, scrivi nero su bianco “il sito sarà conforme alle WCAG 2.2 livello AA”. Senza specificare il livello, l’agenzia può consegnarti un sito conforme al solo livello A (cioè a un quarto delle regole) e dichiarare di aver rispettato il contratto.
Cosa vuol dire un sito accessibile?
Tutte le regole WCAG, in qualunque livello, ricadono in quattro principi:
1. Percepibile
Immagina di avere un negozio. Tutti devono poter “leggere” cosa hai in vetrina: chi vede bene, chi vede poco, chi non vede del tutto, chi sente, chi non sente.
Sul web significa che ogni informazione presente sul sito deve essere percepibile attraverso più di un senso.
In poche parole, qui dentro stanno: gli “alt text” ovvero quelle frase che descrivono le immagini, i sottotitoli sui video, le trascrizioni dei podcast, i contrasti di colore sopra una certa soglia e la possibilità di ingrandire il testo.
Esempio operativo da chiedere al tuo team:
Ogni immagine sul sito ha un alt text? Le foto prodotto dell’e-commerce sono descritte in modo che uno screen reader dica “scarpa nera in pelle taglia 42” e non “IMG_4523.jpg”?
2. Operabile
Usiamo sempre la metafora del negozio: la porta deve potersi aprire. Anche da chi ha una mano sola, anche da chi non vede la maniglia, anche da chi non può girare il polso. Giusto? Bene, sul web significa che tutte le funzioni del sito devono essere utilizzabili da tutti in più modi.
In pratica: navigazione può avvenire con il mouse o trackpad, ma anche solo con la tastiera (premi TAB e ti muovi tra i link o usando le frecce). È bene poi evitare contenuti che lampeggiano o si muovono in modo non controllabile (tipo il classico carosello di loghi che scorre dovrebbe avere un pulsante per mettere lo scorrimento in pausa) o evitare di richiedere movimenti complessi (es. trascinare un elemento sulla pagina) come unico modo per fare un’azione.
Esempio operativo da chiedere al tuo team:
Prova a usare il sito senza mouse, solo con TAB, frecce direnzinali e invio.
Riesci ad arrivare al carrello? A pagare? A fare login? Se a un certo punto ti perdi o il focus sparisce… beh, mi spiace dirtelo, ma hai un problema serio.
3. Comprensibile
Quando entri in un negozio, vuoi che i prezzi siano leggibili e eventuali cartelli o indicazioni in italiano (o nella lingua di chi entra), giusto?
Sul web significa che il sito deve essere usato senza dover tirare a indovinare.
In pratica: linguaggio chiaro nei testi, messaggi d’errore che dicono cosa è andato storto e come sistemarlo (esempio tipico: “credenziali errate”. Ok, grazie, ma è sbagliata la mail o la password? Specificatelo) e i comportamenti del sito dovrebbero essere prevedibili (un menu si comporta sempre da menu, un pulsante “torna indietro” torna sempre indietro, ecc).
Esempio operativo da chiedere al tuo team:
Il form di pagamento, quando rifiuta una carta, dice “Carta scaduta” oppure semplicemente colora di rosso il campo “carta”? Il messaggio d’errore appare vicino al campo sbagliato o in fondo alla pagina dove nessuno lo guarda?
4. Robusto
Il nostro bel negozio deve poter essere visitato sia da chi entra a piedi, sia da chi entra in sedia a rotelle, sia da chi entra con il cane guida.
Il nostro sito web quindi dovrebbe funzionare con tutte le tecnologie assistive che oggi esistono (screen reader, lettori braille, software di dettatura, ecc).
In pratica: codice HTML scritto bene e in modo semantico (un titolo è un titolo, un pulsante è un pulsante, non un misto di “div” e “span” colorati. div e span sono elementi che si trovano nel codice html, scusa il tecnicismo). Uso corretto degli attributi ARIA, che sono le etichette aggiuntive che diciamo agli screen reader.
Cosa significa per te?
Questa è l’unica parte che tu non puoi controllare a occhio. Devi fidarti del tuo sviluppatore o di un qualcuno che utlizza questi strumenti al quale fai fare un test e ne verifichi il corretto funzionamento.
Cosa è cambiato con WCAG 2.2
La versione 2.2 ha aggiunto nove nuovi criteri di successo rispetto alla 2.1.
Di seguito ti lascio i 4 più rilevanti, senza entrare troppo nel tecnico:
Bottoni e link grandi abbastanza (24×24 pixel minimo). È il criterio “Target Size”.
Vale soprattutto per mobile: se le icone social, i bottoni “aggiungi al carrello”, le X di chiusura sono troppo piccoli, l’utente con tremore o motilità ridotta non li clicca con precisione e abbandona. La regola tecnica è 24 pixel per 24 pixel, ma il messaggio per te è semplice: niente più icone-puntino sul mobile.
A meno che tu non voglia fare come quelle pubblicità odiose la cui X è piccola e in alto, al punto da rendere impossibile chiuderla e puntualmente clicchi sul banner.
Login senza puzzle cognitivi. È il criterio “Accessible Authentication”.
È vietato richiedere come unico modo per autenticarsi un puzzle che dipende dalla memoria o dal riconoscimento di immagini.
Hai presente quelle odiose “trova tutti i semafori” o “seleziona gli idranti” che ti chiede Google: ora devono avere un’alternativa accessibile.
Se il tuo sito usa questa autenticazione, devi affiancare un’altra (codice OTP via SMS, link via mail, ecc).
Niente form che ti chiedono di inserire dati già inseriti. Criterio “Redundant Entry”.
Se nel passaggio precedente del checkout hai chiesto nome, cognome e indirizzo per la fatturazione, non puoi richiederli ancora per la spedizione. Prevedi un “precompilazione” dei campo o inserisci una checkbox “stesso indirizzo”.
Aiuto sempre nello stesso posto. Criterio “Consistent Help”. Se ci sono un chatbot, un link “Contattaci”, una sezione FAQs, devono essere nello stesso punto su tutte le pagine. Non puoi mettere il pulsante di aiuto in alto a destra nella home, in basso a sinistra nel checkout e nel menu hamburger nella pagina prodotto.
Questi sembrano 4 dettagli, ma in realtà sono i punti dove più spesso un sito italiano (anche quelli più nuovi) inciampa.
Cosa fare adesso, da decision maker
- Apri il sito sul telefono. Vai in fondo alla home, cerca il link “Dichiarazione di accessibilità”.
Se non c’è, beh è un problema: è la prima violazione che AgID rileva. Puoi ottenerla in pochi giorni di lavoro ed è indipendentemente dal resto (almeno per ora). - Quando ti arriva un preventivo per un sito nuovo o un restyling, esigi che il contratto contenga la frase “il sito sarà conforme alle WCAG 2.2 livello AA”.
Senza specificare la versione e il livello, il contratto è troppo ambiguo per essere fatto valere. - Pretendi un audit indipendente. Chi ti fa il sito non può anche dirti che il sito è a norma, è come l’avvocato che fa anche il giudice della tua causa.
L’audit lo fa un soggetto diverso. Noi ad esempio ci appoggiamo ad un’azienda terza per fare gli audit dei siti che realizziamo. - Metti a budget un controllo annuale. I siti vivi cambiano, ogni nuova pagina, ogni nuovo plugin, ogni nuovo PDF caricato può portarti fuori norma in modo silenzioso. Sei mesi senza controllo bastano per accumulare problemi seri.
- Fai formazione a chi pubblica contenuti. Mezza giornata con la redazione, con chi carica prodotti sull’e-commerce, con chi gestisce le newsletter.
È forse la parte più importante perché determina se la conformità verrà mantenuta nel tempo o al primo PDF caricato senza tag, il sito torna fuori norma.
Vuoi capire cosa controlla AgID quando arriva sul tuo sito?
Abbiamo preparato quattro video di approfondimento, uno per ciascuno dei punti che contano davvero.
Sono brevi, in italiano, e parlano sia a chi decide sia a chi esegue.
- Accessibilità: da obbligo a vantaggio competitivo con Pierfilippo Ariano
- Accessibilità: normativa, linee guida, metodologia con Donato Matturro
- Gli errori di accessibilità più comuni in un sito web con Bianca Carchidio
- Navigare una pagina web con lo screen reader vocale con Cristian Bernareggi
Lasciaci la mail qui sotto e ti arrivano tutti e quattro in una sola mail.
