Accessibilità web 2026: da obbligo di legge a vantaggio competitivo

Prendi un caffè. Siediti. Quello che sto per dirti non è il solito spiegone tecnico che trovi sui manuali di informatica. È una storia di muri invisibili, di porte chiuse e di come, nel 2026, quelle porte stiano finalmente per essere scardinate dalla legge. O meglio: di come la legge stia bussando alla tua, di porta.

Era una mattina di fine primavera, Caserta. Un amico con il quale ci conosciamo da anni. Disegna e produce compementi di arredo in legno fatti a mano, eccellenza campana pura. Mi mostra con orgoglio il nuovo e-commerce appena lanciato. "Umberto, guarda che pulizia. Grigio su bianco, minimal, elegante. È un gioiello."

Prendo il mio smartphone. Attivo lo screen reader. Chiudo gli occhi.

Silenzio.

Poi una voce metallica inizia a leggere: "Immagine 001 punto jpg. Pulsante. Pulsante. Link. Immagine 002 punto jpg. Pulsante non descrittivo. Fine pagina."

Apro gli occhi. Il suo "gioiello" per una persona non vedente è un labirinto di specchi vuoti. Un deserto comunicativo con un cancello sbarrato all'ingresso.

"Pensavo fosse roba per la Pubblica Amministrazione," mi dice lui, quasi scusandosi.

Ecco il punto. Non lo è più. Dal 28 giugno 2025 il mondo è cambiato. E se oggi, a marzo del 2026, il tuo sito non è accessibile, non stai solo facendo un torto alla tua etica: stai rischiando grosso, stai rinunciando a un mercato enorme e stai lasciando soldi sul tavolo.

Benvenuti nell'era dell'accessibilità web universale. Una guida completa per capire cosa cambia, cosa rischi e, soprattutto, cosa puoi fare adesso.

Cosa è successo il 28 giugno 2025 (e perché non puoi più ignorarlo)

Il 28 giugno 2025 non è stata solo un'altra data sul calendario. È stato il giorno in cui l'European Accessibility Act — la Direttiva UE 2019/882, recepita in Italia con il D.Lgs. 27 maggio 2022, n. 82 — è diventato pienamente operativo per il settore privato.

Fino a poco tempo fa, l'accessibilità digitale era un recinto confinato alla Legge Stanca e alla Pubblica Amministrazione. Le aziende private guardavano dall'altra parte, convinte che fosse un vincolo per gli enti pubblici e non per loro. Poi, la svolta. La normativa ha deciso che se vendi un servizio o un prodotto digitale nel mercato unico europeo, quel servizio deve essere per tutti. Senza eccezioni basate sulla forma giuridica o sul settore merceologico.

La comunicazione pubblica italiana ha fallito, come spesso accade in questi casi. Le linee guida operative dell'AgID (Agenzia per l'Italia Digitale) sono arrivate a maggio 2025 — sei settimane prima dell'entrata in vigore — lasciando migliaia di PMI in un limbo di incertezza. Ma la legge non ammette ignoranza. Oggi, nel 2026, siamo in pieno regime di applicazione e il meccanismo sanzionatorio è attivo.

La cosa fastidiosa? Molti titolari di PMI che ho incontrato nell'ultimo anno, tra Napoli e Londra, non sapevano nemmeno dell'esistenza di questa normativa. Non per disinteresse, ma perché nessuno glielo aveva detto chiaramente. Questa guida cerca di rimediare a questo vuoto di informazione.

Chi è obbligato: la mappa definitiva per non sbagliare

La prima domanda che mi viene posta è sempre la stessa: "Umberto, ma io sono piccolo. Devo farlo davvero?" La risposta, nella grande maggioranza dei casi, è sì.

I prodotti e servizi coperti dalla normativa

La normativa non guarda solo al "sito web" nella sua accezione classica. Abbraccia l'intero ecosistema digitale con cui i tuoi clienti interagiscono:

• E-commerce: dalla navigazione del catalogo al checkout, ogni singolo passaggio deve essere accessibile. Se un utente non riesce a portare a termine un acquisto usando solo la tastiera o uno screen reader, sei fuori norma.
• Servizi bancari e finanziari online: home banking, app di pagamento, portali di consulenza.
• Comunicazione elettronica: servizi di messaggistica, portali informativi, newsletter strutturate.
• Contenuti audiovisivi: video su sito, webinar, corsi online. Sottotitoli e audiodescrizioni non sono più optional.
• Servizi di trasporto: siti di prenotazione biglietti, app di tracking, portali informativi.
• Libri elettronici (e-book) e le piattaforme per distribuirli.

La soglia delle microimprese: il grande malinteso

Esiste una deroga per le microimprese — meno di 10 dipendenti e fatturato o bilancio annuo inferiore a 2 milioni di euro — ma va compresa con precisione chirurgica. La deroga riguarda solo i servizi.

Se la tua microimpresa produce o vende prodotti (lettori e-book, terminali self-service, sistemi operativi, hardware con interfaccia digitale), l'obbligo di conformità resta pieno, senza eccezioni.

Inoltre, la deroga non copre la qualità dell'esperienza utente in senso lato. Se sei un e-commerce che rivende prodotti di terzi, la tua piattaforma deve permettere l'acquisto in modo accessibile. "Sono piccolo" non è una difesa giuridicamente valida se vuoi restare sul mercato in modo professionale e, soprattutto, se vuoi partecipare a bandi pubblici o collaborare con grandi gruppi privati.

La trappola dell'aggiornamento significativo

Questo è il punto dove la maggior parte degli imprenditori inciampa, spesso senza rendersene conto.

È vero che esiste un periodo transitorio fino al 28 giugno 2030 per adeguare i servizi digitali esistenti (quelli già attivi prima del 28 giugno 2025). Ma — e questo "ma" vale una consulenza — ogni aggiornamento significativo apportato dopo quella data fa scattare immediatamente l'obbligo di conformità.

Cosa si intende per "aggiornamento significativo"? Hai rifatto il layout del sito? Aggiornato il sistema di pagamento? Cambiato il catalogo prodotti con una nuova struttura? Lanciato una nuova sezione blog? Ognuno di questi interventi può essere considerato un aggiornamento sostanziale. Se lo ha fatto il tuo sviluppatore tra giugno 2025 e oggi, il nuovo codice deve essere conforme. Non tra cinque anni. Adesso.

Cosa rischi se non ti adegui: oltre la multa

Parliamo di numeri concreti. E poi di qualcosa che brucia ancora di più dei numeri.

Le sanzioni economiche

In Italia, i due organi di vigilanza sono l'AgID per i servizi digitali e il MiMIT (Ministero delle Imprese e del Made in Italy) per i prodotti. Le sanzioni non sono simboliche:

• Da 5.000€ a 40.000€ per le violazioni sui servizi e siti web, calibrate sulla gravità e sulla recidiva.
• Fino al 5% del fatturato annuo per le aziende di dimensioni maggiori o nei casi di violazione sistematica.
• Provvedimento di ritiro del prodotto dal mercato per i prodotti non conformi.

Tre anni di fatturato di una PMI italiana media in ambito digitale possono essere spazzati via da una singola ispezione. Non è catastrofismo: è matematica.

Il caso Domino's Pizza: la lezione americana che vale anche qui

Negli Stati Uniti, il precedente legale che ha cambiato il settore è la causa Robles v. Domino's Pizza. Guillermo Robles, non vedente, non riusciva a ordinare pizza online né tramite sito né tramite app. La Corte Suprema ha stabilito, nel 2019, che l'Americans with Disabilities Act si applica ai siti web commerciali. Domino's ha poi speso milioni in adeguamenti, risarcimenti e comunicazione di crisi.

In Europa il quadro giuridico è diverso ma la direzione è identica. Con l'EAA pienamente operativo, le cause civili per discriminazione digitale sono già una realtà nei paesi del Nord Europa. In Italia arriveranno. La domanda non è se, ma quando.

Il danno reputazionale

Un provvedimento dell'AgID viene pubblicato sul registro ufficiale. Il nome della tua azienda associato pubblicamente a una violazione della normativa sulla disabilità è qualcosa da cui non si torna facilmente. Nel 2026, la Corporate Social Responsibility non è un'opzione per chi vuole crescere: è una condizione di accesso al mercato premium.

L'esclusione dai bandi

I finanziamenti del PNRR, i bandi regionali (compreso quelli della Regione Campania per l'internazionalizzazione e la trasformazione digitale), le gare d'appalto di grandi gruppi privati e le collaborazioni con la PA richiedono sempre più spesso la conformità EAA come requisito d'accesso. Non come preferenza: come condizione necessaria. Se il tuo sito non è a norma, non sei nemmeno in gara.

WCAG 2.2: cosa è cambiato davvero e i "5 peccati capitali" del web design

Lo standard tecnico di riferimento è WCAG 2.2 (Web Content Accessibility Guidelines), pubblicato dal W3C nell'ottobre 2023. Non le WCAG 3.0, ancora in fase di bozza. Non le WCAG 2.0 di dieci anni fa. Le 2.2, livello AA. Questo è il livello minimo richiesto dalla normativa europea.

Cosa è cambiato rispetto alle WCAG 2.1

Chi aveva già adeguato il proprio sito alle WCAG 2.1 ha fatto bene, ma non ha finito. La versione 2.2 introduce novità rilevanti, soprattutto per chi usa interfacce complesse:

• Focus Appearance (criterio 2.4.11): l'indicatore visivo di focus — quel contorno che appare intorno a un elemento quando ci si sposta con la tastiera — deve avere dimensioni minime e contrasto sufficiente. Molti siti lo nascondono con CSS perché "è brutto". Dal punto di vista normativo, è illegale.
• Dragging Movements (criterio 2.5.7): ogni funzionalità che richiede trascinamento (drag & drop) deve avere un'alternativa attivabile con un singolo click o una pressione. Chi ha difficoltà motorie fini non può trascinare elementi.
• Target Size Minimum (criterio 2.5.8): i pulsanti e le aree cliccabili devono essere grandi almeno 24x24 pixel. Sembra ovvio. Eppure il 60% dei siti che analizzo ha icone social nel footer di 16x16 pixel, inutilizzabili per chi ha tremori o difficoltà motorie.
• Consistent Help (criterio 3.2.6): se il tuo sito ha un'opzione di supporto (chat, numero verde, FAQ), deve trovarsi nella stessa posizione su ogni pagina.

I 4 pilastri delle WCAG: la mappa mentale

Tutto il sistema WCAG si costruisce su quattro principi fondamentali. Tenerli a mente semplifica qualsiasi audit:

1. Percepibile: l'informazione e i componenti dell'interfaccia devono essere presentabili agli utenti in modo che possano percepirli. Se un'immagine non ha testo alternativo, non è percepibile da chi usa uno screen reader.
2. Operabile: i componenti dell'interfaccia e la navigazione devono essere operabili da chiunque. Se non puoi usare il sito con la sola tastiera, non è operabile.
3. Comprensibile: le informazioni e le operazioni dell'interfaccia devono essere comprensibili. Un linguaggio oscuro o una navigazione imprevedibile violano questo principio.
4. Robusto: il contenuto deve essere sufficientemente robusto da poter essere interpretato in modo affidabile da un'ampia varietà di programmi utente, incluse le tecnologie assistive.

I 5 peccati capitali del web design (e come assolverli)

Nella mia esperienza, analizzando centinaia di siti di PMI italiane tra la Campania e Londra, gli stessi errori si ripetono con una costanza quasi commovente. Eccoli, con le soluzioni pratiche.

Peccato 1 — Il contrasto "grigio eleganza". Quel testo grigio chiaro su sfondo bianco è bellissimo per un designer minimalista. È illegale per le WCAG 2.2. Il rapporto di contrasto richiesto è almeno 4.5:1 per il testo normale e 3:1 per il testo grande (18pt o 14pt grassetto). Strumento consigliato: WebAIM Contrast Checker (gratuito, online). Come riferimento sulla tipografia e contrasto, ho già approfondito questo tema nel nostro articolo sulla tipografia web.

Peccato 2 — Immagini mute. Carichi la foto del tuo prodotto con il nome "DSC_4921.jpg". Per uno screen reader, quella foto non esiste. Usa l'attributo alt con descrizione narrativa: non "Foto di scarpa" ma "Sneaker in pelle blu con cuciture artigianali e suola in gomma bianca". Questo non è solo accessibilità: è storytelling. Ed è SEO. Se non sai da dove iniziare, il nostro articolo sull'architettura del sito web spiega come strutturare semanticamente i contenuti.

Peccato 3 — Navigazione "Mouse-Only". Prova adesso: naviga il tuo sito usando solo il tasto TAB della tastiera. Riesci ad arrivare al carrello senza toccare il mouse? Riesci a compilare il form di contatto? Se la risposta è no, stai escludendo utenti con disabilità motorie, chi usa dispositivi di switch-control e, indirettamente, anche gli utenti da tastiera avanzati.

Peccato 4 — Form senza etichette. I campi di input senza un elemento <label> associato sono trappole per chi usa tecnologie assistive. Lo screen reader non sa cosa chiedere all'utente. "Nome", "Cognome", "Email" devono essere collegati esplicitamente al proprio campo tramite l'attributo for/id. Non basta il placeholder: scompare nel momento in cui inizi a digitare.

Peccato 5 — Video senza parole. Un video senza sottotitoli o senza trascrizione testuale esclude le persone non udenti, le persone con deficit uditivo e — cosa che spesso dimentichiamo — tutte le persone che guardano video in ambienti rumorosi o silenziosi senza cuffie. Stai escludendo il 40% del tuo pubblico video. Gratuitamente.

Il modello da seguire: BBC e GOV.UK

Non è necessario reinventare la ruota. Esistono già esempi eccellenti di accessibilità web a livello globale, a cui ispirarsi concretamente.

BBC (bbc.co.uk): il sito della BBC è considerato uno degli standard mondiali di accessibilità. Pubblica le sue linee guida interne ("BBC Accessibility Guidelines") liberamente online. Ogni componente dell'interfaccia — player video, menu di navigazione, form di feedback — è costruito con l'accessibilità come primo requisito, non come retrofit. Il contrasto è calibrato su tutti i breakpoint. I sottotitoli sono disponibili su ogni contenuto audiovisivo. La navigazione da tastiera funziona perfettamente. È un caso studio da cui qualsiasi team di sviluppo può imparare.

GOV.UK: il portale del governo britannico è il caso di scuola per eccellenza. Il Government Digital Service ha pubblicato la metodologia "Design System" con standard di accessibilità espliciti e verificati. Ogni aggiornamento del sito passa attraverso test con utenti reali con disabilità. Il risultato è un'interfaccia che lavora perfettamente con qualsiasi tecnologia assistiva e che ha ottenuto certificazione WCAG 2.2 AA completa.

Apple.com è un altro riferimento: la sezione "Accessibilità" di Apple non solo dimostra i propri prodotti, ma è essa stessa un esempio di design inclusivo impeccabile — con supporto completo a VoiceOver, Switch Control e ogni tecnologia assistiva sviluppata in casa.

Il vantaggio competitivo: perché l'accessibilità fa vendere di più

Qui smetto di parlare di legge e iniziamo a parlare di business. L'accessibilità non è un costo. È un investimento con un ROI difficilmente replicabile con altri strumenti.

Il mercato che stai ignorando

In Italia, circa il 22% della popolazione — quasi 13 milioni di persone — ha una forma di disabilità permanente o temporanea, secondo i dati ISTAT. Se il tuo sito non è accessibile, stai appendendo un cartello all'ingresso del negozio che dice: "i vostri soldi qui non sono graditi" a un quinto dei tuoi potenziali clienti.

A Londra, dove ho seguito diversi progetti di e-commerce nel settore moda e arredamento, ho visto brand aumentare il tasso di conversione in modo misurabile semplicemente rendendo il checkout navigabile da tastiera e aggiungendo le etichette corrette ai form. Non parliamo di restyling completi. Parliamo di interventi puntuali, mirati, che rimuovono le barriere invisibili.

L'Italia sta invecchiando più rapidamente della media europea. Entro il 2030, il 25% della popolazione italiana avrà più di 65 anni — una fascia demografica con tassi più elevati di ipovisione, difficoltà motorie fini e ridotta familiarità con interfacce complesse. Progettare per l'accessibilità oggi significa progettare per il cliente medio di domani.

La disabilità situazionale: quella che non ci si aspetta

C'è un concetto che cambia completamente la prospettiva di chi pensa che "l'accessibilità riguardi gli altri": la disabilità situazionale.

Sei in un posto illuminato dal sole. Lo schermo diventa quasi illeggibile. È una disabilità situazionale visiva.

Hai il braccio ingessato. Usi il mouse con la mano non dominante, lentamente. È una disabilità situazionale motoria.

Sei in un open space rumoroso senza cuffie. Il video non ha sottotitoli. È una disabilità situazionale uditiva.

Sei madre di un neonato. Stai navigando con una mano sola. È una disabilità situazionale motoria.

Microsoft, nel suo framework "Inclusive Design", ha reso famoso questo concetto con uno schema potentissimo: per ogni persona con disabilità permanente che progetto accessibile serve, ci sono decine di persone in situazione di disabilità temporanea o contestuale che ne traggono beneficio identico.

Progettare per l'accessibilità non è fare beneficenza. È progettare per le condizioni reali in cui le persone usano il web ogni giorno.

Accessibilità è SEO estremo

Google è, nella sua essenza più pura, uno screen reader sofisticatissimo che legge il tuo codice senza poter vedere le immagini.

• Testi ALT descrittivi: contenuto indicizzabile per le immagini di prodotto, aumenta la copertura nelle ricerche visive.
• Struttura H1 > H2 > H3 corretta: Google usa la gerarchia dei titoli per capire l'architettura del contenuto. Saltare livelli di heading è un problema sia di accessibilità che di SEO.
• Velocità e leggerezza: un sito accessibile tende a essere meglio strutturato nel codice, più leggero, più veloce. Questo impatta direttamente i Core Web Vitals di Google.
• Link con testo descrittivo: "Clicca qui" e "Leggi di più" sono illeggibili fuori contesto da uno screen reader. E penalizzano il PageRank dei link interni.

Il plug-in non basta, ma è un punto di partenza

Una precisazione tecnica che vale la pena fare: esistono sul mercato plugin di accessibilità per le principali piattaforme CMS — Joomla e WordPress in primis — che automatizzano una parte degli interventi di adeguamento. Questi strumenti sono utili e spesso fanno la differenza in fase transitoria: migliorano la leggibilità per ipovedenti e dislessici, evidenziano titoli e link, aumentano il contrasto, gestiscono la dimensione del testo, operano su animazioni e saturazione dei colori, e — aspetto fondamentale — predispongono correttamente il sito per l'interpretazione degli screen reader.

Tuttavia, nessun plugin sostituisce un'architettura accessibile nativa. I cosiddetti "overlay" — script che si applicano sopra un sito non accessibile cercando di correggerne i problemi al volo — sono spesso criticati dalla comunità degli utenti con disabilità perché creano conflitti con le tecnologie assistive già in uso (chi usa già VoiceOver sul Mac non vuole un secondo screen reader che interferisce). Il plugin è una soluzione transitoria e complementare, mai sostitutiva di una progettazione corretta alla fonte.

Come mettersi in regola: il piano operativo in 4 step

Non occorre rifare tutto domani mattina. Ma bisogna iniziare oggi. Ecco un percorso pragmatico, costruito su misura per la realtà delle PMI italiane.

Step 1 — L'audit (usa gli strumenti giusti)

Il primo passo è capire dove si è. Non fidarti di chi ti offre "conformità garantita con un clic": sono quasi sempre overlay che peggiorano l'esperienza per chi usa davvero le tecnologie assistive. Usa strumenti di analisi seri:

• WAVE Accessibility Checker (wave.webaim.org): estensione gratuita per Chrome e Firefox, evidenzia visivamente gli errori direttamente sulla pagina. Ottima per un primo screenshot della situazione.
• Lighthouse (integrato in Chrome DevTools, tasto F12): produce un report con punteggio 0-100 di accessibilità, con indicazione specifica dei problemi e delle righe di codice da correggere.
• axe DevTools (deque.com/axe): il tool preferito dagli sviluppatori per test più approfonditi sul codice. Esiste versione gratuita e versione Pro.
• WebAIM Contrast Checker (webaim.org/resources/contrastchecker): inserisci i colori del tuo brand e controlla immediatamente se rispettano i rapporti WCAG.
• Test manuale con screen reader: NVDA (Windows, gratuito) o VoiceOver (Mac/iOS, integrato). Non c'è nulla di più formativo che navigare il proprio sito con gli occhi chiusi.

Step 2 — Prioritizzare: la regola degli incendi

Non tutti i problemi hanno la stessa urgenza. Segui questa gerarchia:

1. Critici (spegni l'incendio adesso): impossibilità di completare un acquisto, form non inviabili, video senza sottotitoli su contenuti obbligatori per legge, totale mancanza di navigazione da tastiera.
2. Significativi (prossima sprint di sviluppo): problemi di contrasto su testo principale, immagini senza alt text, form senza etichette.
3. Ottimizzazioni (backlog): focus appearance, target size, consistenza della navigazione tra pagine.

Step 3 — La dichiarazione di accessibilità

Non è optional. È obbligatoria per legge e deve essere accessibile dal footer di ogni pagina. Molte PMI pensano che basti scrivere "questo sito è conforme alle WCAG". Non è così. La dichiarazione deve contenere:

• Lo stato di conformità: conforme, parzialmente conforme o non conforme, con riferimento alla specifica versione WCAG.
• Le eventuali limitazioni note: quali aree del sito non sono ancora completamente conformi e perché (con tempistica di adeguamento prevista).
• Le alternative: se una funzionalità non è accessibile, come può l'utente ottenerla in altro modo (telefono, email, assistenza dedicata).
• Un contatto per feedback e segnalazioni: deve essere un indirizzo attivo, non una casella generica.
• La data di ultima revisione: la dichiarazione va aggiornata almeno annualmente entro il 23 settembre.

Il modello ufficiale è disponibile sul sito AgID. Seguirlo passo passo riduce il rischio di contestazioni formali.

Step 4 — L'onere sproporzionato: come usarlo correttamente

La normativa prevede una clausola di salvaguardia: se un adeguamento comporta un "onere sproporzionato" per l'organizzazione, può essere posticipato. Ma attenzione: questa clausola non è un'uscita di sicurezza da usare a piacimento. Ha regole precise.

Per invocare l'onere sproporzionato devi:

4. Documentare formalmente la valutazione: non basta dichiararlo a voce. Serve un documento scritto che analizza il rapporto tra il costo dell'intervento e le risorse disponibili dell'organizzazione.
5. Dimostrare la sproporzione: confrontando il costo dell'adeguamento con il fatturato, il numero di dipendenti, e la natura del problema di accessibilità.
6. Indicare le misure alternative: anche invocando l'onere sproporzionato, devi garantire che gli utenti con disabilità possano accedere al servizio in altro modo.
7. Inserire la documentazione nella dichiarazione di accessibilità: il motivo e la durata dell'esenzione devono essere pubblicamente visibili.

Usare questa clausola senza documentazione adeguata non è una difesa: è un'aggravante. L'AgID può considerarla una violazione consapevole e applicare le sanzioni più elevate dello scaglione.

Conclusione: il codice che racconta chi sei

Ti lascio con un'idea che mi porto dietro da anni.

Il codice non mente mai. Racconta chi sei. Racconta se ti importa davvero delle persone che visitano il tuo sito — o se stai solo cercando di vendere qualcosa a chi riesce già a comprarlo senza difficoltà.

L'accessibilità nel 2026 non è una tassa. Non è nemmeno una pratica burocratica da sbrigare per evitare le sanzioni. È la forma più concreta di rispetto verso chi usa il web in modo diverso da come lo usi tu. È la capacità di accendere la luce in una stanza che per troppi è rimasta buia per troppo tempo.

E la cosa bella — quella che i freddi manuali di compliance non ti dicono mai — è che quando accendi quella luce, non ci vede solo chi era al buio. Ci vedono meglio tutti. La persona anziana con l'ipovisione, il ragazzo con la dislessia, la madre con il bambino in braccio che naviga con una mano sola, l'utente in treno senza cuffie.

Hai ancora dubbi sulla conformità del tuo sito? Hai ricevuto una segnalazione dall'AgID o stai per lanciare un sito nuovo e vuoi partire già in regola? La prima cosa da fare è un audit serio, con strumenti certificati e occhi umani, non solo automatismi.

Perché alla fine, l'accessibilità non si certifica con un plugin. Si costruisce, riga di codice dopo riga di codice, scelta di design dopo scelta di design. Con metodo. Con cura. Con rispetto.