 Grazie Laura dell'introduzione e siete tanti, siete sicuri di non aver sbagliato track? Cioè, c'è anche una presentazione intraccuno, in realtà. Eh sì, qua ci sono io, esatto. No, no, nel senso voi siete qui perché siete interessati all'accessibilità, immagino, cioè sulle mani quelli che sono interessati all'accessibilità e non quelli che sono qui per amicizia, eccetera, eccetera. Tutti? Peggio per voi. Allora, una piccola attenzione, in realtà, sono appena uscite le nuove linee guida, sono uscite i 5 di ottobre, non esiste ancora una traduzione ufficiale in italiano, uscirà presumo tra qualche mese perché di solito ci vuole qualche mese perché venga tradotto ufficialmente, quindi le traduzioni che trovate in Corsivo sono traduzioni mie, non sono ufficiali, sono segnalate, non usate. Wicag, cosa sono le Wicag? Sono andato a rileggermi per prepararmi a questa presentazione ve lo ho riportata qui l'introduzione proprio sulle linee guida, vado spot su alcuni elementi che sono importanti. Intanto definiscono specifiche tecniche, Wicag sta per linee guida per l'accessibilità dei contenuti web e definiscono specifiche tecniche per rendere i contenuti web più accessibili alle persone con disabilità. Ora io lo dico tutte le volte che faccio una presentazione, non abbiamo paura di parlare di persone con disabilità, non è offensivo, non è esclusivo, è una caratteristica tra virgolette come un'altra, uno può essere alto, uno può essere basso, uno può avere una disabilità, per cui nessuna paura nel parlare di disabilità quando parliamo di accessibilità. L'accessibilità riguarda una grande varietà di disabilità, tra cui quelle visive, uditive, vocali, cognitive, di linguaggio, di apprendimento e neurologiche. Ci ho tenuto a citarle tutte, perché secondo me questo è l'elenco più completo, all'interno del quale più o meno è possibile far rientrare tutta disabilità. Poi c'è un aspetto importante che è anche quello delle cosiddette disabilità invisibili che per certi versi possono essere fatte rientrare all'interno di queste e che hanno comunque delle altre caratteristiche, però diciamo che in linea di massima queste sono le categorie che ci interessano. Anche se, in realtà, queste linee guida non prendono comunque in considerazione tutti i tipi, i gradi e le combinazioni di disabilità, soprattutto le combinazioni. Perché ovviamente queste linee guida danno indicazioni su come risolvere alcuni problemi, ma poi ovviamente ci sono anche persone che presentano disabilità multiple. In questo caso ovviamente non sempre è possibile andare a fare delle soluzioni standard, in quel caso sono delle soluzioni diverse che vanno prese in considerazione. E un'ultima cosa è che le linee guida per l'accessibilità servono anche per facilitare l'uso per le persone anziane, che quindi sperimentano cambiamenti nell'abilità dovute all'invecchiamento e in generale migliorano l'usabilità per tutti gli utenti. Quindi questo è il rapporto tra accessibilità e usabilità, ma non sono la stessa cosa. Ci concentriamo quando parliamo di accessibilità, ancora una volta, sulle persone con disabilità. Le versioni delle WCAG. Al momento attuale ne sono uscite quattro. La prima versione è il 1999, il web nasce nel 1995 e quattro anni dopo avevamo le prime linee guida e come diceva ieri Elena Brescashin al tavolo accessibilità, siamo irritato di vent'anni bene. Sono uscite le linee guida versione 2 nel 2008, le 2.1 nel 2018 e le 2.2 nel ottobre del 2023, meno poco più di un mese fa. È prevista l'uscita di una versione 3 quando non si sa perché i tempi di solito quando si creano queste linee guida sono sempre estremamente dilatati. La buona notizia è che non cambiano molto spesso, per cui nel momento in cui uno ci prende la mano, diciamo che per qualche anno sa che può essere più o meno a posto. Come sono strutturate? Sono strutturate in base a diversi livelli di orientamento per cui ci sono quattro principi fondamentali alla base, quindi un sito per essere accessibile deve essere percepibile, utilizzabile, comprensibile e robusto. Questi quattro principi si articolano in 13 linee guida, che a loro volta si articolano in criteri di successo, che sono aumentati con il tempo, ma in realtà c'è una caratteristica interessante nella versione 2.2 perché per la prima volta abbiamo una linea guida che è stata tolta. E poi sono presenti una serie di tecniche sufficienti o consigliate che però attenzione non fanno parte di per sé delle linee guida, ma fanno parte di una serie di documenti di supporto che qui vi ho linkato poi quando potrete andare a scaricare le slide li troverete. Come soddisfare le wikag è un paginona all'interno del quale ci sono tutte le linee guida e tutti i criteri di successo. Comprendere le wikag sono dei documenti di supporto che sono però fondamentali per effettuare l'interpretazione delle linee guida, perché le linee guida sono molto generiche ma poi bisogna andare a interpretarle. Delle tecniche abbiamo sostanzialmente già parlato e i documenti wikag è un simpatico scatolone in cui c'è dentro tutto. Cosa c'è di nuovo? Innanzitutto quali sono i gruppi che sono principalmente coinvolti? Sono gli stessi per cui sono stati fatti passaggi dalle wikag 2.0 e 2.1 e sono utenti con disabilità cognitive di apprendimento, principalmente, utenti con i povisione e utenti con disabilità su supporti, su dispositivi mobili. Quindi interessate che questo caso abbiamo due categorie di persone con disabilità che sono principalmente coinvolte, ma abbiamo anche disabilità tra virgolette dovute ai dispositivi che è una cosa abbastanza interessante e ci sono alcuni criteri che proprio vanno a toccare questi punti. Più in dettaglio partiamo dal criterio che è stato tolto. Questo è il testo del criterio che è stato tolto in cui si dice sostanzialmente che un sito web per essere accessibile deve avere del codice che è valido, questo semplificando molto. In realtà che cos'è successo? Questo è il testo originale della linea guida. In realtà questa linea guida anche nella versione 2.1 è stata modificata ed è stato aggiunto una nota in cui dice che questo criterio deve essere sempre soddisfatto per qualsiasi contenuto che utilizzi HTML o XML. Questo perché e lo spiega in realtà il testo della WCAG nella versione 2.2 dice che sostanzialmente non ha un criterio. Il criterio non c'è più nelle WCAG, c'è scritto che è obsoleto e rimosso e passo al testo in italiano che così magari è un po' più facile. Dice che questo criterio è stato inizialmente inserito perché le tecnologie assistive avevano dei problemi a interpretare l'HTML. Ora siccome le tecnologie assistive per come funzionano adesso non interpretano più l'HTML ma interpretano l'albero di accessibilità che è costruito dal DOM che è costruito dall'HTML e quindi i browser sono in grado di costruire un DOM mediamente funzionante anche nel caso in cui ci siano errori nel codice. Allora diciamo che questo criterio non è più necessario perché se ci sono dei problemi sono coperti comunque da altri criteri e qui in sostanza vi ho lasciato una listina su quelli che sono effettivamente come vengono mappati gli errori che c'erano prima erano errori del criterio di successo 4.1.1 negli altri criteri. Ovviamente non è una cosa che bisogna andare a prendere a occhi chiusi bisogna andare a interpretare ad esempio il problema degli ID univoci se noi abbiamo una pagina in cui ci sono due elementi che hanno lo stesso ID e quell'elemento un elemento con uno con i quelli d è il bersaglio di un collegamento quindi è un link che porta a quello ovviamente il browser tende a portarmi al primo collegamento. Se però in realtà il testo del collegamento prevede che io andassi al secondo collegamento in questo caso diventa un errore della linea guida 2.4.4 che mi dice che i link devono essere significativi all'interno del loro testo. Io amo molto i numeri e quindi cito molto i numeri delle WCAG non è necessario studiarle a memoria per saperle e neanche io le so a memoria comunque. Se siete interessati a questo argomento quella tabellina lì è tirata fuori da questo articolo dal blog di Adrian Roselli che è molto carino e il titolo è il 4.1.1 on 4.1.1 perché il 4.1.1 è il numero che si usa negli Stati Uniti per ottenere informazioni per cui se avete bisogno di informazioni del tipo qual'è il numero di telefono di Giorgia Castro chiamate il 4.1.1 e vi dicono qual'è il numero. Il numero di telefono una specie di pagine bianche. Andiamo invece a quelli che sono i criteri di successo che sono stati aggiunti. Primo criterio di successo il 2.4.1 ha come obiettivo di fare in modo che il focus l'elemento con il focus sia visibile e quello che bisogna fare quindi assicurarsi che quando un elemento o riceve il focus della tastiera sia almeno parzialmente visibile. E' importante questo perché ci sono persone che non possono utilizzare il mouse e quindi hanno bisogno di utilizzare la tastiera per andare a prendere gli elementi interattivi e quindi hanno bisogno di sapere qual'è l'elemento che ha il focus. Cosa mi dice il testo della linea guida? Linea guida che ha titolo focus non oscurato di livello minimo diciamo è un criterio di livello doppia. Mi dice che quando un componente dell'interfaccio utente riceve il focus deve essere almeno parzialmente visibile e non deve essere nascosto completamente nascosto a causa del contenuto creato dall'autore. Cosa significa questo? Significa in sostanza che è una situazione che si può verificare di solito quando ci sono sticky header, sticky footer, finestre di dialogo non modali. In quel caso è possibile che il focus vada su elementi che vengono nascosti dall'interfaccio utente, almeno una parte del focus deve essere visibile. Se è completamente oscurato significa che sto andando a violare questa linea guida. La linea guida successiva è strettamente correlata con questa perché è un criterio di livello triple A in sostanza e mi dice, mi richiede la stessa cosa però mi chiede che l'elemento con il focus sia completamente visibile. Questa è l'unica differenza per cui diciamo che su questo criterio non soffermerei più di tanto. Altro criterio. L'obiettivo è come al solito anche in questo caso parliamo di focus è rendere più facile individuare il focus della tastiera e quindi quello che si va a fare è andare a utilizzare un indicatore di focus e abbia dimensioni e contrasto sufficienti. Dal momento che molte persone, comprese le persone anziane, possono avere difficoltà a riconoscere quali sono piccole variazioni in realtà dell'aspetto visivo della mia interfaccia. Cosa mi dice questo criterio di successo? Dice in sostanza che quando l'indicatore del focus è visibile, l'area dell'indicatore del focus soddisfa tutti i seguenti criteri. Parto dal secondo. Ha un rapporto di contrasto di almeno 3 a 1 tra gli stessi pixel negli stati in focus e non in focus. Quindi voi vi andate a prendere per intenderci. Immaginate di avere un link. Tabulo, vado sul link e quindi quel elemento riceve il focus. Di solito quello che succede è che compare un bordo di intorno si mette per andare a indicare il focus. Bene, il rapporto di contrasto tra il colore del focus e il colore che ha lo sfondo diciamo, quello che ci sarebbe dietro il focus quando il focus non c'è, deve essere di almeno 3 a 1. Spero che sia chiaro. Vedo delle facce dubbiose. Il precedente intervento perché in realtà la cosa è interessante perché in realtà ci sono questi criteri che cominci che un po' di criteri che si sovrappongono tra la versione 2.1 e 2.2. Questo ad esempio si va sovrapporre ad esempio con un altro criterio che è quello sul fatto che il focus deve essere visibile. L'elemento col focus deve essere visibile. Non entro troppo nel dettaglio. Mi interessa andare un pochino più in dettaglio invece sul primo criterio che mi dice che è grande almeno quanto l'area di un perimetro spesso 2 pixel del componente o sottocomponente non il focus. Questa è una roba che è abbastanza complicata. L'idea qual è sostanzialmente? L'idea è che se voi immaginate di avere un pulsante. Immaginiamo di avere un pulsante in sostanza. Quello che dovete fare è questo. Dovete andare a prendervi o il box sostanzialmente che vi va a englobare l'elemento oppure il perimetro dell'elemento stesso che state andando a prendere. Spero che questo sia chiaro. Diciamo che questo caso è un rettangolo per cui abbastanza semplice le due cose coincidono. Andate a prendervi il perimetro e andate a moltiplicare per due. Questo valore rappresenta un'area che deve essere l'area minima dell'elemento che è il focus. In questo caso che cosa sta andando a prendere? Sto andando a mettere un focus come outset del mio pulsante. Quindi sono l'indicatore del focus staccato addirittura rispetto all'elemento. Ha un bordo di due pixel. Sono tranquillo perché è più di due volte il perimetro. Ok? Questa in linea di massima è semplificando un po'. Come funziona in realtà in questa cosa? Vedete che qui per l'appunto ci sono quattro indicatori diversi. Ho un outset quindi sono al di fuori del bordo. Ho un outline quindi sono a contatto con il bordo. Sono sul bordo oppure sono dentro il bordo. Le prime tre soluzioni sono accessibili. La quarta no. Le prime due è molto facile da capire. La terza continua a essere accessibile nel momento in cui il contrasto tra il colore del bordo col focus e il colore senza il focus almeno di tre a uno, che in questo caso lo è. L'ultimo elemento non va bene perché se sono all'interno di un elemento devo andare a utilizzare un indicatore di focus che è più spesso. Per cui così fallirebbe ma se fosse spesso tre pixel invece ci sarebbe. Ok? Torno un attimo indietro soltanto per andare a indicarvi le eccezioni. Le eccezioni sono nel caso in cui l'indicatore del focus sia stato fissato dal programma utente. Quindi sostanzialmente il browser vi imposta l'indicatore del focus e non è possibile andare a modificarlo. Oppure nel caso in cui l'indicatore di focus e il colore di sfondo non sono stati modificati dall'autore. Quindi anche in questo caso se uso l'indicatore di default del browser. Prostimo criterio di successo che è quello che secondo me mi rende più felice in assoluto. Non bisogna fare affidamento sul trascinamento per le azioni dell'utente. Stiamo parlando del drag and drop per capirci. Ok? Nel senso che se voi andate a fare un'azione che coinvolge il trascinamento dovete andare a permettere di ottenere lo stesso risultato senza utilizzare il drag and drop. E questa secondo me è una roba pazzesca perché in realtà non era mai stata inserita all'interno delle linee guida sulla accessibilità, ma per quelli che hanno bisogno di utilizzare la tastiera. Quindi diciamo persone non vedenti che usano lo screen reader e la tastiera, piuttosto che persone con mobilità è assolutamente essenziale. Proprio perché ci sono persone che non possono usare il mouse. Cosa mi dice il criterio? Sustanzialmente quello che vi ho già detto, quindi che tutte le funzionalità che usano un movimento di trascinamento per eseguire un'operazione devono essere realizzate con un singolo puntatore, cioè sostanzialmente facendo click prima da una parte poi dall'altra o con un altro meccanismo equivalente, a meno che il trascinamento non sia essenziale o la funzionalità sia determinata dal programma utente non modificata dall'autore. Al solito ci sono sempre queste eccezioni per dire se state utilizzando il default del browser è un problema del browser che non dovrebbe farlo. Prostimo criterio, l'obiettivo è quello di rendere i controlli più facili da attivare, che questo è quello un po' più complesso in realtà, e l'obiettivo di questo criterio è garantire che gli obiettivi abbiano una area di target sufficiente intorno a loro o che per lo meno siano sufficientemente distanziati. E questo è importante perché ci sono persone con disabilità fisiche e anche semplicemente da mobile questa cosa si accentua ancora di più che non riescono a cliccare pulsanti troppo piccoli perché sono troppo vicini. Cosa mi dice il criterio? Che peraltro è l'elaborazione di un criterio di livello tripla che esisteva già nelle linee guida precedenti. Al solito salto tutto. Io vi ho messo tutti i test in inglese per riferimento, vado alle traduzioni per comodità. La dimensione degli obiettivi per gli input tramite puntatore deve essere di almeno 24 pixel per 24, cioè minimo 24 in orizzontale, minimo 24 in verticale. Questa è la cosa, a meno che quello che vi dicevo prima va bene anche se sono sufficientemente spaziati. Quindi se hanno dimensioni più piccole di 24 pixel per 24, se io vado a prendere il centro della bounding box, che era il termine che stavo cercando prima e non mi veniva in mente, quindi sostanzialmente della box che mi circonda l'elemento che sto prendendo in considerazione. Al centro di questa bounding box vado a mettere un cerchio di diametro 24 pixel. Questo cerchio non deve sovrapporsi con nessun altro cerchio e con nessun altro elemento interattivo. Qui purtroppo ci sono delle belle immagini sul sito del V3C che io non sono riuscito a copiare e incollare nella presentazione. Quindi il mio suggerimento è di andarvi poi a vedere esattamente l'understanding di questa linea guida per andare a vedere esattamente come funziona. C'è un esempio fatto molto bene con un menu disposto su due righe, quindi con i link su due righe e in questo caso si vede che ci sono i certi attini che non si sovrappongono tra di loro. Altre eccezioni, nel caso in cui la funzione possa essere fatta in maniera equivalente tramite un altro controllo che ha invece rispetto a questo criterio. Se l'elemento in line non dovete andare a effettuare questo controllo per cui il link all'interno del testo state tranquilli non sono un problema. Nel caso in cui la dimensione dell'obiettivo è determinata dal programma autente non viene modificata dall'autore quindi al solito se uso il default del browser non c'è problema. Oppure se è essenziale quindi se questa specifica presentazione dell'obiettivo è essenziale o è legalmente richiesta perché l'informazione venga trasmessa. Esempio che mi è venuto in mente, immaginate di giocare a Prato Fiorito in cui volete andarvi a giocare con un campo di 250 colonne e 150 righe. Ovviamente le dimensioni delle singole cellule saranno microscopiche ma non è che potete ingrandirle perché altrimenti se volete avere tutto sullo stesso schermo diventa un po' complicate. Prostimo critere il vero ha come obiettivo quello di rendere più facile trovare aiuto e supporto e come si fa questo banalmente andando a mettere l'aiuto nella stessa posizione su tutte le pagine. Non è che vado a mettere l'aiuto in una pagina in alto a sinistra e in una pagina in basso a destra o piuttosto l'aiuto lo metto in una pagina nell'edra e nell'altra nel footer. Questo perché le persone che hanno bisogno di aiuto se una volta che hanno trovato dove possono chiedere aiuto sanno che è lì e vanno sempre lì. E quindi questo gli semplifica notevolmente la vita. Il criterio di successo mi dice che se in una pagina web è presente un meccanismo di aiuto e questo meccanismo di aiuto ti ripete su più pagina web allora il posizione in cui questi messaggi di aiuto devono comparire deve essere la stessa in tutte le pagine. A meno che l'utente non abbia fatto qualche cosa per cui va a spostare la posizione delle aiuto. Quali sono qua questi quattro meccanismi di aiuto. Dei dettagli per contattare una persona. esempio numero di telefono. È un dettaglio che mi permette di andare a contattare una persona che mi può dare aiuto. Meccanismi per contattare una persona. Un link che mi porta che mi permette di mandare un email dicendo ho bisogno di aiuto relativamente a questa cosa. L'utente compila l'email, la manda può ricevere aiuto. È un meccanismo e non un dettaglio perché in realtà non interviene in realtà non c'è un contatto umano diretto in questo caso. Opzioni di auto aiuto. Quindi se ho delle FAC le metto sempre nella stessa posizione. Meccanismi di contatto completamente automatizzati. Chatbot. Prostimo criterio. Siamo quasi in fondo tenete giuro. Rendere l'obiettivo è rendere più facile per gli utenti completare processi multi step. In questo caso quello che non bisogna fare è chiedere le stesse informazioni due volte nella stessa sessione. Ed è importante perché persone con disabilità cognitive possono avere difficoltà a ricordarsi cosando inserito in precedenza. Per esempio in questo caso è processo di checkout. Ho l'indiritto di fatturazione. Ho l'indiritto di consegna. Se l'idea è che se voglio dare un'opzione, voglio creare qualcosa di accessibile. Vado a mettere una checkbox in cui dico usa lo stesso indiritto di consegna come indiritto di fatturazione o viceversa a seconda di come organizzato la cosa. Però in realtà evitate che una persona debba andare a inserire prima l'indiritto di fatturazione e poi andare a copiare tra vergolette gli stessi dati nell'indiritto di consegna visto che gli ha già inseriti. Il criterio di quel successo mi dice esattamente questo. Per cui mi dice che se informazioni sono state chieste in precedenza non devono essere richieste di nuovo. Quindi devono essere auto compilate o disponibili per la selezione. Quindi o ricopiate direttamente il contenuto o date un'opzione per aggiungerlo. Con alcune eccezioni ovviamente se l'inserimento è essenziale, se è necessario per garantire la sicurezza del contenuto. Per esempio sto facendo la registrazione su un sito, mi chiede di inserire una password, mi chiede di inserire la conferma della password. Non gli vado ad auto popolare ovviamente il meccanismo di conferma della password perché se non muore lì il significato della conferma della password. L'utente si ha bisogno può fare coppia in colla, non impedite che possa fare il coppia in colla e diciamo che nessuno si farà male. L'altra possibilità è che le informazioni inserite in precedenza non siano più valide anche in questo caso ovviamente l'utente deve rinserirle. Criterio di successo 3.8 è ridurre lo sforzo mentale nel momento in cui si fa il login. Per veditare che le persone siano costrette a risolvere, ricordare o trascrivere qualcosa per effettuare l'accesso. Questo perché alcune persone con disabilità cognitive possono avere difficoltà anche nel risolvere puzzle. Memorizzare nomi utenti o password o addirittura riscrivere codici monoso. Per cui il criterio di successo esattamente che cosa mi dice? Mi dice che se è presente un test delle funzioni cognitive, quindi qualcosa che in sostanza mi permette riconoscere l'utente come un essere umano. Ad esempio può essere ricordare una password piuttosto che andare utilizzando ricapcia qualcosa di questo genere. Questo procedimento non deve essere richiesto in nessun passaggio di autenticazione, a meno che non sia disponibile una delle seguenti alternative, le seguenti opzioni. O un'alternativa, quindi un metodo di autenticazione che non si basa su un test delle funzioni cognitive. Esempio classico, il login attramite link che viene inviato all'email. Faccio click, mi arriva il link sull'email, faccio click sull'email, so, è verificato che sono io e quindi faccio l'accesso. Se è disponibile un meccanismo per assistere l'utente nel completare il test delle funzioni cognitive. Se il test delle funzioni cognitive consiste nel riconoscere oggetti, quindi se pensate al ricapcia di Google diciamo che quello funziona perché di solito per l'appunto il riconoscimento di oggetti piuttosto che dell'orientamento di oggetti. Oppure nel caso in cui il test delle funzioni cognitive coinvolga l'identificazione di contenuti non testuali forniti direttamente dall'utente. Per cui ad esempio è riconosci una tua foto, la cosa ovviamente la può fare soltanto l'utente o riconosci la foto di qualcuno che eventualmente ha inserito. Personalmente non ho mai pensato che si potesse utilizzare questo sistema come sistema di riconoscimento però se è stato inserito evidentemente qualcuno lo fa. Ultimo criterio di successo di cui vi parlo, in realtà è una semplicemente una versione avanzata di quella precedente. In questo caso è importante non costringere l'utente a riconoscere oggetti, immagini o media neanche se li hanno forniti loro. Perché ci sono persone che hanno difficoltà in ogni caso a risolvere puzzle ma anche a identificare oggetti o eventualmente anche informazioni personali che hanno inserito in precedenza. Quindi in questo caso il criterio di successo è esattamente identico quello prima. La differenza è che le uniche due eccezioni sono le alternative, deve essere disponibile un'alternativa che non richiede il test cognitivo o un meccanismo di assistenza. Ma quindi che cosa cambia in pratica per quanto riguarda adesso che ci sono tutti questi nuovi criteri di successo? Beh la risposta che mi sono dato io è niente e non cambia niente per diverse ragioni. La prima ragione è che sostanzialmente per quanto riguarda gli obblighi legislativi che ci sono questi dipendono da una direttiva e da due decisioni di esecuzione che sono state pubblicate nel corso degli anni. Queste decisioni di esecuzione fanno riferimento a questa norma armonizzata che si chiama N301-549 che sostanzialmente è una norma che contiene i criteri in base ai quali si va a verificare legalmente se un sito web o un'applicazione sono accessibili. La versione 2.1 pubblicata nel 2018 fa riferimento alle wikipedia versione 2.0. La versione 3.1 che è quella actualmente legalmente valida è stata pubblicata il 19 marzo del 2021. La versione 4.1.1 è prevista alla pubblicazione il 15 di febbraio del 2026. Avete due anni e tre mesi quindi per due anni e tre mesi tendenzialmente non ci sarà neanche una norma armonizzata che vi dirà ma si utilizzata è questa cosa. Ma c'è di peggio in realtà perché in realtà non è quando viene pubblicata la norma armonizzata, ma quando nella gazette ufficiale dell'Unione Europea viene detto che siete obbligati legalmente a seguire quella norma armonizzata. Allora la prima decisione che era stata pubblicata è stata citata in gazette ufficiale il 21 dicembre del 2018 quindi dal 21 dicembre del 2018 il 2018 eravate obbligati a rispettare le wikag 2.0, per chi era obbligato all'epoca solo le pubbliche amministrazioni. Decisione successiva pubblicata il 12 di agosto del 2021, dal 12 agosto del 2021 era possibile andare a utilizzare le wikag 2.1. Sei mesi dopo è diventato obbligatorio utilizzare le wikag 2.1 perché è stata rimossa la possibilità di utilizzare le wikag 2.0. In base a queste informazioni e a quelle che sappiamo è prevista la pubblicazione in gazette ufficiale dell'Unione Europea del riterimento alla norma armonizzata nella versione 4.1.1 il 31 di maggio del 2026 e la rimozione quindi diventerà legalmente obbligatorio utilizzare la wikag 2.2 il 30 di novembre del 2026. Tre anni. Cosa cambia oggi? Molto meglio. Siamo d'accordo. Non solo, io ho parlato di questi criteri, ma i criteri di successo all'interno delle wikag hanno diversi livelli di conformità e in realtà i livelli di conformità che viene normalmente richiesto di rispettare sono soltanto livelli di livello, sono tanto requisiti di livello A e W. E quindi già ci cassiamo tra i criteri di successo ulteriormente. Quindi la domanda è perché hai fatto questa presentazione oggi? Giustamente. Perché in realtà noi non possiamo più basarci? Secondo me è arrivato il momento di cambiare mentalità per quando riguarda l'accessibilità. Non possiamo più aspettare di che diventi obbligatorio dal punto di vista legislativo per decidere di fare qualche cosa. E quindi in realtà dobbiamo decidere noi che cosa vogliamo fare, per chi vogliamo fare qualcosa quando lavoriamo in ambito di accessibilità. E io in realtà la persona per cui ho capito che lo faccio è mia nonna. Mia nonna, questa è una foto che aveva fatto durante il suo novantesimo compleanno, novantonesimo compleanno. Ci sono, ci siamo io e i miei cugini e mia nonna. Ha avuto una vita che è stata bellissima, ha avuto i suoi problemi di salute, ovviamente. Però diciamo che ha avuto una vita che comunque è riuscita a viversi bene. Lei fino a un anno dalla sua morte ha vissuta da sola e è morta l'anno scorso. Tre giorni prima di morire, lei fortunatamente ha sempre vissuto bene, ha iniziato ad avere a fare talmente fatica a respirare, che non riusciva neanche più a parlare. E quindi negli ultimi tre giorni noi eravamo lì, lei amo che voleva comunicare, ma lei non riusciva più a comunicare. Allora io in quel momento ho capito che occuparmi di accessibilità significa dare una voce alle persone che non ce l'hanno. E quindi vi chiedo adesso un ultimo sforzo, vi chiedo di chiudere gli occhi e vi chiedo di pensare a una persona per cui da questo momento in avanti volete impegnarvi per migliorarle la vita. Una persona con disabilità, quindi occuparvi dell'accessibilità, sapendo che state migliorando la vita di questa persona. Se non avete una persona di questo tipo potete chiedervi, è possibile, però potete chiedervi in realtà perché non mi sono mai reso conto magari che intorno a me ci sono persone con disabilità, sicuramente le conoscete. Cercate di trovare una persona o perlomeno una spiegazione, lascio 30 secondi soltanto e vi chiedo proprio di fare questo esercizio con profondità. Aprite gli occhi, se non l'avete fatto. Adesso non c'è tempo per le domande in realtà, però se volete, io sono disponibile all'after party e spero che veniate a after party perché è sempre la parte migliore del workout. Sono disposto a rispondere a tutte le vostre domande riguardo l'accessibilità, ma a una condizione. Prima che voi mi facciate una domanda, vi diciate concretamente che azione decidete di fare da oggi per migliorare l'accessibilità, quello che fate per l'accessibilità. Può essere una roba schema e lo dico una cosa che potete fare. Potete iniziare quando pubblicate qualcosa sui social network, aggiungere un testo alternativo alle immagini che inserite. Quindi se non avete niente di meglio da fare, ma può essere qualsiasi cosa. E se invece non volete venire a parlarmi dopo, vi lascio anche i miei contatti e vi ringrazio dell'attenzione.