Non serve strafare

jacopo deyla
5 min readSep 24, 2018

Il pasticcio dell’usabilità in una legge sull’accessibilità

Ecco il terzo articolo sul DL 106/2018 dopo Meno accessibilità per tutti e La lunga coda… di paglia

Personalmente e dopo tanti test con utenti con disabilità, so molto bene che l’accesso da solo non basta. E’ inutile fare una porta abbastanza grande per farti entrare nel mio sito (l’accesso) e poi quando sei dentro ti faccio perdere tra mille pastoie burocratiche, testi incomprensibili, passaggi senza senso, ecc. ecc.

Poter entrare non basta, si deve poter usare e capire.

E quindi non è tanto il sito della PA tecnicamente che deve cambiare, quanto le procedure e l’interpretazione delle norme che devono seguire il buon senso e le regole del buon web. E questo è un processo lungo che passa dalla semplificazione del linguaggio, fino ad arrivare a strumenti semplici che permettono ad esempio, l’identificazione certa dell’utente (es. SPID). Su questo AGID e il team digitale stan facendo davvero tanto.

Quindi ben venga tutto quello che porta in primo piano l’usabilità e i suoi concetti. Ben venga anche perchè l’usabilità è anche il mio lavoro e la mia passione. Ma qui, no, non si può tirarla in ballo!

Questa legge parla di accesso, non parla di qualità, di fruibilità, parla in termini astratti e generali. Purtroppo, una misteriosa mano, nottetempo ci ha scolpito dentro cose, che sono completamente fuori (stile, linguaggio, obiettivo, ecc. ecc.)

E anziché fermarci a quel che ci chiede l’Europa, e anziché cioè recepire la direttiva, come dovremmo semplicemente fare, abbiamo fatto il pasticcio.

2. Sono accessibili i servizi realizzati tramite sistemi informatici, inclusi i siti web e le applicazioni mobili, che presentano i seguenti requisiti:

a) accessibilita’ al contenuto del servizio da parte dell’utente;

b) fruibilita’ delle informazioni offerte, caratterizzata da:
1) facilita’ e semplicita’ d’uso, assicurando, fra l’altro, che le azioni da compiere per ottenere servizi e informazioni siano sempre uniformi tra loro;
2) efficienza nell’uso, assicurando, fra l’altro, la separazione tra contenuto, presentazione e modalita’ di funzionamento delle interfacce, nonche’ la possibilita’ di rendere disponibile l’informazione attraverso differenti canali sensoriali;
3) efficacia nell’uso e rispondenza alle esigenze dell’utente, assicurando, fra l’altro, che le azioni da compiere per ottenere in modo corretto servizi e informazioni siano indipendenti dal dispositivo utilizzato per l’accesso;
4) soddisfazione nell’uso, assicurando, fra l’altro, l’accesso al servizio e all’informazione senza ingiustificati disagi o vincoli per l’utente.

Cioè

  1. si ribadisce nuovamente il concetto di accessibilità, appena spiegato al punto a) per estenderlo col punto b); ovvero si estende la legge su un argomento, direttamente al suo interno;
  2. ogni qualità richiesta contiene esempi, che diventano legge, quando la norma invece in tutti gli altri punti è lungimirante e lascia ogni applicazione a successive linee guida, aggiornabili e più elastiche.
  3. si introduce il concetto di fruibilità e si dichiara che corrisponde alle tre qualità dell’usabilità, più una, la facilità e semplicità d’uso; cioè la fruibilità include un’euristica dell’usabilità stessa, più la sua definizione; per uno un po’ tecnico, un pasticcio, nel pasticcio;

Perchè è un pasticcio

Per diversi motivi, ma il principale è che l’accessibilità in parte si può oggettivare grazie a dei requisiti tecnici piuttosto precisi, l’usabilità no.

Quando fai un bando o una gara e chiedi a un fornitore di darti una soluzione accessibile, tu poi puoi controllare che lo sia o un concorrente può contestare l’assegnazione, verificando i vari contenuti. E’ una verifica che può fare un tecnico da solo, costa tempo, ma è fattibile e parzialmente oggettiva.

Es.
il codice HTML non è valido, e lo verifica un tool automatico, la fornitura non è a norma. I colori non contrastano sufficientemente, e lo verifica un altro strumento, la fornitura non è a norma. Non c’è un testo alternativo o c’è ma è sbagliato, su un bottone, la fornitura non è a norma. ecc. ecc.

Prendiamo la nuova definizione, e scegliamo ad esempio l’ultima qualità, la soddisfazione: come si fa a dire che il disagio causato all’utente nell’accedere sia ingiustificato?

Quale utente? Quale disagio? Come facciamo a verificare che sia davvero ingiustificato?

Non si può! Si può solo osservare l’esperienza di tanti utenti, con delle verifiche qualitative. Con un numero di utenti sufficiente si può avere un dato statistico, e non oggettivo, sulla presenza di un certo disagio, che comunque è qualcosa di impalpabile. Il dato statistico può avere una precisione elevatissima, ma quando possiamo considerarlo al pari di un valore binario, VERO/FALSO, SODDISFATTO/NON SODDISFATTO come avviene per molti dei requisiti di accessibilità?

Le linee guida ci salveranno (?)

Fortunatamente col Gruppo di lavoro sull’usabilità (GLU) stiamo lavorando da un sacco di tempo sull’usabilità nella PA e nella penultima revisione abbiamo proprio introdotto un argomento utile alla soluzione di questo nuovo problema che solleva la 106.

Se non si può oggettivamente verificare la qualità ma solo misurarla con gli utenti, si può però oggettivamente verificare che si sia fatta almeno la misura.

Sono quindi nate le Linee guida sugli appalti HCD, che forniscono alle PA delle indicazioni su cosa chiedere ai propri fornitori affinché gli venga dato un prodotto qualitativamente valido. Lo scopo di quel documento è di dare a una PA, una traccia per scrivere un bando, un appalto, in cui si richiede al fornitore di fare certi tipi di verifiche con gli utenti. Il fornitore una volta che le fa, deve produrre degli output (es. delle registrazioni delle sedute, dei report, ecc.). Poi deve mostrare che le problematiche emerse, sono state risolte e come. Il cuore di tutto, è che il fornitore deve in un qualche modo dimostrare di aver inserito gli utenti nel processo di sviluppo.

Ora, il testo della legge forse non si può cambiare, anche se tutto quell’articolo 2 andrebbe cancellato, considerato che di fruibilità, semplicità e altre caratteristiche se ne parla già nel CAD nell’art. 53, ma quel che si può sperare, è che si dimentichi che c’è e si scriva almeno nelle linee guida che seguiranno, qualcosa di più sensato.

Il primo dovere delle future linee guida è quindi già tracciato così come a chi si deve ispirare: al GLU e alle Linee guida sugli appalti HCD.

--

--