Accessibilità nel 2025: chi deve adeguarsi, cosa comporta, quali sono le opportunità e un esempio pratico di App accessibile

Nel 2019 l’Unione Europea ha approvato in via definitiva l’European Accessibility Act (Direttiva 2019/882, abbreviato in EAA, per gli amici), un regolamento che impone ai soggetti economici (cioè un qualsiasi privato, libero professionista o azienda che venda prodotti o servizi) di adeguare App e Siti Web ai requisiti minimi di accessibilità entro il 28 giugno 2025. Ecco perché ultimamente se n’è parlato tanto

Questo regolamento in Italia è stato recepito dal D.lgs 82/2022, che lo riporta pressoché identico.
Il regolamento si applica alle aziende che offrono:

• servizi di telecomunicazioni;
• servizi televisivi;
• servizi bancari;
• servizi di trasporto pubblico nazionale o internazionale;
• commercio elettronico;
• ebook e relativi software.

Fino qui tutto bene no? Adesso viene la parte complicata: in Italia esisteva già una legge relativa all’accessibilità, la Legge 4/2004, successivamente estesa dal D.lgs 76/2020.

Mentre la L. 4/2004 prevedeva già gli obblighi di accessibilità per la Pubblica Amministrazione e per le aziende partecipate a maggioranza pubblica, il D.lgs 76/2020 ha esteso questi obblighi ai soggetti privati con fatturato annuo medio, negli ultimi tre anni, superiore a 500 milioni di euro.

In particolare, poi, l’AGenzia per l’Italia Digitale (Agid), che è l’ente preposto a vigilare sull’applicazione delle norme in materia di accessibilità, ha pubblicato, a fine 2022, un documento contenente i criteri con cui verranno interpretate queste leggi. In questo documento troviamo una lista di servizi essenziali i cui siti e App dovrebbero conformarsi agli obblighi di accessibilità:

• servizi di energia, gas, acqua, raccolta dei rifiuti e telecomunicazioni;
• trasporto di passeggeri;
• servizi postali ed attività di corriere;
• servizi di istruzione, sanità ed assistenza sociale;
• servizi bancari e assicurativi;
• servizi funebri;
• servizi veterinari;
• servizi media basati sulle trasmissioni in diretta che sono mantenuti on line o ripubblicati dopo la trasmissione e, più in generale, media basati sul tempo preregistrati, pubblicati dal 23 settembre 2020 (quindi praticamente qualsiasi servizio con video on-demand);
• servizi di commercio elettronico, aventi ad oggetto “beni di prima necessità”, ovvero quei prodotti senza i quali non sarebbe possibile svolgere una dignitosa esistenza (l’elenco non esaustivo delle categorie merceologiche include praticamente qualsiasi cosa). Sono inclusi anche i marketplace, di ogni genere.

A noi qui, però, adesso sorge un dubbio:

Le aziende che forniscono questi servizi (e che non sono già incluse nell’EAA) dovranno rendere i propri Siti ed App accessibili anche se fatturano meno di 500 milioni di euro? Oppure, viceversa, sono proprio le aziende che offrono questi servizi che, al di sopra dei 500 milioni di euro di fatturato, devono attenersi agli obblighi in materia di accessibilità?
Non lo sappiamo. Nel dubbio, secondo noi, vale assolutamente la pena adeguarsi, perché, si legge nell’EAA, l’intento è che, a tendere, tutti i prodotti digitali diventino pienamente accessibili.

Anche se l’obiettivo del legislatore è quello di fare sì che il maggior numero di privati possibile si attivi per offrire servizi sempre più accessibili, è prevista una deroga specifica per le microimprese con meno di 10 dipendenti e un fatturato inferiore ai 2 milioni di euro. Sotto questa soglia, almeno per ora, non c’è nessun obbligo in materia di accessibilità.

Per le PMI (meno di 250 dipendenti e fatturato inferiore ai 50 milioni di euro) è invece prevista la possibilità di valutare se l’adozione di alcuni cambiamenti nei propri prodotti comporta un Onere Sproporzionato e, in questo caso, non procedere ad attuarli. Attenzione però: l’onere sproporzionato non può essere relativo al fatto che, ad esempio, ci possa volere “troppo tempo” per fare le necessarie modifiche oppure che queste modifiche siano troppe di per sé o, ancora, che ci voglia troppo tempo per raccogliere le informazioni necessarie all’adeguamento. In più, l’onere sproporzionato va dimostrato per ogni singolo elemento o contenuto.

Se volete un consiglio spassionato: meglio non provarci neanche. Dimostrare l’onere sproporzionato potrebbe essere molto più difficile e costoso che fare gli interventi necessari per adeguarsi. Rendere App e siti più accessibili è nel vostro interesse molto più di quanto possiate pensare. Ci arriviamo tra poco.

Esiste anche una deroga per quanto riguarda quei singoli contenuti che formano un archivio e che sono stati pubblicati prima del 28 giugno 2025. Ad esempio, potrebbero rientrare in questa categoria vecchi articoli di un giornale (o di un blog). Va considerato però che spesso questo genere di contenuti deve la propria accessibilità non tanto al contenuto in sé, che è spesso un testo, ma a tutto il sito che li contiene, quindi anche questa deroga riguarda casi abbastanza limitati.

Tutti i soggetti interessati sono tenuti a redigere e pubblicare la Dichiarazione di Accessibilità, un documento dove si va a dichiarare se la App o il sito in questione sono o meno accessibili e in che misura. In caso si vada a dichiarare una condizione di accessibilità parziale, si è tenuti ad indicare per ogni parte della App o del sito quale parametro delle linee guida non viene rispettato e soprattutto per quale motivo non si è provveduto ad adeguarsi (è qui che si può tirare in ballo l’onere sproporzionato di cui sopra). La dichiarazione va anche aggiornata, secondo le linee guida fornite da Agid, almeno una volta all’anno e ogni qual volta si facciano modifiche alla App o al sito in questione. Il concetto della Dichiarazione di Accessibilità è quindi molto simile a quello della Privacy Policy.

Il termine “accessibile” è inteso dal regolamento in senso molto ampio: significa eliminare, fin dal principio, ogni tipo di possibile “ostacolo” per l’utente. L’EAA è un testo molto innovativo nei principi e cita esplicitamente la cosiddetta progettazione universale (o inclusiva). Significa progettare prodotti ed esperienze digitali con maggiore buon senso e senza dare nulla per scontato, in modo che non siano solo più accessibili per l’utente con questa o quella specifica disabilità, ma che siano migliori per tutti, by design.

Gli “ostacoli” di cui parliamo possono essere di qualsiasi genere: dalla necessità di poter usare Siti e App con più di un canale sensoriale (e quindi, ad esempio, accessibile per gli utenti che fanno uso di screen reader) fino al rendere disponibili alternative dei contenuti che usano un linguaggio semplificato. L’EAA fissa sia le linee guida da adottare sia dei requisiti funzionali “generali” (dei principî) cui attenersi nei casi in cui le linee guida non siano applicabili.

L’EAA stabilisce che la norma a cui fare riferimento per quanto riguarda le linee guida è la UNI CEI EN 301549. L’ultimo aggiornamento (del 2021) di questa norma aggancia i parametri minimi richiesti a quelli delle WCAG 2.1 livello AA. Le WCAG (Web Content Accessibility Guidelines) sono linee guida redatte e pubblicate da W3C, il World Wide Web Consortium, cioè l’ente che si occupa di coordinare e standardizzare i linguaggi web.

Ma le App? Giusto, le WCAG sono linee guida specifiche per il Web, però le interfacce delle App sono molto simili (molti framework mirano ad avere gli stessi risultati sia sul web che su una App) e quindi in realtà tutti i parametri visivi sono perfettamente sovrapponibili: se una App si conforma alle WCAG, allora è accessibile. Per tutto ciò che, invece, non si può applicare ad una App, restano validi i requisiti funzionali più generali a cui accennavamo prima.

I parametri contenuti nella WCAG sono oggettivi, contengono criteri per effettuare dei test e dei controlli e hanno tre livelli di applicazione A, AA e AAA. Come già detto, quello ritenuto minimo è il livello AA. Per schematizzare, possiamo dividere i parametri in tre macro-ambiti (ci fa comodo per illustrarvi meglio gli esempi tra poco):

• elementi visivi e quindi relativi soprattutto alla UI: dimensioni dei testi, contrasto tra il colore del testo e quello dello sfondo;
• comportamenti interattivi: cosa succede quando apro un pannello, clicco un bottone eccetera cioè la gestione del focus, un tema a cavallo fra UI, UX e sviluppo;
• informazioni semantiche nel codice: l’uso corretto dei tag html, l’aggiunta di etichette e descrizioni alternative, l’aggiunta di attributi che identificano il ruolo delle varie parti di un documento e l’uso di specifici sistemi semantici nelle App (che non sono standardizzate come sul web, quindi le cose si complicano);

Potete trovare liste più o meno approfondite dei vari parametri un po’ ovunque, evitiamo di replicarle anche qui, anche perché sarebbe abbastanza inutile avere una lista parziale: per essere in regola i parametri della WCAG 2.1 livello AA vanno rispettati tutti quanti.

Per quanto riguarda invece l’adozione di un linguaggio “semplice”, purtroppo, non c’è ancora un accordo totale su quali criteri adottare per definire quale sia un linguaggio “universalmente semplice“. Nella WCAG 2.1, un requisito di livello AAA (quindi superiore a quello minimo richiesto), stabilisce di fornire alternative semplificate di un testo se questo richiede un livello di istruizione più avanzato di quella secondaria inferiore (in Italia, le scuole medie). Quindi, per ora, i siti delle PA potranno rimanere incomprensibili ai più pur essendo considerati “accessibili”.

I parametri ed i criteri di cui tenere conto, elencati nelle WCAG, ed i più generali “criteri funzionali di prestazione”, sono innumerevoli. Controllare tutto a mano, soprattutto per un applicativo vasto, sarebbe incredibilmente lungo e complesso. Noi qui usiamo qualche scorciatoia:

Esistono pochissimi strumenti per fare controlli automatici sulle App e, neanche a farlo apposta, sono altre App. Per Android, ad esempio, Google fornisce Accessibility Scanner, che consente di verificare varie cose in modo abbastanza semplice ed intuitivo. Questo tipo di strumenti, se e quando funzionano, (non è scontato), consentono di controllare quasi unicamente gli aspetti relativi all’interfaccia utente, ad esempio la dimensione dei bottoni e dei relativi touch-target: controllo utilissimo ma incompleto.

Per tutto il resto, bisogna affidarsi ad un professionista che, codice alla mano, faccia le opportune verifiche sotto il cofano e poi faccia anche test reali.

Per quanto riguarda i siti web, i controlli sono più semplici: ci sono molti servizi automatizzati come Accessibility Checker (controlla due url al giorno gratis), ma anche molte estensioni per il browser che fanno più o meno le stesse cose. Qui usiamo soprattutto IBM Equal Access Accessibility Checker. È uno strumento completamente gratuito ma rivolto ai professionisti, quindi non proprio semplicissimo da utilizzare. È in grado di controllare tutti gli aspetti dell’accessibilità, compresi quelli semantici.

Attenzione! Ci sono varie situazioni in cui questi strumenti automatici falliscono: qui un esempio dalla nostra homepage.

Il tool automatico suggerisce di controllare il contrasto di questo testo che si trova su uno sfondo sfumato e animato perché non riesce a calcolarlo in automatico e quindi fallisce la verifica. In realtà, il contrasto qui è maggiore di 4.5:1, cioè compatibile con il livello AAA per i testi con corpo maggiore di 18px, quindi un risultato superiore a quello richiesto dalla normativa (ovvero, per il livello AA, un contrasto minimo di 3:1).

In più, se si utilizza un tool che “ragiona” per singole pagine di un sito, difficilmente controllerà cose come la coerenza degli elementi fra le varie pagine, perché queste verranno controllate una per una e non raffrontate le une con le altre. Ad esempio, potrebbe non controllare che le voci del menu principale siano sempre le stesse. Quindi, pur utilizzando strumenti molto avanzati e completi, rimane ancora un certo margine di incertezza.

Per le App, è indispensabile affidarsi ad un professionista per eseguire un controllo completo, mentre per i Siti Web, si può utilizzare uno strumento automatico e chiedere l’aiuto di un professionista solo nel caso in cui il controllo automatico evidenzi delle problematiche, avendo cura di controllare tutte le pagine del sito.

In ogni caso, bisogna comunque compilare e aggiungere al sito o alla App la Dichiarazione di Accessibilità in cui si autocertifica lo stato del prodotto/servizio.

A parte le sanzioni previste dalla legge, che a seconda dei casi, possono andare da 2.500€, al 5% del fatturato annuo medio, ci sono ragioni molto solide per lavorare sull’accessibilità.

Per capire davvero perché è importante, occorre scardinare il presupposto fondamentale di tutta la situazione, ovvero il rapporto fra accessibilità e disabilità.

Spesso si associa il tema dell’accessibilità soltanto a quello della disabilità. Ci sentiamo dire: “questo prodotto/servizio non è certo rivolto ai non vedenti”. Non ci siamo. Il punto non è rivolgersi anche ai non vedenti piuttosto che a qualsiasi altra tipologia di utente: il punto è realizzare un prodotto migliore per tutti. Universalmente migliore, universalmente accessibile.

Certo che tutte queste norme nascono per favorire l’accesso ai prodotti digitali da parte delle persone diversamente abili, però la portata reale delle varie migliorìe è molto più ampia.

Facciamo qualche esempio:

• Sistemare i tag html renderà più facile a qualsiasi screen reader interpretarne correttamente il contenuto della pagina web e renderà più facile interpretarne il contenuto anche ai Google Bot, che arricchiranno lo snippet mostrato nei risultati di ricerca.
• Migliorare il contrasto dei bottoni farà sì che gli utenti con meno di dieci decimi li vedano meglio, ma migliorerà anche l’esperienza di chi ha dieci decimi, che li troverà e decifrerà ancora più velocemente. Migliorerà la leggibilità anche per chi, banalmente, tiene bassa la luminosità dello schermo per risparmiare batteria oppure, all’aperto, in pieno giorno, fatica a leggere perché c’è troppa luce.
• Aggiungere un testo alternativo alle immagini consente agli screen reader di leggerne il contenuto ma consente anche di aggiungere informazioni e contesto ai motori di ricerca che le faranno comparire correttamente nella ricerca immagini e consente di avere, ovviamente, un fallback in caso l’immagine non venga caricata, magari in condizioni di ricezione scarsa.
• Ottimizzare il codice sia frontend che backend per migliorare le performance non migliora l’esperienza solo di chi ha un deficit di attenzione e non aspetterà più di due secondi il caricamento della pagina ma renderà il sito (o App, come sempre) fruibile a quella enorme maggioranza di utenti che ha un dispositivo lento (vecchio oppure semplicemente economico). Tutti bravi a testare con smartphone top di gamma ultimo modello collegato alla WiFi da 5 Gbps, ma il mondo reale è fatto di telefoni da 100 euro di 5 anni fa in metropolitana.
• Spostare tutti i bottoni di conferma e i menu nella parte bassa dello schermo non rende la tua App utilizzabile solo da chi ha una sola mano ma da tutti quelli che hanno l’altra mano impegnata a reggere le borse della spesa, il palo sui mezzi di trasporto o il manico dell’aspirapolvere.

Potremmo andare avanti ancora ma il punto rimane quello: l’accessibilità non è qualcosa di strettamente legato e confinato ad alcuni casi limite. Riguarda cose che succedono ad una larga maggioranza di utenti che, semplicemente, hanno un modo di fruire prodotti e servizi leggermente diverso da quello che viene dato per scontato.

Se poi per te gli utenti sono anche clienti, caro ecommerce manager, considera che questo genere di modifiche coincidono con quello che ti direbbe di fare il tuo consulente di CRO per aumentare le vendite. Il bottone “aggiungi al carrello” più grande ed evidente, no? È esattamente quello di cui stiamo parlando, ma su tutto il sito/app.

Se poi, invece, vuoi saperne di più sulle disabilità visive, ecco qualche dato:

… se si sommano le limitazioni visive moderate a quelle gravi, complessivamente ne soffre il 18,6% della popolazione, percentuale che sale al 33,8% tra gli ultrasessantacinquenni…

La disabilità visiva in Italia (pnrr.salute.gov.it)

…il daltonismo nella popolazione europea interessa circa l’8% degli uomini e l’1% delle donne…

Daltonismo (humanitas.it)

Ci sarebbero poi tutte le altre forme di disabilità che non vanno trascurate: uditive, fisiche, mentali e tutto lo spettro delle neurodivergenze. Prese complessivamente, queste persone sono una fetta non trascurabile della popolazione: circa il 21% nel 2023. Di queste, quasi l’80% utilizza internet. Fonte: Istat.

Soprattutto, dobbiamo tenere presente che la popolazione, semplicemente, sta invecchiando e questo non comporta solo un naturale calo della vista ma anche più difficoltà nei movimenti, soprattutto in quelli che richiedono grande precisione, e che spesso implica anche un diverso atteggiamento e una diversa propensione nell’uso e nel rapporto con la tecnologia. No, non nel senso che c’è un rifiuto o una opposizione, anzi: è proprio un diverso modo di fare le cose, di interagire con i prodotti digitali e va considerato in fase di progettazione, per creare esperienze e prodotti di successo.

Pensi che non riguardi il tuo prodotto digitale? Sbagliato. Gli over 60 nel 2024 in Italia erano il 32% della popolazione. Fonte: sempre Istat.

Pensi che per fare tutto questo serva un budget colossale? Sbagliato. Serve fare formazione e saper scegliere gli strumenti giusti: strumenti che ti garantiscono App e Siti Web davvero accessibili fin dall’inizio, dalle fondamenta. Te lo facciamo vedere qui sotto (con un po’ di immagini, finalmente!).

Qui facciamo le cose fatte bene. Fatte per durare. I requisiti di accessibilità e la WCAG non ci hanno certo colti di sorpresa, facciamo tanta formazione, ci teniamo aggiornati il più possibile e facciamo sempre in modo di applicare al meglio tutte le nostre competenze nei progetti, proprio perché crediamo in un approccio di design universale, piuttosto che solamente inclusivo. Nel tempo, oltre a dare più spazio alla progettazione (perché prevenire è sempre meglio che curare), abbiamo selezionato strumenti che ci consentono di ottenere risultati già in linea con gli standard più elevati.

Ora, come già detto, sul web è tutto più semplice: gli strumenti sono più flessibili, è più semplice creare personalizzazioni ed è più semplice controllare che tutto stia funzionando correttamente. Questo grazie al fatto che bene o male tutto il web è basato sugli stessi standard di funzionamento.

Le App, invece, sono una cosa diversa. Molto diversa. Per questo non basta scegliere lo strumento giusto per creare le App, bisogna partire dalle fondamenta, dal design system.

Per le nostre App sfruttiamo come base Material Design 3, l’ultima evoluzione del design system di Google. Material Design 3 è stato concepito per adeguarsi proprio ai parametri previsti dalla WCAG 2.1 e consente di generare temi colore personalizzati dove tutti gli elementi della App, tutti i testi, tutti i bottoni, le icone eccetera, avranno i giusti rapporti di contrasto e le giuste dimensioni. Tutto questo ovviamente pone dei vincoli alla progettazione ma ci consente comunque di andare a personalizzare profondamente l’aspetto della UI e di adattarlo a pressoché qualsiasi situazione.

Banalmente, ci consente di creare un tema colori completo partendo dai colori aziendali di un cliente per poi andare ad aggiustare tutti i parametri nel dettaglio, aggiungere altri colori completamente personalizzati e, in pochissimo, tempo ottenere anche la trasposizione di questi colori in versione scura, dando all’utente la possibilità di utilizzare l’una o l’altra, automaticamente. Tutto, come dicevamo, certamente accessibile.

Quali sono i vincoli qui? Non ci sarà possibile scegliere esattamente i colori. Quando si lavora con questa modalità, il sistema deriva i colori finali da quello inserito inizialmente, per garantire che siano rispettati tutti i parametri di accessibilità. Significa che i colori finali sono sempre leggermente diversi ma, onestamente, lo sapremo solo noi.

Una volta pronto il tema colore, iniziamo a sviluppare con Flutter, il framework per creare App native che funzionano sia su Android che su iOS. Flutter, sempre di casa Google, è uno dei pochi framework ad implementare Material Design 3 totalmente, quindi ci consente di utilizzare il tema appena creato senza particolari lavorazioni extra. La libreria di componenti è pienamente compatibile con le linee guida di Material Design 3 e della WCAG, sia per quanto riguarda le dimensioni di testi, bottoni eccetera, che per quanto riguarda la gestione delle interazioni e del focus.

In pratica, utilizzando Material Design 3 per progettare la App e Flutter per realizzarla, siamo sempre certi di avere un prodotto con un’interfaccia perfettamente accessibile, risparmiando tantissimo tempo e ottimizzando quindi il budget, ma non è finita qui. Per rendere la nostra App completamente accessibile dobbiamo fare in modo che sia utilizzabile con le tecnologie assistive: è ora di mettere da parte l’interfaccia e di tornare a parlare degli aspetti di semantica.

Cosa intendiamo per semantica quando parliamo di codice? Semplificando molto, intendiamo tutto quell’insieme di informazioni che aiutano il sistema (il sistema operativo, il browser o uno screen reader) ad intuire il senso ed il ruolo di ogni parte del software. Alcune di queste informazioni sono “gratis”: significa che il software le fornisce in automatico al sistema, oppure che il sistema è in grado di ricavarle automaticamente. Altre informazioni, sfortunatamente, non sono “gratis” ed è qui che occorre intervenire manualmente.

Facciamo un esempio:

Il componente che crea il menù, “informa” il sistema di essere un menù e di collegare quindi le varie parti della nostra App. Questo consente alle tecnologie assistive, come gli screen reader, di interfacciarsi con la App, leggere il menù e accedervi senza che l’utente lo debba ritrovare ogni volta o senza dover aspettare che la App lo proponga.

Sul web questo si ottiene includendo il menu all’interdo dell’apposito tag <nav>. Funziona automaticamente, è “gratis”.

La maggior parte degli elementi di interfaccia di una App, però, non ha un ruolo semantico definito a priori, né un testo che li renda accessibili. Moltissimi bottoni contengono solamente un’icona, molte card per necessità di layout, contengono piccoli elementi che uno screen reader impiegherebbe molto tempo ad elencare prima di raggiungere il contenuto.

Molti layout sono semplicemente complessi e non strutturati in modo da essere perfettamente accessibili a livello semantico ed è necessario fornire alternative.

Flutter nello specifico costruisce un accessibility tree a partire dal suo widget tree, cioè dalla struttura dei suoi componenti. Questo schema, che viene poi letto ed utilizzato dalle varie tecnologie assistive, può essere manipolato per aggiungere informazioni, raggruppare elementi oppure toglierne altri.

Ogni blocco colorato nelle immagini qui sopra rappresenta un elemento dell’interfaccia ed è posizionato dove si troverebbe normalmente, con il suo contenuto al centro. Qui vediamo bene la differenza che c’è dopo la manipolazione dell’accessibility tree.

La differenza è abbastanza evidente: la seconda schermata è molto più “semplice”. Gli elementi sono molti meno e sono tutti descritti da un testo. Sono stati rimossi tutti gli elementi troppo piccoli e alcuni testi vengono modificati contestualmente, cioè solo per le tecnologie assistive, per aggiungere maggiori informazioni.  Ad esempio, il bottone che consente di saltare l’introduzione, da “Salta” diventa “Salta introduzione”.

In quest’altra schermata la differenza è molto meno evidente. Si tratta di un caso particolare: normalmente questa schermata proporrebbe le selezioni di contenuti fatte dall’utente (varie liste di contenuti “preferiti”). Qui è ancora vuota. Visivamente la schermata è semplice da leggere, ma non è così per una tecnologia assistiva: è stato necessario ripulire l’accessibility tree da tutta la stratificazione che serve per creare il layout e lavorare ancora una volta sui testi e sulle informazioni, che sono molto più dettagliate.

Perché questo è il risultato a cui ambire? Perché è meglio avere una schermata con meno elementi, più ordinata? Perché in realtà, ad oggi, molti utenti ipovedenti che sfruttano screen reader e altre tecnologie assistive, piuttosto che farsi leggere cosa c’è sullo schermo “in ordine”, dall’alto in basso, trascinano il dito sullo schermo per farsi leggere cosa c’è in ogni punto della App. Se avessimo lasciato tutto com’era, questo sarebbe stato quasi inutile, perché avrebbero incontrato troppi elementi, di cui molti senza alcuna etichetta oppure con etichette tutte uguali, indistinguibili.

Anche se può sembrare una cosa complessa, in realtà questa ottimizzazione incide per una piccola percentuale del budget di sviluppo, siamo tra il 5 ed il 10% a seconda dei casi e questo sempre grazie a Flutter, che ci semplifica enormemente anche questo lavoro. Ovviamente l’ideale è progettare bene la App dall’inizio e, nella nostra esperienza, progettare bene non ha un costo extra.

Abbiamo visto insieme il quadro normativo di riferimento che, come spesso accade in Italia, è un quadro cubista. L’unica cosa di cui siamo certi è che bisogna sviluppare App e Siti Web accessibili, non tanto perché siamo obbligati (e presto o tardi lo saremo tutti), ma perché ci porta a creare prodotti migliori per tutti gli utenti, inclusi quelli che pagano, che potrebbero sceglierci di più anche per questo. Abbiamo anche visto come tutto questo non comporti dei costi particolarmente alti, quindi, che stiamo aspettando? È ora di sviluppare App e Siti Web Accessibili!

Web Content Accessibility Guidelines (WCAG) 2.1 – World Wide Web Consortium (W3C)
https://www.w3.org/Translations/WCAG21-it/

Direttiva Europea 2019/882 (European Accessibility Act)
https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX:32019L0882

D.lgs 82/2022 – Attuazione della direttiva (UE) 2019/882
https://www.gazzettaufficiale.it/eli/id/2022/07/01/22G00089/SG

Linee guida AGID (PDF, aprile 2022)
https://www.agid.gov.it/sites/default/files/repository_files/linee_guida_accessibilit_erogatori_art_31bis.pdf

Circolare AGID n. 3-2022 (PDF, dicembre 2022) – “criteri interpretativi”
https://www.agid.gov.it/sites/agid/files/2024-08/Circolare%20n.%203-2022%20accessibilit%C3%A0%20privati.pdf

Modello di Dichiarazione di Accessibilità (fonte: AGID)
https://www.agid.gov.it/sites/default/files/repository_files/allegato_1_modello_dichiarazione_accessibilit_art_31bis.pdf