Un Software Accessibile non basta: perché l'Usabilità fa la differenza

Molti considerano Accessibile un programma semplicemente se una persona cieca riesce a utilizzarlo. Per me questo è soltanto il punto di partenza. Le vere domande sono altre: quanto è comodo usarlo? Quanto tempo richiede svolgere un'Operazione? Quanti passaggi sono necessari per arrivare a un risultato?

Un Software può essere perfettamente accessibile dal punto di Vista Tecnico e, allo stesso tempo, risultare scomodo nell'uso Quotidiano. Se per eseguire un'operazione devo interrompere ciò che sto facendo, cercare informazioni, modificare il mio modo di lavorare o seguire un Percorso inutilmente lungo, allora c'è ancora qualcosa che non funziona.

Indice

1. Oltre la conformità tecnica
2. Il flusso del pensiero e l'attrito cognitivo
3. Percezione sequenziale vs. visione spaziale
4. La matematica dei micro-ritardi
5. La duplice prospettiva: sviluppatore e utente
6. Dall'accessibilità all'usabilità
7. Dove accessibilità e usabilità si incontrano
8. Note bibliografiche

Oltre la conformità tecnica

Nello sviluppo di Biblos ho sempre cercato di andare oltre il semplice funzionamento delle singole caratteristiche. L'obiettivo è stato creare uno strumento che permetta di lavorare in modo spontaneo, senza costringere la persona ad adattare continuamente il proprio modo di operare ai limiti del software.

Una delle mie certezze è che Biblos non sia perfetto. Dopo tanti anni di sviluppo so che la costanza è uno degli elementi fondamentali per mantenere vivo un Progetto, perché solo attraverso il miglioramento continuo è possibile seguire l'evoluzione delle tecnologie e continuare a rispondere alle esigenze delle persone che lo utilizzano.

Il flusso del pensiero e l'attrito cognitivo

A 13 anni ho imparato intuitivamente che un software accessibile deve permettere alla persona di mantenere il proprio flusso mentale. Il Computer non deve diventare un ostacolo tra l'idea e la sua realizzazione.

A 53 anni ho razionalizzato che, quando una persona scrive e organizza un Lavoro, il pensiero segue un percorso continuo. Le idee arrivano, si collegano, cambiano direzione, vengono sviluppate. Il programma utilizzato dovrebbe accompagnare questo processo.

Se ogni azione richiede un'attesa, se ogni comando introduce un rallentamento, se ogni operazione obbliga l'utente a fermarsi per attendere una risposta, qualcosa si spezza.

Questo aspetto è particolarmente evidente per chi utilizza una Tecnologia assistiva.

Percezione sequenziale vs. visione spaziale

Un utente vedente riceve continuamente informazioni attraverso lo Schermo. Può osservare la posizione del cursore, il cambiamento di un elemento grafico o l'evoluzione simultanea di più informazioni. La vista offre un feedback immediato e spazialmente distribuito.

Un utente che utilizza uno screen reader, invece, costruisce il rapporto con il computer attraverso una sequenza temporale. Ogni Informazione arriva attraverso la Sintesi Vocale o il display Braille. La risposta del programma deve quindi essere precisa, coerente e tempestiva.

Ma c'è qualcosa che molti ignorano o sottovalutano: l'abitudine. L'utente sviluppa nel tempo un'aspettativa precisa sul comportamento dello strumento. Se un comando produce abitualmente una risposta dopo 100 millisecondi, un aumento occasionale del tempo di risposta può essere sufficiente a interrompere la continuità dell'interazione. Anche quando questa variazione non viene percepita consapevolmente, può introdurre un piccolo attrito che modifica la naturalezza dell'esperienza.

La qualità di uno strumento accessibile dipende anche dalla capacità di rispettare queste aspettative, perché la fluidità dell'interazione contribuisce a creare fiducia e familiarità.

Nel progettare Biblos ho sempre considerato la reattività come una caratteristica fondamentale. Un programma non dovrebbe costringere l'utente ad aspettarlo. Questa attenzione si manifesta in molte scelte tecniche apparentemente piccole: ridurre i tempi di avvio, evitare caricamenti inutili, mantenere immediate le operazioni quando possibile, progettare funzioni che rispondano senza introdurre pause percettibili.

A volte, nello sviluppo software, si tende a considerare le prestazioni come un dettaglio secondario. Se una funzione “funziona”, il problema sembra risolto. Ma per uno strumento utilizzato ogni giorno, per ore, la differenza tra una risposta immediata e una risposta ritardata diventa enorme.

La matematica dei micro-ritardi

Facciamo un esempio concreto: consideriamo un Documento complesso, per la cui Scrittura e revisione si compiano fino a un milione di interazioni con il software, tra digitazione, spostamenti, selezioni, cancellazioni e operazioni varie. Ipotizziamo che ogni singola interazione abbia un costo medio di 10 millisecondi. Il costo complessivo sarebbe quindi di 10 milioni di millisecondi, equivalenti a circa 167 minuti.

Se il costo medio di ogni interazione salisse da 10 a 20 millisecondi, il tempo complessivo necessario per gestire le stesse operazioni raddoppierebbe, passando da circa 167 minuti a oltre 333 minuti. Un incremento apparentemente minimo nella singola risposta del software, moltiplicato per centinaia di migliaia o milioni di interazioni, può quindi trasformarsi in un rallentamento significativo nell'esperienza quotidiana dell'utente.

La duplice prospettiva: sviluppatore e utente

Biblos è nato da una necessità concreta: creare uno strumento che permettesse in prima istanza a me, persona cieca, di lavorare con i documenti in modo autonomo e rapido, senza dover continuamente adattare il mio Metodo di lavoro ai limiti della tecnologia.

Come utente quotidiano di tecnologie assistive, ho potuto osservare il software da una prospettiva privilegiata: quella dell'utente che ogni giorno deve affidarsi al programma per lavorare.

La doppia visione di programmatore e di utente mi ha portato inevitabilmente a pormi domande diverse. Non è stato sufficiente chiedermi: “Questa funzione è disponibile?”. È stato necessario chiedermi anche:

• Questa funzione è raggiungibile con naturalezza?
• Il programma comunica in modo chiaro ciò che sta accadendo?
• Il tempo di risposta permette di mantenere il ritmo del lavoro?
• Questa soluzione semplifica davvero la vita dell'utente?

Sono domande che spesso non emergono nei normali processi di sviluppo software, perché richiedono non solo di progettare una funzione, ma di vivere il rapporto tra persona e tecnologia dal punto di vista dell'interazione quotidiana.

La sfida più grande nello sviluppo di strumenti accessibili è forse proprio creare una tecnologia che non chieda continuamente attenzione all'utente. Il software ideale è quello che accompagna il lavoro senza diventare protagonista. È presente, ma non ingombra. Aiuta, ma non interrompe.

Quando una persona scrive un documento, prepara un progetto o studia un testo, il suo obiettivo è realizzare qualcosa attraverso un software. Il compito della tecnologia è eliminare gli ostacoli visibili e invisibili che si frappongono tra il pensiero e il risultato.

Per questo l'accessibilità, nella mia visione, non può fermarsi alla compatibilità Tecnica. Deve arrivare fino all'esperienza. Per me un programma davvero accessibile è quello che permette alle persone di lavorare al ritmo delle proprie idee. Questo inevitabilmente ci introduce a un mondo che considero ancora più affascinante: quello dell'usabilità.

Dall'accessibilità all'usabilità

Finora ho parlato di accessibilità, ma in realtà vi ho portati, quasi senza dirlo, dentro un altro territorio: quello dell'usabilità. Ho scritto di tempi di risposta, continuità del pensiero, fluidità del lavoro, Autonomia, semplicità nell'interazione e capacità del software di accompagnare l'utente senza interromperlo. Tutto questo è entrato in scena sotto la bandiera dell'accessibilità, ma serve a spalancare le porte a un orizzonte ancora più ampio e, per me, fondamentale: l'usabilità.

L'accessibilità risponde a una domanda: una persona con una determinata caratteristica o necessità può utilizzare questo strumento? È una domanda indispensabile. Senza accessibilità, molte persone vengono escluse dall'utilizzo della tecnologia. Ma l'usabilità pone una domanda successiva che riguarda tutti, ancora più profonda: Una persona può utilizzare questo strumento nel modo migliore possibile?

Un programma può essere accessibile e permettere di raggiungere un risultato. Ma può anche essere lento, complesso, poco intuitivo, pieno di passaggi inutili. Può richiedere attenzione continua per capire cosa sta accadendo, invece di lasciare spazio al lavoro che la persona vuole svolgere.

Faccio un esempio emblematico. Pensiamo a una qualsiasi esperienza, Digitale o materiale, nella quale dobbiamo raggiungere un obiettivo. La prima domanda che ci poniamo è: sarà facile?

Immaginiamo di utilizzare un servizio Online. Magari impieghiamo un'ora, o anche più, per raggiungere un risultato o reperire un'informazione. Alla fine ci rendiamo conto che l'obiettivo è stato raggiunto, ma con quale costo? La stessa operazione, se il servizio fosse stato progettato meglio, avrebbe richiesto appena cinque minuti.

Credo che questo esempio sia paradigmatico, perché descrive una situazione nella quale chiunque può trovarsi. Quando un servizio costringe le persone a sprecare tempo ed energie per compiere operazioni semplici, il problema non è l'accessibilità, ma la mancanza di usabilità. E l'usabilità si misura proprio così: dalla facilità con cui una persona raggiunge il proprio obiettivo e dall'assenza di ostacoli che incontra lungo il percorso.

Cominciamo a comprendere la differenza? L'accessibilità apre una possibilità. L'usabilità determina la qualità di quell'esperienza.

Un edificio accessibile è un edificio in cui una persona può entrare. Un edificio Usabile è un edificio in cui quella persona può muoversi facilmente, orientarsi, trovare ciò che cerca e vivere gli spazi in modo naturale.

Lo stesso principio vale per il software. L'accessibilità risponde alla domanda: “Posso farlo?”. L'usabilità risponde alla domanda: “Quanto è facile farlo?”.

È questo il motivo per cui, nello sviluppo di Biblos, non ho mai considerato l'accessibilità come un punto di arrivo, ma come il punto di partenza del mio lavoro. La vera sfida non è soltanto rendere disponibile una funzione, ma renderla naturale. Non è soltanto consentire un'azione, ma permettere che quell'azione avvenga senza interrompere il ragionamento e il ritmo personale dell'utente.

Dove accessibilità e usabilità si incontrano

Nel lavoro su Biblos mi accompagna spesso un pensiero di Antoine de Saint-Exupéry: “La perfezione si raggiunge non quando non c'è più nulla da aggiungere, ma quando non c'è più nulla da togliere”.

Quando un software accessibile consente di raggiungere un obiettivo e rimuove ogni ostacolo superfluo lungo il percorso, allora l'accessibilità si sarà sposata felicemente con l'usabilità. Quando un software segue il modo di pensare e di lavorare della persona, la tecnologia smette di essere uno strumento da comandare e diventa un Ambiente in cui lavorare con naturalezza.

È il momento esatto in cui possiamo concentrarci su ciò che vogliamo realizzare, lasciando alla tecnologia il compito di accompagnarci senza ostacolarci.

Note bibliografiche

1. Steve Krug, Don't Make Me Think (2014).
   Il principio cardine dell'usabilità di Krug si fonda sulla riduzione del carico cognitivo: l'interfaccia deve risultare trasparente e immediata, permettendo all'utente di completare le proprie azioni senza dover riflettere sul funzionamento dello strumento.
2. Jakob Nielsen, Usability Engineering (1993)
   Nielsen analizza i limiti di risposta delle interfacce, evidenziando come i ritardi superiori ai 100 millisecondi interrompano la percezione di causalità immediata e la continuità del flusso di lavoro quotidiano.
3. Donald A. Norman, The Design of Everyday Things (2013)
   Norman distingue la mera accessibilità formale dall'usabilità reale, teorizzando come il miglior design sia quello che elimina ogni attrito interattivo rendendo la tecnologia un'estensione naturale dell'intento Umano.

Giuseppe Di Grande è programmatore, esperto di accessibilità e autore di Biblos, Word processor specialistico per la stampa braille e la Grafica Tattile diffuso a livello internazionale. Founder e amministratore di Iblaris, sviluppa da oltre trent'anni tecnologie assistive unendo il rigore dell'architettura software alla sua esperienza diretta di utente non vedente.

Questo articolo è il frutto di conoscenza, esperienza e impegno. Se lo hai trovato interessante, il modo migliore per condividerlo è valorizzarlo: puoi citarne una parte e linkarne la fonte. Solo così offri il giusto riconoscimento a chi lo ha creato.

Per ulteriore supporto ci si può iscrivere nel Gruppo di Biblos su Facebook o nel Canale di Biblos su Telegram.