Spesso si sente dire o si dà per scontato che accessibilità (a11y) ed esperienza utente (UX) siano due mondi separati con pochi punti di contatto: il primo riguarda soltanto gli utenti che utilizzano tecnologie assistive e, in contrapposizione, il secondo è pensato per il navigatore “medio” di un qualsiasi sistema.

Probabilmente non c’è nulla di più lontano dalla realtà. 

È possibile, quindi, fare incontrare queste due rette parallele e discipline apparentemente  difficili da intersecare?

Certo che è possibile, anzi è molto importante che ciò accada.

Accessibilità by Design ed Esperienza utente

Per implementare l’accessibilità by design e non by patch, la collaborazione tra i reparti di una qualsiasi realtà, ad esempio un’azienda, è fondamentale: business, designer e sviluppatori non devono isolarsi nel loro dominio come se fossero compartimenti stagni, ma condividere idee, intuizioni, identificare i punti di stallo, le criticità, le innovazioni create ad hoc per non far “impantanare” l’utente. In una parola, dialogare. E questo “esercizio” permette di migliorare anche l’esperienza utente.

Immaginiamo di dover costruire una casa: pur utilizzando i migliori materiali del mondo, mattoni di prima qualità, il miglior cemento e tutti gli attrezzi corretti se ingegneri e muratori non si parlano il rischio di costruire un “ecomostro” o un edificio pericolante è altissimo.

Molte volte, nella mia esperienza lavorativa di Web Accessibility Expert, mi è capitato di partecipare a riunioni dove il tema centrale fossero alcuni elementi del Design System di un sistema, e che i team di design e di sviluppo fossero pesantemente ancorato ognuno alle proprie idee: “ormai l’elemento è stato disegnato così e non ci possiamo fare niente” veniva spesso contrapposto a “lo abbiamo sviluppato così perché c’è un motivo (e solitamente sono richieste lato business)”. Ogni lato vorrebbe portare acqua al proprio mulino, pronto quasi al conflitto l’un l’altra, dimenticando il motivo per il quale nascono e vengono alimentati i Design System: creare una base condivisa che possa rendere agevoli e durature le varie fasi di vita degli elementi al suo interno.

Ancorarsi così fortemente ad elementi attinenti solo alla propria materia, o alle indicazioni di business, senza mettere l’utente e la sua esperienza con il sistema al centro è un errore critico: ci si basa soltanto sulle proprie conoscenze, su quanto studiato, si cerca continuamente il famoso “effetto wow”, il “di più”, dimenticando però che non chi dovrà interagire con la nostra “creazione” saranno per lo più utenti che non si accorgeranno di tecnicismi e sofismi ma che vorranno solo che questa funzioni bene, senza trovare intoppi, problemi e frustrazioni.

Progettare un’interfaccia utente solida per qualsiasi tipologia di utente, fluida e senza intoppi, aiuta più di quanto si pensi a rendere un sistema accessibile: disegnare e sviluppare CTA chiare, distinguibili e percepibili correttamente, implementare funnel fluidi e senza intoppi per qualsiasi tecnologia assistiva (hardware o software), fornire alle persone istruzioni non fraintendibili, utilizzare la semantica coerentemente e correttamente sono gli elementi alla base sia dell’accessibilità che dell’esperienza utente.

A questo proposito vi porto un esempio reale di alcune interfacce presenti in qualche app mobile/servizio web che utilizzo io stesso o che ho incontrato nel corso del tempo.

Primo caso: confermi di annullare?

Mostra il pulsante di conferma e di annullamento.

 

In una sezione di questa applicazione è possibile richiedere un appuntamento con un dipendente, per un qualsiasi motivo, e si ha la possibilità di annullarlo. Nel caso si decida di farlo compare una finestra modale, con il seguente messaggio: “sei sicuro di voler annullare la richiesta di contatto?” e successivamente si trovano due Call to Action (CTA), “conferma” e “annulla”.

Questo è un chiaro esempio di applicazione degli standard di design e sviluppo senza però comunicazione fra i reparti dato che non è assolutamente chiaro cosa queste CTA vogliano trasmettere: utilizzando “Conferma” sto confermando di annullare oppure no? E idem per “annulla”.

Secondo caso: confermi di annullare (2)?

Un’altra situazione simile alla precedente. Cercando di annullare il processo di attivazione compare una modale con due CTA: “Conferma” e “chiudi”.

È importante notare che, in entrambi gli esempi, nella domanda sia presente la parola “annullare” ma per uscire effettivamente dal funnel sia necessario utilizzare “Conferma”.

Questi due esempi evidenziano in maniera evidente la confusione che può essere creata all’utente con un elemento semplice quanto può essere un pulsante.

Terzo caso: selezione multipla, nessun riepilogo.

In questo esempio le CTA sono chiare: è il messaggio di conferma che fa storcere un po’ il naso. Per fornire del contesto, si tratta di un provider italiano e stiamo effettuando la cancellazione di diversi indirizzi mail contemporaneamente: nella modale di “avviso”, però, non viene ricordato quali indirizzi si vogliano eliminare.

Dato che si tratta di un’azione irreversibile che andrà a cancellare dati che non saranno più ripristinabili, è importante fornire a tutti gli utenti (che utilizzino o meno tecnologie assistive) un riepilogo degli elementi che verranno impattati da questa modifica: potrebbero essere presenti elementi selezionati per sbaglio e che, una volta cancellati, sarebbero persi per sempre.

Conclusione

Accessibilità ed esperienza utente non sono due mondi separati: è importante che i Web Accessibility Expert e i Designer/esperti di UX si parlino, si confrontino e arrivino a soluzioni condivise.

Non trincerarsi dietro muri indistruttibili e aprirsi al dialogo migliora la soddisfazione dell’utente e la reputazione dell’azienda: chi adotta pratiche inclusive ed esperienze utente non frustranti godono di maggiore fedeltà da parte dei visitatori e hanno un vantaggio competitivo. Inoltre, non dimentichiamolo, l’adeguamento alle normative sull’accessibilità previene potenziali controversie legali e sanzioni.