UX Caffè

Accessibilità: non è più un dettaglio da sistemare alla fine

Contrasto, focus, form, dimensioni dei controlli e navigazione non sono correzioni tecniche dell’ultimo minuto. Sono decisioni di design che dovrebbero nascere insieme al prodotto.

Giovedì 17 settembre 2026

Per molto tempo l’accessibilità digitale è stata trattata come una sorta di controllo finale. Prima si progettava l’interfaccia, poi si sviluppava il prodotto e soltanto alla fine qualcuno iniziava a chiedersi se i colori avessero abbastanza contrasto, se la navigazione funzionasse da tastiera o se un lettore di schermo riuscisse a comprendere correttamente la pagina.

È un modo di lavorare che oggi mostra tutti i suoi limiti. Non soltanto perché il quadro normativo europeo è diventato molto più concreto, ma soprattutto perché molti problemi di accessibilità nascono molto prima dello sviluppo. Nascono nel momento in cui scegliamo una gerarchia visiva, decidiamo di rendere un pulsante molto piccolo, comunichiamo un errore soltanto attraverso il colore o eliminiamo il focus perché “graficamente non ci piace”.

Dal 28 giugno 2025 l’European Accessibility Act ha reso ancora più evidente il tema, introducendo requisiti comuni di accessibilità per numerosi prodotti e servizi commercializzati nell’Unione Europea, tra cui e-commerce, servizi bancari e di pagamento, comunicazioni elettroniche e diversi prodotti digitali. Nel settembre 2026 è stata inoltre pubblicata la nuova versione dello standard europeo EN 301 549, che incorpora WCAG 2.2 come nuovo riferimento tecnico per siti, software e documenti digitali, anche se al momento non è ancora il riferimento armonizzato utilizzabile automaticamente per dimostrare la conformità normativa.

Il punto, però, non dovrebbe essere semplicemente adeguarsi a una legge.

Il punto è progettare prodotti che possano essere utilizzati dal maggior numero possibile di persone.

L’accessibilità comincia nel file di design

Quando pensiamo all’accessibilità, spesso immaginiamo attività tecniche: attributi ARIA, HTML semantico, screen reader, navigazione da tastiera. Tutti elementi fondamentali, ma che rischiano di farci pensare che l’accessibilità appartenga soprattutto allo sviluppo.

In realtà molte delle decisioni più importanti vengono prese molto prima.

Il designer decide il contrasto tra testo e sfondo. Decide quanto deve essere grande un pulsante. Decide se un link è riconoscibile soltanto grazie al colore. Decide come viene mostrato un errore in un form. Decide la gerarchia delle informazioni, la dimensione dei testi, la posizione delle label, gli stati di focus e la struttura di un flusso.

Se queste decisioni sono sbagliate, lo sviluppatore può certamente cercare di correggerle. Ma significa intervenire su un progetto già definito, spesso quando modificare componenti e comportamenti costa molto più tempo.

L’accessibilità dovrebbe quindi entrare nel processo esattamente come entrano responsive design, design system o usabilità.

Non come controllo finale.

Come requisito iniziale.

Il contrasto non è soltanto una questione di numeri

Il contrasto è probabilmente uno degli aspetti più conosciuti dell’accessibilità. Le WCAG definiscono valori precisi per garantire che testo ed elementi importanti rimangano leggibili.

Ma ridurre tutto a un rapporto numerico sarebbe un errore.

Un’interfaccia può superare formalmente un controllo di contrasto e continuare a essere difficile da utilizzare.

Testi troppo piccoli, gerarchie deboli, quantità eccessive di informazioni, font poco leggibili o superfici visive troppo simili possono creare difficoltà anche quando il rapporto cromatico rispetta i valori richiesti.

Il problema diventa ancora più evidente quando utilizziamo il colore come unico mezzo di comunicazione.

Pensiamo a un form in cui i campi errati vengono semplicemente evidenziati in rosso. Oppure a un grafico in cui due categorie vengono distinte esclusivamente attraverso verde e rosso.

Per alcune persone quel messaggio potrebbe essere molto meno chiaro di quanto immaginiamo.

La soluzione non significa rinunciare al colore.

Significa evitare che il colore sia l’unico elemento che trasmette l’informazione.

Un’icona, un testo esplicativo, una label o una variazione visiva aggiuntiva possono rendere il messaggio molto più robusto.

Il focus non è un difetto grafico

Un altro esempio molto comune riguarda il focus da tastiera.

Durante la progettazione di un’interfaccia capita ancora di vedere il classico contorno del browser considerato come qualcosa di brutto da eliminare. Il problema è che quel contorno comunica una cosa fondamentale: mostra quale elemento della pagina è attualmente selezionato da chi naviga senza utilizzare il mouse.

Le WCAG 2.2 dedicano particolare attenzione proprio a questo aspetto. Il focus deve essere visibile e non può essere completamente nascosto da altri contenuti; sono inoltre state introdotte indicazioni più precise sulla sua percepibilità.

Dal punto di vista del design, quindi, la domanda non dovrebbe essere “come eliminiamo questo bordo?”, ma “come possiamo progettare uno stato di focus coerente con la nostra interfaccia e sufficientemente evidente?”.

Il focus può essere bello.

Può utilizzare colori coerenti con il brand, un outline ben progettato o un cambiamento dello stato del componente.

La condizione fondamentale è che rimanga riconoscibile.

Nasconderlo non rende l’interfaccia più pulita.

Rende semplicemente più difficile utilizzarla.

I pulsanti devono essere facili da premere

L’accessibilità riguarda anche qualcosa di estremamente concreto: riuscire a selezionare ciò che vogliamo selezionare.

WCAG 2.2 introduce, tra le altre cose, un criterio relativo alla dimensione minima dei target per gli input tramite puntatore. Il riferimento di livello AA prevede generalmente almeno 24×24 CSS pixel oppure una spaziatura sufficiente rispetto agli altri controlli.

Il principio però è molto più semplice della specifica tecnica.

Se mettiamo due piccole icone una accanto all’altra e l’utente deve fare uno sforzo per premere quella corretta, abbiamo creato un problema.

Può riguardare una persona con una disabilità motoria, ma anche qualcuno che utilizza lo smartphone mentre cammina, una persona anziana, chi ha le mani fredde o semplicemente chi sta usando un dispositivo con uno schermo piccolo.

Ed è proprio qui che emerge uno dei concetti più interessanti dell’accessibilità: molte soluzioni progettate per risolvere una difficoltà specifica migliorano l’esperienza di tutti.

Un target più grande non è utile soltanto a chi ha una disabilità.

È semplicemente più facile da utilizzare.

I form raccontano molto della qualità di un’interfaccia

I form sono probabilmente uno dei punti in cui UX e accessibilità si incontrano più chiaramente.

Pensiamo a un modulo di registrazione.

Le label scompaiono appena iniziamo a digitare perché sono state utilizzate come placeholder? Un errore viene comunicato soltanto attraverso un bordo rosso? Dopo l’invio non è chiaro quale campo contenga il problema? L’utente deve reinserire informazioni che ha già fornito pochi passaggi prima?

Sono tutte decisioni che influenzano l’esperienza.

WCAG 2.2 introduce anche criteri dedicati alla riduzione dell’inserimento ridondante e all’autenticazione accessibile, proprio perché operazioni apparentemente semplici possono diventare barriere significative.

Per il designer significa progettare non soltanto lo stato ideale del form, ma l’intero comportamento:

• stato iniziale;
• focus;
• compilazione;
• errore;
• successo;
• campo disabilitato;
• informazioni obbligatorie;
• aiuti contestuali.

Progettare soltanto il form “perfetto”, completamente compilato e senza errori, significa progettare soltanto una piccola parte dell’esperienza reale.

Accessibilità e design system

Uno dei modi più efficaci per integrare l’accessibilità nel processo è farla entrare direttamente nel design system.

Se ogni nuovo progetto deve reinventare pulsanti, form, focus state, colori, dimensioni minime e comportamenti, inevitabilmente aumentano le possibilità di errore.

Un componente accessibile progettato una volta e riutilizzato correttamente riduce invece il problema alla radice.

Un design system può definire:

• colori e combinazioni già verificate;
• scale tipografiche leggibili;
• focus state standard;
• dimensioni minime dei controlli;
• errori e messaggi di validazione;
• componenti form correttamente strutturati;
• comportamento degli elementi interattivi;
• alternative ai pattern basati esclusivamente sul drag.

Questo non significa che il design system garantisca automaticamente l’accessibilità.

Un componente accessibile può comunque essere utilizzato nel contesto sbagliato.

Ma sposta molte decisioni ripetitive dal singolo progetto a una base condivisa e controllabile.

Non tutti utilizzano un’interfaccia come noi

Forse uno dei problemi più grandi nel design nasce dal fatto che tendiamo naturalmente a progettare partendo dalla nostra esperienza.

Vediamo bene lo schermo.

Utilizziamo il mouse.

Comprendiamo velocemente le convenzioni digitali.

Abbiamo probabilmente un dispositivo relativamente recente e una connessione stabile.

Ma l’utente non è necessariamente come noi.

Può avere una disabilità visiva, motoria, uditiva o cognitiva. Può utilizzare tecnologie assistive. Può avere una disabilità temporanea. Può essere anziano. Può avere poca familiarità con la tecnologia.

Oppure può semplicemente utilizzare il prodotto in condizioni diverse da quelle che abbiamo immaginato.

Il sole può rendere lo schermo difficile da leggere.

Una mano può essere occupata.

Un ambiente rumoroso può rendere inutilizzabile un contenuto audio.

Una connessione lenta può modificare il comportamento dell’interfaccia.

Pensare all’accessibilità significa in parte accettare che il nostro modo di utilizzare un prodotto non sia quello universale.

Accessibilità non significa progettare interfacce brutte

Esiste ancora la percezione che rispettare regole di accessibilità significhi limitare la creatività.

Pulsanti più grandi, contrasti maggiori, focus visibili, testi leggibili: sembra quasi che tutti questi requisiti portino inevitabilmente verso interfacce standardizzate e poco interessanti.

Ma una buona progettazione non dipende dalla possibilità di utilizzare testo grigio chiarissimo su sfondo bianco o nascondere informazioni dietro comportamenti difficili da scoprire.

I vincoli fanno parte del design.

Abbiamo vincoli tecnici, economici, di brand, di contenuto e di business.

L’accessibilità è semplicemente un altro insieme di vincoli da comprendere.

E spesso obbliga a prendere decisioni migliori.

Se un’informazione può essere compresa soltanto attraverso il colore, probabilmente il sistema di comunicazione è fragile.

Se un pulsante può essere utilizzato soltanto con grande precisione, probabilmente è troppo piccolo.

Se la navigazione funziona soltanto con il mouse, manca una modalità fondamentale di interazione.

In questo senso, l’accessibilità non limita il design. Elimina il design pigro.

Testare prima, non correggere dopo

La stessa logica vale per il testing.

Aspettare che il prodotto sia praticamente completo per verificare l’accessibilità significa trasformare ogni problema in una correzione.

Cambiare il colore di un singolo testo può essere semplice.

Scoprire che l’intera palette del design system genera problemi di contrasto è diverso.

Correggere un pulsante è semplice.

Scoprire che tutti i componenti interattivi del prodotto non hanno uno stato di focus richiede molto più lavoro.

Per questo conviene inserire controlli progressivi durante il progetto.

Il designer può verificare contrasto, gerarchie, target e stati già durante la progettazione. Lo sviluppatore può controllare semantica, navigazione da tastiera e tecnologie assistive durante l’implementazione. I test con utenti possono evidenziare problemi che nessun controllo automatico sarebbe in grado di individuare.

L’accessibilità non è una checklist da completare una volta.

È un processo.

Conclusioni

L’accessibilità digitale è stata trattata troppo a lungo come qualcosa da verificare quando il prodotto era ormai quasi terminato. Un controllo prima della pubblicazione, una lista di errori da correggere o, nei casi peggiori, un’attività da affrontare soltanto quando emergeva un obbligo normativo. Questo approccio oggi non è più sufficiente. L’European Accessibility Act ha aumentato l’attenzione sul tema in Europa e la nuova evoluzione dello standard EN 301 549 conferma una direzione sempre più chiara verso WCAG 2.2. Ma fermarsi alla conformità significherebbe perdere la parte più interessante del problema.

L’accessibilità è prima di tutto design.

Quando scegliamo un contrasto, dimensioniamo un bottone, progettiamo uno stato di focus, organizziamo le informazioni di un form o decidiamo come comunicare un errore, stiamo già facendo scelte che possono facilitare oppure ostacolare l’utilizzo del prodotto. Aspettare la fine significa spesso chiedere allo sviluppo di correggere problemi che sono nati molto prima.

Integrare l’accessibilità dall’inizio non significa trasformare ogni designer in un esperto di normative. Significa conoscere alcuni principi fondamentali, inserirli nei design system, discuterli con gli sviluppatori e considerarli parte normale della qualità di un prodotto. Esattamente come facciamo con responsive design, performance, sicurezza o consistenza dell’interfaccia.

C’è poi un aspetto ancora più importante. Molte decisioni accessibili producono esperienze migliori anche per persone che non hanno una disabilità permanente. Testi leggibili, target più grandi, navigazione chiara, messaggi di errore comprensibili, sottotitoli e interazioni prevedibili sono semplicemente caratteristiche di un buon prodotto.

Forse dovremmo quindi smettere di vedere l’accessibilità come una versione speciale del design destinata a qualcuno.

È design.

E quando un’interfaccia esclude una parte delle persone perché abbiamo scelto una soluzione più elegante, più minimale o semplicemente più veloce da realizzare, il problema non è che l’accessibilità limita la creatività. Il problema è che non abbiamo progettato abbastanza bene.

Un buon designer non dovrebbe chiedersi alla fine: “Questo prodotto è accessibile?”.

Dovrebbe iniziare molto prima con una domanda diversa:

“Chi potrebbe avere difficoltà a utilizzare ciò che sto progettando, e cosa posso fare adesso per evitarlo?”

È una domanda molto semplice.

Ma può cambiare completamente la qualità del risultato.