Design per interazioni semplici

Identificate e descrivete gli elementi interattivi#section1

Gli elementi interattivi dovrebbero essere semplici da distinguere dagli altri elementi della pagina. Per esempio, i link e i pulsanti possono essere identificati nei seguenti modi:

• Visivamente: i link sono spesso a colori e vengono sottolineati, i pulsanti sono identificabili tramite la loro forma.
• Nel codice: il codice di markup di link e pulsanti può mostrare il loro stato, ad esempio se sono attivi, attraverso dei cambiamenti nel loro aspetto. Vi si può inoltre accedere da tastiera o utilizzando delle liste di elementi interattivi create dalla tecnologia assistiva.

Tra HTML, WAI-ARIA e le feature della piattaforma tecnologica, ci sono molte opzioni per realizzare un’interazione accessibile usando il codice per identificare e descrivere gli elementi interattivi.

Usate il codice HTML di base in maniera corretta#section2

Oltre a programmare i componenti interattivi, potete anche descrivere la loro funzione utilizzando il codice sorgente piuttosto che l’interfaccia utente. HTML ha dei codici che aiutano il software a comunicare informazioni sui componenti agli utenti.

Con HTML di base l’interazione è limitata ai link e ai form control. I codici che usate per creare l’interazione includono gli attributi necessari per rendere accessibili gli elementi. Implementare tali elementi in maniera completa, stando alla specifica, permette di fornire un’interazione realmente accessibile. Consideriamo, per esempio, una label per un campo “text input”, come mostrato in Figura 5.1.

Visivamente, la label è messa in relazione con il campo dalla vicinanza: di solito si trova appena prima del campo. Nel codice, la label è collegata ad esso usando l’elemento e l’attributo <label for>, che connettono “programmaticamente” la label all’input field. In questo modo, il software comunica all’utente che tipo di informazione inserire nel campo.

<label for="firstname">First name:</label>
<input type="text" id="firstname" />
<label for="lastname">Last name:</label>
<input type="text" id="lastname" />

Figura 5.1: Le label sono visivamente associate ai campi “input text” dalla loro prossimità. Nel codice, le label sono “programmaticamente” connesse utilizzando l’elemento <label>, l’attributo “for” e l’attributo “id” dell’input field, creando così il collegamento.

Utilizzate WAI-ARIA per elementi complessi#section3

Fino a poco tempo fa, non c’era a livello di pagina lo stesso supporto integrato per l’accessibilità di interazioni complesse che c’è per i link e per le form. Fortunatamente, questa situazione sta finalmente cambiando. Con WAI-ARIA si possono identificare e descrivere gli elementi interattivi in modo che il software possa leggerli, così da essere accessibili agli utenti di tecnologie assistive.

Per esempio, un pattern di interazione è la widget “accordion”, ossia un link che, una volta cliccato, si espande per mostrare il contenuto nascosto (vedi Figura 5.2). Cliccando una seconda volta, il contenuto si riduce di nuovo per ritornare nello stato nascosto. Questo pattern serve nel caso in cui ci sia del contenuto che potrebbe non essere importante per tutti gli utenti, fa risparmiare spazio prezioso sullo schermo e fornisce anche un modo per apprendere di più nel contesto, senza saltare a pagine differenti o dover scrollare attraverso un’unica lunga pagina.

ARIA fornisce dei codici che si possono utilizzare per identificare e descrivere dei componenti interattivi in maniera “programmatica” come una widget “accordion”, così che la tecnologia assistiva possa comunicare delle informazioni riguardanti tale componente ai suoi utenti. Per esempio, nel caso di una widget accordion, l’attributo “aria-expanded” può essere impostato a “true” o “false” “programmaticamente”, a seconda dello stato del componente.

Figura 5.2: La OpenAjax Alliance fornisce degli esempi e del codice scaricabile per molti design pattern comuni, inclusa una widget “accordion” accessibile.

ARIA è utile anche per altre interazioni. Infatti, nella form di registrazione di esempio mostrata nella Figura 5.3, i messaggi di errore sono codificati con l’attributo role=“alert”, così che gli utili messaggi di errore “in-line” possano essere annunciati agli utilizzatori di screen reader.

Figura 5.3: in questo esempio di form di registrazione, gli avvisi (o “alert”) sono identificati “programmaticamente” utilizzando il “role attribute” di ARIA.

Usate le feature della piattaforma tecnologica.#section4

Quando realizzate degli elementi usando codice di linguaggi di programmazione diversi da HTML, dovreste usare le feature di tale tecnologia per identificare e descrivere completamente gli elementi interattivi. Per la maggior parte, tecnologie come Flash e Java hanno gli hook necessari per l’accessibilità. Chi sviluppa utilizzando questi strumenti non deve far altro che usarli correttamente e progettare in maniera tale che sia possibile programmare l’interazione in maniera accessibile.

Tuttavia, dovreste considerarne attentamente le implicazioni prima di allontanarvi dalle tecnologie standard. L’interazione è necessaria per l’utilizzo e gli scopi del prodotto? Se sì, potete ottenere quello di cui avete bisogno usando codice standard? Esaurite ogni possibilità di utilizzo delle tecnologie web standard prima di impegnarvi con un formato non standard e quindi meno stabile e meno accessibile.

Date istruzioni e feedback accessibile#section5

Nel Capitolo 4, Organize code for clarity and flow, abbiamo discusso come alcune modalità di interazione si basino su un accesso lineare e su come l’ordine del codice sia importante perché influenza l’ordine in cui vengono presentati gli elementi. Per esempio, la modalità audio di uno screen reader non può presentare più di un’informazione o più di un’opzione interattiva alla volta. Gli elementi interattivi che non sono messi nella giusta sequenza possono creare delle barriere per tutti, ma in maniera particolare per le persone che fanno affidamento su una presentazione lineare.

Non sono i dettagli dell’interazione stessa a creare una barriera, ma il modo in cui è strutturata nel codice e presentata agli utenti. Una semplice regola pratica è di progettare la pagina così in modo che qualsiasi cambiamento fatto dopo il suo primo caricamento accada “a valle” rispetto al cursore.

La posizione nel codice fa davvero una gran differenza per l’accessibilità di form e messaggi d’errore. Per esempio, man mano che un utente compila una form, il codice controlla ogni “entry” per essere sicuro che sia valida. Potrebbe controllare che lo username sia disponibile, ma, se il feedback viene mostrato sopra al campo, la tecnologia assistiva non vede il cambiamento e procede semplicemente verso il campo successivo. Ancora peggio: alcune form mostrano i messaggi di errore in una finestra pop-up “modale” che deve essere chiusa dall’utente prima di correggere l’errore. Non avendo più a disposizione il messaggio d’errore, l’utente deve provare a ricordarsi l’elenco dei problemi mentre cerca i campi da correggere.

Oppure potrebbe succedere che, dopo che un utente ha inviato una form, il software sul server identifichi un problema con i dati inviati e mostri di nuovo la form, così che si possano correggere tali errori. In alcuni casi, il programma posiziona il cursore sul campo in cui si è generato l’errore. Sfortunatamente, il messaggio di errore viene mostrato in cima alla pagina: non solo la tecnologia assistiva non vedrà il messaggio, ma anche la maggior parte degli utenti non lo vedrà.

Pertanto, quando progettate delle form, dovreste assicurarvi che qualsiasi feedback interattivo appaia sia nel codice sia sullo schermo, in un modo che abbia senso quando viene presentato in modo lineare. Il più delle volte, questo significa posizionare il feedback dopo l’elemento, in modo tale che sia l’item successivo nell’ordine dei tab e di lettura, così come è necessario usare un ARIA role, come mostrato nella form di registrazione di esempio della Figura 5.3.

La sequenza è importante anche per le istruzioni. A volte, le form sono codificate in maniera tale che le istruzioni e le label appaiono dopo i campi e i pulsanti della form. Gli utenti (e la tecnologia assistiva) devono per prima cosa leggere per determinare lo scopo di ciascun campo e poi tornare indietro per riempire il campo. Assicuratevi che gli elementi della form seguano una sequenza logica: identificate e descrivete gli elementi prima dell’interazione, sia in maniera visuale sia nel codice.

Le istruzioni e le label che appaiono all’interno del campo sono problematiche perché sparisco quando si attiva il campo. Gli utenti che hanno bisogno di guardare la tastiera mentre scrivono si perderanno completamente il suggerimento. Altri non ricorderanno i dettagli nelle istruzioni e nelle label una volta che questi non saranno più visualizzati.

Supportate l’interazione da tastiera#section6

Il modello di interazione “point-and-click” reso celebre dal mouse non è universalmente usabile. Gli utenti con seri problemi di vista non possono puntare il mouse. Le persone con problemi di manualità possono trovare difficili e scomode le operazioni con il mouse. Al contrario, alcuni dispositivi di input alternativi funzionano attivando i comandi da tastiera. Inoltre, alcune persone si trovano meglio con i controlli da tastiera, pensano che siano più comodi e più efficienti di un puntatore.

Create un ordine dei tab logico#section7

Nel Capitolo 4, abbiamo parlato di come l’ordine del codice influenzi l’accesso lineare alle pagine web in Organize code for clarity and flow. L’ordine del codice ha un impatto significativo sulla navigazione da tastiera, specialmente quando si usa il tasto tab per girare tra gli elementi azionabili (controlli interattivi come i link e i pulsanti) presenti sulla pagina. L’utilizzo del tab è un approccio comune alla navigazione per gli utenti che usano una tastiera per muoversi nella pagina, simile al modo in cui gli utenti che usano il mouse cercano i link e i controlli su cui cliccare. Gli utenti da tastiera premeranno il tasto tab più volte, fino ad arrivare all’elemento desiderato per poi premere Invio per attivare il controllo.

Con le pagine web standard, l’ordine dei tab è basato sulla sequenza degli elementi nell’ordine del codice. Altri formati usano altri metodi. Per esempio, Flash calcola il tab order basandosi sulla posizione degli elementi sullo schermo. In altri casi, è importante testare l’ordine dei tab per essere sicuri che segua una progressione logica.

Sebbene sia possibile impostare un ordine dei tab manualmente nel codice, l’approccio migliore consiste nel mettere nella giusta sequenza gli elementi, così che l’ordine naturale dei tab funzioni in maniera logica e usabile.

Non esigere l’interazione “point-and-click”#section8

Supportare l’interazione da tastiera non vuol dire che non potete mai usare interazioni complesse come il “drag and drop”. Semplicemente, assicuratevi che tutte le interazioni abbiano un’opzione che non richieda il puntamento del mouse.

Ecco alcune cose da tenere a mente quando progettate le interazioni:

• Hover: alcuni device, come i touchscreen, non supportano lo stato “hover”. Potete passare sopra a qualsiasi cosa su un touchscreen, ma non succederà nulla! Le azioni “hover” possono anche dare fastidio quando vengono attivate inavvertitamente, come quando viene mostrato un menu semplicemente perché il puntatore del mouse ci è passato sopra durante lo spostamento verso un’altra parte dello schermo. Gli “hover” possono anche distrarre le persone con disabilità cognitive o dell’attenzione.
• Select: utilizzare “select” per attivare delle azioni è problematico per gli utenti che usano solo la tastiera perché gli eventi vengono attivati inavvertitamente non appena vengono selezionati. Il miglior approccio consiste nell’utilizzare un modello di interazione “select/activate”, in cui gli elementi sono selezionati ed identificati e poi esplicitamente attivati dall’utente. Usando questo modello, potete creare una modalità di interazione che funziona in maniera universale.
• Drag and drop: questo stile di interazione rende semplice la manipolazione diretta degli oggetti, ma tipicamente richiede un device di puntamento e l’utilizzo delle mani senza problemi. Tuttavia, potete offrire un’alternativa accessibile da tastiera per spostare gli oggetti da un punto ad un altro (vedi Figura 5.5).

Figura 5.5: Questa feature, raggruppare bookmark per oggetti correlati, richiede un mouse per fare “drag and drop” degli item nella lista. Un semplice pulsante “Aggiungi” renderebbe il tutto più accessibile.

Mostrare quale elemento ha il focus da tastiera#section9

Gli utenti da tastiera traggono beneficio anche da un indicatore chiaro che mostri quale elemento attualmente ha il focus. I browser hanno un indicatore di focus di default, tipicamente un bordo a puntini attorno all’elemento. Tuttavia, la keyboard usability può essere migliorata usando CSS per dare delle chiare indicazioni visive che aiutino gli utenti a fare scelte precise sugli elementi con cui si vuole interagire. La Figura 5.6 mostra un esempio di codice CSS. La best practice consiste nel fornire le stesse indicazioni visive che si usano per indicare lo stato “hover”, come ad esempio, quando il mouse o un altro device di puntamento sta “passando sopra” ad un elemento.

a:hover, a:active, a:focus { outline: 2px solid blue }

Figura 5.6: Usate CSS per creare un profilo visibile attorno agli oggetti che hanno il focus da tastiera. In questo esempio, lo stesso bordo blu di 2 pixel identifica quale oggetto ha il “mouse over” (hover), l’active o il focus da tastiera.

Non intrappolare il focus da tastiera#section10

La “keyboard trap” avviene con gli oggetti “embedded”, come i video, le applet e Flash. Quando il focus è intrappolato, gli utenti non possono entrare o uscire da un elemento senza un dispositivo di puntamento, come il mouse. Le tecniche per evitare la keyboard trap dipendono in larga parte dalla tecnologia degli oggetti “embedded”. Idealmente, l’entrata o l’uscita da un oggetto “embedded” dovrebbe usare gli stessi metodi di navigazione di una pagina web, ossia i tab e i tasti freccia. Per le tecnologie che non supportano la navigazione standard, fornite un’opzione da tastiera e documentatela in maniera tale che gli utenti da tastiera possano evitare di rimanere intrappolati.

Rendete i controlli sufficientemente grandi da poterli gestire facilmente#section11

I controlli sullo schermo potrebbero non essere tridimensionali, tuttavia gli utenti hanno ancora bisogno di una certa manualità per azionarli. Condizioni fisiche quali l’artrite o i tremori possono rendere difficile l’uso accurato di un controllo, ma anche il contesto, come lavorare su un aereo pieno senza spazio sufficiente per i gomiti, o usare dei guanti può rendere difficile l’uso di tali controlli. Le persone che navigano sul web usando dispositivi mobili con touchscreen possono avere delle difficoltà cercando, ad esempio, di selezionare un radio button da un insieme di opzioni o provando ad attivare un pulsante di invio. Anche i siti responsive potrebbero non prendere in considerazione le differenze di dimensione tra un device di puntamento e la punta di un dito.

Le seguenti linee guida contribuiscono a rendere i controlli semplici da usare:

• Minimizzate le capacità di movimento preciso richieste per gli elementi interattivi. Fate in modo che i pulsanti e i punti in cui si deve toccare siano sufficientemente grandi.
• Controlli di spazio. Lasciate uno spazio sufficiente tra i controlli, così che gli utenti non attivino accidentalmente quello sbagliato.
• Minimizzate la complessità dell’azione richiesta. Scegliete, quando possibile, dei controlli che non richiedano una temporizzazione o la gestione di azioni multiple. State attenti ai controlli come i menu multi-livello che richiedono una mano rapida per operarci.

Lasciate che siano gli utenti a controllare il funzionamento dell’interfaccia#section12

Cercate di evitare di fare cambiamenti che non siano attivati da una richiesta esplicita dell’utente. Per esempio, il “carosello” di storie in evidenza su una homepage ha tipicamente un avanzamento automatico, basato sulla stima del tempo necessario per la lettura del contenuto. Il movimento incontrollato di un’interfaccia distrae e ha un impatto sulla comprensione. Alcuni utenti hanno bisogno di più tempo per assorbire le informazioni, così, come minimo, rendete disponibile un metodo per fermare l’avanzamento automatico. (Vedi Capitolo 9, “Accessible Media” per ulteriori informazioni sul multimedia).

Un approccio migliore consiste nel caricare la prima immagine e di fornire dei controlli chiari per l’avanzamento tra le storie. Questo si applica a tutti gli elementi in movimento, come i video e gli audio. Non fate partire un media in automatico. Al contrario, aspettate che sia l’utente a scegliere di farlo partire. L’autoplay non è solo una distrazione, può anche causare problemi alle persone che si trovano in un ambiente tranquillo o che usano una connessione con banda scarsa per collegarsi al web (come quando si ha una scarsa copertura con il cellulare).

Un’altra pratica comune consiste nell’aprire i link in una nuova finestra, solitamente con l’intenzione di aiutare gli utenti a tornare al sito web originale perché possono farlo semplicemente chiudendo quest’ultima finestra. Sfortunatamente, l’apertura di una nuova finestra dà il via a una nuova cronologia di navigazione. Quando gli utenti navigano in questa nuova finestra e cercano di usare il pulsante “Indietro” per tornare al primo sito web, non possono farlo, perché il primo sito web non è nella cronologia della finestra che abbiamo aperto “programmaticamente”. Questa pratica potrebbe davvero risultare nell’esatto opposto dell’effetto desiderato perché gli utenti potrebbero non essere in grado di trovare la strada per tornare indietro.

Decidere se aprire una nuova finestra è la semplice illustrazione di un principio importante: Non fate azioni al posto degli utenti quando questi possono farle da soli.

Le persone che vogliono aprire i link in una nuova finestra possono farlo da soli, usando i controlli “built-in” nei browser. Le persone che non amano aprire link in una nuova finestra non possono non usare questo comportamento se lo programmate nell’interfaccia. Come designer, dobbiamo rispettare i limiti dell’ambiente dell’utente.

Progettate per le eventualità#section13

Proprio come gli allarmi antincendio e le uscite di sicurezza di un edificio, i prodotti digitali devono anch’essi essere creati così che quando qualcosa va storto, vengano minimizzati gli effetti dannosi o vengano prevenuti attraverso una risposta all’errore e un opportuno recovery.

Gli errori possono capitare a vari livelli. Alcuni, come i broken link o le anomalie dovute alla programmazione, sono un problema di scrittura di codice valido. Altri possono capitare a causa della confusione riguardo al modo in cui funzionano le cose, per dei semplici errori, come cliccare la voce di menu sbagliata quando vi urtano il gomito o mentre date dei colpetti su un piccolo schermo. Non esiste un sistema a prova di errori. Nessuna interfaccia è intuitiva per tutti gli utenti e nessun utente è sempre il target.

Progettare per le eventualità vuol dire utilizzare il design per minimizzare l’impatto degli errori e gli insuccessi di sistema quando non possono essere evitati.

Per esempio, dovreste supportare gli utenti che stanno inserendo delle informazioni, ordinando un prodotto o postando un commento.

• Mettete a disposizione una pagina di revisione. Permettete agli utenti di rivedere i dati che hanno inserito prima di inviarli.
• Date delle opzioni per sistemare i dati inseriti. Supportate un processo iterativo di revisione/editing per dare agli utenti tutto il tempo necessario e l’opportunità di essere sicuri dei dati inseriti.
• Realizzate una pagina di conferma. Quando si invia l’informazione, confermate la transazione e date le istruzioni necessarie per fare ulteriori cambiamenti. Le pagine di conferma non solo sono un buon modo per terminare un’interazione, ma funzionano anche come conversazione:

Utente: Vorrei fare un ordine. Ecco tutte le mie informazioni.

Sito: Grazie. Ricevute. Ti manderemo il tuo ordine in tre giorni.

Una buona comunicazione può anche rendere più semplice utilizzare il sistema ed evitare gli errori. Per esempio, se il sistema richiede uno specifico formato per la data, fornite un esempio di data corretto prima del campo di input.

Se dovesse capitare un errore, fornite un feedback utile e accessibile in risposta agli errori di input. Il feedback dovrebbe apparire con l’elemento contenente un errore e dovrebbe fornire delle istruzioni chiare su come correggere l’input, come mostrato nella form di registrazione d’esempio della Figura 5.3.

Permettete agli utenti di prendersi più tempo#section14

Il tempo è una sfida per molte persone. Potrebbe volerci più tempo per qualcuno che usa delle tecnologie assistive come uno screen reader, un ingranditore di testo o un device di input alternativo come un joystick. Potrebbero leggere più lentamente o aver bisogno di più tempo per pensare a quello che stanno leggendo. Altre persone necessitano di tempo semplicemente per muovere i propri muscoli e potrebbe volerci molto tempo perché il loro braccio e la loro mano si coordinino per interagire con un link, un pulsante o un campo. I time-out potrebbero rovinare la loro esperienza.

Alcuni siti web hanno delle feature che vengono attivate dal tempo. Un esempio comune è la feature di timeout usata per ragioni di sicurezza da molte applicazioni web. Quando un utente fa il login in un sistema, il sistema segna l’ora e controlla l’attività. Se un intervallo predeterminato passa senza attività da parte dell’utente, il sistema va in timeout e chiude la sessione dell’utente.

Un processo di timeout ben progettato avvisa gli utenti prima di chiudergli la sessione e gli dà la possibilità di continuare la sessione corrente. Inoltre, se il sistema alla fine chiude effettivamente la sessione dell’utente, mette in cache qualunque attività abbiano iniziato nel browser. Questo permette all’utente di riconnettersi al sistema e di ripartire da dove aveva lasciato.