Audit di accessibilità: cosa controlliamo prima di consegnare

In sintesi: un audit di accessibilità serio non è il check del punteggio Lighthouse a fine progetto. È un lavoro fatto a mano, per pattern e componenti, con screen reader, tastiera e sensibilità di chi testa, su uno standard WCAG 2.2 AA. Spieghiamo come lo facciamo in PaperPlane, perché gli strumenti automatici da soli non bastano, e cosa significa concretamente consegnare un sito conforme.

Quando un grafico passa l’audit automatico ma è inutilizzabile

Quando abbiamo iniziato a lavorare sul nuovo sito di Gimme5, il servizio di risparmio digitale di AcomeA SGR, c’era un componente che ci ha dato più filo da torcere di tutti gli altri: i grafici interattivi della sezione fondi di investimento. Generati al volo a partire da dati in formato JSON, costruiti con Chart.js, esteticamente impeccabili. Su qualsiasi tool automatico passavano senza segnalazioni rilevanti.

Provando a navigarli con la sola tastiera, non succedeva niente: nessun focus, nessuna interazione. Provando con uno screen reader, il grafico semplicemente non esisteva. Un’intera sezione informativa del sito, quella che racconta come stanno andando i fondi su cui le persone investono i propri soldi, era invisibile per chi usa tecnologie assistive. Nessun automatismo te lo dice; te ne accorgi solo se quel componente lo testi davvero, come lo userebbe una persona cieca o ipovedente.

La soluzione l’abbiamo costruita lì: gli stessi dati JSON che alimentano i grafici vengono trasformati in tabelle accessibili parallele, con colonne data/valore e una sintesi testuale dell’andamento del fondo. Stessa informazione, due rappresentazioni, accessibili a tutti.

Questo articolo racconta come arriviamo a trovare cose così, prima di consegnare un sito.

Cosa intendiamo per audit di accessibilità (e cosa no)

L’audit di accessibilità è il momento in cui verifichiamo la conformità a WCAG 2.2 livello AA di un sito che stiamo per consegnare. È il controllo che chiude il nostro lavoro sull’accessibilità digitale prima dello switch on. È un controllo tecnico e funzionale che risponde a una domanda semplice: questo sito funziona per chiunque dovrà usarlo, comprese le persone che navigano con screen reader, tastiera, comandi vocali, ingranditori di schermo?

Non è la dichiarazione di accessibilità, che è un atto formale con requisiti di legge specifici (e che tratteremo in un altro pezzo). Non è il punteggio di Lighthouse, che è una metrica utile ma molto parziale: ne abbiamo parlato a proposito di cosa misurano davvero i Core Web Vitals. È un lavoro fatto per pattern e per componenti, da persone che testano il sito come lo userebbero le persone reali.

Perché gli strumenti automatici non bastano (e perché non bastano davvero)

Su axe DevTools, Lighthouse, Wave e simili gira un equivoco diffuso: producono punteggi alti che danno la sensazione del lavoro finito. Sono utili (anche noi li usiamo come prima passata) ma intercettano solo una frazione delle violazioni WCAG reali. La stima che gira nella community tecnica è intorno al 30-40%, e la nostra esperienza la conferma. Tutto quello che riguarda significato, contesto, ordine, esperienza sfugge alle macchine.

Esempi concreti da audit recenti: un componente carrello duplicato, visivamente invisibile ma navigabile dallo screen reader, che disorientava chi si trovava a incontrarlo “nel nulla” del DOM. Un’icona di calendario nella navigazione principale che NVDA saltava completamente in modalità sequenziale, per via di un problema di calcolo del buffer virtuale legato a come era costruito il link. Un menu a tendina che usava display:none sulle option per filtrare le scelte: su Safari iOS quel filtro viene ignorato dal sistema operativo, che mostra l’intero elenco compresi gli elementi che dovrebbero essere nascosti. Tre problemi critici, nessuno rilevato da axe o Lighthouse.

Il punto non è che gli strumenti automatici siano inutili. Il punto è che chi consegna un sito vantando “100/100 su Lighthouse” sta dichiarando una cosa vera che non significa quello che sembra significare. Significa che non ci sono errori di codice grossolani. Non significa che il sito sia usabile da chi ha disabilità.

Come facciamo l’audit manuale in PaperPlane

L’audit lo facciamo a partire da una checklist interna costruita negli anni e affinata progetto dopo progetto. Su un foglio Google strutturato dove ogni problema viene registrato con criterio WCAG, criterio EN 301 549 (la norma tecnica europea), pagina, area, descrizione, livello di criticità (Critico, Alto, Medio, Basso), settore coinvolto (Design, Sviluppo, Contenuto, PDF) e stima delle ore di intervento. Lo stesso foglio genera due report distinti: uno tecnico per il team di sviluppo, uno leggibile per il cliente.

A condurre il lavoro è Girolamo, che ha la responsabilità dell’audit completo. È un auditor certificato, ma il modo in cui analizza i problemi non nasce solo dalla certificazione: nasce dal suo lavoro di UX/UI designer. Anni passati a pensare come un utente e a metterlo al centro delle decisioni progettuali gli hanno dato una sensibilità che non è scontata, anche per chi quel mestiere lo fa da tempo.
Usa uno screen reader chiedendosi soprattutto cosa succede a chi il sito non lo guarda come lo guardiamo noi. È una qualità rara: l’accessibilità tecnica si può imparare leggendo le WCAG, l’attenzione genuina per l’esperienza di chi usa tecnologie assistive no. Giovanni e Aurora lo affiancano per le correzioni al codice e sui componenti non standard (caroselli, modali, mega-menu, datepicker, filtri dinamici), dove i pattern attesi da WCAG vanno conosciuti uno per uno e gli automatici falliscono di più.

Navigazione da tastiera

È la prima prova, e già da sola dice molto. Solo Tab, Shift+Tab, Invio, Spazio, frecce. Ogni elemento interattivo deve essere raggiungibile. Il focus deve essere sempre visibile, con un contrasto sufficiente. L’ordine deve seguire la logica visiva della pagina. Non devono esserci trappole: situazioni in cui si entra in un componente (una modale, un menu) e non si riesce più a uscirne premendo Tab. I componenti modali devono implementare un focus trap corretto: il focus resta nella modale finché è aperta, e ritorna sul pulsante che l’ha attivata quando viene chiusa.

Test con screen reader (NVDA e VoiceOver)

NVDA su Windows, VoiceOver su macOS e iOS. Sono i due lettori di schermo più diffusi, con comportamenti diversi che vanno verificati separatamente. Ci interessano cose che non si vedono da nessun’altra parte: cosa annuncia il lettore quando arriva su una card, su un bottone, su un titolo? I form dichiarano correttamente label, errori, stati? Le immagini decorative sono saltate o vengono lette inutilmente? I link dicono dove portano anche fuori contesto (un “scopri di più” da solo, in un elenco di link, non dice niente)? Quando un contenuto cambia dinamicamente, per esempio un filtro applicato o un caricamento di nuovi risultati, lo screen reader lo annuncia?

Componenti non standard

I pattern custom sono il territorio dove l’accessibilità si gioca più seriamente. Una <div> con un onclick non è un bottone, anche se sembra un bottone: per la tastiera non esiste, per lo screen reader non ha ruolo. Un mega-menu che usa <ul> annidate per gestire le colonne può funzionare visivamente e annunciare strutture di lista incomprensibili. Un datepicker fatto in proprio è quasi sempre un problema, e spesso la soluzione più accessibile è offrire un’alternativa testuale (un campo data libero in formato gg/mm/aaaa) anche quando il datepicker funziona.

Contrasto e tipografia

Per il contrasto usiamo Stark come strumento principale, ma il controllo non si limita ai testi: vanno verificati anche gli stati interattivi (default, hover, focus, disabled), gli elementi non testuali (icone informative, indicatori di stato, bordi di componenti), e i casi limite: testo bianco sovrapposto a immagini fotografiche, dove la variabilità della foto sottostante può rendere il contrasto insufficiente in alcune zone. La soglia minima per testo normale è 4.5:1, per testo grande 3:1, per gli elementi non testuali 3:1.

Struttura semantica, contenuti, zoom

Heading in ordine gerarchico (h1, h2, h3 senza salti illogici), landmark ARIA dove servono per orientare la navigazione, alt text scritti pensando al contesto e non al file di origine. Si testa il sito con zoom della pagina al 200% (soglia richiesta da WCAG 1.4.4) verificando che nessun contenuto venga troncato o reso inaccessibile. Si testa il reflow a 320px di larghezza, simulando uno zoom al 400% su un mobile, e si controlla che non si verifichi quello che capita spesso sui siti con tanti elementi sticky: una pila di barre fisse in alto che occupa metà schermo e lascia uno spiraglio minuscolo per leggere il contenuto.

Documenti collegati

L’accessibilità non si ferma all’HTML. Un sito istituzionale è quasi sempre punteggiato da PDF: verbali, rassegne stampa, documenti scaricabili. Vanno controllati anche quelli, perché un PDF senza tag semantici, senza titolo associato, costruito a partire dalla scansione di un documento cartaceo, è completamente inaccessibile a chi usa tecnologie assistive. Un sito conforme con allegati non conformi è un sito non conforme. È un tema che abbiamo affrontato nei progetti dove la conformità alle linee guida AgID era un requisito di partenza.

Cosa esce da un audit serio: l’esempio del Teatro Franco Parenti

Per dare un’idea concreta di cosa significa fare un audit così, prendiamo un progetto recente: il sito del Teatro Franco Parenti. È un sito che avevamo realizzato noi in precedenza, e su cui siamo tornati per un audit di accessibilità approfondito alla luce dello standard WCAG 2.2 AA. L’audit ha messo in evidenza 138 problemi di accessibilità: alcuni introdotti negli aggiornamenti successivi al primo rilascio, altri che il livello di consapevolezza sull’accessibilità di qualche anno fa non ci aveva permesso di prevenire come oggi sapremmo fare. La conformità iniziale, calcolata sui 55 criteri WCAG 2.2 di livello A e AA, era al 65%. Tra audit e fix abbiamo lavorato circa 80 ore, e la maggior parte dei problemi è stata risolta prima della nuova consegna.

I numeri raccontano due cose che vale la pena spiegare.

La prima: la stragrande maggioranza dei problemi era di sviluppo (100 su 138), seguita da Design (18), Contenuto web (16) e PDF (4). Attenzione però a leggere bene questo dato: un problema finisce nella casella “Sviluppo” perché lì si manifesta nel codice, ma la sua origine è quasi sempre a monte, in una scelta di design o di contenuto. L’accessibilità non è una rifinitura che si delega a chi programma: si decide quando si progetta un componente, e i pattern custom sono il territorio più delicato proprio per questo.

La seconda, ancora più interessante: 68 errori su 104 erano “generali”, ricorrenti su tutto il sito, contro 36 specifici di una singola pagina. Gli errori di accessibilità raramente sono problemi della pagina X. Sono pattern (un componente card, un menu, un sistema di filtri) che, sbagliati una volta, si propagano ovunque. La cosa buona è il rovescio: sistemato il pattern, si sistema l’accessibilità di decine di pagine in un colpo solo. È il motivo per cui un audit non va fatto pagina per pagina come se fossero indipendenti, ma per componenti e pattern di interazione.

I criteri WCAG più violati raccontano dove cadono di più i siti italiani: in cima 1.3.1 (Info and Relationships, ovvero struttura semantica del contenuto) con 28 occorrenze, seguito da 4.1.2 (Name, Role, Value, ovvero nomi accessibili di componenti interattivi) con 17, 2.4.3 (Focus Order) con 11 e 2.4.4 (Link Purpose) con 9. Sono problemi che hanno tutti la stessa radice: il sito è stato costruito per essere visto, non per essere usato in modi diversi.

Un limite reale: nessun audit interno sostituisce il test con persone reali

C’è una cosa che vogliamo dire chiaramente, perché fa parte di un’onestà che ci interessa difendere: per quanto un audit manuale sia accurato, è sempre fatto da chi conosce gli strumenti. Sviluppatori e designer che testano emulando l’esperienza di chi usa tecnologie assistive. Non è la stessa cosa che osservare una persona ipovedente o cieca usare il sito per la prima volta, senza preavviso, con i suoi strumenti, con il suo modo di interagire, che è quasi sempre diverso da quello che abbiamo immaginato.

L’audit interno fatto bene ti porta vicino. Il test con persone reali ti dice cosa hai mancato.

E c’è un secondo limite, ancora più a monte: l’audit migliore è quello che trova poco. Se arriviamo alla verifica finale con centinaia di problemi, vuol dire che l’accessibilità è stata trattata come una rifinitura invece che come un criterio di progettazione. Quando un componente nasce accessibile fin dal design, l’audit serve a confermare, non a riparare. È lì che vogliamo arrivare su ogni progetto.

Da dove iniziare se hai un sito da auditare

Quattro passi concreti, in ordine.

Primo: parti dagli automatici, ma trattali come una prima passata. Installa axe DevTools nel browser, lancia Lighthouse, vedi cosa esce. Ti dà l’ordine di grandezza del problema, niente di più. Se Lighthouse dice 95/100 non hai finito; se dice 60/100 sai già che c’è del lavoro grosso.

Secondo: prova a navigare il sito solo con la tastiera. Cinque minuti su tre o quattro pagine. Senza mouse, senza touchpad. Se non riesci a raggiungere un pulsante, se ti perdi nel focus, se entri in una modale e non sai come uscirne, lo capisci subito.

Terzo: apri uno screen reader e leggi la home. NVDA è gratuito su Windows, VoiceOver è già installato su macOS e iOS. Bastano pochi minuti per capire se i contenuti hanno una struttura comprensibile o se sono una sequenza piatta di link e testo.

Quarto: pensa in pattern, non in pagine. Se trovi un problema su un componente (una card, un menu, un form, un modale) è quasi certo che sia presente in tutte le pagine in cui quel componente compare. Sistema il pattern, non la singola istanza.

Quando vale la pena chiedere aiuto

Un audit serio richiede tempo, strumenti e una conoscenza approfondita di come WCAG e EN 301 549 si traducono in scelte concrete di codice e design. È un lavoro che si può fare in fasi: analisi, intervento sui pattern principali, verifica finale.

Se vuoi capire da che parte iniziare, in PaperPlane offriamo una call gratuita di trenta minuti dedicata all’accessibilità digitale. Guardiamo insieme il tuo sito e ti diciamo cosa vediamo: quanto vicino sei alla conformità WCAG 2.2 AA, dove sono i pattern critici, e quale impatto avrebbe un intervento mirato. Senza promesse di 100/100 su Lighthouse: ci interessano le persone che il tuo sito devono poterlo usare davvero.