CSS Day 2020: il punto sull’accessibilità

Il CSS Day è un appuntamento a cui cerchiamo di non mancare mai. Per noi è un’occasione di riflessione molto importante per confrontarci con la comunità degli addetti ai lavori e lo stato dell’arte, in un momento di ritrovo e incontro. Quest’anno, per ovvie ragioni di forza maggiore, la più importante conferenza italiana sul CSS si è svolta in remoto, permettendo ai partecipanti di incontrarsi solo virtualmente. È stata un’esperienza nuova e interessante in questa modalità inedita, almeno per noi. In un certo senso questa versione remota del CSS Day ha avvicinato la comunicazione perché ha permesso a tutti di stare nella stessa stanza, nella stessa conversazione. Ma, almeno per noi, non conoscendo direttamente la maggior parte dei partecipanti, data anche la distanza geografica, lo schermo di distanza non ci ha aiutato nel partecipare attivamente. Nel nostro caso abbiamo interagito tra di noi, in una nostra call, un po’ come se fossimo seduti accanto.

Il mio talk preferito è stato quello di Massimo Artizzu di cui questo blog post attinge a piene mani nei contenuti e ringrazio molto per averlo portato al CSS Day 2020. L’Accessibilità del Web è un tema che mi sta molto a cuore e per cui è auspicabile una svolta culturale per abbracciarlo. Se ne parla da anni ed è bello immaginarlo come la gocciolina d’acqua che nel tempo, con la sua forza piccola ma inesorabile, prima o poi buca anche una roccia.È un tema fortemente etico, pratico, e diciamolo anche un po’ noioso in confronto ai trend di design che ricercano gli effetti wow e il colpo d’occhio.Come dice Massimo:

Bisogna premettere che l’accessibilità non è solo per chi è non vedente, ma è per tutti. Con il naturale aumento dell'età degli utenti anche piccoli difetti alla vista sono sempre più diffusi, come la presbiopia. Dunque quello che oggi vediamo bene tra qualche anno potrebbe essere difficile da leggere, anche con degli occhiali. Non va quindi visto come una sorta di angolino nascosto del lavoro di chi progetta e realizza UI, ma piuttosto come parte integrante degli obiettivi che ci diamo normalmente verso qualsiasi utente. Rendere un sito accessibile migliora l’esperienza di navigazione e anche la qualità del lavoro.Se per noi è facile vedere e immaginare il prodotto che stiamo costruendo in un normale schermo, che sia di un dispositivo portatile o fisso, non è altrettanto facile capire come uno screen reader interpreta l’output prodotto dalla nostra app, quindi come il prodotto verrà visto e fruito da chi non ha una visione regolare o non ce l’ha affatto. Massimo ci spiega in maniera molto chiara e semplice che la lettura di uno screen reader è di tipo monodirezionale, quindi molto simile a quella di un sito responsive nella sua visualizzazione da mobile. Ottima notizia! Vuol dire che lavorare mobile-first è un’ottimo modo anche per capire se l’ordine dei contenuti e la loro lettura è comprensibile da uno screen reader.Andare anche oltre, perché l’accessibilità non è solo una soluzione a chi è non vedente, ma è anche nelle piccole cose che influenzano l’esperienza di qualsiasi utente: dimensione dei font adeguata, line-height che permetta una leggibilità ottimale, uso di icone con label comprensibili che non lascino spazio ad ambiguità rispetto al contesto, e l’uso di palette colori che non affatichino la vista in varie condizioni di luce ambientale.

La discussione in merito è in corso da anni e non ancora risolta. Si può pensare che i due mondi siano inconciliabili, c’e chi prova a trovare delle mediazioni, ma non tutti sono convinti che il problema sia ben posto.Una UI che offre un contenuto comprensibile e accessibile per chi ha difficoltà visive o cognitive è comunque una UI ben funzionante per chiunque. L’esempio migliore che posso portare è il sito web di Nielsen Norman Group.Dimensione dei font, ed insieme contrasto di colore tra testo e il suo sfondo sono un fronte caldo di discussione. Di recente i browser come Chrome hanno incorporato strumenti di misurazione agili per aiutarci a capire se i requisiti di accessibilità su questi due parametri sono sufficienti.Non ci sentiamo di dare una risposta a questo tema, anzi piuttosto possiamo allargarne la discussione: qual è il rapporto tra funzione espressiva e funzione comunicativa delle UI che realizziamo nel 2020?Tutti possiamo osservare che il mondo del design web si è direzionato negli anni verso UI tutte simili, piatte, semplici, ma estremamente comunicative ed efficaci per gli scopi che devono raggiungere. Possiamo vederlo come una conseguenza dell’allargamento e specializzazione di campi di ricerca relativi alla UX, e la loro fitta comunicazione con le esigenze di business. Da questo punto di vista sembrerebbe inevitabile l’adozione di un punto di vista paradigmatico sull’accessibilità.Ma non è così semplice. Qualcosa non ci soddisfa del tutto. Forse siamo nostalgici del vecchio web pionieristico. Forse la componente estetica ed espressiva della comunicazione visiva reclama comunque il suo spazio. Anche e soprattutto in prodotti come le UI web che hanno spazi e tempi di fruizione sempre più ridotti. 

In aiuto a questa situazione sono arrivati di recente nuovi strumenti tecnici. Il problema e relativa sfida nasce e si risolve nel coniugare in una sola UI tante esigenze. Ma il responsive ci ha già portato a pensare e produrre delle UI che esistono contemporaneamente in forme e modalità interattive diverse.Le media queries sono strumenti che ci permettono di comprendere il contesto dell’utente che sta utilizzando la nostra app, e quindi adattare la UI e UX alle sue preferenze. Quella usata da chiunque abbia fatto un sito responsive è relativa alla dimensione della finestra, e permette di capire, o perlomeno intuire con relativa certezza, se la fruizione del sito sta avvenendo da uno smartphone, da un tablet o da un desktop. Con le Interaction Media Queries abbiamo iniziato a raffinare questa identificazione utilizzando anche il tipo di sistema di input usato dall’utente: touch o meno, preciso o meno.Con le Media Queries Level 5 possiamo andare ancora oltre e capire se l’utente ha particolari esigenze:

• prefers-reduced-motion
• prefers-color-scheme
• prefers-reduced-transparency
• prefers-contrast

Dunque se sappiamo tutto questo possiamo predisporre una UI adatta a quelle precise esigenze dell’utente, e proporgli versioni alternative e accessibili di caroselli, effetti di parallasse, animazioni e transizioni. Ma anche schemi di colore e rapporti di contrasto adatti a quanto richiesto.Queste nuove media queries non sono ancora tutte supportate dai browser, ma forse sono un passo ulteriore verso il creare UI sempre più adatte agli specifici bisogni degli utenti.

Nel 2017 abbiamo avuto la prima richiesta esplicita di rispetto dei requisiti di accessibilità in un progetto web: il sito delle Gallerie degli Uffizi. Abbiamo testato il prodotto con vari strumenti e realizzato una modalità ad altro contrasto che l’utente può attivare direttamente dalla UI. Una piccola funzione ma che ci ha permesso di offrire comunque un sito graficamente più curato ed appagante nella versione “standard”, e meglio leggibile nella modalità “alto contrasto”.

Sappiamo che al momento la maggior parte dei prodotti che realizziamo sono da migliorare da questo punto di vista. Ma la strada è tracciata e già da qualche mese ci siamo muovendo attivamente per implementare il paradigma dell’accessibilità nel nostro workflow e renderlo finalmente un default, almeno in tutti quei requisiti che siano facilmente testabili con un processo automatico. Va anche considerato che dopo il famoso GDPR un nuovo regolamento europeo è entrato in vigore l’anno scorso: European Accessibility Act. Non sappiamo ancora come questo darà una spinta concreta all’adozione e si integrerà con la normativa italiana a riguardo, ma stiamo seguendo la cosa con attenzione.Chissà che il 2020 sia l’anno in cui la gocciolina vince sulla roccia :)