Accessibilità di default

C’è un cambio di passo silenzioso in corso nei team di design, ed è di quelli che meritano attenzione perché non si vedono subito. Secondo il sondaggio State of Design di Material Design, quasi la metà dei team che lavora a un design system dichiara di avervi già integrato linee guida sull’accessibilità, non come nota a margine ma come parte del sistema stesso. Il dato arriva da un contesto specifico, quello dei design system, ma racconta una tendenza più ampia: l’accessibilità non è più l’ultimo controllo prima del rilascio, ma un requisito che si discute fin dal primo wireframe, insieme a layout, gerarchia visiva e contenuti.

Anni fa ho aderito al programma di accessibility ambassador di PayPal, un’iniziativa interna che formava persone di team diversi (design, contenuti, ingegneria) per portare competenze di accessibilità dentro i rispettivi progetti, invece di lasciarla come compito esclusivo di un unico reparto specializzato. È stata l’esperienza che mi ha fatto capire quanto le due strade, integrare fin dall’inizio o correggere alla fine, producano risultati completamente diversi, sia per chi usa il prodotto sia per chi lo costruisce.

Cosa cambia quando l’accessibilità entra nel processo fin dal primo wireframe

Nel gergo dello sviluppo software si parla spesso di “shift left”: spostare un controllo di qualità il più presto possibile nel ciclo di lavoro, invece di scoprirlo tardi quando costa di più rimediare. Applicato al design, significa passare da un modello in cui l’accessibilità viene verificata (e spesso rattoppata) a ridosso del lancio, a un modello in cui contrasto cromatico, struttura semantica, stati di focus e testi alternativi vengono decisi insieme al resto dell’interfaccia.

La differenza pratica è enorme. Un pulsante senza etichetta accessibile scoperto in fase di QA richiede una modifica isolata, magari urgente, spesso scollegata dal contesto in cui è nato. Lo stesso pulsante pensato come componente accessibile fin dal design system si porta dietro automaticamente la sua etichetta, il suo stato di focus, il suo contrasto corretto, ovunque venga riutilizzato. Non è un dettaglio tecnico: è la ragione per cui i design system più maturi, come racconta il blog di Figma, puntano a costruire componenti “accessibili di default”, cioè conformi agli standard fin dal momento in cui vengono creati, così che ogni prodotto costruito con quei mattoncini erediti la conformità invece di doverla rincorrere.

Cosa significa in pratica “accessibile di default”

Non è una certificazione né un traguardo da spuntare una volta sola. È un insieme di abitudini che entrano nel flusso quotidiano di chi progetta:

pensare alla gerarchia dei contenuti con un markup semantico corretto, non solo con uno stile visivo che “sembra” un titolo;
verificare il contrasto tra testo e sfondo mentre si sceglie la palette, non dopo che è già stata approvata;
progettare stati di focus visibili per la navigazione da tastiera, non solo interazioni pensate per il mouse o il tocco;
scrivere testi alternativi ed etichette dei campi come parte del contenuto, non come metadato da aggiungere in un secondo momento;
coinvolgere persone con disabilità nella ricerca utente, invece di affidarsi solo a checklist tecniche compilate a distanza.

Quest’ultimo punto è quello che, nella mia esperienza, fa la differenza reale. Una checklist WCAG dice se un componente rispetta certi criteri tecnici; una sessione con una persona che usa uno screen reader tutti i giorni mostra dove quel componente crea davvero attrito. Sono due livelli diversi di verifica, e servono entrambi.

I sei problemi che continuano a ripetersi sulle homepage di tutto il web

Il report WebAIM Million, che ogni anno analizza l’accessibilità del milione di homepage più visitate al mondo, offre un termometro utile per capire quanta strada resti da fare. Nell’edizione 2026 il 95,9% delle homepage analizzate presentava almeno un errore rilevabile rispetto alle WCAG, con una media di 56,1 errori per pagina, in aumento del 10,1% rispetto all’anno precedente. Sei categorie di problemi, sempre le stesse, coprono da sole il 96% degli errori rilevati: contrasto insufficiente (83,9% delle pagine), immagini senza testo alternativo (53,1%), campi modulo senza etichetta (51%), link vuoti (46,3%), pulsanti vuoti (30,6%) e lingua della pagina non dichiarata (13,5%).

Sono errori quasi tutti evitabili in fase di progettazione, prima ancora che di sviluppo. Un link vuoto o un pulsante privo di testo, per esempio, nascono spesso da un’icona usata senza etichetta accessibile, una scelta che si decide sul tavolo del design, non durante il collaudo finale.

Il costo di rimandare tutto alla fine

Il report State of Digital Accessibility di Level Access segnala un paradosso interessante: pur essendo ormai chiaro a chiunque lavori nel settore che intervenire presto è il modo più efficiente per gestire l’accessibilità, l’adozione proattiva sta rallentando rispetto agli anni precedenti. Il motivo è quasi sempre lo stesso, riassunto bene da chi lavora nel settore fintech: affrontare l’accessibilità dopo che il prodotto è già stato costruito richiede una rilavorazione costosa, spesso più costosa della progettazione iniziale corretta.

È lo stesso principio che vale per tanti altri aspetti della qualità di un prodotto digitale, dai microtesti degli errori ai bottoni delle call to action: più tardi si interviene, più il cambiamento costa e più difficile è farlo bene.

La mia esperienza da accessibility ambassador in PayPal

Quando ho aderito al programma interno di accessibility ambassador, la prima cosa che ho imparato è quanto poco sapessi davvero, nonostante lavorassi da anni su interfacce e contenuti. Avevo dato per scontato che “scrivere bene” un’etichetta o un messaggio d’errore bastasse a renderlo utile a chiunque. Le sessioni di formazione, e soprattutto il confronto diretto con chi usava tecnologie assistive, mi hanno mostrato quante piccole scelte quotidiane, l’ordine di tabulazione, la lunghezza di un messaggio letto ad alta voce da uno screen reader, il modo in cui viene annunciato un errore in un form, potessero cambiare radicalmente l’esperienza di chi cercava semplicemente di completare una registrazione o un pagamento.

Ho raccontato altrove i dettagli di uno di questi progetti, quello sul pulsante di registrazione in Italia, e resta l’esempio che cito più spesso quando qualcuno mi chiede perché l’accessibilità dovrebbe entrare nel design fin dal primo giorno: non perché sia un obbligo normativo (anche se spesso lo è), ma perché il costo di ignorarla ricade sempre su chi ha meno margine per aggirare l’ostacolo.

Il ritardo che si vede ancora nei siti della pubblica amministrazione italiana

Se c’è un ambito in cui il divario tra teoria e pratica resta ampio, in Italia, è proprio quello della pubblica amministrazione. Basta misurarsi con il sito dell’INPS o quello dell’Agenzia delle Entrate per rendersi conto di quanto lavoro manchi ancora: percorsi di navigazione poco intuitivi, moduli complessi da compilare anche per chi non ha alcuna disabilità, contenuti scritti con un linguaggio tecnico che sembra pensato per scoraggiare chi legge, invece di guidarlo.

L’ho toccato con mano anche come volontaria per il Festival DiParola, nell’edizione 2024 dedicata alla precisione del linguaggio. Ho contribuito alle ricerche dell’Osservatorio sul Linguaggio Chiaro, promosso dall’Associazione Linguaggi Chiari, occupandomi della valutazione di quattro siti istituzionali su un totale di venti analizzati. Il lavoro combinava un’analisi testuale automatica, con lo strumento READ-IT sviluppato dall’ItaliaNLP Lab del CNR, e una verifica basata sui principi della norma ISO 24495-1:2023 sul linguaggio chiaro. Anche in quel contesto il problema principale non era la mancanza di linee guida, che esistono e sono pure piuttosto dettagliate, ma il momento in cui vengono applicate: quasi sempre a lavoro concluso, raramente durante la progettazione dei contenuti e delle interfacce.

Una checklist pratica per chi vuole iniziare

Per chi progetta interfacce e vuole spostare l’accessibilità più a monte nel proprio flusso di lavoro, alcuni punti di partenza concreti:

integrare un controllo di contrasto cromatico negli strumenti di design già usati, come plugin o estensioni, invece di verificarlo solo a sviluppo concluso;
documentare stati di focus, ordine di lettura e testi alternativi direttamente nei file di design, come parte delle specifiche consegnate a chi sviluppa;
costruire (o adottare) componenti di design system già conformi, così che ogni nuova schermata erediti automaticamente le proprietà accessibili;
includere, quando possibile, persone con disabilità nei test di usabilità, non solo nelle fasi finali di validazione;
trattare ogni deroga alle linee guida di accessibilità come si tratterebbe una deroga a qualsiasi altro requisito di prodotto: documentata, motivata, e con un piano per essere risolta.

Nessuno di questi passaggi implica reinventare il processo di design da zero. Serve, piuttosto, trattare l’accessibilità come una componente del prodotto al pari delle altre, con lo stesso peso che si dà a performance, sicurezza o coerenza visiva. È un cambiamento culturale più che tecnico, e come tutti i mutamenti di questo tipo procede per ondate successive: prima i team più esposti al tema (fintech, pubblica amministrazione, grandi piattaforme), poi, gradualmente, tutti gli altri.