Accessibilità diritto o dovere? (capitolo 2)

Clicca qui per leggere il capitolo 1 di Accessibilità diritto o dovere? 

Accessibility matters

Accessibilità oggi non è più un dovere ma un diritto. Un diritto per chi non può, il diritto di costruire qualcosa per tutti, senza tralasciare nessuno. Per parafrasare qualcuno: ma davvero c’è bisogno di una legge? Dovrebbe essere naturale pensare che un design possa funzionare in modalità differenti, che lo user-centric design debba coinvolgere diverse tipologie di users, e non solo le personas che il marketing ha in mente quando pensa alle conversion. Perché non dobbiamo mai dimenticare che in quelle personas il 15% avrà bisogno di strumenti di assistenza, di configurazioni particolari del device, dell’architettura dell’informazione, della scrittura del codice.

Per me è diventata Accessibilità by Design perché se non si parte dalla testa, dal concept, poi ci si scontra con tutta la filiera dello sviluppo e del test.

Deve diventare la missione di ognuno, non scordarsi mai che esistono browser differenti, device differenti, linee guida differenti dedicate alle varie disabilità, metodologie per cominciare a progettare app e siti friendly. Anche se il vostro prodotto o servizio non gravita attorno alla PA. Perché non è un lusso che possiamo permetterci. Non vogliamo il bollino, vogliamo abbattere le barriere digitali.

La cassetta degli attrezzi

Vorrei suddividere i suggerimenti pratici per ogni fase del ciclo di vita di produzione del vostro software, in modo da essere più agili e comodi quando, mi auguro, un giorno verrete a ritrovare le info per il vostro progetto accessibilissimo.

1. Your mindset: l’accessibilità deve diventare un concetto vostro, un dogma inscalfibile, oggi ve lo sto donando affinché ne facciate tesoro. Io l’ho ricevuto da una persona splendida con cui ho condiviso oltre 10 anni della mia vita professionale (forse 15 ma non lo diciamo, è permalosa). È riuscita a snaturare il mio essere informatico, inventarsi la user experience quando in Italia si parlava ancora di interfacce grafiche, farmi capire come ci si sente quando uno dei tuoi sensi ti tira un brutto scherzo. Se cominci a pensare con questi orizzonti allargati, tutto ciò che genererai sarà a prova di inclusività. Budget e attori successivi permettendo. Scherzo.
   
   
2. User-Centered Design: forse siamo stufi di metodologie di progettazione, oggi ne vanno di moda altre, vogliamo essere agili, fare gli sprint, chi se ne frega dei piani di lavoro, noi facciamo i backlog… Ne abbiamo parlato su in più punti: ci sono tante, differenti casistiche di disabilità a vari livelli; il 15% della vostra base utenti potrebbe averne una o più di una, i designer e voi stessi potreste non avere idea di cosa significhi viverci. La UCD è roba anni 2000, ma è l’unica che potrebbe permettere di selezionare personas e scenari che contengano target con disabilità (probabilmente la vostra azienda o il vostro committente ha già ricevuto urla di protesta, ma ad ogni modo attenti ai dati ipersensibili su queste persone e al loro trattamento secondo la GDPR), quindi si possono dare delle priorità. L’AGID nelle sue linee guida suggerisce una metodologia di progettazione che coinvolga e testi con gli utenti il design e la prototipazione. Quindi consigliato vivamente, progettare con un campione di utenti reali, con disabilità comprese, vi assicura un risultato con un buon grado di acceptance e conversion, piuttosto che seguire altre logiche più business o chief oriented.
   
   
3. Le linee guida dei BIG: lo dicevamo qualche paragrafo fa, sistemi per “rendere accessibili” siti e app ce ne sono già, esistono i tool assistivi, come gli screenreader. È vero che se scrivete le cose male e chilometriche, mettete le voci di menù random, i campi alla rinfusa non è proprio un piacere passare a trovarvi. Un vocale da 10 minuti, che vi bloccano e Ciao! Giusto per ricordarselo, l’AGID ha un form online dove gli utenti possono segnalare queste situazioni al difensore civico per digitale, quindi non prenderei le cose sottogamba. Da qualche anno Apple e Google hanno pubblicato una sezione per sviluppatori dedicata all’accessibilità, su vari device e per varie disabilità:
   
   a. Apple include specifiche per usare il VoiceOver
   b. Google sezione Accessibility del Material Design
   
   Solo un amarcord dedicato agli appassionati della mela. L’anno 2011 in cui fu annunciata SIRI, pochi avevano notato che nel teaser, sempre toccante, oltre a capire che potevi dialogare con una bambola parlante, fissare appuntamenti mentre correvi e così via, in realtà tutto questo “hands free” aveva già le potenzialità di aiutare alcune categorie a rendere più semplice e teneramente inclusiva la propria vita. Ve lo lascio qui sotto.

4. Lo sviluppo: dello sviluppo abbiamo già parlato tanto. Specie quando all’inizio dell’era web alcune professioni non erano ancora nate, tutto era nelle dita dello sviluppatore: anche rispettare alcune accortezze che abbiamo visto nel paragrafo riservato all’uso dell’HTML. Oggi con il supporto del design, della user experience e del content generation, i pesi si ridistribuiscono. Le architetture informative vengono descritte e alleggerite per creare menù con le giuste priorità sui – o senza - sotto item, i testi dovrebbero essere più concisi e immaginati recitati da un sintetizzatore vocale (TTS – Text To Speech per gli amanti degli acronimi), lo sviluppatore dunque dovrà avere anche skill sull’uso di questi strumenti vocali che se per un verso “leggono” ciò che l’app rappresenta e prioritizza, dall’altra riconoscono gli input vocali che l’utente fornisce (Riconoscimento vocale, da non confondere con quello biometrico che è un’altra cosa, e ci porta verso il mondo della security).

5. Collaudo o Qualità?: mi diverte molto quando parlando del ciclo di vita del software si parla di Test. Tutti vogliono lo stesso trono, basta capire solo a quale casata si appartiene. Senza spoilerare e senza essere Jon Snow, di casate ne ho girate un po’. Tutti vogliamo che il nostro progetto sia perfetto, impeccabile e piaccia a tutti. Ma li abbiamo ascoltati una decina di quei potenziali tutti? Va bene testare il codice, i link, le impaginazioni, l’accesso ai dati, le formule e i calcoli, va bene testare tutto assieme senza lotte intestine tra chi ha disegnato la UI e guarda solo gli ingombri, chi ha scritto il copy e corregge i typo, e chi conosce il prodotto e sa che quella somma è palesemente errata (arrotondando arrotondando…). Sono sempre dell’avviso che il punto 2 che mette l’utente al centro della progettazione, con un flip diventa 5, e anche il test non può tralasciare il coinvolgimento di una platea che vada oltre il gruppo di lavoro. Chiamate i draghi! - o anche no. Un beta test può coinvolgere i family & friends, ma poi bisogna raccogliere in modo sistematico segnalazioni, dar loro compiti, fare in modo che siano imparziali, che rispettino le vostre scadenze etc… Oppure affidarvi a un crowd con una community che probabilmente avrà modo di selezionare utenti simili al vostro target e fare il lavoro sporco per voi. E lasciarvi la parte divertente. In una community di tester probabilmente il 15% potrebbe avere le caratteristiche di usabilità che fanno al caso vostro, e che renderanno la vostra app e/o il vostro sito accessibile a loro e scevro di pericolosi bug da day one, facendovi dormire sogni più sereni. Ben approdati su UNGUESS.

L’era della consapevolezza globale

Ci sono varie teorie new age che segnano in questi anni un grande shift della nostra consapevolezza verso temi e tempi più alti, spirituali, comunicativi, meno ancorati al materiale, allo sfruttamento delle risorse della terra, alle guerre degli uni contro gli altri (ok sembra la trama del musical Hair e di Age of Aquarius, ma qualche dubbio me lo fanno venire). In realtà questo cambiamento era cominciato già prima dei grandi lockdown, solo che eravamo un po’ più distratti, ognuno preso dagli impegni del proprio ufficio, dalla famiglia etc…

Non è probabilmente un caso se dopo tutti questi anni di programmazione, progettazione, creazione e curiosità tecnologica, il mio radar abbia cominciato a captare i bisogni intangibili, quelli che forse non misuri con il breakeven point, ma hanno un ROI che oltre a una eventuale monetizzazione ti rende consapevole che ciò che stai facendo lo stai facendo bene, per te, per la tua famiglia, il futuro dei tuoi figli, e tutti quelli che ti sono prossimi e via via a onde concentriche fino ad arrivare a chiunque userà la tua app, il tuo sito, leggerà il tuo articolo, che tu avrai contribuito a creare, a testare, a scrivere, a pubblicare.

Siamo partiti dall’accessibilità perché è un tema importante per me, per la comunità e penso che dovremmo arrivare a un punto in cui non ci sarà più bisogno di parlarne perché dovrà diventare naturale e fisiologico per noi del mestiere includere tutte le persone con difficoltà tra gli utenti più agili dei nostri prodotti e servizi. Ma prima di allora dobbiamo creare, insieme, la consapevolezza e il senso di inclusività.

È proprio l’inclusività che troveremo frequentemente negli Obiettivi di Sviluppo Sostenibile - SDGs che affronteremo in questa rubrica, 17 obiettivi globali che le aziende e i singoli nel loro piccolo, nel lavoro di ogni giorno e nel loro mindset, devono perseguire entro il 2030 per rendere il mondo un posto migliore dove far crescere i nostri figli e dove cercare di rimediare ai danni degli ultimi due secoli.