Perché oggi (più che mai) è di fondamentale importanza per lo sviluppatore?
Dal 28 giugno 2025 è entrato in vigore l’European Accessibility Act il quale definisce le linee guida di accessibilità di contenuti web e applicazioni mobile a livello europeo ed impone l’obbligo di conformità a tutte le PMI (> 10 dipendenti oppure > €2 milioni di fatturato).
Ma cosa significa questo termine che sentiamo spesso utilizzato come buzz word senza che ci venga effettivamente spiegato nel concreto?
“L'accessibilità è la capacità di rendere prodotti, servizi e contenuti digitali utilizzabili da chiunque, in qualsiasi contesto o situazione.” - AGID
Il punto cruciale di questa definizione è la parola “chiunque”, questo pronome include ogni singolo nostro potenziale utente, con particolare attenzione a coloro che hanno “ridotta o impedita capacità sensoriale, motoria o psichica”, che sia essa temporanea o stabile. Quest’ultima categoria di utenti (~15-20%) è il motivo per il quale si pone tanta attenzione all’accessibilità, ma è importante ricordare che le accortezze prese al fine di migliorare questo aspetto del nostro software facilitano l’esperienza di ogni utente.
Vediamo quindi una lista di problematiche che possono ostacolare l’utilizzo di un’applicazione mobile:
👁️ Visive: cecità, ipovisione, daltonismo, schermo offuscato da fattori esterni.
👂 Uditive: sordità, ipoacusia, impossibilità di recepire informazioni audio.
🦾 Motorie: impossibilità di navigare ed interagire con il software nei modi “classici” ai quali siamo abituati.
🧠 Cognitive o Psichiche: dislessia, deficit dell’attenzione, problemi di memoria.
Come posso rendere la mia applicazione accessibile?
L’unico vero modo per assicurarsi che la propria app sia accessibile è farla testare da diversi tipi di utenti con diversi gradi di disabilità; tuttavia ci sono modi e strumenti che uno sviluppatore può adoperare per simulare o verificare da sé l’esperienza utente.
Vediamone alcuni.
Dimensione Font
Una delle problematiche principali nasce quando una struttura UI pixel perfect si scontra con una dimensione font incrementata a livello di sistema, uno schermo più piccolo del previsto oppure un testo più lungo del solito; dei widget non accessibili in questo caso vanno facilmente in overflow nascondendo contenuto importante e rappresentando una barriera per un gran numero di utenti.
È possibile testare il comportamento dell’app che si sta sviluppando impostando la dimensione del font ad approssimativamente 200%.
iOS: Settings > Accessibility > Display & Text Size > Larger Text > attivare Larger Accessibility Sizes > impostare lo Slider almeno al terzultimo tick.
Android: Settings > Accessibility > Display Size & Text > portare Font Size Slider al massimo (può variare).
Una volta impostato un font sufficientemente grande, sarà possibile provare ad utilizzare l’app e controllare quali testi “rompono” la UI o vengono nascosti/tagliati perché troppo grandi, è importante verificare ogni schermata ed ogni stato nel quale un widget si può trovare. Una volta individuato un widget di testo in overflow, ci possono essere due soluzioni:
Permettergli di occupare più di una linea andando a capo ed occupando più spazio verticalmente (da preferire in quanto permette a tutti gli utenti di vedere il testo nella sua interezza). Nella pratica questo si fa includendo il widget in un Flexible (è possibile anche dare un numero massimo di linee attraverso il parametro maxLines).
Porre un limite massimo alla larghezza e selezionare un comportamento in risposta al taglio (es. l’aggiunta dei “…”) passando il parametro overflow: TextOverflow.ellipsis al widget.
Contrasto Colore
Due colori che si sovrappongono (specialmente se si tratta di testo/sfondo) devono avere un contrasto sufficiente che permetta la facile comprensione/lettura anche agli utenti con problematiche visive. Fortunatamente il contrasto colore è facilmente calcolabile attraverso una formula ed esistono diversi strumenti per mezzo dei quali esso è calcolabile (es. contrast checker).
Un altro modo per controllare i contrasti di una schermata è per mezzo dell’Accessibility Scanner di Android : una volta installato, esso si può attivare dalle impostazioni di Accessibilità e cliccando l’icona blu esso esaminerà i contrasti presenti nei testi. L’obiettivo deve essere il raggiungimento di un rapporto di contrasto di almeno 3:1 per i testi grandi e di 4.5:1 per i rimanenti. Sono esenti gli elementi UI disabilitati.
Utilizzo con Screen Reader
Gli Screen Reader sono tecnologie assistive che interpretano il contenuto dello schermo convertendolo in sintesi vocale, è necessario quindi assicurarsi che gli elementi dell’applicazione siano correttamente segnalati e interpretabili da questi software.
Esistono due Screen Reader mobile principalmente utilizzati con i quali si può testare il comportamento dell’app: VoiceOver per iOS e TalkBack per Android. Entrambi funzionano in modo abbastanza simile:
è possibile navigare fra i widget swipe-ando a destra e a sinistra (rispettivamente indietro e avanti),
nel momento in cui un widget è selezionato, il suo significato semantico verrà letto dalla sintesi vocale,
è possibile fare doppio click per attivare/clickare il widget correntemente selezionato.
Un altro strumento utile per verificare i Semantics della propria applicazione è l’attivazione del parametro showSemanticsDebugger del tipo MaterialApp, questo rimuoverà totalmente gli elementi UI lasciando solamente dei riquadri contenenti il testo di quello che gli Screen Reader andranno a leggere se selezionati.
Quando si utilizzano i widget stock di flutter nella maggior parte dei casi i loro ruoli semantici sono già ben dichiarati; contrariamente è importante fare attenzione quando si implementa un widget custom da zero, in quanto è possibile che lo Screen Reader non sia in grado di descrivere correttamente il suo significato o funzionamento.
Semantics è la classe di widget per mezzo la quale è possibile descrivere il significato dei componenti dell’applicazione. L’insieme delle descrizioni è poi raggruppato nel Semantics Tree che è effettivamente ciò che lo Screen Reader “attraversa”.
Vediamo alcuni dei suoi parametri:
label: String: descrive il widget / il suo stato / ciò che accade al click;
(es. IconButton con la matita descritto come “Modifica elemento”)liveRegion: bool: notifica il Reader quando questo widget cambia stato;
(es. contatore che viene incrementato in seguito ad un azione dell’utente)enabled: bool: dichiara se il widget è abilitato o meno;
(es. bottone conferma di un form non valido)toggled: bool: dichiara se un widget attivabile/disattivabile è attivo;
(es. radio button)selected: bool: simile a toggled;
(es. checkbox)button: bool: dichiara che il widget è cliccabile
(es. bottone custom che non fa uso delle classi preesistenti);role: SemanticsRole: descrive il ruolo dell’elemento UI.
(es. tab, dialog, menu, status…).
Esistono poi altri widget a scopo semantico, tra cui:
ExcludeSemantics: elementi ignorabili e non necessari alla comprensione della schermata dell’applicazione;
(es. immagine di sfondo)MergeSemantics: più elementi uniti in un’unica descrizione semantica in quanto profondamente correlati;
(es. label e description in una lista di dati)BlockSemantics: per ignorare gli elementi che seguono questo widget nello stesso contenitore semantico.
(es. una colonna)
Utilizzo del Colore
Un’informazione non può essere unicamente conferita per mezzo del colore di un elemento UI. Impostare i colori del dispositivo di test in modalità greyscale e assicurarsi che nessuna informazione venga persa.
Un caso classico è quello di utilizzare i colori rosso/verde per simboleggiare qualcosa di corretto/sbagliato, questa scelta stilistica aiuta certamente chi non ha problemi di distinzione dei colori ad utilizzare l’applicazione con più facilità, tuttavia non può essere l’unico indicatore di stato del widget in questione, ad esempio può essere utile inserire un’icona (con label semantica coerente per gli Screen Reader).
Aree cliccabili
Le aree cliccabili devono avere una dimensione che permette a qualsiasi utente di interagire con facilità, inoltre va visivamente mostrato che l’interazione con esse è possibile. Analizzando la schermata con Android Accessibility Scanner verranno flaggati tutti gli elementi interattivi con dimensioni insufficienti. La dimensione richiesta dalle WCAG 2.1 affinché un elemento interattivo venga considerato accessibile è di almeno 48px x 48px.
