Design accessibile dopo l'EU Accessibility Act

L'European Accessibility Act (EAA) è la legge UE che obbliga prodotti e servizi digitali rivolti ai consumatori e immessi sul mercato europeo a rispettare i requisiti di accessibilità allineati a EN 301 549 e WCAG 2.1 livello AA. È in vigore dal 28 giugno 2025, con periodi transitori limitati per contratti preesistenti e terminali self-service.

Se vendete un prodotto SaaS, un sito e-commerce, un'app mobile, un e-reader, un servizio bancario o una piattaforma di biglietteria a consumatori UE, siete dentro lo scope. Le microimprese (meno di 10 dipendenti e meno di 2 milioni di euro di fatturato) che forniscono servizi sono esenti, ma le microimprese che producono o distribuiscono prodotti coperti dall'EAA non lo sono. I servizi B2B puri e gli strumenti corporate interni restano fuori dallo scope.

Perché questo problema brucia ora

Il punto di partenza è brutale. Il report WebAIM Million 2025 ha rilevato che il 94,8% delle prime un milione di home page del web contiene errori WCAG 2 A/AA rilevabili automaticamente, con una media di oltre 50 errori per pagina. Sei problemi ricorrenti, guidati da basso contrasto del testo e alt mancanti, spiegano il 96% di tutti gli errori. Il web, in aggregato, non è stato progettato per essere accessibile.

Le sanzioni le fissano i singoli stati membri. Spagna e Italia possono multare le grandi aziende fino al 5% del fatturato annuo per non conformità sistemica. La Francia applica una sanzione di quinta classe da 7.500 euro per violazione alle persone giuridiche, con sanzioni aggregate fino a 250.000 euro per problemi sistemici su una piattaforma, più una sanzione annuale separata da 25.000 euro per la mancata pubblicazione della dichiarazione di accessibilità. L'Irlanda è oggi l'unico stato membro in cui le violazioni gravi dell'EAA possono comportare sanzioni penali. L'articolo 20 della direttiva permette alle autorità di rimuovere completamente dal mercato i prodotti non conformi.

Il rischio finanziario è reale, ma non è la voce più cara. La voce più cara è il costo di adeguare un prodotto progettato senza accessibilità. I dati di settore indicano che l'accessibilità costruita in corsa costa circa un terzo rispetto al retrofit. Gli audit (2.500-10.000 euro) sono economici. La remediation (5.000-20.000 euro e spesso ben oltre) è dove il budget evapora, perché tocca ogni componente, ogni flusso, ogni test.

Perché audit e retrofit non bastano

La maggior parte dei team adotta lo stesso playbook. Si commissiona un audit esterno. Si riceve un foglio di calcolo con 200 righe di problemi WCAG. Lo si passa all'engineering. Si spera che entri nei prossimi due sprint. Questo genera tre problemi prevedibili.

Primo, l'audit cattura i sintomi. I problemi più diffusi (basso contrasto, alt mancanti, link vuoti, label assenti sui form) vivono nel layer dei componenti. Risolvere il sintomo in dodici punti non risolve il design system che lo ha emesso dodici volte. Tre mesi dopo, i componenti nuovi presentano gli stessi difetti.

Secondo, axe-core e gli strumenti automatici simili intercettano al massimo il 30-40% dei problemi WCAG. Il resto (gestione del focus, annunci per screen reader, struttura semantica, pattern di interazione complessi) richiede test manuale con tecnologia assistiva. I team che spediscono axe-green e lo trattano come prova di conformità ricevono la prima segnalazione e lo imparano nel modo peggiore.

Terzo, il retrofit introduce regressioni. Ogni fix di contrasto tocca il layer dei token. Ogni fix sul focus tocca la gestione del focus. Ogni fix di label tocca un input primitive condiviso. Senza governance, un retrofit è un prodotto appena rotto in modo nuovo.

Cosa cambia davvero con accessibility-first

Accessibility-first non significa aggiungere l'accessibilità in backlog. Significa spostare i vincoli di accessibilità nello stesso posto dove vivono le decisioni su tipografia, spaziatura e colore. Quattro spostamenti contano.

1. I token portano accessibilità, non solo stile

Un design token system che spedisce coppie di colore (foreground più background) invece di colori singoli rende il contrasto una proprietà del token, non del consumer. Il rapporto di contrasto si calcola una volta, nel layer dei token, e il consumer non può spedire una combinazione non conforme. La stessa logica vale per focus ring, dimensione minima delle hit area (44 per 44 pixel CSS secondo WCAG 2.5.5, usato come default di sistema) e preferenze di motion.

2. I componenti sono accessibili per costruzione

Ogni primitive (button, input, dialog, menu, tabs, tooltip) spedisce con modello da tastiera, pattern ARIA e gestione del focus integrati nel componente, non nel codice consumer. I team che costruiscono le proprie primitive su Radix Primitives o React Aria ottengono tutto questo quasi gratis. I team che costruiscono da soli pagano il costo una volta e mai più, a patto che la governance regga. La mossa sbagliata è una libreria di componenti di terze parti che fa male il modello da tastiera: si eredita il bug senza poterlo correggere. Abbiamo trattato il tema in 10 design system mistakes that wreck consistency at scale.

3. Lint e CI presidiano l'accessibilità, non solo i tipi

Il cambiamento è operativo. axe-core in CI cattura il 30-40% dei problemi che l'automazione può rilevare, prima che la PR venga mergiata. eslint-plugin-jsx-a11y cattura i problemi di markup nell'IDE. L'addon a11y di Storybook li cattura per componente. Nessuno di questi sostituisce il test manuale, ma insieme impediscono al pavimento di crollare tra un audit e l'altro.

4. Test manuale con tecnologia assistiva reale, a ogni release

Si scelgono pochi flussi che spiegano la maggior parte del fatturato o delle azioni critiche. Si testano questi flussi con VoiceOver su macOS e iOS, NVDA su Windows, TalkBack su Android e navigazione da sola tastiera. A ogni release, non una volta l'anno. Il piano di test è una checklist; il valore sta nel catturare ciò che l'automazione non vede.

Come si presenta nella pratica

Un team SaaS con cui collaboriamo pubblica una dashboard di analytics consumer per clienti UE. È partito a marzo 2025 con un audit esterno che ha riportato 187 problemi distinti su 14 componenti. Invece di correggere i problemi in loco, il team ha fatto tre cose in parallelo: ha riscritto le quattro primitive più riutilizzate (button, input, modal, table) sopra fondamenta accessibili; ha introdotto token a coppie di colore che hanno reso il contrasto una proprietà di sistema; ha aggiunto axe-core e jsx-a11y in CI, con build configurata per fallire sulle nuove violazioni.

Entro fine giugno 2025, la dashboard ha superato tutti i controlli automatici WCAG 2.1 AA e tre passaggi manuali su VoiceOver, NVDA e navigazione da tastiera. Il costo totale di engineering è stato di 22 persona-giorno. Il team legale ha pubblicato e registrato la dichiarazione di accessibilità. Sei mesi dopo, il team non ha regredito, perché il sistema, non gli ingegneri, presidia il pavimento.

La lezione non è che 22 persona-giorno è il numero giusto per ogni prodotto. La lezione è che il lavoro si capitalizza quando vive nel sistema, e si esaurisce quando vive nei ticket.

Da dove partire se siete in ritardo

Tre passi, in questo ordine. Eseguite un audit sui tre flussi principali (sign-up, task primario, pagamento) per capire la forma del gap. Sistemate il design system, non le pagine, riscrivendo le quattro-sei primitive che spiegano l'80% dei findings. Poi aggiungete lint e gate in CI che impediscono la regressione. Saltate questi passi in quest'ordine e il lavoro si capitalizza; invertite l'ordine e tornerete a spedire le stesse correzioni l'anno prossimo.

Accessibility-first non è una posizione morale, è una posizione operativa. I prodotti che trattano l'accessibilità come una proprietà del sistema servono più utenti, spediscono più velocemente dopo l'investimento iniziale e smettono di portare rischio di conformità a ogni release. L'EAA ha chiuso la porta all'alternativa per chi vende all'UE.