Se gestisci un sito o un e-commerce, la domanda non è “siamo accessibili?”. La domanda che arriva in riunione, o in una richiesta di fornitura, è più scomoda: “Se domani ci chiedono evidenze, cosa mostriamo?”. Una checklist wcag 2.1 livello aa serve esattamente a questo: trasformare un tema percepito come tecnico in controlli verificabili, assegnabili e tracciabili.
Qui sotto trovi una checklist ragionata, pensata per chi deve governare rischio e operatività: marketing, IT, compliance, agenzie e freelance multi-sito. Non è un elenco infinito di micro-regole. È un percorso per identificare le non conformità più frequenti, ridurre l’esposizione in vista dell’European Accessibility Act 2025 e arrivare a un set di evidenze che “regge” un audit.
Come usare davvero una checklist WCAG 2.1 livello AA
Una checklist funziona solo se definisci due cose: lo scopo e il perimetro. Scopo: “conformità WCAG 2.1 AA” e non “miglioriamo un po’ l’usabilità”. Perimetro: quali pagine e flussi contano (home, categorie, schede prodotto, checkout, area riservata, pagine legali, assistenza, prenotazioni, candidatura, ecc.).
Poi va chiarito un punto che fa risparmiare tempo: i tool automatici non bastano, ma sono indispensabili. Automatizzano la copertura dei problemi ripetibili (contrasto, alt mancanti, struttura, attributi ARIA errati). Il resto richiede test manuali, soprattutto su tastiera e con lettori di schermo. “AA” è un obiettivo misurabile solo se unisci scansioni, verifica umana e remediation.
1) Navigazione da tastiera: il test che smonta più siti
Per WCAG 2.1 AA la tastiera non è un caso limite. È un requisito.
Apri le pagine chiave e fai il test più semplice e più rivelatore: usa TAB, SHIFT+TAB, INVIO e SPAZIO. Se ti perdi, se il focus sparisce, se resti intrappolato in un componente, hai un problema reale.
Verifica che l’ordine di tabulazione segua la logica visiva e funzionale, che ci sia sempre un indicatore di focus ben visibile e che i menu a tendina, i filtri e i modali siano navigabili senza mouse. Attenzione ai caroselli e ai componenti “custom” di design system: spesso sono belli, ma non gestiscono correttamente focus e ruoli.
Sul piano del rischio, questo è uno dei punti più contestabili perché impatta direttamente l’accesso al servizio. Sul piano operativo, è anche uno dei più “ripetibili”: risolto nel componente, si risolve su tutto il sito.
2) Contrasto e stato: leggibilità non negoziabile
Il contrasto colore è un classico: testi grigi su sfondo chiaro, placeholder poco visibili, link quasi indistinguibili. A livello AA il contrasto minimo è una soglia chiara, e spesso la non conformità nasce da scelte di brand o da variazioni introdotte nel tempo.
Non fermarti al testo. Controlla anche i componenti: pulsanti disabilitati, chip di filtro, badge, tag e stati hover/focus. Molti siti “passano” la pagina statica ma falliscono sugli stati interattivi. Se un’informazione è comunicata solo con il colore (errore in rosso, successo in verde), serve un rinforzo: un’icona, un testo, un messaggio esplicito.
Trade-off reale: a volte il contrasto “rompe” una palette. La soluzione non è sacrificare il brand, ma definire token accessibili per testo e UI, mantenendo coerenza grafica.
3) Struttura semantica: titoli, landmark e ordine dei contenuti
Una pagina accessibile è una pagina leggibile anche senza vederla. Questo dipende dalla struttura.
Controlla che ci sia un solo H1 sensato, che gli H2/H3 seguano un ordine logico e che non siano usati per “fare più grande il font”. Verifica la presenza di landmark (header, nav, main, footer) e che il contenuto principale sia identificabile. Se il sito è costruito a componenti, i problemi tipici sono duplicazioni di landmark, sezioni senza etichetta, e blocchi ripetuti che rendono la navigazione estenuante.
Qui la checklist è manageriale: se la struttura è coerente, anche i contenuti futuri nasceranno meglio. Se è confusa, ogni nuova pagina aggiunge debito.
4) Testi alternativi e immagini: zero “foto1.jpg”
WCAG 2.1 AA non chiede “metti alt ovunque”. Chiede che l’informazione non vada persa.
Per le immagini informative, l’alt deve descrivere lo scopo, non l’estetica. Per le immagini decorative, alt vuoto. Per le icone che sono controlli (es. lente per cerca, carrello, chiudi), serve un nome accessibile che comunichi l’azione.
Caso tipico in e-commerce: immagini prodotto con alt generici uguali per tutte, o banner promozionali senza testo alternativo. Se il banner contiene una promozione, quella promozione deve essere percepibile anche senza immagine.
5) Moduli e checkout: il punto dove l’accessibilità diventa business
Se hai un flusso di conversione, qui si gioca tutto.
Controlla che ogni campo abbia una label associata e persistente (non solo placeholder). Verifica che gli errori siano identificati vicino al campo, spiegati con testo chiaro e che siano annunciati correttamente alle tecnologie assistive. Se c’è una validazione in tempo reale, deve essere gestibile da tastiera e non deve interrompere l’utente con messaggi che appaiono e scompaiono.
Attenzione alle checklist “solo design”: il messaggio “Campo obbligatorio” deve essere programmaticamente determinabile, non solo un asterisco rosso. E le istruzioni (formato data, password, CAP) devono essere presenti prima dell’errore, non dopo.
Trade-off: alcune misure antifrode (captcha, OTP, limiti temporali) possono confliggere con l’accessibilità. Non significa eliminarle, significa scegliere implementazioni accessibili e prevedere alternative.
6) Contenuti dinamici e componenti: modali, toast, accordion
Molte non conformità AA arrivano da UI moderne.
Nei modali, il focus deve entrare nel modale quando si apre, restarci finché è aperto e tornare al trigger quando si chiude. I toast e le notifiche devono essere annunciati in modo coerente: se comunichi un errore o un successo, l’utente deve accorgersene anche senza vedere.
Accordion e tab devono avere ruoli e stati corretti (espanso/non espanso, selezionato, ecc.) e comportamenti standard da tastiera. Se usi librerie, non dare per scontato che la configurazione sia accessibile “di default”.
7) Link, pulsanti e nomi accessibili: chiarezza operativa
WCAG 2.1 AA richiede che i controlli siano comprensibili fuori contesto. “Clicca qui” ripetuto venti volte è un problema. Anche i link in card con aree cliccabili ambigue generano confusione: l’utente deve capire cosa succede prima di attivare.
Verifica che i pulsanti abbiano etichette coerenti con l’azione (“Aggiungi al carrello”, non “Invia”), che i link abbiano testo descrittivo e che non esistano elementi cliccabili che non sono semanticamente cliccabili (div con onClick senza ruolo e senza gestione da tastiera).
8) Video e audio: sottotitoli, trascrizioni, controlli
Se pubblichi video marketing, tutorial o webinar, il livello AA richiede sottotitoli per i contenuti preregistrati e controlli fruibili. Non basta caricare un file e sperare.
Verifica anche l’autoplay: se parte audio automaticamente, l’utente deve poterlo fermare facilmente. Se un video è essenziale per capire un servizio (es. istruzioni di onboarding), prevedi alternative testuali.
9) Documenti e PDF: quando “il sito” non finisce nel sito
Molte organizzazioni pubblicano moduli, listini, bandi, manuali in PDF. Se quei documenti sono necessari per accedere a un servizio, rientrano nel problema.
Controlla che il PDF sia taggato, con ordine di lettura, titoli e testo selezionabile. Se la generazione avviene da template, serve mettere mano al processo, non solo al singolo file. Spesso la scelta più efficace è portare i contenuti critici in HTML e lasciare al PDF il ruolo di copia scaricabile.
10) Evidenze, responsabilità e continuità: la parte che decide se sei “a norma”
La conformità non è una foto. È un processo. Una checklist wcag 2.1 livello aa diventa potente quando produce output riutilizzabili: backlog di remediation, criteri di accettazione, test case, e una routine di monitoraggio.
Definisci chi approva i componenti (design system), chi corregge il codice, chi valida. Fissa un ritmo: scansioni periodiche, test manuali sulle release e controllo su nuovi contenuti caricati dal CMS. Se pubblichi spesso, l’accessibilità deve entrare nella Definition of Done, altrimenti torni indietro ogni mese.
Se vuoi ridurre frizione e rendere il percorso misurabile, una piattaforma come Inclusivia combina scansioni automatiche, guida alla conformità WCAG 2.1 AA, supporto esperto per la remediation e gestione della dichiarazione di accessibilità come deliverable operativo.
Quando la checklist non basta (e cosa fare)
Ci sono casi in cui la checklist da sola non chiude il rischio: applicazioni web complesse, area riservata con workflow articolati, componenti custom, integrazioni terze parti (pagamenti, chat, prenotazioni) che non controlli direttamente.
Qui serve una decisione manageriale: o sostituisci il componente, o contrattualizzi requisiti di accessibilità al fornitore, o introduci alternative e mitigazioni. “Non dipende da noi” non è una strategia. È un rischio trasferito male.
L’accessibilità, quando diventa obbligo regolatorio, funziona come qualsiasi altra disciplina di compliance: o la governi con metodo, o la insegui con urgenze.
Chiudi la checklist con una domanda semplice e concreta: “Questa esperienza è utilizzabile, oggi, da una persona che naviga solo da tastiera e da una persona che usa uno screen reader?”. Se la risposta non è un sì tranquillo, hai già trovato la prossima azione da fare.
Questo articolo è stato realizzato con il supporto di sistemi di intelligenza artificiale. I contenuti hanno finalità informative e non costituiscono consulenza legale.