Accessibilità digitale — l'European Accessibility Act e il web che non lascia indietro nessuno

Un sito può superare tutti i test di performance, avere una grafica curata e un tasso di conversione invidiabile, e restare comunque inutilizzabile per una persona su quattro. Chi naviga con uno screen reader, chi non usa il mouse, chi ha una vista ridotta o legge con difficoltà non vede un errore 500: vede un pulsante che non si può attivare da tastiera, un contrasto illeggibile, un modulo che lo screen reader annuncia come «campo, campo, campo». Per lui il servizio semplicemente non esiste. Dal 28 giugno 2025, con l'entrata in applicazione dell'European Accessibility Act, questa non è più solo una questione di qualità: per molti servizi digitali è diventata un obbligo di legge.

Che cosa chiede davvero l'European Accessibility Act

L'European Accessibility Act (Direttiva UE 2019/882, in Italia recepita dal D.Lgs. 82/2022) estende gli obblighi di accessibilità — finora concentrati sulla pubblica amministrazione — a una vasta platea di operatori economici privati: e-commerce, servizi bancari, biglietterie e trasporti, e-book, servizi di comunicazione elettronica. In pratica, se vendete o erogate un servizio online rivolto ai consumatori, con ogni probabilità rientrate nel perimetro.

Il riferimento tecnico non è un documento arbitrario: la norma europea EN 301 549 rimanda alle WCAG 2.1 di livello AA, le linee guida internazionali per l'accessibilità dei contenuti web. Sono organizzate intorno a quattro principi che vale la pena conoscere anche solo per capire di cosa si parla: il contenuto dev'essere percepibile (alternative testuali, contrasti adeguati), utilizzabile (tutto raggiungibile da tastiera, tempi non punitivi), comprensibile (linguaggio e comportamenti prevedibili) e robusto (compatibile con le tecnologie assistive). Non è una checklist di adempimenti formali: è una descrizione di che cosa significa, concretamente, che un servizio funzioni per tutti.

Perché non è (solo) un problema di compliance

È facile ridurre l'accessibilità a un rischio sanzionatorio da neutralizzare — e le sanzioni ci sono. Ma chi la affronta solo per paura della multa costruisce la soluzione peggiore: un adeguamento di facciata, magari un widget «accessibilità» incollato in un angolo che promette di sistemare tutto con un click e che, nella pratica, non risolve quasi nulla e a volte peggiora l'esperienza per chi usa davvero le tecnologie assistive.

Il punto è che l'accessibilità, fatta bene, paga anche al di fuori dell'obbligo. Un mercato del 15% della popolazione con qualche forma di disabilità — a cui si aggiunge una popolazione che invecchia — è un mercato che oggi molti servizi lasciano semplicemente sul tavolo. E c'è un effetto collaterale che gli ingegneri conoscono bene: quasi tutto ciò che rende un sito accessibile lo rende anche migliore per chiunque. Il markup semantico che aiuta uno screen reader è lo stesso che i motori di ricerca leggono per capire e posizionare le pagine; i sottotitoli pensati per chi non sente servono a chiunque guardi un video in treno senz'audio; una gerarchia chiara di titoli e un contrasto pulito riducono il carico cognitivo per tutti.

L'accessibilità non è una funzione da aggiungere per una minoranza. È il collaudo più onesto della qualità di un'interfaccia: se funziona anche nelle condizioni più difficili, funziona meglio per tutti.

Gli errori che troviamo più spesso negli audit

Quando analizziamo un sito esistente, gli stessi problemi tornano con impressionante regolarità, e quasi mai per cattiva volontà: nascono dal fatto che nessuno li ha mai verificati.

• Immagini e icone senza alternativa testuale, o con alt inutili («immagine1.png»): per chi usa uno screen reader, l'informazione veicolata da quell'immagine semplicemente sparisce.
• Contrasto insufficiente tra testo e sfondo: il grigio chiaro elegante sul bianco è spesso sotto la soglia minima di 4,5:1 e diventa illeggibile in pieno sole o per chi ha una vista ridotta.
• Navigazione impossibile da tastiera: menu che si aprono solo al passaggio del mouse, focus invisibile, «trappole» in cui il cursore entra e non esce più.
• Moduli senza etichette collegate: campi che lo screen reader non sa nominare, errori di validazione segnalati solo con il colore rosso — invisibili a chi non distingue i colori.
• Struttura semantica assente: pagine costruite con soli div, senza una gerarchia di titoli né landmark, in cui le tecnologie assistive non trovano appigli per orientarsi.

Nessuno di questi problemi è irrisolvibile. Ma tutti condividono una caratteristica: si correggono in un pomeriggio se il sito è progettato bene, e diventano un cantiere costoso se l'accessibilità viene affrontata alla fine, come rattoppo.

L'accessibilità è una scelta di progetto, non un collaudo finale

Vale per l'accessibilità la stessa regola che vale per la sicurezza: non si aggiunge alla fine, si progetta dall'inizio. Un <button> nativo è accessibile da tastiera e annunciato correttamente senza scrivere una riga in più; lo stesso pulsante ricostruito con un div e un gestore di click va poi «riparato» con attributi ARIA, gestione del focus e del tasto Invio — più lavoro, più fragilità, per un risultato peggiore. La lezione, ripetuta in decine di progetti, è che l'HTML semantico è la prima e più potente tecnologia assistiva: prima di aggiungere ARIA, conviene quasi sempre usare l'elemento giusto.

Da qui discende anche il modo giusto di verificare. Gli strumenti automatici (Lighthouse, axe e simili) sono utili e vanno messi nella pipeline di CI, ma intercettano solo una parte dei problemi — indicativamente un terzo. Il resto si trova solo con la prova manuale: navigare l'intero flusso con la sola tastiera, ascoltare una pagina con uno screen reader, verificare che un modulo sia compilabile senza vedere lo schermo. È lì che emerge la differenza tra un sito «conforme sulla carta» e uno realmente usabile.

Dove interviene MAST

L'accessibilità non si risolve con un widget né con un bollino: si costruisce come pratica, esattamente come la performance o la sicurezza. Il percorso che seguiamo è concreto e incrementale. Partiamo da un audit che unisce scansione automatica e verifica manuale con tastiera e screen reader, e produce un elenco di problemi ordinati per impatto sull'utente e sul rischio di compliance — non un report da mille righe che nessuno leggerà. Correggiamo prima ciò che blocca l'uso del servizio, poi il resto, portando le pagine allo standard WCAG 2.1 AA richiesto dall'EAA. Infine radichiamo la pratica in casa vostra: componenti accessibili di default, controlli automatici nella pipeline di rilascio e una dichiarazione di accessibilità aggiornata, così che la conformità non sia una fotografia di oggi ma una proprietà stabile del sistema.

Se non sapete se il vostro servizio digitale rientra nell'European Accessibility Act — o se sospettate di sì ma non sapete da dove partire — cominciamo da un audit di accessibilità: in pochi giorni avrete un quadro chiaro di dove siete, di che cosa vi espone a un rischio e di quali interventi restituiscono più valore, agli utenti prima ancora che alla compliance.