Atto V: L'apparenza del completamento
L'audit di accessibilità su cui prima o poi il tuo CFO farà domande
L’e-commerce director non aveva un’aria sulla difensiva quando l’ha detto, ed è il dettaglio che vale la pena tenere a mente. Aveva l’aria stanca tipica di chi riferisce una domanda con cui è solo a metà d’accordo. Eravamo da pochi minuti dentro un check-in, la solita sfilza di metriche e piccoli incendi, e lei ha posato il caffè e l’ha detto nel modo in cui si confessa qualcosa per conto di qualcun altro: Il nostro CFO vuole sapere perché abbiamo speso tutti quei soldi in un audit di accessibilità e ancora non siamo compliant.
Ecco la cosa su cui, in quella conversazione, nessuno aveva torto. L’audit era reale—uno serio, condotto da persone che conoscevano lo standard, voce per voce rispetto alle WCAG, ri-testato dopo che le correzioni erano entrate. La remediation era reale; il team di engineering aveva fatto il lavoro e il report era tornato verde. Il negozio è andato online nei tempi. E poi, nei mesi successivi, il team ha fatto esattamente quello che fa un team sano: ha rilasciato una serie di nuove sezioni stagionali, ha pubblicato aggiornamenti di prodotto su tutto il catalogo, ha cablato un paio di script di terze parti perché il marketing li voleva entro venerdì. Niente di tutto questo è passato per qualcosa che somigliasse anche solo lontanamente a una review di accessibilità, perché la review di accessibilità era una cosa che era già successa. Era al passato. Era fatta.
L’audit non sbagliava. Era accurato il giorno in cui è stato fatto. Ma era progettato per rispondere a una domanda puntuale, e il CFO ne stava facendo una continua.
Avevano ragione tutti e due. È questo che rende la conversazione difficile, ed è anche questo che la rende degna di essere affrontata come si deve, invece che sulla difensiva.
Il motivo per cui l’audit sembra un traguardo è che si comporta come tale. Produce un deliverable—un report delle violazioni, una checklist di remediation, una conferma di ri-test con una data sopra. Ha una forma: un inizio, una parte centrale, una fine ordinata che puoi inoltrare al CFO con oggetto fatto. Per un team che prende sul serio l’accessibilità per la prima volta, condurre un audit e correggere quello che fa emergere è un progresso reale, visibile, archiviabile. Non faremo finta del contrario, perché fare finta del contrario è il modo in cui si finisce a deridere chi ha fatto una cosa buona e difficile.
Il problema è ciò che il modello dà tacitamente per scontato. Tratta l’accessibilità come un brand tratta un redesign—qualcosa che fai, completi e ti lasci alle spalle, nel modo in cui ridipingeresti una vetrina senza poi pensare alla vernice per tre anni. Ma il tuo sito non è una vetrina che resta ferma una volta che la vernice si asciuga. Si rilasciano feature. Si aggiungono sezioni. Un content editor carica un’immagine hero un martedì. Qualcuno installa una app di recensioni. Ognuna di queste è nuova superficie esposta, e non un solo centimetro quadrato era nel report, perché niente di tutto questo esisteva quando gli auditor hanno fatto il login.
(Head of Digital il cui audit si è chiuso pulito la primavera scorsa: fai i conti su quello che il tuo team ha rilasciato da allora. Non per spaventarti. Solo perché il numero sia nella stanza.)
E l’esposizione dall’altro lato di quella superficie non sta nemmeno lei ferma. Nel 2025, negli Stati Uniti i ricorrenti hanno depositato 3.117 cause per accessibilità dei siti web presso le corti federali—il 27% in più rispetto all’anno prima, secondo il conteggio di Seyfarth Shaw. Citiamo il numero una volta e poi lo posiamo, perché la tentazione è raccoglierlo e agitarlo, e un capitolo che agita in giro un numero di cause diventa un capitolo diverso e peggiore. Ma c’è uno spostamento, dentro quella statistica, che vale la pena nominare, perché cambia la texture del rischio. Sempre più spesso le diffide non nascono da un cliente disabile che ha sbattuto contro un muro mentre cercava di fare il checkout. Nascono dai bot—crawler automatici che percorrono i negozi a caccia di violazioni WCAG, per fabbricare diffide su larga scala. La cosa che scandaglia il tuo sito alla ricerca di una label mancante non si stanca, non va in ferie nei giorni di festa, e non gliene importa nulla che tu abbia passato un audit in primavera. Vede il sito solo com’è, proprio adesso, nel modo in cui è nel momento esatto in cui arriva.
Quindi se l’audit non ti avrebbe mai tenuto compliant—e non l’avrebbe fatto, non è mai stato quello il suo compito—la domanda onesta successiva è cosa lo fa. E la prima mossa onesta è essere precisi sullo standard, perché qui la vaghezza è una piccola responsabilità a sé.
Le WCAG 2.1 AA sono il punto pratico in cui la legge americana e la regolamentazione europea si incontrano. Negli Stati Uniti l’enforcement dell’ADA punta lì; anche l’European Accessibility Act punta lì, in modo più esplicito, e l’EAA aggiunge una piega che il brand con sede negli Stati Uniti ama saltare a piè pari: vuole una dichiarazione di accessibilità pubblicata, e la sua portata segue la vendita, non i documenti di costituzione. Se vendi in Europa, ti riguarda. (Se questa formulazione fa rima con qualcosa del capitolo precedente—la direttiva che segue dove fai marketing, non dove i tuoi avvocati depositano le carte—quella rima non è un caso. La piattaforma gestisce parzialmente moltissime cose. L’accessibilità è un’altra stanza con una linea tracciata in mezzo, e vale la stessa disciplina: sapere quale lato della linea è tuo.)
Ma lo standard non è la parte difficile. La parte difficile è la frase che tutto il capitolo cerca di farti sentire, più che semplicemente leggere: la compliance non è uno stato che raggiungi. È uno stato in cui il tuo sito è, o non è, in un dato momento. L’audit ti ha detto a che punto eri un giorno specifico. Non ha detto nulla—non poteva dire nulla—del sito che avresti gestito sessanta giorni dopo, perché quel sito non era ancora stato costruito. Nessun audit copre un sito che non è ancora stato costruito. Non puoi ispezionare una stanza prima che ne salgano le pareti, e tu tiri su pareti nuove a ogni sprint.
La risposta, per fortuna, non è fai più audit. Scattare lo snapshot più spesso è comunque scattare snapshot; accorcia soltanto l’intervallo tra l’uno e l’altro, senza chiuderlo. Ciò che regge davvero sono tre strati di copertura sovrapposti, ognuno che intercetta una classe diversa di fallimento in un punto diverso del workflow, nessuno dei quali è sufficiente da solo.
Il primo strato vive nel browser dello sviluppatore. Un’estensione—axe DevTools, WAVE—installata nel browser di ogni engineer, così le violazioni emergono mentre il codice viene scritto, prima che qualunque cosa vada in deploy da qualche parte. Un problema intercettato qui non costa quasi niente: qualche minuto, un attributo corretto, uno sviluppatore che impara il pattern e smette di commetterlo. Lo stesso problema intercettato nell’audit dell’anno prossimo costa un ordine di grandezza in più—tempo di remediation, una release bloccata, ogni tanto una lettera da uno studio legale. Il posto più economico in cui correggere un bug di accessibilità è lo stesso in cui è più economico correggere ogni altro tipo di bug: la tastiera su cui è stato scritto.
Il secondo strato è il testing automatico in CI, ed è qui che la maggior parte dei team ha una lacuna che non sa di avere, perché la lacuna ha esattamente la forma dello strumento che già usano. Molti si appoggiano a Lighthouse, che esegue controlli di accessibilità dentro la sua suite standard. Lighthouse è davvero utile e non siamo qui a denigrarlo. Non è però sufficiente, e il motivo è strutturale, non una questione di impegno. Lighthouse testa lo stato statico di una pagina—quello che il browser renderizza al caricamento. Non può vedere il cart drawer che esiste solo dopo un click. Non può vedere il modal che si apre a metà checkout, o la navigazione che si dispiega all’hover. Una quota enorme della superficie interattiva di un negozio e-commerce semplicemente non compare mai in una scansione della pagina inerte—il che significa che le parti del tuo negozio che hanno più probabilità di intrappolare un utente da tastiera sono esattamente le parti a cui lo scanner di default è cieco. La forma migliore è Playwright che pilota l’SDK di axe: scrivi prima lo script dell’interazione—apri il drawer, poi fai l’assert—così il test percorre la strada che percorre il cliente, invece di fotografare l’atrio e chiamarlo l’edificio.
Il terzo strato è quello umano, e nessuna quantità di tooling lo manda in pensione. Gli strumenti automatici intercettano grosso modo un terzo delle violazioni WCAG. I restanti due terzi vogliono giudizio: se l’ordine di lettura ha senso a livello semantico, se un widget custom collabora davvero con uno screen reader, se l’alt text è significativo o solo presente. Perché è tutto qui il fulcro dello strato, ed è la frase che vale la pena attaccare al monitor con lo scotch: gli strumenti automatici possono confermare che un attributo di alt text esiste; non possono dirti se dice “image.jpg” o qualcosa che un utente di screen reader troverebbe davvero utile. Una review manuale trimestrale non è una versione più piccola di una annuale. È uno strumento diverso, perché il sito che ispeziona è più vicino al sito che hai effettivamente rilasciato, e una violazione intercettata a tre mesi è più economica in ogni valuta di una rimasta live per dodici.
Ed ecco la parte che resta fuori da quasi ogni conversazione sull’accessibilità, la parte che sopravvive intatta a tutti e tre gli strati tecnici: una buona fetta dei fallimenti non vive affatto nel codice. Vive nel contenuto.
Un’immagine di prodotto in cui il nome del prodotto è reso come un font cotto dentro il JPEG. Un banner di campagna in cui l’intera call to action fa parte della grafica, illeggibile a qualunque cosa non ci veda. Un articolo di blog in cui a ogni immagine manca l’alt text, perché l’editor che l’ha pubblicato non ha mai saputo che il campo esistesse. Nessuno scanner segnala queste cose. Tornano pulite—gloriosamente, falsamente pulite—e falliscono categoricamente la WCAG 1.1.1. Il tooling guarda alla struttura; il fallimento è nella sostanza, e la sostanza è stata digitata da una persona che stava pensando a un lancio, non a una specifica.
L’architettura a sezioni di Shopify può fare da contrappeso a questo, ma solo se la costruisci con quell’intento fin dall’inizio. Gli schema delle sezioni possono prevedere campi di alt text obbligatori, input aria-label obbligatori, vincoli che rendono la cosa non compliant più difficile da pubblicare di quella compliant. Sui progetti in cui abbiamo cotto questi requisiti dentro lo schema, gli editor commettono meno violazioni—non perché qualcuno abbia letto la specifica, ma perché il form si rifiuta di lasciargli saltare il campo. È il cambiamento di comportamento più economico dell’edificio: non addestri l’editor, rendi solo la mossa sbagliata leggermente più fastidiosa di quella giusta.
Non è una soluzione completa, e dovremmo essere onesti sul fatto che non lo è. L’editor può comunque digitare “immagine hero” nel campo dell’alt text e tabulare oltre, avendo tecnicamente soddisfatto il form e non avendo ottenuto nulla per chi usa uno screen reader. L’altra metà sono le linee guida editoriali e un breve, poco glamour orientamento all’accessibilità per chiunque pubblichi—la parte che non si automatizza, che non fa bella figura in demo, ed è quietamente responsabile di una quota sproporzionata di ciò che gli audit veri trovano davvero.
Il che ci lascia la relazione con il vendor, e merita più scrutinio di quanto di solito ne sopravviva, perché la struttura del contratto decide tacitamente quanto sei davvero protetto—indipendentemente da quanto sia bravo il vendor.
Alcuni contratti—Level Access è uno—vendono un numero fisso di review manuali all’anno, con sovrapprezzo a review oltre quel numero. Leggi l’incentivo che questo crea, perché il tuo team lo leggerà al posto tuo, che qualcuno lo dica a voce alta o no: le review vengono razionate. Vengono accumulate per dopo i lanci grossi, spese con parsimonia, e i tratti tra l’una e l’altra accumulano superficie non revisionata secondo una scadenza prevedibile. Stai razionando la tua stessa sicurezza, e le lacune capitano su un calendario che potresti cerchiare in anticipo.
I servizi gestiti come TestParty vanno nella direzione opposta: monitoraggio continuo, violazioni identificate non appena compaiono, pull request con correzioni rilasciate a cadenza regolare. L’output è spesso davvero buono. Ma nota che c’è comunque una finestra—tra il momento in cui il codice non compliant va live e il momento in cui la correzione atterra—durante la quale il sito è fuori compliance, e un crawler che passa di lì non sa né gli importa che un rimedio sia in volo. Se quella finestra si traduca in rischio legale reale dipende dalla tua situazione, e non faremo finta di conoscere la tua situazione da qui; diremo solo che fa parte della decisione, prezzata onestamente, prima di firmare e non dopo.
Nessuna di queste è un traguardo, nemmeno lei. Sono strumenti per restare in uno stato, non eventi che ti ci mettono dentro per sempre. Saremo diretti sul costo: costruire tutto il modello—l’estensione in ogni browser, i controlli scriptati in CI, le linee guida sui contenuti, la relazione con il vendor strutturata per la copertura invece che per gli eventi—richiede tempo vero, e la maggior parte dei brand che leggono queste pagine è già in ritardo. L’istinto di partire dall’audit non è il punto di partenza sbagliato. Devi sapere a che punto sei prima di poter sapere cosa sta andando alla deriva. Diventa l’approccio sbagliato solo nel momento in cui viene scambiato per una destinazione.
Così il CFO ottiene una risposta vera, non un sussulto. L’audit era uno snapshot: ti ha detto, con accuratezza, a che punto eri un giorno specifico, e non ha detto nulla delle sezioni e dei caricamenti e delle app arrivate dopo, perché il giorno dello snapshot nessuna di queste cose era ancora nata. Ciò che tiene un brand compliant è tutto quello che gira dopo che la foto è stata scattata—l’estensione che intercetta il problema prima che vada in deploy, il test in CI che fa fallire una pull request perché un nuovo modal non ha un focus trap, l’editor che sa a cosa serve l’alt text, la review trimestrale che fa emergere ciò che le macchine non hanno saputo giudicare. L’audit era la fotografia. Restare compliant è l’atto di continuare a essere il tipo di negozio che la fotografia continuerebbe a lusingare.
L’e-commerce director, per quel che vale, ha riportato tutto questo al suo CFO più o meno intatto, e il CFO—che, ricordiamolo, stava facendo una domanda del tutto legittima—ha finanziato il workflow invece del prossimo audit una tantum. Che è l’esito giusto, ed è raro, e lo citiamo perché i capitoli di questa parte del libro hanno la tendenza a finire sulle cose che non sono state intercettate in tempo, e questo non era costretto a farlo.
Perché la domanda su cui valeva la pena fare budget non è mai stata abbiamo passato un audit di accessibilità. L’hai passato, o lo passerai; quella parte è conoscibile e finita e alle tue spalle. La domanda che tiene davvero onesto un sito è quella che il calendario continua a fare al posto tuo, quietamente, ogni giorno in cui rilasci qualunque cosa: lo passeremmo, oggi?