Servizi inclusivi e usabili per tutti

Scarica la trascrizione in formato ODT.

[...]

La parola a Daniele Tabellini e Fabrizio Caccavello

Daniele: “Ciao buongiorno a tutti.”

Fabrizio: “Buongiorno a tutti.”

Daniele: “Ciao Fabrizio, condivido lo schermo così andiamo nel vivo subito della presentazione. Federica, ti chiedo solo di confermarci che si vede lo schermo... Farei le presentazioni, vai Fabrizio, ti do la precedenza.”

Fabrizio: “È ordine di anzianità oggi! Allora sì. Fabrizio Caccavello, sono un esperto di accessibilità. Sono consulente di Agenzia per l'Italia Digitale e insieme a Daniele abbiamo portato avanti questo argomento legato al design system del Paese. Daniele è sostanzialmente l'owner del progetto di cui oggi vi parliamo.”

Daniele: “Sì, io sono Daniele Tabellini, mi occupo di UX, UI, due termini magici per dire esperienza utente e interfaccia utente, nel Dipartimento per la trasformazione digitale della Presidenza del Consiglio da due anni e mezzo, circa tre. Nell'ultimo anno e mezzo sono stato il referente tecnico, più che l'owner, dei progetti di aggiornamento e definizione del design system del Paese. E nell'ultimo anno anche del rinnovamento del sito del progetto Designers Italia, che è quello che oggi useremo per raccontarvi un pò di cose sull'accessibilità. Fondamentalmente quello che state vedendo (designers.italia.it) è un progetto in comune tra il Dipartimento per la trasformazione digitale e AGID che esiste da qualche anno e che ha visto il proprio sito web rinnovarsi proprio il 10 maggio, qualche giorno fa, nemmeno un mese fa. Entriamo nel vivo. Noi che cosa faremo oggi? Vi racconteremo cos'è Designers Italia e parleremo un attimo di norme e riferimenti in un primo cappello iniziale. E poi ci chiederemo cos'è l'accessibilità, perché è importante, come affrontarla e come il progetto design system del Paese, che vedete qua in questa voce, affronta e semplifica anche per tutta la Pubblica Amministrazione italiana, in parte, il tema dell'accessibilità digitale. Iniziamo da qui. Che cos'è... ”

Fabrizio: “Abbiamo anche la novità, che diciamo, questo progetto è ormai pubblico, mentre qualche mese fa ne parlavamo come una cosa in prospettiva. Invece finalmente abbiamo questa versione pubblica.”

Daniele: “Sì, questo è vero, questo sito che state vedendo ha vissuto da dicembre del 2022 fino al 10 maggio, fondamentalmente su un URL secondario che si chiamava prossima.designers.italia.it. È stato pubblicato sei mesi prima, praticamente quasi, del suo rilascio, proprio per raccogliere feedback. Nel primo webinar che abbiamo fatto sulla qualità dei servizi digitali, infatti abbiamo usato quel sito in mostra, diciamo in raccolta feedback, per raccontare questa storia. Oggi invece vedete il sito che è andato online, che ha sostituito il vecchio sito Designers Italia che esisteva da diversi anni. Ed è interessante come sia questo webinar nella prima edizione, sia i feedback raccolti in questi sei mesi dagli utenti, sia un percorso di test di usabilità fatto con un tavolo tecnico della Conferenza Stato Regioni ci abbia permesso di evolverlo. Chi ha avuto modo, o avrà modo nei prossimi mesi, quando saranno disponibili, di vedere questi racconti, si accorgerà anche dell'evoluzione tra quello che abbiamo raccontato due mesi fa e quello che raccontiamo oggi. Allora iniziamo da qui. Come si progetta bene un nuovo sito per un progetto del genere, che fondamentalmente ha lo scopo, lo vedete qua, di mettere a disposizione di tutta la Pubblica Amministrazione e dei suoi fornitori, conoscenza da una parte, quindi come si fanno le cose, informazioni, approfondimenti e strumenti dall'altra. Per fare che cosa? Per creare servizi digitali della Pubblica Amministrazione. Come si fa bene questo per essere un buon esempio in sé, anche lo stesso sito? Fondamentalmente l'abbiamo fatto partendo dalla ricerca. Quindi come, ora vedremo ci raccontano anche le nuove linee guida di design uscite l'anno scorso, si dovrebbe fare un progetto digitale. Però mi interessava farvi vedere che l'abbiamo fatto in maniera aperta, quindi esiste un posto su GitHub che è una piattaforma per lo sviluppo di software open source, quindi aperto, dove questo sito vive, dove questo sito è stato evoluto e tutto quello che succede qui dietro fondamentalmente è pubblico e navigabile, quindi basta partire da Designers Italia e poi si arriva anche qua, per esempio, che è la board che è la lavagna di progettazione dove tutte le attività avvengono, fatte da personale interno del Dipartimento e di AGID, fatte da persone della Community, come voi, che contribuiscono e fatte da fornitori che contribuiscono. Quindi lo stesso Designers Italia è un vero e proprio progetto sviluppato utilizzando le pratiche che il CAD chiede di utilizzare a tutta la Pubblica Amministrazione. Non ci soffermeremo molto su che cos'è Designers Italia, perché ve l'hanno in parte introdotto anche nei webinar precedenti. Ci interessava solo entrare nella sezione progetto ed ntrare dentro la sezione visione perché questa frase fondamentalmente secondo noi, rappresenta bene anche quello che vi stiamo raccontando oggi. O comunque è un buon cappello per quello che vi stiamo raccontando oggi, no Fabrizio?, una Pubblica Amministrazione vicina, semplice e utile alle persone di oggi e di domani, grazie a siti e servizi pubblici digitali che sono progettati in modo collaborativo. Dà per implicito una cosa questa, le persone di oggi o di domani sono tutte le persone. Non credi Fabrizio?”

Fabrizio: “Esatto, infatti diciamo una delle caratteristiche fondamentali del nostro lavoro è stato quello di pensare comunque... Prima, dicevamo, in maniera inclusiva, ora diciamo sempre non esclusiva, cioè non escludendo le persone, anche perché chiaramente quando si progetta una... quando si fa una progettazione digitale si tende, si tendeva almeno fino a un po di tempo fa, a pensare che comunque, siccome il digitale fosse comunque inclusiva, fosse comunque accessibile, cosa che invece non è assolutamente vera, anzi, per troppo tempo abbiamo creato progetti digitali in maniera molto disordinata, molto spesso non aderente anche a delle normative esistenti. E l'idea proprio di base di Designers Italia è quello di fornire un punto d'accesso unico per chi progetta e avere un quadro complessivo di quello che sono non solo le norme, le leggi, perché ci vogliono, per carità, ma anche strategie e punti di partenza efficaci, perché dobbiamo creare accessibile, ossia per tutti. Questo è un po, diciamo, lo spirito con cui abbiamo portato avanti questa questo lavoro.”

Daniele: “Aggiungo che questa foto che vedete sotto, seppur rielaborata per essere una grafica di vision, come vedete, sono persone intorno a vari computer che stanno facendo dei test di usabilità. Eravamo a Wired l'anno scorso a Milano in questa occasione e stavamo facendo quello che c'è scritto sopra, progettando in modo collaborativo il modello, per esempio, di sito dei Comuni italiani e stavamo facendo una sezione di test di usabilità con persone con e senza disabilità o con condizioni particolari che ha bisogno di configurazioni particolari. Che è un tema molto interessante, insomma, per progettare in maniera accessibile non si può prescindere da coinvolgere le persone reali e da collaborare con diverse professionalità. Entriamo nel vivo, tu dicevi norme e riferimenti. Norme e riferimenti, si prende una buona fetta delle schede delle nuove delle tantissime 300 nuove schede di questo sito. Se entriamo nella sezione norme riferimenti non a caso le due in evidenza sono linee guida di design e linee guida di accessibilità. Mi sono accorto, tra l'altro ci siamo accorti facendo i test negli ultimi mesi prima del rilascio, infatti in questa versione non è così, che non mettere i riferimenti di legge, quindi non mettere, per esempio, "rispondono all'articolo 53 del decreto legislativo del 7 Marzo 2005 numero 82 contenente il CAD". Non mettere questi tipi di riferimenti, purtroppo a molti di noi della Pubblica Amministrazione, non fa percepire le linee guida come norme, ma soltanto come delle piccole guide tecniche o delle guide tecniche da seguire per i tecnici. In realtà queste due che state vedendo sono esattamente norme dello Stato. Le linee guida di design, seppur di secondo grado perché emesse a norma CAD, sono comunque una norma che quindi impone degli obblighi e le linee guida di accessibilità lo sono, perché in Italia abbiamo Fabrizio ci insegna, anzi ti chiedo di dire due parole su queste, forse una delle legislazioni più antiche sull'accessibilità al mondo, in realtà. Perché nei primi anni 2000, nel primo quinquennio del 2000, è stata emessa la legge Stanca, c'erano anche dei precedenti negli anni precedenti. Diciamo dei primi germogli. E il famoso European Accessibility Act che è uscito ormai due o tre anni fa, credo...”

Fabrizio: “2018”

Daniele: “Scusami 5 anni fa era ancora nei sogni in realtà, di qualunque legislatore, quindi siamo andati ben 14 anni avanti all'Europa. Entrambe sono norme dello Stato. Sul sito Designers, senza soffermarsi troppo, tranne chiedere magari tra un secondo a Fabrizio di integrare queste informazioni, che dicevo sulle linee guida accessibilità e di European Accessibility Act, mi interessava farvi vedere che nel nuovo sito... Allora che cosa sono le linee guida di design? Sono la norma che devi rispettare ogni volta che fornisci o progetti, siti e servizi digitali per la Pubblica Amministrazione, quindi sono un obbligo che va anche ricordato ai fornitori. Vi faccio vedere che l'articolo 4.8, per esempio, è un articolo che serve esattamente a quello: che cosa inserire dentro i contratti. Il fornitore incaricato deve rispettare le indicazioni e riportare alle linee guida di design per i siti Internet e servizi digitali della PA. Questo è quello che l'articolo 4.8 impone a tutte le PA di inserire nei contratti da giugno dell'anno scorso. Una norma ancora non troppo conosciuta. All'interno delle linee guida di design c'è un rimando a l'accessibilità e a seguire le norme sull'accessibilità ma più che altro ci sono cose come si deve fare ricerca utente, si deve valutare in modo esplicito obiettivi, si devono mappare gli scenari eccetera eccetera. Oggi siamo qui per l'accessibilità, quindi non scendo nel dettaglio, però quello che ci interessa farvi vedere è che l'articolo 4.5. Il requisito 4.5 della norma ha dentro alcune azioni. E l'azione 2 è quella che ci interessa, entro dentro, l'azione 2 ci dice che si devono realizzare nell'ambito dello stesso sito Internet o servizi digitali, interfacce coerenti nello stile e nell'esperienza d'uso. Quello che segue è quello che ci interessa, "privilegiando le indicazioni e gli strumenti previsti su Designers Italia" che è un si dovrebbe, quindi, se si può fare meglio si può fare altrimenti. Ma se no si dovrebbero seguire le indicazioni. Le indicazioni sono quelle che vi racconteremo tra poco. Chiedo solo a Fabrizio se c'è qualcosa che possiamo dire in più sulle linee guida accessibilità.”

Fabrizio: “Sì, due cose. In questo paese sempre un po diciamo maltrattato di cose che si fanno sempre con ritardo e sempre con un po'...guardando l'estero, con una specie di, diciamo così, di vabbè insomma non so dire come. Però in realtà sia in accessibilità che nelle linee guida di design abbiamo delle cose, delle esperienze molto antiche, nel senso che, come diceva Daniele in accessibilità siamo uno dei primi paesi europei a essersi dotato di una legge dal 2004. Poi, chiaramente è evoluta con, come ricordava Daniele, anche con l'Accessibility Act del 2018, quindi integrato nella legge già esistente nel 2020. Quindi è chiaro che comunque l'idea di accessibilità è un'idea che si è formata veramente nel tempo da noi. Ma anche quello delle linee guida di design, perché anzi questo mi piace raccontarlo perché ha creato qualche piccolo problema di interpretazione anche fra gli addetti ai lavori. Perché in epoche precedenti si erano già pubblicate delle linee guida di design che non erano una parte normativa. Poi piano piano è arrivato il CAD che ha deciso che AGID deve emanare le linee guida e si è creato un gruppo di lavoro che ha portato alle attuali linee guida di design dei servizi della Pubblica Amministrazione che sono una parte normativa, come diceva prima Daniele. Che non bisogna confondere con le, diciamo i suggerimenti che abbiamo sempre avuto da molti anni prima rispetto al design. E chiaramente queste due linee guida sono oggi noi le vediamo qui, ben formate e ben pubblicate, ma sono frutto di un lavoro di professionisti come me e Daniele, abbiamo fatto parte anche noi di questi gruppi di lavoro, quindi c'è stato un lavoro molto importante anche qualche volta un pò animato, Daniele ti ricorderai, in alcuni tavoli e però siamo arrivati alla definizione di questi due fondamenti, linee guida di design e di accessibilità che sono un pilastro della costruzione dei servizi digitali.”

Daniele: “Aggiungo un pezzettino e poi passiamo alla parte tecnico-pratica che vogliamo raccontarvi. Sono entrato in linee guida di design, nel requisito 4.1 accessibilità dentro l'azione 1 del requisito che deve essere garantito il rispetto dei dettami della legge 4/2004 i seguenti e delle correlate linee di accessibilità, come vedete dentro c'è un pò di risorse suggerite, utili che sono presenti in Designers Italia o di approfondimento. Questo è un articolo che io e Fabrizio abbiamo scritto più di un anno fa sul tema, su come si progettano servizi di qualità, per esempio o il fondamento accessibilità del design system che vedremo tra poco. Però mi interessava farvi vedere che sotto c'è il manuale operativo di design. Quello che diceva Fabrizio che sono esistite per un pò di anni delle linee guida di design non normative, solo come riferimento tecnico, è vero. Nel momento in cui si è riusciti a far diventare linee guida di design norma, si è separato quello che è a norma dall'implementazione tecnica diciamo perché si evolve molto velocemente. Ovviamente l'implementazione tecnica è stata spostata comunque in uno strumento che è ancora a disposizione di tutte le pubbliche amministrazioni. Anche esteso in collaborazione con questo tavolo tecnico della Conferenza Stato Regioni, anche verificato nel tempo con loro. E che contiene al suo interno molte indicazioni su tanti temi, è una specie di grande manuale di come si progetta per la Pubblica Amministrazione digitale. Giusto per farvi vedere che cos'è: è un lunghissimo manuale che è presente sulla piattaforma Docs Italia, e ne approfitto per chiedere a Fabrizio soltanto una frase molto veloce, perché il tempo ovviamente è tiranno, sull'approccio con cui il manuale e le le risorse che vi facciamo vedere ci guida a tenere sull'accessibilità. Qui, in questa pagina, c'è scritto Accessibilità by design nel titolo e più più in basso c'è scritto anche by default. Se dovessimo dire in due parole che cosa intendiamo per accessibilità by design e che cosa intendiamo per accessibilità by default. E poi ognuno potrà approfondire tornando qua, che cosa si può dire Fabrizio?”

Fabrizio: “Sì, tra l'altro sono due concetti che qualche volta qualcuno porta diciamo sui tavoli come sinonimi. Invece non è esattamente così. Ossia accessibile by design vuol dire che quando si progetta un qualunque voto digitale, bisogna avere l'accessibilità in testa, come si diceva una volta, devo partire con l'idea che devo includere il maggior numero possibile di persone.”

Daniele: “Mentre progetto passo passo mi devo chiedere se sto facendo accessibile.”

Fabrizio: “Esatto passo passo, per esempio anche quando faccio cose che riguardano altri settori, che ne so, metto un OTP per recuperare un codice di accesso e lo metto a tempo. Ma quel tempo che stabilisce qualcuno che si sveglia la mattina e dice 20 secondi è stato capito, cioè è stato deciso da qualcuno in quei 20 secondi sono un tempo congruo per la maggior parte degli utenti? È stata fatta una ricerca, è stato fatto uno studio con gli utenti oppure qualcuno una mattina si è svegliato e ha detto, 20? Ecco, questo è quello: l'accessibilità by design.”

Daniele: “L'accessibilità by default?”

Fabrizio: “By default è invece devo avere già pronto il cassetto degli attrezzi accessibili. Esempio, nel nostro sistema è il nostro Bootstrap Italia.”

Daniele: “La libreria dei componenti di sviluppo già accessibili, che io posso assemblare.”

Fabrizio: “Per quanto possibile, accessibile, per quanto una libreria possa decontestualizzata e quindi di per sé non avere tutte le caratteristiche di accessibilità, perché essendo decontestualizzata non può avere l'accessibilità del processo. Non c'è il processo, è ovvio, però il cassetto agli attrezzi ce l'ho buono, questo è il concetto.”

Daniele: “Se parlassimo di un template, di un documento sarebbe la carta intestata già accessibile, diciamo, per fare un esempio pratico.”

Fabrizio: “Esatto. La base ce l'ho accessibile.”

Daniele: “Io progetto il contenuto ma la base è ok. Speriamo sia chiaro per tutti, perché quello che vi faremo vedere d'ora in poi è lo sforzo che il team di Designers Italia sta facendo per permettere da una parte di capire come si progetta by design accessibile e dall'altra di capire che ci sono delle risorse progettate da noi by design accessibili che diventano by default accessibili per chi deve progettare servizi digitali, scusate il gioco di parole. Stiamo facendo i pezzi di questa scatola di puzzle accessibili finché sono da soli, poi ovviamente se li assembli in maniera sbagliata o senza chiederti by design, senza rimanere accessibile, fai confusione. Ok, stiamo entrando nel tema, ma stiamo rimanendo troppo alti. Scendiamo nel concreto. Come si progetta? Allora noi crediamo che crediamo che il processo di progettazione sia un processo iterativo. Un processo che assomiglia molto a un loop. Quindi si parte da organizzare, organizzare il lavoro, comprendere, comprendere i bisogni, per esempio lo scenario d'uso. Mettersi a progettare una soluzione, ad esempio con dei wireframe e dei prototipi, mettersi a realizzare davvero la soluzione, per esempio con un kit di interfaccia o con una libreria di componenti di sviluppo, come diceva Fabrizio, Bootstrap Italia nel nostro caso. E validare, validare l'accessibilità, per esempio testando la soluzione finale, validare con i test di usabilità l'usabilità e poi ricominciare. Però questo schema non rende giustizia a come si dovrebbe affrontare l'accessibilità ancora. Infatti questo è un tema che racconteremo meglio nei prossimi anni. Perché? Perché l'accessibilità fa parte in realtà di tutte le fasi dovrebbe far parte. Va bene fare una validazione finale, però se dovessimo fare un disegno reale, assomiglierebbe più un frattale. Cioè per ogni fase, per ogni pezzettino, noi continueremmo a fare un piccolo loop di test di usabilità, dei prototipi, dei test di accessibilità, chiedersi se è accessibile, chiedersi come si possa fare meglio. Il tema dell'accessibilità deve essere trasversale a tutti e su questo tema del trasversale... innanzitutto deve essere iterativa, in ogni fase ci deve essere, e poi deve essere trasversale anche tutti i profili. È solo responsabilità dello sviluppatore o dell'esperto di accessibilità l'accessibilità? Fabrizio, faccio un esempio banale che mi viene a mente, a me ne viene uno banale. A te verranno molti più importanti sicuramente che è questo: io ho la piattaforma più bella del mondo, ma l'editor che scrive i contenuti non mette testi alternativi alle immagini, il sito è accessibile ma diventa automaticamente non accessibile perché non ha testi alternativi per chi non può vedere le immagini e le ascolta con con le orecchie. Quindi, in realtà un editor di un sito è un profilo coinvolto, ma ce ne sono altri coinvolti?”

Fabrizio: “Sì, assolutamente, per esempio, uno fra tutti, anzi, forse il capofila può essere il mondo del design, perché è chiaro che se lato design si progetta senza alcuna consapevolezza ed accessibilità, quando poi il progetto arriva allo sviluppo, chi sviluppa avrà o un effort improponibile per risolvere quei problemi, oppure potrà proprio non risolverli e mantenere le problematiche di accessibilità. E ancora prima nella raccolta dei requisiti, se i requisiti sono pensati non accessibili, è chiaro che io sto già escludendo, sto già creando l'anticamera...”

Daniele: “Quante volte lo vediamo, quante volte lo vediamo nelle nostre forniture che questa parte iniziale non viene presa in considerazione, non si coinvolgono designer o non ci si pone il problema o non è scritto nei requisiti. E poi ci troviamo alla fine a dire no, ma non c'è tempo. Mettiamolo online non accessibile. Poi ci si scrive Beta, lo faremo uscire accessibile quando ci sarà tempo e non succede mai in realtà. E su questo, se mi ricollego alla prima fase che si è detto prima, stiamo decidendo chi escludere. Noi non possiamo scegliere, non siamo un privato che può fare delle scelte, noi siamo pubbliche amministrazioni, i nostri servizi devono essere usati da tutti, a prescindere da condizioni o configurazioni particolari. Quindi non è che è una scelta, questo è un requisito che deve stare qua, deve stare nella fase organizzare quindi chi comprende progetta e realizza un servizio lo deve fare accessibile, cioè questa cosa deve diventare... deve essere scritta in alto, in qualunque organizzatore e amministratore e contratto. Anche perché le norme ci sono e potenzialmente ci saranno anche le multe o le sanzioni. Ma c'è anche un'altra cosa, validare una cosa non accessibile e poi sistemarla costa, farla accessibile costa uguale, cioè costa più o meno uguale, non è che farla accessibile costa di più, o dovrebbe costare di più perché significa progettare bene, se non lo fai accessibile oggi stai semplicemente progettando male, Giusto, ti torna?”

Fabrizio: “Sì, volevo aggiungere una cosa proprio sul frattale. Facciamo un esempio proprio, tipico: piccolo sito fatto con Wordpress. Perché ci hanno raccontato che by default è accessibile, è il cassetto degli attrezzi giusto. E hanno ragione perché Wordpress è un CMS che, possiamo dire fa il giusto cassetto degli attrezzi. Poi arriva l'esigenza di aggiungere un plugin, quando aggiungiamo quel plugin di nuovo ricomincia il nostro ciclo, perché del plugin mi devo chiedere non solo se funziona come spesso succede, mi serve un plugin che fa il calendario per gli eventi. No, devo chiedermi se funziona, se è sicuro, se mi permette di rispettare la privacy delle persone e se è accessibile.”

Daniele: “Sì, perché noi abbiamo saltato il pezzo, ma by design e by default ovviamente ci sono anche i temi della sicurezza e della privacy, anche nelle linee guida di design, tra l'altro. Noi ne stiamo parlando concentrandoci sull'accessibilità. Però i temi sono simili. ”

Fabrizio: “Si, dicevo quando lavori sul frattale, che è solo il plug-in, ti devi rispondere a tutte le domande necessarie, non solamente, come si fa spesso, se funziona oppure molto peggio, scusami molto peggio, lo uso perché lo usano tutti perché ha 100.000 download e quindi lo posso utilizzare. Questa è una strategia sbagliata, infatti non l'abbiamo mai scritto da nessuna parte.”

Daniele: “Corretto. Il punto non è diventare tutti esperti di accessibilità, ovviamente, ma tutti sapere che deve essere un requisito e poi quindi costringere per esempio i fornitori a rivolgersi agli esperti se non li hanno, oppure essere in grado di capire che se ti dicono è fatto bene fare le domande giuste. Insomma, esistono queste norme, risponde a tutte le norme? Dimostrami come: ci sono dei test, ci sono delle valutazioni. Insomma, si possono ottenere queste cose. Vi faccio vedere un piccolo assaggio di come abbiamo cercato di progettare bene fin dall'inizio tutto il nuovo sito Designers Italia, anche ponendosi queste domande. Quello che vedete qua è uno strumento, uno dei tanti che serve a un progettista come me di esperienze digitale per progettare l'esperienza, quindi una grande lavagna dove si possono creare i prototipi, quelli che si chiamano mock up, quindi degli esempi di pagina che poi saranno sviluppati. Ovviamente arriva dopo un lavoro di progettazione fatto a bassa qualità con dei prototipi in cui la qualità non è importante ma il flusso. Questi sono i prototipi finali, vi faccio vedere che nei prototipi c'è già qui e anche prima, non semplicemente nello sviluppo finale, in ogni fase del processo noi ci siamo sempre chiesti cos'è accessibile o no. Per esempio le card, quindi lo strumento card, lo strumento “carta”, in italiano non torna però lo strumento card che mostra i contenuti della pagina community, è uno strumento che abbiamo completamente ripensato anche rispetto a quello disponibile nel design system del Paese, che vi presenteremo tra poco, ed è un lavoro che quindi integreremo nel design system del Paese. Perché l'abbiamo ripensato? Perché per esempio, e ci sono dei post-it qui annotati che dicono cose del genere: "stai attento quando sviluppi..." "abbiamo ripensato questo perché più accessibile". L'abbiamo ripensato perché per esempio, verrebbe naturale pensare di mettere la data prima di un evento, ma se pensate a quattro eventi di seguito e tutti avessero la data in alto, un utente che non vede ma ascolta, o fruisce in altro modo questi contenuti, percepirebbe solo 10 agosto, 10 agosto, 10 agosto, 10 agosto. Senza sapere che cosa c'è il 10 agosto, senza avere una distinzione se fossero lo stesso giorno questi eventi. Il titolo quindi diventa gerarchicamente il contenuto più importante da vedere per primo. Questo tipo di interventi, che sembra una scelta solo in realtà di gusto a chi non conosce la progettazione dell'esperienza utente, è una scelta che comprende anche scelte di accessibilità. Ti torna Fabrizio quello che sto raccontando?”

Fabrizio: “Assolutamente. Per prima cosa devo capire di cosa sto parlando, non quando succede, qual è il tag di riferimento. Cosa invece vediamo spesso. Anteporre all'elemento primario degli attributi secondari.”

Daniele: “Pensate a una persona che naviga saltando, perché è più facile per lui o per lei saltare di contenuti e cercare nell'indice di pagina i contenuti che vuole leggere. Salterebbe tra durata 20 minuti, 10 agosto, 6 dicembre, leggi su Medium, se fossero scritti al contrario queste; cioè senza capire esattamente che cosa c'è. Questo tipo di scelte, ce ne sono centinaia che un progettista è chiamato a fare oggi, se un progettista non le fa non è che non è un esperto di accessibilità, sta progettando male oggigiorno, perché queste cose devono essere nel bagaglio di qualunque progettista. Torno al sito Designers. Perché vi ho fatto vedere questo? Giusto una frase in più. Perché alla fine di ogni ciclo, quindi, questo è il ciclo fatto per esempio da uno UI designer una persona che progetta interfacce, è bene che prima di passare al ciclo dopo allo sviluppo, esistano questa serie di annotazioni, per esempio, post-it o di altro tipo che raccontino come si fanno le cose. Il design system del Paese semplifica le cose perché il progettista UI che utilizza UI Kit Italia, che è il kit per progettare, passa già a sviluppo informazioni: questo è un titolo di tipo gerarchia tre, quindi sarà un h 3 in sviluppo, vi faccio un esempio banale; questa card ha questi elementi in questo ordine, quindi chi sviluppa sa già che sono in quest'ordine. Questo tipo di informazioni automatiche, nel senso che sono by default dentro le risorse che vengono usate da chi usa queste risorse, fornitore o PA che sia, e questo tipo qua sono in più. L'accessibilità è una cosa di cui bisogna anche dialogare, giusto Fabrizio? È una cosa che non c'è nessun dubbio che non è automatica, c'è bisogno che i progettisti e gli sviluppatori, gli editor, chi organizza il lavoro, chi lo progetta, chi scrive, i requisiti si parlino anche con strumenti del genere.”

Fabrizio: “E questo è importante che tu dici questo del post-it perché crea il collante fra quei due mondi, fa il design e lo sviluppo. C'è un passaggio di informazioni che toglie quel quel baratro che c'è lì in mezzo, cioè chi progetta non sa minimamente di cosa faranno gli sviluppatori e viceversa. Lì dentro, in questo diciamo in questo passaggio di consegne, si creano spessissimo i problemi di accessibilità, ecco perché, come tu giustamente hai detto, è importante aggiungere quel bagaglio di informazioni.”

Daniele: “E tra l'altro, cioè lo stesso vale per ogni fase, per ogni profilo, cioè se il progetto viene consegnato ma agli editor non viene suggerito come usare magari le automazioni fatte per semplificare l'accessibilità o quali sono gli obblighi di accessibilità, non vengono formati, sono loro che poi non rendono il sito accessibile. Considerate che un sito o un servizio, un prodotto digitale è accessibile fintanto che lo è, non lo è per sempre. Non è una qualità che si acquisisce una tantum per tutte le pagine e per tutti i contenuti che ci saranno da lì in poi. È una cosa che va verificata, è una cosa che va continuamente chiesto se funziona o no. E in più quando ti metti a testare con gli utenti veri puoi scoprire che ci sono cose che magari non sono nelle linee guida accessibilità, ma l'utente vero comunque non riesce a fruirle per un altro motivo legato al contesto d'uso e quindi puoi continuare a migliorare. Vado velocemente in un'altra fase, eravamo in quella della progettazione, andiamo in quella dello sviluppo e usiamo sempre il sito Designers per fare un esempio: il megamenu, cioè questo tipologia di menu in cui in in ogni sezione del menu c'è una spiegazione, un'immagine, un accesso al primo livello e accessi ai secondi livelli. Questo megamenu è bello raccontarne la storia, perché qualche mese fa, mentre era in sviluppo proprio tu, Fabrizio, hai scritto un articolo per la rivista web accessibile giusto?”

Fabrizio: “Sì.”

Daniele: “In cui racconti una serie di cose.”

Fabrizio: “Sì, nel senso che i megamenu sono un oggetto quasi sempre inaccessibile. Che non è compreso in nessun, cioè è compreso in pochissimi design system, framework. C'era bisogno di portare semantica, accessibilità, strategia nello studio di questo oggetto, che a me non piace tantissimo personalmente, però è un oggetto molto, molto utile e richiesto nelle fasi di design. Siccome c'è stato questo lavoro di sviluppo, mi piaceva rappresentare questo, questa cosa.”

Daniele: “Ovviamente il tempo è tiranno, però lasciamo a chiunque il link per approfondire, però quello che mi prendeva raccontare è che esce il sito in raccolta feedback su questo dominio temporaneo qualche mese fa, Fabrizio racconta questa storia, indipendentemente dal nostro lavoro. Ovviamente siamo contenti che stiamo facendo un bel lavoro, anche pensando di integrare questo megamenu poi in questa scatola di pezzi che è il design system del Paese, questo nuovo megamenu, però un utente ci segnala su GitHub, guardate, sarà anche accessibile a norma di legge però io che che che ho una condizione di ipovisione e che non vedo bene i colori, la differenza tra questo testo descrittivo e le parole non la capisco, qual è un link? E questo è un confrontarsi con il mondo reale alla fine. Non c'era niente di tra virgolette “contro la legge”, tra tra molte virgolette, in realtà così evidente. Però porsi questa domanda e ritestarlo ci ha portato a fare modifiche ancora al megamenu, seppure era già un buon esempio, in un mondo in cui ce ne sono pochissimi fatti bene. Che è quello che vedete oggi on-line, che ha una navigazione da tastiera ottimizzata e che ha delle leggere differenze da quello che racconta Fabrizio in quell'articolo, per esempio esplora e non panoramica come testo, perché i test di usabilità ci hanno detto che funziona molto meglio per far capire che è un accesso al primo livello. Ha queste piccole freccine a sinistra che indicano il fatto che sia un menu di voci e anche un leggero e diverso peso nelle voci, perché i testi di usabilità ci chiedevano di distinguere meglio tra primi e secondi livelli. Questo per ribadirvi che l'accessibilità, anche una volta sviluppata, è continuamente migliorabile. Questo tipo di strumenti che vi faccio vedere sono a disposizione di tutta la PA, tutta la Pubblica Amministrazione. Andrei veloce su questa parte, che sennò ci rimane poco tempo, che è il design system del Paese, diciamo che è una libreria... entro dentro così ve lo ve lo faccio vedere. Di cui la documentazione... diciamo che è un grande framework fatto in realtà di più cose. Un pezzo è la documentazione che vive sul sito Designers Italia, con istruzioni su come iniziare per designer, per sviluppatori, per responsabili progetto. Che cosa c'è di importante da sapere per un responsabile di progetto: dalla norma, all'azione, l'attuazione, oltre alla norma, a che cosa serve il design system. Per designer, quindi per progettisti come me: quali sono le risorse, il famoso UI Kit Italia. Per sviluppatori: quali sono le risorse Bootstrap Italia, che è una libreria, un framework di sviluppo che ha già tutti i componenti del kit di interfaccia. E poi dentro i componenti: cioè i pezzi del puzzle, per assemblare un'interfaccia, per esempio, questo è un accordion, questa è la scheda di documentazione che racconta un accordion, che è uno strumento per racchiudere più contenuti in un flessibile, in una fisarmonica in italiano, che si può vedere su mobile, su tablet, su desktop. Si può avere istruzioni di Content Design, di contenuto, di progettazione, quando usarlo, come usarlo, a cosa serve, eccetera. Però quello che mi preme farvi vedere è che qui vive la documentazione e l'accesso a come usare queste risorse, UI kit Italia per designer, Bootstrap Italia per sviluppatori, un domani il kit per React e Angular che sono altri framework di sviluppo per altri tipi di sviluppo. Qui vivono Fondamenti che spiegano, per esempio, come si usa il linguaggio, che tono di voce bisogna usare, con esempi anche di cosa va bene o non va bene di come si scrivono le cose nei nostri siti e servizi. Però vive anche altro. Vivono delle scelte sempre per semplificare il mondo dell'accessibilità by design e by default. By default, perché questi componenti noi li testiamo continuamente per l'accessibilità. E quindi, tornando all'accordion qui sotto, per esempio, c'è accessibilità ai test che sono stati fatti: visivamente accessibile, amichevole con lettori di schermo, navigabile, comprensibile. E ovviamente si possono aprire segnalazioni su GitHub e su Bootstrap Italia se si vedono cose migliorabili, come è successo per il sito Designers Italia. Però ci sono due cose in particolare su cui Fabrizio forse potremmo mettere l'attenzione in questi ultimi 6 o 7 minuti. Il primo, una scelta che ancora non abbiamo raccontato bene, ma che secondo me è molto importante per chi, come noi, si occupa di accessibilità. Nella scheda di sviluppo di ogni componente è disponibile sempre l'anteprima e il codice riusabile, si può copiare. Inoltre è disponibile questo tasto qua, a cui ancora non abbiamo dato evidenza particolare perché lo vogliamo raccontare in autunno all'interno di video tutorial che faremo su come funziona. Ma questo tasto fa una cosa molto particolare, se io lo clicco mi apre questa fisarmonica in una pagina a sé. A cosa serve questo Fabrizio?”

Fabrizio: “È importantissima perché permette di percepire quell'oggetto isolato dal contesto. Perché per fare un test reale, un test efficace con le persone che utilizzano anche tecnologie assistive, è importante isolare gli oggetti al di fuori del contesto, perché potrebbe essere fuorviante, potrebbe non far capire esattamente qual è l'oggetto che si sta analizzando. Infatti questa è una caratteristica che è stata introdotta recentemente. Che devo dire è molto importante per l'evoluzione di questi componenti, anche attraverso la raccolta di feedback.”

Daniele: “Vi faccio vedere un'altro componente. Abbiamo 5 minuti di storia ancora da raccontarvi e poi apriamo 10 minuti di domande e proviamo a rispondervi. Un altro componente, che ancora non abbiamo raccontato bene perché è in via di stesura il contenuto di questa scheda, è il nuovo video player. Fa fa un sacco di cose che vi racconteremo prossimamente, compreso essere un componente sviluppato per essere GDPR compliant, quindi per rispettare la privacy. Però è anche un componente accessibile, è un video player completamente accessibile che si può usare per usare servizi di streaming o per avere video anche in locale. Un video player che ha già integrate modalità per avere sottotitoli e trascrizioni, che vi ricordo sono obbligatori. State attenti a incorporare direttamente video da piattaforme senza porvi il problema di come impattano sull'accessibilità delle vostre piattaforme, perché integrare una risorsa da una piattaforma video senza avere sottotitoli o trascrizione, vuol dire rendere la stessa piattaforma non accessibile, non solo il video. Diventa una di quelle cose per cui nella dichiarazione di accessibilità dovresti scrivere che non sei accessibile perché integri i video da piattaforme che non hanno sottotitoli o trascrizione. Giusto Fabrizio?”

Fabrizio: “Assolutamente.”

Daniele: “Colgo l'occasione di questo componente per farvi vedere che alcune parti di questa documentazione, ma non delle risorse, quindi non del kit per la progettazione o del kit per lo sviluppo, contengono le diciture “in stesura”. Questo perché questa documentazione è ancora la versione alfa. Se cliccate qua vedete che c'è un changelog. C'è un racconto di cosa sta succedendo, giorno per giorno si sta evolvendo. Praticamente gli ultimi aggiornamenti sono del 12 maggio e lunedì va online da alfa.7 e durante l'estate andrà on-line la beta, quindi sarà completa di tutti i contenuti probabilmente. Però le risorse collegate, quindi il kit UI raggiungibile dalla voce "Per designer" che è qua. Basta cliccare "vai alla versione corrente" che già sappiamo essere utilizzata da moltissimi fornitori per progettare siti e servizi. Noi stessi li utilizziamo. E il il kit per sviluppatori, il framework per sviluppatori Bootstrap Italia, per esempio. Ma ci sono anche in sviluppo gli altri framework. Qua ci sono tutti i link. Sono utilizzati correntemente da migliaia di piattaforme. Per capirsi, la versione attuale di Bootstrap Italia è la stessa integrata nei siti e servizi finanziati col PNRR delle scuole e dei comuni, quindi una risorsa sicuramente manutenuta e aggiornata. Vi dicevo prima, ci sono due cose relative all'accessibilità, due grandi novità che ancora non abbiamo raccontato e stiamo raccontando a voi. Uno quel tasto e l'altro è il fondamento accessibilità. E chiuderei su questo. Il fondamento accessibilità è una scheda della documentazione del design system del Paese che racconta l'approccio, quello che abbiamo anche introdotto a voi relativo ai concetti by design e by default. C'è un approfondimento su Medium che è questo articolo scritto da me e Fabrizio a luglio del 2022, in cui raccontiamo come si deve progettare bene, i 10 punti per fare meglio un servizio digitale. E non solo, perché, vi dico la verità, è relativo a come si progetta in digitale in generale. Perché questo non vale solo per la Pubblica Amministrazione. Le linee guida e il rimando alle WCAG, che sono la norma tecnica di riferimento a cui fanno riferimento anche le norme legislative. I due livelli che vanno raggiunti per essere in regola. Non è che si possono raggiungere solo alcuni criteri. Le WCAG sono 50 e più criteri, non è che si possano scegliere. Una domanda tipica "quali sono le più importanti da rispettare?" Tutte. La risposta è che non è che se progetti una macchina puoi rispettare sono alcune leggi su come si progettano le automobili ma tutte. I profili coinvolti in stesura, quello che raccontavamo a voi, però c'è una cosa qua che è bene raccontare. Come si fanno i test di accessibilità? È una domanda tipica, no? Mentre sviluppo come li faccio? Ovviamente hai bisogno di un esperto. Però, oltre aver bisogno di un esperto, specialmente per le cose complesse, per esempio per le banche come tu, Fabrizio, raccontavi prima, un sistema per pagare ha bisogno per forza di una valutazione esperta, non può essere rimandato a uno sviluppatore o un designer la scelta di come si fanno le cose. Però qui c'è un processo che chiunque può utilizzare, specialmente un progettista, uno sviluppatore, un tecnico, ma non solo loro, perché è spiegato per tutti. Il processo si può seguire per fare diverse cose come testare il codice scritto. Una delle cose più importanti è scrivere codice fatto bene. L'HTML base che insegnano in quasi qualunque scuola superiore.... se impari a scrivere bene quello stai già facendo una cosa accessibile. Ci sono possibilità di fare test automatici. Vi ricordo che le ultime misurazioni scientifiche dicono che si riesce a misurare un 20% dei problemi in automatico, più o meno dal 20 al 50%. Però non è che se un test automatico ti dice che sei a norma, puoi scrivere che sei a norma da qualche parte. La dichiarazione di accessibilità non è a norma, giusto Fabrizio?”

Fabrizio: “Esattamente. Diciamo che hai detto una percentuale, una forbice giusta, 20-50%. Ci stiamo dentro.”

Daniele: “Diciamo che sono strumenti importantissimi perché servono a fare reminder o perché ti suggerisco anche cosa controllare a mano. Questo lo fanno gli ultimi, più evoluti. Però sono strumenti in più, se non sai cosa stai testando. Uno dei passaggi più importanti è questo: testare a mano. Quindi simulare una navigazione reale, per esempio da tastiera, per esempio ingrandendo il contenuto fino a 400% sulle viewport larghe 1280px. Qui ci sono tutte le specifiche. E uno dei test fondamentali è testarlo con gli screen reader. Diciamo che non si può dedurre come funziona con uno Screen Reader, o almeno non del tutto se non sei un super esperto, finché non lo fai davvero.”

Fabrizio: “Sì, se vuoi lo vedo anche nelle domande. Quindi anticipo una domanda. Il test con uno strumento automatizzato può essere un supporto, un aiuto. Non lo dico io o altri colleghi, lo dicono le WCAG stesse. Dicono che il test automatizzato è un aiuto che puoi prendere, a volte molto importante, per fare i tuoi test, che però devono essere condotti anche a mano, perché l'accessibilità è un problema di semantica, quindi di significato degli oggetti. E quindi, purtroppo, per molti sostenitori del completo automatismo, rientra nella sfera della del dominio umano. Questo è un punto essenziale.”

Daniele: “Diciamo due cose in più e poi chiudiamo e apriamo le domande davvero, anche se tu hai già anticipato la prima risposta. Due cose da dire. Innanzitutto gli automatismi nel nostro mondo sono importantissimi. Penso a uno sviluppatore che può mettere soluzioni tipo pa11y per esempio, o un Linter per chi di voi sviluppa, sul proprio codice che continuamente gli suggerisce "guarda, hai scritto male questo pezzo", "guarda, la semantica di come è scritto questo HTML non è corretta", oppure pa11y che controlla, sempre l'esempio banale vi faccio ma almeno il più comprensibile, "hai messo un bottone ma in realtà è un link". Cioè non è un bottone che fa succedere un'azione "salva", ma ti sta portando su un'altra pagina. "Sei sicuro che sia la semantica giusta?". Questo tipo di test sono i più importanti di tutti, per lo sviluppatore, ma cominciano a esserci anche per designer e ci sono ovviamente per editor. Si possono integrare dentro le piattaforme, per esempio per CMS. I test sull'accessibilità, nel senso far testare una pagina, qui ci sono due strumenti, ce ne sono tanti altri, solo a titolo di esempio questi due. Sono importantissimi perché anche questi supportano i test. Però se non c'è un umano che è in grado di intellegire, di fare tutti gli altri che non è possibile fare in automatico, di fare questi, non si può dire di essere accessibili, non c'è nessun modo di poterlo dire. Giusto Fabrizio? Tra l'altro non c'è nessun modo di esserlo, perché non è solo un problema di dirlo. L'accessibilità bisogna toglierla dal dominio della burocrazia. Cioè quella dichiarazione è "sono accessibile", se non lo sei stai dichiarando il falso a casa mia e non solo. E quindi l'importante è essere accessibili e non riempire la dichiarazione di accessibilità. Chiuderei su una domanda. Ti viene in mente un caso in cui non solo si possono formare persone a testare l'accessibilità, ma è bene coinvolgere un super esperto di accessibilità, essere sicuri che il fornitore abbia un esperto di accessibilità nelle sue fila, non soltanto che ti dica che è accessibile? Ti vengono a mente dei casi del genere? Facevo l'esempio banale, ma l'ho raccontato male (se vuoi aggiungi qualcosa) della banca e del pagare. Sono convinto che ce ne sono altri.”

Fabrizio: “Sì, diciamo ci sono due aspetti. Secondo me uno è quando hai un touchpoint che è assolutamente fondamentale per il servizio, è quello per esempio per pagare oppure "Accedi", accedi con quello che vuoi. Perché non è la lettura di uno dei 67 articoli, è un punto cruciale. L'altro è quando pretendi di sviluppare un pezzetto che è, diciamo, completamente, come si dice nel nostro modo, custom. Ossia non esiste su Bootstrap, non esiste da altre parti. Vuoi fare, come si dice sempre in maniera..., il figo, per avere una cosa molto innovativa.”

[...]