L’abilismo è un sistema di discriminazione e svalutazione che opera su più livelli: individuale, sociale e strutturale. Questo permea il modo in cui vengono progettati spazi, servizi e tecnologie, assumendo come norma un corpo e una mente funzionanti secondo standard arbitrari.

Nel contesto digitale, l’abilismo si manifesta quando interfacce e servizi vengono progettati escludendo a priori le esigenze delle persone con disabilità, trattando l’accessibilità come un’aggiunta opzionale anziché come un requisito progettuale.

La Convenzione ONU sui diritti delle persone con disabilità (2006) riconosce che la disabilità nasce dall’interazione tra limitazioni funzionali e barriere ambientali. Questo sposta la responsabilità dall’individuo alla società e ai sistemi che creano ostacoli, inclusi quelli digitali.

L’accessibilità digitale garantisce che siti web, applicazioni mobili, documenti e software possano essere percepiti, compresi, navigati e utilizzati da tutte le persone, incluse quelle con disabilità.

Il quadro normativo europeo e italiano definisce obblighi specifici per la Pubblica Amministrazione e per i soggetti privati che offrono servizi al pubblico. In particolare, la conformità viene valutata rispetto a standard tecnici come le WCAG 2.1 livello AA e la norma UNI CEI EN 301549.

L’accessibilità non si esaurisce però nella sola conformità formale. Richiede test con utenti reali, l’uso di tecnologie assistive e una comprensione concreta di come persone con diverse disabilità interagiscono con le interfacce digitali nella pratica.

L’accessibilità by design, o accessibility by design, è un approccio metodologico che integra i requisiti di accessibilità fin dalle prime fasi del processo di progettazione e sviluppo. In questo modo l’accessibilità viene considerata un requisito funzionale nativo e non un intervento correttivo successivo.

Analisi, wireframe, mockup, prototipazione, sviluppo e testing includono i criteri WCAG 2.1 e la norma EN 301 549 come parte integrante del progetto. Questo approccio permette di ridurre in modo significativo i costi nel tempo. Correggere barriere su un prodotto già pubblicato comporta, infatti, costi mediamente più elevati rispetto a una progettazione accessibile fin dall’inizio.

L’accessibilità by design comprende attività come il coinvolgimento di persone con disabilità nella user research, la creazione di design system con componenti accessibili nativi, test automatici nei flussi CI/CD e la formazione dei team su WCAG e tecnologie assistive.

Questo approccio è coerente con metodologie Agile e DevOps, dove l’accessibilità entra a far parte della Definition of Done. Le linee guida AgID e la normativa europea riconoscono l’efficacia di processi strutturati e continuativi, evidenziando i limiti di interventi correttivi tardivi. L’accessibilità diventa così una componente stabile della qualità progettuale.

L’accessibilità cognitiva riguarda la rimozione di barriere che rendono difficile la comprensione e l’utilizzo di contenuti digitali a persone con disabilità cognitive, disturbi dell’apprendimento o neurodivergenze.

Include l’uso di un linguaggio semplice e diretto, strutture informative prevedibili, riduzione del carico cognitivo, istruzioni chiare, limitazione degli elementi di distrazione e possibilità di mettere in pausa o controllare i contenuti dinamici.

Le WCAG 2.1 affrontano questi aspetti in particolare attraverso il principio della Comprensibilità, ma l’accessibilità cognitiva richiede un’attenzione trasversale. Coinvolge design coerente, icone comprensibili, alternative testuali adeguate e un supporto efficace alla navigazione.

È fondamentale per persone con dislessia, discalculia, ADHD, disturbi dello spettro autistico o della memoria e migliora l’esperienza complessiva per tutti gli utenti.

AgID, Agenzia per l’Italia Digitale, ha il compito di definire, aggiornare e verificare il rispetto delle linee guida tecniche e dei modelli per l’accessibilità degli strumenti informatici. Opera come riferimento istituzionale per la Pubblica Amministrazione e per i soggetti privati obbligati.

In base alla Legge 4/2004, al D.Lgs. 106/2018 e al D.Lgs. 82/2022, AgID emana le linee guida applicative, fornisce il modello ufficiale di dichiarazione di accessibilità, coordina il monitoraggio periodico e gestisce il database delle dichiarazioni pubblicate.

Le linee guida AgID definiscono i criteri di conformità basati sulla norma UNI CEI EN 301 549 e sulle WCAG 2.1 livello AA. Specificano inoltre le metodologie di verifica, i requisiti per documenti non web e software e le procedure di rimediazione delle non conformità.

AgID opera nell’ambito del Codice dell’Amministrazione Digitale e in attuazione delle direttive europee WAD ed EAA.

WAI-ARIA (Accessible Rich Internet Applications) è una specifica tecnica del W3C che fornisce attributi aggiuntivi per rendere accessibili componenti dinamici e interfacce complesse quando l’HTML semantico nativo non è sufficiente.

ARIA definisce ruoli, proprietà e stati che comunicano alle tecnologie assistive la funzione e lo stato degli elementi interattivi, ad esempio tramite attributi come role, aria-expanded o aria-pressed. Questi attributi non modificano il comportamento nativo del browser, ma aggiungono informazioni semantiche fondamentali per l’accessibilità.

Gli attributi ARIA sono utilizzati in particolare per widget personalizzati come tab, accordion, dialog e carousel, per applicazioni single-page e per la gestione di contenuti dinamici. ARIA è richiamato nella norma UNI CEI EN 301 549 e nelle linee guida AgID come parte integrante della conformità alle WCAG 2.1.

L’attributo aria-label fornisce un’etichetta testuale non visibile, letta dalle tecnologie assistive, utilizzata quando un controllo interattivo non ha un testo visibile associato. È tipicamente impiegato per pulsanti composti solo da icone, controlli grafici o elementi interattivi personalizzati.

Esempi comuni includono pulsanti di chiusura, controlli di condivisione social o campi di ricerca che presentano solo un placeholder. In questi casi è fondamentale garantire coerenza tra il testo visibile e l’etichetta accessibile ed evitare duplicazioni inutili.

Il criterio WCAG 2.5.3 richiede che l’etichetta accessibile includa il testo visibile quando presente. Un uso scorretto di aria-label può creare incongruenze e problemi di usabilità per chi utilizza screen reader.

Le aria-live regions permettono di comunicare agli screen reader contenuti che cambiano dinamicamente senza spostare il focus dell’utente. Sono utilizzate per rendere accessibili aggiornamenti automatici dell’interfaccia.

L’attributo aria-live prevede tre livelli di priorità: “off” (nessun annuncio), “polite” (annuncia al termine della lettura corrente, usato per aggiornamenti non urgenti), “assertive” (interrompe e annuncia immediatamente, riservato ad alert critici).

Le live region possono essere associate a ruoli specifici come alert, status, log o timer sono fondamentali in applicazioni dinamiche, moduli con validazione in tempo reale, notifiche di sistema, messaggi di conferma o di errore, chat e contenuti che si aggiornano automaticamente.

Una corretta implementazione richiede sempre test con screen reader reali poiché il comportamento può variare tra JAWS, NVDA e VoiceOver.

Le ATAG, Authoring Tool Accessibility Guidelines, si rivolgono ai produttori di strumenti di authoring come CMS, editor visuali, piattaforme di pubblicazione e strumenti di sviluppo.

Le linee guida hanno due obiettivi principali: la Parte A riguarda l’accessibilità dell’interfaccia dello strumento, affinché anche autori con disabilità possano utilizzarlo, la Parte B riguarda il supporto alla creazione di contenuti accessibili, aiutando gli autori a evitare errori e a rispettare i requisiti WCAG.

Uno strumento conforme alle ATAG fornisce funzionalità come suggerimenti contestuali, controlli automatici, template accessibili, documentazione dedicata e supporto alla gestione dei metadati di accessibilità.

CMS, piattaforme di e-learning e strumenti no-code svolgono un ruolo chiave nel determinare la qualità dell’accessibilità dei contenuti pubblicati. L’adozione delle ATAG, seppur meno diffusa rispetto alle WCAG, è in crescita e riflette una maggiore consapevolezza del fatto che l’accessibilità debba essere integrata fin dalla fase di creazione dei contenuti.

Un audit di accessibilità è un’attività di verifica strutturata che combina più livelli di analisi. I test automatizzati, tramite strumenti come axe-core, Lighthouse o WAVE, consentono di individuare una parte delle non conformità ma coprono solo una percentuale limitata dei requisiti di accessibilità.

A questi si affiancano i test manuali basati sulle WCAG, necessari per valutare criteri non automatizzabili come l’ordine di lettura, la semantica, la qualità dei testi alternativi o la coerenza delle interazioni. Un audit completo include anche test con tecnologie assistive reali, come screen reader e navigazione da tastiera per verificare l’esperienza d’uso concreta.

Il risultato dell’audit è un report dettagliato che documenta le non conformità riscontrate, ne indica la gravità, fornisce riferimenti alle WCAG e alla norma UNI CEI EN 301 549. Propone inoltre indicazioni operative di remediation e l’analisi viene condotta su un campione rappresentativo di template, contenuti e user journey critici.

L’audit di accessibilità non va confuso con semplici scan automatici che non sono sufficienti a valutare la conformità né l’effettiva fruibilità di un servizio digitale.

Il Braille è un sistema di lettura e scrittura tattile basato su combinazioni di punti in rilievo, ideato da Louis Braille nel XIX secolo. Le celle braille, composte da sei punti disposti su due colonne, rappresentano lettere, numeri, segni di punteggiatura e simboli.

In ambito digitale, il Braille è utilizzato tramite display braille rinfrescabili, dispositivi che trasformano il testo visualizzato a schermo in caratteri braille grazie a pin meccanici che si aggiornano dinamicamente. Questo consente un accesso tattile a siti web, documenti e applicazioni.

L’output braille rappresenta un’alternativa o un complemento all’output vocale degli screen reader ed è particolarmente rilevante per persone sordocieche o per utenti che necessitano di un’elevata precisione nella lettura, ad esempio in ambito professionale o tecnico. La norma UNI CEI EN 301 549 include requisiti specifici per il supporto alle tecnologie braille.

Il criterio WCAG 2.4.1 livello A richiede meccanismi per bypassare blocchi di contenuto ripetuti in più pagine. L’implementazione più comune è lo skip link: un link visibile al focus posizionato come primo elemento tabulabile che porta direttamente al main content.

Alternativa o complementare è l’ uso di landmark ARIA e HTML5 semantici (header, nav, main, aside, footer) che permettono agli screen reader di saltare rapidamente tra sezioni.

Gli skip link devono essere sempre accessibili da tastiera, visibili al focus (non solo visibili all’hover), con label chiaro (“Vai al contenuto principale”). Sono utili non solo per screen reader ma anche per utenti che navigano interamente da tastiera.

Il Codice dell’Amministrazione Digitale (CAD) è il quadro normativo che disciplina la trasformazione digitale della Pubblica Amministrazione italiana. Definisce i diritti di cittadinanza digitale e stabilisce le regole per l’erogazione dei servizi digitali, la gestione dei documenti informatici, le firme elettroniche, la conservazione digitale e le comunicazioni ufficiali.

Il CAD integra e richiama la Legge 4/2004 sull’accessibilità come requisito trasversale dei servizi digitali pubblici, affermando il diritto di cittadini e imprese a utilizzare strumenti informatici fruibili e accessibili.

L’articolo 17 del CAD istituisce la figura del Responsabile per la Transizione Digitale (RTD), presente in ogni amministrazione, con il compito di coordinare i processi di digitalizzazione, inclusi gli adempimenti in materia di accessibilità.

Nel tempo il CAD è stato aggiornato per recepire direttive europee e adeguarsi all’evoluzione tecnologica. Il mancato rispetto delle sue disposizioni può comportare responsabilità amministrative e dirigenziali. Le linee guida AgID ne attuano i principi operativi, anche in ambito di accessibilità digitale.

Il carico cognitivo è la quantità di risorse mentali richieste a una persona per comprendere le informazioni e completare un compito. In ambito UX si distinguono tre componenti principali: il carico intrinseco legato alla complessità del compito, il carico estrinseco, legato al modo in cui le informazioni sono presentate e il carico pertinente, legato ai processi di apprendimento.

Nel design digitale, la riduzione del carico estrinseco è particolarmente rilevante poiché migliora l’accessibilità per persone con disabilità cognitive, ADHD, dislessia o età avanzata e beneficia anche utenti in condizioni di stress, stanchezza o distrazione.

Strategie comuni includono la limitazione delle scelte simultanee, una struttura visiva chiara, l’uso di un linguaggio semplice, la suddivisione delle informazioni in blocchi, la progressiva rivelazione dei contenuti, feedback immediati e pattern di interazione familiari.

Le WCAG affrontano questi aspetti in modo indiretto attraverso il principio della Comprensibilità e i criteri relativi alla leggibilità dei contenuti e all’assistenza nella compilazione degli input.

Il principio della comprensibilità è uno dei quattro principi fondamentali delle WCAG, noto come Understandable all’interno del modello POUR (Perceivable, Operable, Understandable, Robust).

La comprensibilità riguarda sia i contenuti sia il comportamento dell’interfaccia. Le WCAG richiedono che il linguaggio sia chiaro e leggibile, che le pagine si comportino in modo prevedibile e che gli utenti siano supportati nell’evitare e correggere gli errori. Questo include istruzioni esplicite, etichette comprensibili, feedback chiari e cambiamenti di contesto solo su azione intenzionale dell’utente.

Comprendere non significa solo leggere un testo, ma essere in grado di orientarsi, completare un’azione, interpretare correttamente messaggi di stato ed errori. Un’interfaccia può essere tecnicamente conforme ma risultare comunque incomprensibile se sovraccarica, ambigua o imprevedibile.

Il principio MUST ha un impatto diretto sull’accessibilità cognitiva e riguarda in particolare persone con dislessia, ADHD, disturbi dell’apprendimento, utenti non madrelingua, anziani e persone in condizioni di stress. Garantire la comprensibilità significa rendere l’esperienza digitale realmente utilizzabile, non solo formalmente accessibile.

Le WCAG 2.1 definiscono i criteri di successo organizzati in tre livelli di conformità crescenti.

Il livello A rappresenta i requisiti minimi di accessibilità e comprende i criteri di base.
Il livello AA include tutti i criteri del livello A e requisiti aggiuntivi considerati lo standard di riferimento.
Il livello AAA rappresenta il livello più avanzato e include criteri ulteriori che, in molti casi, risultano difficili o non applicabili a tutti i contenuti e contesti.

La normativa europea e italiana, attraverso la norma EN 301 549, richiede la conformità alle WCAG 2.1 livello AA. La valutazione della conformità viene effettuata su un campione rappresentativo di pagine o funzionalità e deve indicare il livello raggiunto, la versione delle WCAG, la data della valutazione e la metodologia adottata.

Non esiste una conformità parziale ufficiale. Tuttavia, la dichiarazione di accessibilità può documentare eccezioni motivate come contenuti di terze parti, materiali storici non modificabili o casi di onere sproporzionato.

Il contrasto colore indica il rapporto di luminosità tra il contenuto in primo piano, come testo o componenti dell’interfaccia, e lo sfondo. Viene espresso come rapporto numerico, ad esempio 4.5:1.

Le WCAG definiscono valori minimi di contrasto per garantire la leggibilità. Il criterio 1.4.3, livello AA, richiede un contrasto minimo di 4.5:1 per il testo normale e di 3:1 per il testo grande. Il livello AAA innalza questi requisiti a 7:1 e 4.5:1. Il criterio 1.4.11, livello AA, stabilisce inoltre un contrasto minimo di 3:1 per componenti dell’interfaccia e grafica informativa.

Un contrasto insufficiente può rendere i contenuti difficili o impossibili da leggere per persone con ipovisione, cataratta o daltonismo, ma anche in condizioni di luce ambientale sfavorevoli o su dispositivi con schermi di bassa qualità.

Il contrasto può essere verificato tramite strumenti dedicati come WebAIM Contrast Checker, Colour Contrast Analyser, Stark o axe DevTools. È importante ricordare che il contrasto non riguarda solo il colore, ma soprattutto la differenza di luminanza. Un contrasto eccessivo, come in alcune modalità ad alto contrasto, può a sua volta affaticare alcuni utenti.

Le WCAG definiscono valori minimi di contrasto cromatico per garantire la leggibilità dei contenuti.

Al livello AA, il criterio 1.4.3 richiede un contrasto minimo di 4.5:1 per il testo normale e di 3:1 per il testo grande. Il criterio 1.4.11 stabilisce inoltre un rapporto minimo di 3:1 per i componenti dell’interfaccia e per la grafica informativa significativa.

Al livello AAA, il criterio 1.4.6 innalza i requisiti a 7:1 per il testo normale e 4.5:1 per il testo grande.

Il calcolo del contrasto si basa sulla luminanza relativa dei colori secondo la formula definita dalle WCAG e non sulla percezione soggettiva. Alcuni elementi sono esclusi dai requisiti, come testo puramente decorativo, loghi e contenuti non essenziali.

Fattori come font, peso del carattere e antialiasing possono influenzare la leggibilità percepita, pur non modificando il calcolo formale del contrasto. I requisiti di contrasto sono tra i più frequentemente violati e, allo stesso tempo, tra i più facilmente verificabili tramite strumenti automatici. Sono fondamentali per persone con ipovisione, utenti anziani e in condizioni di luce ambientale sfavorevole.

Il D.Lgs. 106/2018 recepisce in Italia la Direttiva UE 2016/2102, nota come Web Accessibility Directive (WAD), e disciplina l’accessibilità dei siti web e delle applicazioni mobili della Pubblica Amministrazione.

Il decreto aggiorna e integra la Legge 4/2004, introducendo obblighi operativi come il riferimento agli standard tecnici UNI CEI EN 301 549 e alle WCAG 2.1 livello AA, la pubblicazione della dichiarazione di accessibilità secondo il modello AgID, il monitoraggio periodico e la presenza di meccanismi di feedback per gli utenti.

Prevede inoltre una procedura di applicazione gestita da AgID in caso di mancata risposta o di inadempienza, con possibili conseguenze in termini di responsabilità amministrativa e dirigenziale.

Alcune tipologie di contenuti possono essere escluse dagli obblighi, come materiali pubblicati prima del 23 settembre 2018 non soggetti a revisione, documenti di ufficio storici, contenuti di terze parti non controllati, mappe e media temporali in diretta, nei limiti previsti dalla normativa.

Il D.Lgs. 106/2018 si applica al settore pubblico e si coordina con il D.Lgs. 82/2022, che attua l’European Accessibility Act e disciplina gli obblighi di accessibilità per prodotti e servizi del settore privato.

Il D.Lgs. 82/2022 attua in Italia la Direttiva UE 2019/882, nota come European Accessibility Act (EAA), estendendo gli obblighi di accessibilità a specifiche categorie di prodotti e servizi offerti ai consumatori da soggetti privati.

Il decreto si applica a servizi B2C come il commercio elettronico, i servizi bancari e finanziari, i trasporti, gli e-book e i servizi di comunicazione elettronica, oltre a determinati prodotti hardware e software, tra cui computer, smartphone, tablet, terminali self-service e sistemi operativi.

Sono escluse dall’obbligo le microimprese con meno di 10 dipendenti o con fatturato o bilancio annuo non superiore a 2 milioni di euro, nei limiti previsti dalla normativa.

Il riferimento tecnico per la conformità è la norma UNI CEI EN 301 549. L’applicazione degli obblighi è graduale, con piena efficacia a partire dal 28 giugno 2025 per i nuovi prodotti e servizi immessi sul mercato.

Il decreto prevede un regime sanzionatorio amministrativo che può arrivare fino a 40.000 euro in caso di violazioni, in funzione della gravità e della reiterazione dell’inadempienza.

Il D.Lgs. 82/2022 allinea l’Italia al quadro normativo europeo, contribuendo alla creazione di un mercato unico più inclusivo e accessibile.

Il daltonismo, o color blindness, è una condizione che comporta difficoltà nella distinzione di alcuni colori. Colpisce circa l’8% della popolazione maschile e una percentuale minore di quella femminile.

Le forme più comuni includono la protanopia, legata alla percezione del rosso, la deuteranopia, legata al verde, e la tritanopia, più rara, che coinvolge la distinzione tra blu e giallo. Esiste anche l’acromatopsia, una condizione molto rara caratterizzata dall’assenza quasi totale della percezione dei colori.

Le WCAG affrontano il tema attraverso il criterio 1.4.1, livello A che richiede che il colore non sia l’unico mezzo per trasmettere informazioni, indicare azioni o distinguere elementi dell’interfaccia.

Per rispettare questo principio, le informazioni veicolate tramite colore devono essere sempre accompagnate da alternative come testo, icone, pattern, etichette o variazioni di forma. Ad esempio, i grafici dovrebbero utilizzare pattern oltre ai colori, gli errori nei form devono essere segnalati anche con messaggi testuali o icone, non solo con bordi rossi.

Esistono strumenti che permettono di simulare le diverse forme di daltonismo, come Color Oracle, Sim Daltonism o filtri del browser, utili in fase di progettazione e verifica. I criteri sul contrasto cromatico, come 1.4.3 e 1.4.11, contribuiscono ulteriormente a migliorare la leggibilità, ma non sostituiscono il principio di non basarsi esclusivamente sul colore.

La descrizione audio, o audiodescrizione (Audio Description), fornisce una narrazione vocale degli elementi visivi significativi che non emergono dall’audio originale di un contenuto video, come azioni, ambientazione, espressioni facciali, testi a schermo e cambi di scena.

L’audiodescrizione viene inserita, quando possibile, nelle pause naturali del dialogo per non sovrapporsi ai contenuti sonori principali. Le WCAG affrontano questo requisito nei criteri relativi ai media temporali: il criterio 1.2.3, livello A, richiede la presenza di un’audiodescrizione o di un’alternativa testuale completa per i video preregistrati, mentre il criterio 1.2.5, livello AA, richiede l’audiodescrizione integrata.

L’audiodescrizione standard utilizza le pause del parlato, mentre l’audiodescrizione estesa prevede la messa in pausa del video per consentire descrizioni più dettagliate quando le pause non sono sufficienti.

L’audiodescrizione è fondamentale per permettere a persone cieche o ipovedenti di comprendere pienamente contenuti video, film, tutorial e materiali informativi. La sua realizzazione richiede competenze specifiche di scrittura, sintesi e produzione audio ed è un ambito in crescita con l’aumento dei contenuti video e degli obblighi normativi in materia di accessibilità.

Il design responsivo, o responsive design, è un approccio progettuale che utilizza griglie fluide, media queries e immagini flessibili per adattare layout e contenuti a dispositivi e dimensioni di schermo differenti.

Tra le tecniche più comuni rientrano l’approccio mobile-first, la definizione di breakpoint strategici, l’uso di unità di misura relative, il corretto utilizzo del viewport meta tag, font scalabili e immagini responsive.

Dal punto di vista dell’accessibilità, il responsive design supporta la fruizione su dispositivi mobili, facilita il ridimensionamento del testo e il reflow dei contenuti, e riduce la necessità di scroll orizzontale. Tuttavia, un’interfaccia responsiva non è automaticamente accessibile: possono persistere problemi legati all’ordine del focus, al contrasto cromatico o alla dimensione dei target interattivi.

Il responsive design si intreccia con diversi criteri WCAG, tra cui quelli relativi all’orientamento dello schermo, al ridimensionamento del testo, al reflow e alla dimensione dei target di interazione. La verifica deve essere effettuata su dispositivi reali ed emulatori, testando orientamenti diversi, livelli di zoom e l’uso di screen reader mobili.

Il design universale, o universal design, è un paradigma progettuale che considera la diversità delle persone fin dalle prime fasi di progettazione, evitando soluzioni correttive o adattamenti successivi. L’obiettivo è creare prodotti e servizi utilizzabili dal maggior numero possibile di persone, indipendentemente da abilità, età o condizioni d’uso.

Il concetto si basa sui sette principi formulati da Ronald Mace, tra cui l’uso equo, la flessibilità, la semplicità e intuitività, la percepibilità delle informazioni, la tolleranza all’errore e l’adeguatezza di dimensioni e spazi per l’accesso e l’utilizzo.

Nel contesto digitale, il design universale si traduce in interfacce comprensibili, utilizzabili con modalità diverse, navigabili tramite differenti tecnologie e capaci di ridurre gli errori e le difficoltà operative.

I benefici non riguardano solo le persone con disabilità, ma anche utenti anziani, persone con limitazioni temporanee, chi utilizza dispositivi diversi o opera in contesti ambientali sfavorevoli.

Il design universale si distingue da un approccio puramente reattivo all’accessibilità perché interviene a monte, eliminando le barriere progettuali prima che si manifestino. È riconosciuto come principio di riferimento anche nella Convenzione ONU sui diritti delle persone con disabilità.

La dichiarazione di accessibilità è un documento pubblico obbligatorio che descrive lo stato di conformità di un sito web o di un’applicazione mobile ai requisiti di accessibilità. È prevista per la Pubblica Amministrazione dal D.Lgs. 106/2018 e, a partire dal 28 giugno 2025, anche per i soggetti privati obbligati ai sensi del D.Lgs. 82/2022.

La dichiarazione deve indicare il soggetto erogatore del servizio, lo stato di conformità (conforme, parzialmente conforme o non conforme), l’elenco dei contenuti non accessibili con le relative motivazioni, la data e il metodo della valutazione, un meccanismo di feedback accessibile e la procedura di applicazione gestita da AgID.

Deve essere pubblicata in formato accessibile, facilmente reperibile e aggiornata almeno una volta all’anno o in occasione di modifiche rilevanti del sito o dell’applicazione. AgID mette a disposizione un modello standardizzato per la sua compilazione.

La dichiarazione di accessibilità rappresenta anche uno strumento di tutela per l’organizzazione, in quanto documenta lo stato dell’accessibilità e le azioni intraprese. Tuttavia, la sua efficacia è legata all’esistenza di una valutazione tecnica reale e documentabile.

La dislessia è un disturbo specifico dell’apprendimento che interessa la lettura e colpisce una quota significativa della popolazione, con diversi livelli di intensità. In ambito digitale può manifestarsi con difficoltà nella decodifica di testi densi, nella distinzione tra caratteri simili, nel mantenimento del punto di lettura o nella lettura fluida e continuativa.

Un design attento alla dislessia adotta strategie che migliorano la leggibilità complessiva dei contenuti, come l’uso di font ad alta leggibilità, una spaziatura adeguata tra righe, parole e caratteri, l’evitare il testo giustificato, la suddivisione dei contenuti in paragrafi brevi e una gerarchia visiva chiara. È importante anche garantire un buon contrasto cromatico, senza ricorrere a soluzioni eccessivamente affaticanti.

Le WCAG affrontano alcuni di questi aspetti nel criterio 1.4.8 (Presentazione visiva), di livello AAA, che introduce raccomandazioni avanzate sulla personalizzazione del testo. Al di là dei requisiti formali, è cruciale offrire all’utente il controllo su dimensioni del testo, font e spaziatura.

Molte persone con dislessia utilizzano inoltre strumenti di text-to-speech come supporto alla lettura. Le scelte di design orientate alla dislessia non migliorano solo l’accessibilità per utenti con DSA, ma aumentano la leggibilità e la qualità dell’esperienza per tutti.

L’EAA, European Accessibility Act, è la Direttiva UE 2019/882 che rappresenta la più ampia estensione degli obblighi di accessibilità a livello europeo, introducendo requisiti vincolanti anche per il settore privato, oltre a quello pubblico.

La direttiva si applica a specifiche categorie di prodotti e servizi offerti ai consumatori, tra cui computer e sistemi operativi, terminali self-service come ATM, chioschi e sistemi di check-in, servizi bancari e finanziari, e-book, servizi di commercio elettronico, trasporti, comunicazioni elettroniche e servizi di emergenza.

I requisiti di accessibilità sono definiti a livello funzionale e attuati attraverso standard tecnici armonizzati, in particolare la norma UNI CEI EN 301 549 e si ispirano ai principi del design universale.

Gli Stati membri sono tenuti a recepire l’EAA tramite normative nazionali e a definire i relativi regimi di controllo e sanzione. In Italia, l’attuazione avviene attraverso il D.Lgs. 82/2022.

L’EAA completa il quadro normativo europeo insieme alla Web Accessibility Directive, contribuendo alla costruzione di un mercato unico più inclusivo e accessibile.

La EN 301 549 è lo standard tecnico europeo di riferimento per l’accessibilità delle tecnologie dell’informazione e della comunicazione (ICT). È richiamata dalla Web Accessibility Directive, dall’European Accessibility Act e dalla normativa italiana di recepimento, tra cui il D.Lgs. 106/2018 e il D.Lgs. 82/2022.

Lo standard definisce requisiti di accessibilità e metodi di verifica per un’ampia gamma di prodotti e servizi digitali. Include, tra gli altri, i requisiti per i contenuti web, allineati alle WCAG 2.1 livello AA, per i documenti non web, per il software e le applicazioni mobili, per l’hardware, per il supporto alle tecnologie assistive e per i terminali self-service e i servizi di comunicazione.

La EN 301 549 fornisce criteri tecnici puntuali e verificabili, utilizzabili sia in fase di progettazione sia in fase di test e valutazione. In quanto norma armonizzata a livello europeo, la sua applicazione consente di presumere la conformità ai requisiti di accessibilità previsti dalle direttive europee pertinenti.

Lo standard viene aggiornato periodicamente per recepire l’evoluzione tecnologica e l’aggiornamento delle WCAG

Le etichette dei campi, o form labels, sono testi visibili che descrivono lo scopo di un campo di input e che devono essere associate in modo programmatico al relativo controllo. Le WCAG richiedono che ogni campo abbia un’etichetta chiara e accessibile, come previsto da diversi criteri relativi alla struttura, alla navigazione e all’assistenza nella compilazione dei form.

L’associazione corretta può essere realizzata collegando l’elemento <label> all’input tramite l’attributo for, includendo l’input all’interno della label oppure utilizzando aria-labelledby nei casi più complessi. Quando sono necessarie istruzioni o informazioni aggiuntive, è possibile affiancare aria-describedby.

L’etichetta deve essere sempre visibile, persistente e descrittiva.

Tra gli errori più comuni rientrano l’uso del placeholder come unica indicazione, etichette troppo generiche o la presenza di label solo visive, non collegate programmaticamente al campo. In questi casi, gli screen reader non riescono a comunicare correttamente lo scopo dell’input quando il focus viene spostato sul campo, compromettendo la compilazione del form.

Il feedback tattile, o haptic feedback, è una risposta fisica dell’interfaccia, come una vibrazione o un impulso, che segnala all’utente l’avvenuta interazione con un elemento touch. Viene utilizzato per confermare azioni come pressioni, trascinamenti, errori o notifiche.

Per le persone cieche o ipovedenti, il feedback tattile rappresenta un importante supporto, poiché conferma che un’azione è stata registrata anche in assenza di riscontri visivi. I principali sistemi operativi mobili, come iOS e Android, integrano il feedback aptico all’interno delle tecnologie assistive, ad esempio tramite VoiceOver e TalkBack.

Nella progettazione di siti e applicazioni, l’uso del feedback tattile deve essere calibrato con attenzione. Le API di vibrazione vanno utilizzate in modo non invasivo, prevedendo la possibilità di disattivazione e senza affidare all’aptico comunicazioni critiche. Le informazioni devono essere sempre fornite anche tramite altri canali, come feedback visivo o sonoro.

Il feedback tattile può risultare fastidioso o problematico per alcune persone, ad esempio in presenza di tremori, e ha limiti legati al consumo energetico e alla compatibilità dei dispositivi. Le WCAG non trattano esplicitamente l’aptica, ma il principio di ridondanza delle informazioni e della multimodalità si applica anche a questo ambito. Il feedback tattile è quindi un supporto complementare, non sostitutivo, agli altri tipi di feedback.

Un form accessibile prevede che ogni campo sia dotato di un’etichetta associata programmaticamente, che istruzioni e requisiti siano comunicati prima dell’inserimento dei dati e che eventuali errori vengano identificati in modo chiaro e comprensibile, con indicazioni utili per la correzione. I campi correlati devono essere raggruppati logicamente e l’intero form deve essere utilizzabile da tastiera, senza trappole di focus.

Dal punto di vista implementativo, è fondamentale che le label siano visibili e persistenti, che il placeholder non venga usato come sostituto dell’etichetta, che l’ordine di navigazione segua una logica coerente e che la validazione fornisca feedback accessibili, anche tramite messaggi di stato annunciati alle tecnologie assistive.

Form non accessibili generano frustrazione, abbandono e perdita di conversioni, oltre a escludere utenti con disabilità. Progettare form accessibili significa migliorare l’esperienza per tutti e ridurre attriti lungo i percorsi più importanti del sito o dell’applicazione.

La gestione del focus riguarda il modo in cui il cursore di tastiera si sposta tra gli elementi interattivi di una pagina. È un aspetto centrale dell’accessibilità perché consente alle persone che navigano senza mouse di orientarsi e interagire con l’interfaccia in modo prevedibile.

Le WCAG richiedono che l’ordine di tabulazione sia logico, che il focus sia sempre visibile e che non esistano trappole che impediscano di uscire da un componente. Questi requisiti diventano particolarmente critici nelle interfacce dinamiche.

Componenti come finestre modali, menu a discesa, tab e pannelli interattivi devono gestire il focus in modo esplicito, assicurando che l’utente sappia sempre dove si trova e possa entrare e uscire dai contenuti senza difficoltà.

Una gestione scorretta del focus può causare perdita di orientamento, blocchi nella navigazione e impossibilità di completare azioni fondamentali. Per questo è uno degli aspetti più complessi da implementare, ma anche tra i più importanti per garantire una buona esperienza da tastiera.

Google Tag Manager (GTM) è uno strumento che consente di gestire script di tracciamento, analytics e componenti di terze parti tramite un’interfaccia web, senza intervenire direttamente sul codice sorgente del sito.

In ambito accessibilità, GTM viene spesso utilizzato per distribuire widget o overlay di accessibilità. Questo approccio presenta però diversi limiti: gli script iniettati dopo il caricamento della pagina possono non essere pienamente compatibili con le tecnologie assistive, possono interferire con il comportamento nativo dell’interfaccia e introdurre complessità o problemi di performance.

È importante sottolineare che l’aggiunta o la rimozione di script tramite GTM non risolve le barriere di accessibilità presenti nel codice sorgente. Le correzioni strutturali devono essere integrate direttamente nell’HTML, nel CSS e nel JavaScript dell’applicazione.

GTM può essere uno strumento utile per attività di monitoraggio, sperimentazione o test di miglioramenti incrementali, ma non può sostituire un approccio di progettazione e sviluppo accessibile.

L’HTML semantico consiste nell’utilizzo degli elementi HTML in base al loro significato e alla loro funzione, non solo all’aspetto visivo. Usare il tag corretto permette di descrivere in modo esplicito la struttura e il ruolo dei contenuti all’interno di una pagina.

Elementi come header, nav, main, article, section e footer definiscono la struttura del documento, mentre titoli, link, pulsanti, liste e tabelle comunicano alle tecnologie assistive come i contenuti devono essere interpretati e utilizzati.

Le WCAG richiedono un markup semantico e valido perché consente agli screen reader, ai browser e ad altri strumenti di interpretare correttamente l’interfaccia. L’uso di elementi nativi offre inoltre comportamenti accessibili predefiniti, come la navigazione da tastiera e l’attivazione corretta dei controlli.

Un HTML semantico migliora l’accessibilità, la robustezza nel tempo e la manutenibilità del codice, oltre ad avere benefici indiretti anche sul SEO. Per questo motivo, la prima regola dell’accessibilità tecnica è utilizzare sempre HTML nativo quando disponibile, ricorrendo ad ARIA solo quando necessario.

Le immagini decorative sono elementi visivi che hanno una funzione esclusivamente estetica e non trasmettono informazioni necessarie per comprendere il contenuto o completare un’azione. Rientrano in questa categoria, ad esempio, sfondi grafici, pattern, separatori visivi o icone che duplicano un testo già presente.

Le WCAG richiedono che le immagini decorative vengano ignorate dalle tecnologie assistive. Nel caso di immagini inserite con l’elemento img o svg, questo si ottiene utilizzando un testo alternativo vuoto (alt=""), evitando che gli screen reader le annuncino. Le immagini usate tramite CSS come background sono invece già trasparenti alle tecnologie assistive.

Un errore comune è omettere l’attributo alt o inserire descrizioni inutili, che appesantiscono la navigazione e distraggono l’utente. È fondamentale valutare sempre il contesto: un’icona può essere decorativa se accompagnata da un testo esplicativo, ma diventa informativa se rappresenta da sola un’azione o un contenuto.

L’indipendenza dal dispositivo indica la capacità di un’interfaccia di essere utilizzata con diversi metodi di input, senza dipendere esclusivamente da mouse o touch. Ogni funzione deve poter essere attivata tramite modalità alternative, come tastiera, comandi vocali o tecnologie assistive.

Le WCAG richiedono che le interazioni siano accessibili da tastiera e introducono criteri specifici per le interfacce touch, come l’uso di gesti semplici, target di dimensioni adeguate e l’assenza di dipendenza da movimenti del dispositivo, ad esempio scuotimento o inclinazione, senza alternative.

Un’interfaccia realmente indipendente dal dispositivo deve funzionare su desktop, mobile e altri contesti d’uso, inclusi smart TV, tastiere fisiche e sistemi di input alternativi come switch ed eye tracking.

Progettare in modo device-independent migliora l’accessibilità, riduce la complessità di manutenzione e rende i prodotti digitali più robusti nel tempo, adattabili a nuove tecnologie e modalità di interazione.

Le interfacce gestuali sono basate su interazioni come swipe, pinch, drag o movimenti del dispositivo e sono molto diffuse su smartphone e tablet. Dal punto di vista dell’accessibilità, è fondamentale che queste interazioni non rappresentino l’unico modo per attivare una funzione.

Le WCAG richiedono che le operazioni basate su gesti complessi o multipunto abbiano alternative più semplici, come un tap singolo o controlli visibili equivalenti. Allo stesso modo, le funzionalità attivate tramite il movimento del dispositivo, ad esempio scuotere lo smartphone, devono prevedere modalità alternative o la possibilità di disattivare questo tipo di interazione.

Componenti come carousel, menu o azioni contestuali non devono dipendere esclusivamente da gesti come lo swipe o il drag. Persone con mobilità ridotta, tremori, protesi o che utilizzano dispositivi montati su supporti fissi potrebbero non riuscire a eseguire gesti complessi o basati sul movimento.

Progettare interfacce gestuali accessibili significa affiancare ai gesti controlli chiari e utilizzabili, garantendo che tutte le funzioni siano raggiungibili senza richiedere abilità motorie specifiche.

JAWS, acronimo di Job Access With Speech, è uno screen reader commerciale per Windows ed è uno degli strumenti più utilizzati in ambito professionale e aziendale, in particolare nei contesti enterprise e nella Pubblica Amministrazione.

Fornisce output vocale altamente configurabile e supporto per display braille, oltre a funzionalità avanzate per la navigazione, l’interazione con moduli complessi e l’utilizzo di applicazioni professionali. JAWS consente anche l’uso di script personalizzati per adattarsi a software specifici.

Il comportamento di JAWS può differire da quello di altri screen reader, come NVDA o VoiceOver, soprattutto nella gestione di form, tabelle, contenuti dinamici e attributi ARIA. Per questo motivo, testare l’accessibilità con JAWS è particolarmente importante per siti e applicazioni business-critical, come servizi finanziari, e-commerce strutturati e piattaforme della PA.

Pur essendo uno strumento commerciale e più complesso rispetto ad alternative gratuite, JAWS rimane un riferimento professionale nel panorama delle tecnologie assistive per Windows.

I landmark identificano le principali aree semantiche di una pagina e consentono agli utenti di orientarsi rapidamente all’interno dei contenuti. Sono particolarmente importanti per chi utilizza screen reader, che offrono scorciatoie dedicate per spostarsi direttamente tra le diverse sezioni della pagina.

I landmark possono essere definiti tramite elementi HTML semantici, come header, nav, main, aside e footer, oppure tramite ruoli ARIA equivalenti. Il contenuto principale deve essere identificato in modo univoco, mentre eventuali sezioni ripetute dello stesso tipo possono essere distinte tramite etichette descrittive.

Una corretta struttura a landmark crea una vera e propria mappa logica della pagina, riducendo il tempo necessario per raggiungere le informazioni rilevanti e migliorando l’esperienza di navigazione. Le WCAG richiedono una struttura semantica chiara, e i browser e le tecnologie assistive moderne supportano pienamente l’uso dei landmark HTML5.

La Legge Stanca, Legge 4/2004, è la normativa italiana di riferimento in materia di accessibilità degli strumenti informatici. Introdotta inizialmente per la Pubblica Amministrazione e per i concessionari di servizi pubblici, ha avuto un ruolo pionieristico nel riconoscere l’accessibilità digitale come diritto fondamentale delle persone con disabilità.

La legge definisce l’accessibilità come la capacità dei sistemi informatici di erogare servizi e fornire informazioni fruibili senza discriminazioni, anche da parte di persone con disabilità, e stabilisce principi generali di uguaglianza nell’accesso ai servizi digitali.

Nel tempo, la Legge 4/2004 è stata aggiornata e integrata per recepire l’evoluzione normativa europea e tecnologica. Il D.Lgs. 106/2018, che attua la Web Accessibility Directive, e il D.Lgs. 82/2022, che recepisce l’European Accessibility Act, ne hanno ampliato l’ambito applicativo e introdotto obblighi operativi più specifici, come la dichiarazione di accessibilità, il monitoraggio e i meccanismi di feedback.

Le linee guida tecniche e i modelli attuativi sono definiti da AgID, che coordina le attività di verifica e monitoraggio. I requisiti tecnici di riferimento si basano sugli standard europei armonizzati, in particolare la norma UNI CEI EN 301 549 e le WCAG.

Le mappe tattili sono strumenti di orientamento accessibile utilizzati in ambienti fisici complessi, come musei, stazioni, edifici pubblici o parchi. Consentono alle persone cieche o ipovedenti di esplorare uno spazio attraverso il tatto e di costruire una rappresentazione mentale dell’ambiente.

Sono realizzate con diverse tecniche, come stampa 3D, termoformatura o incisione laser, e combinano elementi tattili, come rilievi e texture, con elementi visivi ad alto contrasto. Includono generalmente una legenda in braille e in caratteri ingranditi, simboli standardizzati e una struttura semplificata per evitare il sovraccarico informativo.

In ambito digitale, il concetto di mappa tattile si traduce nella necessità di fornire alternative accessibili alle mappe visive, come descrizioni testuali complete, indicazioni passo-passo o supporto tramite tecnologie assistive. Le WCAG richiedono che le informazioni veicolate da mappe statiche siano disponibili anche in forma testuale.

Le mappe rappresentano uno dei contenuti più complessi dal punto di vista dell’accessibilità. Quando non è possibile garantire una piena equivalenza, è fondamentale offrire alternative efficaci, come descrizioni dettagliate, assistenza umana o soluzioni che integrino feedback sonoro o tattile.

I messaggi di errore sono una componente fondamentale dei form accessibili e influiscono direttamente sulla possibilità di completare un’azione. Le WCAG richiedono che gli errori di input vengano identificati chiaramente e descritti in forma testuale, indicando cosa non va e, quando possibile, come correggerlo.

Un messaggio di errore accessibile deve essere specifico, associato programmaticamente al campo interessato e percepibile anche dalle tecnologie assistive. È importante evitare messaggi generici e fornire indicazioni concrete, ad esempio sul formato richiesto o sui dati mancanti.

La gestione degli errori deve inoltre supportare la navigazione da tastiera, portando l’attenzione dell’utente sugli errori presenti tramite lo spostamento del focus o un riepilogo iniziale, senza perdere i dati già inseriti.

Errori comunicati solo visivamente, validazioni invasive o linguaggio colpevolizzante aumentano frustrazione e abbandono. Al contrario, messaggi di errore ben progettati migliorano l’esperienza complessiva, riducono gli errori ripetuti e supportano sia l’accessibilità sia le conversioni.

La modalità ad alto contrasto è una preferenza di sistema che consente agli utenti di visualizzare contenuti con combinazioni cromatiche fortemente contrastate, per migliorare la leggibilità. È utilizzata in modo permanente da alcune persone ipovedenti e attivata in modo occasionale da altri utenti, ad esempio in presenza di luce intensa o affaticamento visivo.

I siti e le applicazioni devono rispettare queste impostazioni e rimanere pienamente utilizzabili quando la modalità ad alto contrasto è attiva. Ciò significa evitare soluzioni grafiche che dipendono esclusivamente dal colore o da immagini di sfondo e garantire che testi, icone e controlli restino visibili e distinguibili.

Alcuni sistemi operativi, come Windows, possono sovrascrivere completamente i colori dell’interfaccia. Per questo è importante testare il comportamento delle pagine in modalità ad alto contrasto e utilizzare proprietà CSS standard e strutture robuste.

Il supporto alla modalità ad alto contrasto rientra nel più ampio principio di rispetto delle preferenze dell’utente ed è un aspetto essenziale dell’accessibilità visiva.

Il monitoraggio è l’insieme delle attività periodiche necessarie a verificare che siti web e applicazioni mantengano nel tempo i requisiti di accessibilità. Il D.Lgs. 106/2018 prevede il monitoraggio per i siti e le app della Pubblica Amministrazione, con il coordinamento di AgID.

Il monitoraggio comprende test automatizzati, verifiche manuali, controlli con tecnologie assistive e campionamenti rappresentativi dei contenuti e delle funzionalità, in particolare quelli introdotti dopo le verifiche precedenti. Gli esiti delle attività devono essere documentati e utilizzati per aggiornare la dichiarazione di accessibilità.

Nelle PA il monitoraggio rientra tra le responsabilità organizzative, spesso affidate al Responsabile per la Transizione Digitale o a figure delegate. AgID utilizza i dati raccolti anche per elaborare report aggregati a livello nazionale.

Il monitoraggio non deve essere visto come un’attività una tantum, ma più come un processo continuo. Siti e applicazioni evolvono nel tempo, così come i contenuti e le funzionalità. Un presidio costante riduce il rischio di regressioni e consente di mantenere la conformità nel tempo.

La navigazione da tastiera è un requisito fondamentale dell’accessibilità. Le WCAG richiedono che tutte le funzionalità di un’interfaccia siano utilizzabili senza mouse, consentendo agli utenti di spostarsi, interagire e completare azioni esclusivamente tramite tastiera.

Una navigazione corretta prevede un ordine di tabulazione logico, un indicatore di focus sempre visibile e l’assenza di trappole che impediscano di uscire da componenti o sezioni della pagina. Tutti i controlli interattivi devono essere raggiungibili e attivabili, inclusi menu, form, dialog e componenti dinamici.

La navigazione da tastiera è essenziale per persone con disabilità motorie, per utenti che utilizzano screen reader e per chi non può o non vuole usare il mouse. È anche ampiamente utilizzata da utenti esperti per velocizzare le operazioni.

Errori comuni includono elementi interattivi non raggiungibili tramite Tab, componenti che funzionano solo al passaggio del mouse o finestre modali che bloccano il focus. Un test semplice ed efficace consiste nel disconnettere il mouse e verificare che l’intero sito sia utilizzabile solo con la tastiera.

NVDA (NonVisual Desktop Access) è uno screen reader open source e gratuito per Windows, sviluppato da NV Access. È oggi uno degli strumenti più utilizzati sia da persone cieche o ipovedenti sia da professionisti dell’accessibilità.

NVDA supporta i principali browser e applicazioni desktop, fornisce output vocale e braille ed è aggiornato regolarmente grazie a una comunità attiva. Il suo supporto agli standard web, come HTML5 e ARIA, lo rende particolarmente affidabile per la valutazione dell’accessibilità delle interfacce digitali.

In ambito professionale, NVDA è spesso lo screen reader di riferimento per i test di accessibilità perché è gratuito, facilmente installabile e rappresentativo di un’ampia base di utenti reali. I suoi comportamenti sono in molti casi simili a quelli di soluzioni commerciali come JAWS, pur presentando alcune differenze operative.

Per sviluppatori, designer e team di QA, testare con NVDA è fondamentale per verificare che contenuti e funzionalità siano realmente fruibili tramite tecnologie assistive.

L’operabilità da tastiera rientra nel principio Operable del modello POUR delle WCAG e stabilisce che tutte le funzionalità di un’interfaccia debbano essere utilizzabili senza mouse. Non riguarda solo la navigazione, ma la possibilità di compiere qualsiasi azione tramite input da tastiera o tecnologie assistive equivalenti.

Il principio include requisiti relativi all’accesso da tastiera, all’assenza di trappole che blocchino la navigazione, alla gestione delle scorciatoie, ai limiti di tempo, alla sicurezza rispetto a contenuti lampeggianti e alla possibilità di orientarsi all’interno della pagina. Tutti i controlli interattivi devono essere raggiungibili e azionabili in modo prevedibile.

L’operabilità da tastiera è fondamentale per persone con disabilità motorie che non utilizzano il mouse, per utenti di screen reader, per chi usa dispositivi di input alternativi come switch o comandi assistivi, e anche per utenti esperti che preferiscono l’uso della tastiera.

Verificare l’operabilità significa assicurarsi che l’intero sito o applicazione sia utilizzabile esclusivamente tramite tastiera, senza perdita di funzionalità o blocchi operativi.

L’ordine di lettura è la sequenza con cui i contenuti vengono interpretati dalle tecnologie assistive ed è determinato dall’ordine del DOM, non dalla disposizione visiva ottenuta tramite CSS. Le WCAG richiedono che questa sequenza rispetti il significato e la logica dei contenuti.

Quando l’ordine visivo non corrisponde all’ordine del codice, gli screen reader leggono gli elementi in modo diverso da come appaiono a schermo, generando confusione e perdita di contesto. Questo accade spesso in layout complessi in cui gli elementi vengono spostati visivamente senza una struttura HTML coerente.

Un ordine di lettura corretto segue una progressione logica, ad esempio dal titolo della pagina al contenuto principale, fino agli elementi secondari come sidebar e footer. La soluzione consiste nell’utilizzare HTML semantico con un ordine strutturato e affidare al CSS solo la presentazione visiva.

Un ordine di lettura coerente riduce il carico cognitivo, migliora la comprensione dei contenuti e rende l’esperienza più fluida per chi utilizza screen reader o altre tecnologie assistive.

POUR è l’acronimo dei quattro principi fondamentali su cui si basano le Web Content Accessibility Guidelines. Tutti i criteri di successo WCAG derivano da questi principi e ne rappresentano l’applicazione concreta.

Percepibile significa che le informazioni e i componenti dell’interfaccia devono poter essere percepiti dagli utenti, ad esempio tramite alternative testuali, sottotitoli, strutture adattabili e sufficiente distinguibilità visiva.

Operabile indica che l’interfaccia deve poter essere utilizzata, includendo l’accesso da tastiera, una navigazione chiara, la gestione del tempo, la sicurezza rispetto a contenuti potenzialmente dannosi e il supporto a diverse modalità di input.

Comprensibile riguarda la chiarezza dei contenuti e del comportamento dell’interfaccia. Il linguaggio deve essere leggibile, le interazioni prevedibili e gli utenti devono essere aiutati a evitare e correggere gli errori.

Robusto significa che il contenuto deve essere interpretabile correttamente da una vasta gamma di user agent, inclusi browser e tecnologie assistive, grazie a markup valido e semantica corretta.

POUR fornisce un framework logico di riferimento.

La progettazione inclusiva, o inclusive design, è un approccio che integra la diversità di abilità, contesti ed esperienze umane fin dalle prime fasi di un progetto. Non si limita a rendere un prodotto conforme a standard di accessibilità a posteriori, ma incorpora l’inclusione nei processi di ricerca, ideazione, progettazione e test.

A differenza dell’accessibilità reattiva, che interviene spesso su prodotti già realizzati, l’inclusive design parte dal riconoscimento delle esclusioni e utilizza queste come leva progettuale. Un principio chiave è che risolvere un problema per una persona in condizioni estreme può migliorare l’esperienza per molti altri utenti.

Le metodologie di progettazione inclusiva includono il coinvolgimento di persone con disabilità nei processi di ricerca e test, la creazione di personas inclusive, l’analisi di scenari limite e pratiche di co-design. L’obiettivo è progettare soluzioni che funzionino per una pluralità di utenti senza la necessità di modalità o percorsi “speciali”.

L’inclusive design va oltre la conformità tecnica e abbraccia valori di equità, diversità e responsabilità progettuale, trasformando l’inclusione in un motore di qualità e innovazione.

La ricerca con utenti (user research) è una pratica fondamentale per garantire un’accessibilità reale, non solo formale. Integra persone con diverse disabilità all’interno dei processi di ricerca, progettazione, test e validazione lungo tutto il ciclo di sviluppo.

Attraverso interviste, osservazioni e test basati su task realistici, è possibile comprendere bisogni, contesti d’uso e strategie adottate dagli utenti nell’interazione quotidiana con le interfacce digitali. Il coinvolgimento diretto consente di individuare barriere che i test automatici o le checklist normative non sono in grado di rilevare.

La ricerca con utenti permette anche di verificare che la conformità tecnica alle WCAG si traduca in un’esperienza effettivamente utilizzabile, evidenziando problemi di comprensione, flussi poco chiari o soluzioni solo apparentemente accessibili.

Il principio guida è “Nothing about us without us”: le persone con disabilità sono esperte della propria esperienza. Integrare la user research nei processi di accessibilità sposta il focus dalla semplice compliance normativa a un approccio realmente human-centered.

Il riconoscimento vocale, o voice control, consente agli utenti di controllare dispositivi e interfacce digitali e di inserire testo utilizzando la voce come principale modalità di input. È una tecnologia fondamentale per persone con limitazioni motorie che non possono utilizzare tastiera o mouse tradizionali.

Perché un’interfaccia sia utilizzabile tramite comandi vocali, i controlli devono essere strutturati in modo chiaro e coerente. Le etichette visibili devono corrispondere ai nomi accessibili, la struttura semantica deve essere corretta e tutte le funzionalità devono essere raggiungibili senza dipendere da hover, gesture complesse o interazioni esclusivamente visive.

Le WCAG affrontano questi aspetti in particolare attraverso il criterio Label in Name, che richiede coerenza tra testo visibile e nome accessibile dei controlli, rendendo possibile l’attivazione tramite voce.

Il riconoscimento vocale è distinto dagli assistenti vocali: mentre questi ultimi eseguono comandi o azioni autonome, il voice control consente di interagire direttamente con interfacce esistenti. Testare l’accessibilità con sistemi di controllo vocale è complesso ma sempre più rilevante, soprattutto per applicazioni orientate a servizi essenziali.

La ridondanza è una strategia fondamentale dell’accessibilità che consiste nel non affidare informazioni o funzionalità a un solo canale sensoriale. Un contenuto accessibile deve poter essere percepito in più modi, così che la perdita o l’indisponibilità di un canale non impedisca la comprensione o l’uso.

Le WCAG integrano il principio di ridondanza in numerosi criteri, ad esempio richiedendo alternative testuali per le immagini, sottotitoli e audiodescrizioni per i contenuti video, informazioni non basate esclusivamente sul colore e messaggi di errore accompagnati da spiegazioni testuali.

In pratica, la ridondanza si traduce nell’offrire più segnali per la stessa informazione: un errore indicato con colore, icona e testo; una notifica comunicata visivamente e annunciata alle tecnologie assistive; un controllo identificabile sia visivamente sia tramite nome accessibile.

Se un canale non è disponibile o efficace — ad esempio per persone cieche, sorde o in particolari contesti ambientali — l’informazione deve comunque arrivare. Questo principio, centrale nel design universale, migliora l’esperienza per tutti gli utenti.

La rimediazione, o remediation, è il processo di correzione delle barriere di accessibilità individuate durante un audit. Comprende interventi tecnici e progettuali finalizzati a rendere un sito o un’applicazione conforme ai requisiti WCAG e agli standard di riferimento.

Le attività di rimediazione possono includere la modifica del codice HTML, CSS e JavaScript, il miglioramento della struttura semantica, la gestione corretta del focus, l’adeguamento dei contrasti cromatici, l’aggiunta di testi alternativi e la revisione di componenti interattivi non accessibili. In alcuni casi è necessario riprogettare intere parti dell’interfaccia.

Una rimediazione efficace richiede competenze tecniche, conoscenza approfondita delle linee guida di accessibilità e l’uso di tecnologie assistive per la verifica dei risultati. Gli interventi vengono generalmente prioritizzati in base alla gravità delle barriere, al loro impatto sugli utenti e alla frequenza con cui si presentano.

La rimediazione è spesso più costosa e complessa quando viene effettuata a posteriori. Per questo motivo, è fondamentale accompagnarla con attività di prevenzione, come la formazione dei team, l’aggiornamento delle linee guida di progetto e l’integrazione di controlli di accessibilità nei processi di sviluppo. Un approccio by design riduce il rischio di regressioni e i costi complessivi nel tempo.

Gli screen reader sono software che interpretano il contenuto delle interfacce digitali e lo restituiscono tramite sintesi vocale o display braille. Analizzano il codice HTML, gli attributi ARIA e le informazioni fornite dal sistema operativo per comunicare struttura, contenuti e funzionalità all’utente.

Consentono di navigare una pagina in modo non visivo, ad esempio saltando tra titoli, link, campi di form e sezioni semantiche, oppure esplorando tabelle e componenti interattivi. Gli utenti di screen reader sviluppano strategie avanzate di navigazione basate sulla struttura logica dei contenuti, non sulla loro disposizione visiva.

Il corretto funzionamento degli screen reader dipende dalla qualità del markup: HTML semantico, etichette dei campi, testi alternativi, gestione coerente dei ruoli e degli stati. Un uso scorretto o eccessivo di ARIA può compromettere l’esperienza invece di migliorarla.

Testare con screen reader reali è essenziale per verificare l’accessibilità effettiva di un’interfaccia. I test automatici individuano solo una parte delle criticità, mentre l’interazione con uno screen reader permette di valutare comprensibilità, flussi e usabilità reale. Per questo motivo, la conoscenza di base del funzionamento degli screen reader è una competenza chiave per chi si occupa di accessibilità.

I sottotitoli, o caption, rendono accessibili i contenuti audio dei video a persone sorde o ipoudenti, ma sono utili anche in molti altri contesti, come ambienti rumorosi, dispositivi senza audio o per utenti non madrelingua.

Le WCAG richiedono la presenza di sottotitoli per i contenuti video preregistrati e, a livello più avanzato, anche per le trasmissioni in diretta. I sottotitoli per l’accessibilità non riportano solo i dialoghi, ma includono anche informazioni rilevanti come l’identificazione dei parlanti, i suoni significativi e, quando necessario, il tono o l’emozione.

È importante distinguere tra sottotitoli per l’accessibilità e sottotitoli linguistici: i primi trascrivono l’audio nella stessa lingua del contenuto e sono pensati per garantire comprensione, mentre i secondi servono principalmente alla traduzione.

Sottotitoli di qualità devono essere accurati, ben sincronizzati e facilmente leggibili. Soluzioni automatiche possono costituire un punto di partenza, ma richiedono sempre una revisione umana per garantire precisione e completezza.

Lo spazio bianco indica lo spazio vuoto tra testi, immagini, componenti e sezioni di un’interfaccia. Non è uno spazio “inutile”, ma un elemento progettuale fondamentale per guidare la lettura, separare i contenuti e migliorare la comprensione.

Una spaziatura adeguata migliora la leggibilità dei testi, facilita la scansione visiva, riduce il sovraccarico cognitivo e rende l’interfaccia più prevedibile. È particolarmente importante per persone con disabilità cognitive, dislessia, ADHD, ipovisione e per utenti anziani, ma migliora l’esperienza per tutti.

Nel contesto dell’accessibilità, lo spazio bianco contribuisce a soddisfare criteri legati alla comprensibilità e alla percepibilità dei contenuti. Spaziatura insufficiente può rendere difficile distinguere sezioni, pulsanti o campi di input, aumentando errori e affaticamento.

Un uso corretto del white space include margini e padding coerenti, interlinea adeguata, distanza sufficiente tra elementi interattivi e una chiara separazione visiva delle informazioni. Lo spazio bianco è quindi parte integrante di un design accessibile, non solo una scelta estetica.

Gli stati ARIA servono a comunicare alle tecnologie assistive le condizioni dinamiche degli elementi interattivi, ovvero come un componente si trova in un determinato momento. A differenza delle proprietà, che descrivono caratteristiche più stabili, gli stati cambiano in risposta alle azioni dell’utente o del sistema.

Esempi comuni di stati ARIA includono l’indicazione di un contenuto espanso o compresso, di un pulsante attivato o disattivato, di una voce selezionata o della posizione corrente all’interno di una navigazione. Queste informazioni permettono agli screen reader di restituire un feedback corretto e aggiornato durante l’interazione.

Gli stati devono essere aggiornati dinamicamente tramite JavaScript ogni volta che il componente cambia comportamento o aspetto. Se uno stato non viene aggiornato correttamente, l’utente riceve informazioni errate o incomplete, con effetti diretti sulla comprensione e sull’usabilità.

Un uso scorretto o incoerente degli stati ARIA può compromettere l’accessibilità invece di migliorarla. Per questo motivo è fondamentale applicarli solo quando necessario, preferendo sempre elementi HTML nativi quando disponibili, e verificare il risultato con tecnologie assistive reali.

tabindex è un attributo HTML che controlla come e se un elemento può ricevere il focus tramite tastiera, influisce direttamente sull’ordine di tabulazione e quindi sull’esperienza di navigazione per utenti che non utilizzano il mouse.

Usato correttamente, tabindex consente di rendere focusabili elementi non interattivi in modo nativo o di gestire il focus in contesti dinamici. Valori come tabindex="0" permettono di inserire un elemento nel flusso naturale di tabulazione, mentre tabindex="-1" consente di spostare il focus in modo programmatico senza alterare l’ordine di navigazione.

Un uso improprio di tabindex può compromettere l’operabilità da tastiera e violare i requisiti WCAG sull’ordine del focus. Per questo motivo va considerato uno strumento avanzato, da utilizzare solo quando necessario e sempre verificando il risultato con test di navigazione da tastiera e tecnologie assistive.

Le tecnologie assistive, o Assistive Technologies (AT), comprendono un insieme di strumenti hardware e software che permettono alle persone con disabilità di utilizzare computer, dispositivi mobili e contenuti digitali. Tra queste rientrano screen reader, display braille, ingranditori di schermo, sistemi di input alternativi, comandi vocali e soluzioni di supporto cognitivo.

Le AT consentono di compensare limitazioni visive, motorie, uditive o cognitive, offrendo modalità di interazione diverse rispetto a mouse e tastiera tradizionali. Per funzionare correttamente, interagiscono con i sistemi operativi e le applicazioni attraverso specifiche API di accessibilità che rendono disponibili informazioni su struttura, ruoli e stati dell’interfaccia.

Se un’interfaccia non è progettata correttamente, nessuna tecnologia assistiva può renderla realmente utilizzabile. Per questo motivo, la responsabilità dell’accessibilità ricade su chi progetta e sviluppa i sistemi digitali, non sugli strumenti utilizzati dagli utenti.

I test con utenti reali coinvolgono persone con disabilità che utilizzano quotidianamente tecnologie assistive e permettono di valutare l’accessibilità nell’uso reale, non solo a livello tecnico.

Attraverso lo svolgimento di task realistici, emergono criticità che difficilmente vengono intercettate da audit automatici o checklist normative, come difficoltà di orientamento con screen reader, terminologia poco comprensibile, flussi complessi, interazioni faticose o ambigue.

I user test consentono di osservare strategie, workaround e comportamenti reali degli utenti, offrendo indicazioni preziose per migliorare UX, contenuti e componenti interattivi. Per questo rappresentano uno degli strumenti più affidabili per valutare la qualità effettiva dell’esperienza accessibile e verificare che la conformità tecnica si traduca in reale usabilità.

I test con utenti reali non sostituiscono audit e verifiche normative ma li completano, trasformando l’accessibilità da requisito formale a esperienza realmente inclusiva.

Il testo alternativo (alt text) è un attributo HTML (alt="…") che fornisce una descrizione testuale del contenuto o della funzione di immagini, icone, grafici ed elementi non testuali. È uno dei requisiti fondamentali dell’accessibilità web ed è disciplinato dal criterio WCAG 1.1.1 (livello A).

Un alt text efficace descrive ciò che l’utente deve sapere dall’immagine nel contesto in cui si trova, in modo conciso ma informativo. Non deve essere una descrizione visiva generica, né includere formule ridondanti come “immagine di…”, già implicite per le tecnologie assistive.

Le immagini puramente decorative devono avere testo alternativo vuoto (alt="") per essere ignorate dagli screen reader, evitando rumore informativo. Per immagini complesse, come grafici o diagrammi, l’alt text fornisce una sintesi, mentre una descrizione più dettagliata va resa disponibile nel contenuto testuale circostante.

La qualità del testo alternativo incide direttamente sull’esperienza di persone cieche o ipovedenti e rappresenta un punto di contatto tra accessibilità, usabilità e SEO, contribuendo anche alla corretta indicizzazione dei contenuti.

I titoli (heading) definiscono la struttura semantica di una pagina e ne organizzano i contenuti in sezioni logiche. Le WCAG richiedono che questa struttura sia coerente e significativa, perché viene utilizzata dalle tecnologie assistive per comprendere e navigare i contenuti.

Gli screen reader permettono agli utenti di esplorare una pagina saltando direttamente da un titolo all’altro, costruendo rapidamente una mappa mentale della struttura. Per questo motivo, i titoli devono essere descrittivi, seguire una gerarchia logica e rappresentare correttamente il contenuto della sezione che introducono.

Una struttura corretta prevede un titolo principale che identifica l’argomento della pagina e livelli successivi utilizzati in modo progressivo, senza salti arbitrari. I titoli non devono essere usati solo per motivi grafici, ma per esprimere la struttura informativa; l’aspetto visivo va gestito tramite CSS.

Titoli ben progettati migliorano l’accessibilità per chi utilizza screen reader, facilitano la comprensione per persone con disabilità cognitive e rendono i contenuti più leggibili per tutti. Contribuiscono inoltre alla SEO, aiutando i motori di ricerca a interpretare correttamente la gerarchia delle informazioni.

Le trascrizioni (transcripts) sono versioni testuali complete di contenuti audio o video. Rendono accessibili le informazioni anche al di fuori della fruizione temporale del media e sono disciplinate dalle WCAG nei criteri sui media temporali. In particolare, il criterio 1.2.1 (livello A) richiede una trascrizione per contenuti audio preregistrati, mentre il criterio 1.2.8 (livello AAA) la prevede come alternativa completa ai video preregistrati.

A differenza dei sottotitoli o delle caption, che sono sincronizzati all’interno del player, le trascrizioni sono documenti separati e consultabili liberamente. Includono dialoghi, identificazione dei parlanti, suoni significativi e, quando necessario, descrizioni delle informazioni visive rilevanti.

Le trascrizioni migliorano l’accessibilità per persone sorde, sordocieche o con difficoltà di elaborazione uditiva, ma offrono benefici trasversali: consentono la ricerca testuale, facilitano la traduzione, migliorano l’indicizzazione SEO e permettono la fruizione dei contenuti in contesti dove l’audio non è disponibile o desiderabile.

Possono essere fornite in diverse forme, da documenti testuali statici a versioni interattive sincronizzate con il player, purché il contenuto informativo sia completo ed equivalente.

La visibilità del cursore incide sull’esperienza di utenti con ipovisione, tremori, difficoltà di coordinazione oculo-manuale o deficit attentivi. Un cursore poco visibile può rendere complessa l’interazione anche quando l’interfaccia è formalmente accessibile.

I sistemi operativi come Windows e macOS consentono di personalizzare il cursore, modificandone dimensione, colore, contrasto o aggiungendo effetti visivi come la scia. Le applicazioni e i siti web dovrebbero rispettare queste preferenze di sistema e non introdurre personalizzazioni che riducano la riconoscibilità del puntatore.

Nel web, l’uso della proprietà CSS cursor può migliorare la comprensione degli elementi interattivi, ma personalizzazioni eccessive o non coerenti possono generare confusione. L’interattività deve essere comunicata principalmente tramite HTML semantico e ruoli ARIA appropriati, non solo tramite il cursore.

L’accessibilità del cursore si intreccia con quella dei controlli interattivi e con le impostazioni del sistema operativo, contribuendo a un’esperienza più robusta e inclusiva.

VoiceOver è lo screen reader nativo sviluppato da Apple ed è integrato in tutti i principali sistemi dell’ecosistema: macOS, iOS, iPadOS, tvOS e watchOS. Permette alle persone cieche o ipovedenti di navigare e utilizzare dispositivi attraverso comandi da tastiera, gesture touch o trackpad, con output vocale e supporto ai display braille rinfrescabili.

Su macOS può essere attivato tramite scorciatoia da tastiera, mentre su iPhone e iPad è accessibile tramite la funzione di accessibilità rapida configurabile dall’utente. VoiceOver utilizza un modello di interazione basato su focus e gesti specifici, diverso da quello degli screen reader su desktop Windows, ed è quindi fondamentale considerarlo separatamente nei test.

La combinazione VoiceOver e Safari rappresenta una delle configurazioni di riferimento per la verifica dell’accessibilità secondo le WCAG, soprattutto in ambito mobile. Apple fornisce linee guida e documentazione dedicate per sviluppatori e designer.

Per una valutazione affidabile dell’esperienza utente, è essenziale testare VoiceOver su dispositivi reali, poiché simulatori ed emulatori non riproducono completamente comportamenti, gesture e feedback dell’uso quotidiano.

Il W3C (World Wide Web Consortium) è l’organismo internazionale di standardizzazione del web, fondato da Tim Berners-Lee nel 1994. Il suo obiettivo è garantire lo sviluppo di un web aperto, interoperabile e accessibile attraverso specifiche tecniche condivise.

Il W3C sviluppa e mantiene gli standard che costituiscono l’infrastruttura del web moderno, tra cui HTML, CSS, DOM, SVG e XML, attraverso il lavoro di gruppi di esperti (Working Groups) e un processo di consenso internazionale.

All’interno del W3C opera la Web Accessibility Initiative (WAI), dedicata in modo specifico all’accessibilità digitale. La WAI produce e aggiorna le principali linee guida di riferimento, tra cui le WCAG per i contenuti web, ARIA per le applicazioni interattive, ATAG per gli strumenti di authoring e UAAG per i user agent come browser e media player.

Gli standard e le linee guida del W3C costituiscono la base tecnica su cui si fondano le normative europee e nazionali in materia di accessibilità digitale.

Il W3C (World Wide Web Consortium) è l’organismo internazionale che sviluppa gli standard fondamentali del web. All’interno del W3C opera la WAI (Web Accessibility Initiative), dedicata in modo specifico all’accessibilità digitale.

La WAI coordina lo sviluppo e l’aggiornamento delle principali linee guida di riferimento per l’accessibilità, tra cui le WCAG per i contenuti web, ARIA per le applicazioni interattive e ATAG per gli strumenti di authoring.

Gli standard definiti da W3C e WAI costituiscono la base tecnica su cui si fondano le normative europee e nazionali in materia di accessibilità digitale e rappresentano il riferimento ufficiale per progettazione, sviluppo e verifica della conformità.

Le WCAG 2.1 (Web Content Accessibility Guidelines) sono linee guida internazionali che definiscono i requisiti tecnici e funzionali per rendere accessibili contenuti web e applicazioni mobili. I criteri di successo sono organizzati secondo quattro principi fondamentali: Percepibile, Operabile, Comprensibile e Robusto (POUR).

Le WCAG 2.1 introducono criteri specifici per il mobile, il touch, il ridimensionamento dei contenuti e l’accessibilità cognitiva, ampliando le versioni precedenti. Ogni criterio è associato a un livello di conformità (A, AA, AAA).

In Europa e in Italia, le WCAG 2.1 livello AA rappresentano il riferimento tecnico principale per la conformità normativa, in quanto richiamate dalla norma EN 301 549 e dalle principali leggi sull’accessibilità digitale.

Le WCAG sono uno standard operativo che guida progettazione, sviluppo, test e valutazione dell’accessibilità dei prodotti digitali.

I widget o overlay di accessibilità sono script JavaScript che aggiungono un pannello di controllo all’interfaccia, offrendo funzionalità come aumento del contrasto, ingrandimento del testo, modifica dei font o modalità di navigazione alternative. Vengono spesso presentati come soluzioni rapide o “chiavi in mano” per rendere un sito accessibile.

Tuttavia, questi strumenti non garantiscono la conformità agli standard di accessibilità e non risolvono problemi strutturali del codice sorgente. Non possono correggere HTML non semantico, uso scorretto di ARIA, gestione errata del focus, ordine di lettura incoerente o componenti interattivi inaccessibili. In alcuni casi possono introdurre nuove barriere o interferire con tecnologie assistive.

Molte delle funzionalità offerte dagli overlay sono già disponibili nei browser o nei sistemi operativi attraverso impostazioni di accessibilità native. Affidarsi esclusivamente a un overlay può generare un falso senso di conformità e di tutela legale.

Le normative e gli standard di riferimento richiedono che l’accessibilità sia garantita nel codice e nella progettazione, non attraverso layer superficiali. Per questo motivo, le comunità di persone con disabilità e gli esperti di accessibilità scoraggiano l’uso dei widget come unica soluzione. Il loro impiego può essere considerato, al massimo, come supporto temporaneo durante un percorso di rimediazione strutturale, con piena trasparenza sui limiti.