{"id":439,"date":"2014-02-26T15:29:48","date_gmt":"2014-02-26T14:29:48","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/design-per-interazioni-semplici\/"},"modified":"2014-02-26T15:29:48","modified_gmt":"2014-02-26T14:29:48","slug":"design-per-interazioni-semplici","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/design-per-interazioni-semplici\/","title":{"rendered":"Design per interazioni semplici"},"content":{"rendered":"<p class=\"editors-note\"><strong>Nota dell&#8217;editore:<\/strong> Siamo lieti di presentarvi un estratto del Capitolo 5 di <cite><a href=\"http:\/\/rosenfeldmedia.com\/books\/a-web-for-everyone\/\">A Web for Everyone: Designing Accessible User Experiences<\/a><\/cite> di Sarah Horton e Whitney Quesenbery. Usate il codice <span><span class=\"caps\">AWFEALA<\/span><\/span> per risparmiare il 20% sull&#8217;acquisto del libro su <a href=\"http:\/\/rosenfeldmedia.com\">Rosenfeld Media<\/a>.<\/p>\n<p><img decoding=\"async\" src=\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2014\/02\/sketch263211229.jpg\" border=\"0\" align=\"left\" \/>Il successo nell&#8217;interaction design \u00e8 in gran parte determinato dall&#8217;uso di alcuni pattern prestabiliti, cos\u00ec che le persone possano applicare le proprie conoscenze a nuovi contesti. Utilizzare dei controlli interattivi noti e ben consolidati permetter\u00e0 di avere successo nella progettazione di interazioni semplici. Ci sono per\u00f2 delle considerazioni specifiche da fare per rendere i controlli pi\u00f9 usabili da parte delle persone che utilizzano le tecnologie assistive e ci sono degli accorgimenti nella progettazione che rendono le interazioni pi\u00f9 usabili e pi\u00f9 gradevoli per tutti, incluse le persone con disabilit\u00e0.<\/p>\n<div class=\"paragrafo\">\n<h2>Identificate e descrivete gli elementi interattivi<\/h2>\n<p>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:<\/p>\n<ul>\n<li><strong>Visivamente<\/strong>: i link sono spesso a colori e vengono sottolineati, i pulsanti sono identificabili tramite la loro forma.<\/li>\n<li><strong>Nel codice<\/strong>: il codice di markup di link e pulsanti pu\u00f2 mostrare il loro stato, ad esempio se sono attivi, attraverso dei cambiamenti nel loro aspetto. Vi si pu\u00f2 inoltre accedere da tastiera o utilizzando delle liste di elementi interattivi create dalla tecnologia assistiva.<\/li>\n<\/ul>\n<p>Tra HTML, WAI-ARIA e le feature della piattaforma tecnologica, ci sono molte opzioni per realizzare un&#8217;interazione accessibile usando il codice per identificare e descrivere gli elementi interattivi.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Usate il codice HTML di base in maniera corretta<\/h2>\n<p>Oltre a programmare i componenti interattivi, potete anche descrivere la loro funzione utilizzando il codice sorgente piuttosto che l&#8217;interfaccia utente. HTML ha dei codici che aiutano il software a comunicare informazioni sui componenti agli utenti.<\/p>\n<p>Con HTML di base l&#8217;interazione \u00e8 limitata ai link e ai form control. I codici che usate per creare l&#8217;interazione includono gli attributi necessari per rendere accessibili gli elementi. Implementare tali elementi in maniera completa, stando alla specifica, permette di fornire un&#8217;interazione realmente accessibile. Consideriamo, per esempio, una label per un campo &#8220;text input&#8221;, come mostrato in Figura 5.1.<\/p>\n<p>Visivamente, la label \u00e8 messa in relazione con il campo dalla vicinanza: di solito si trova appena prima del campo. Nel codice, la label \u00e8 collegata ad esso usando l&#8217;elemento e l&#8217;attributo <code>&lt;label for&gt;<\/code>, che connettono <a href=\"http:\/\/en.wiktionary.org\/wiki\/programmatically\">&#8220;programmaticamente&#8221;<\/a> la label all&#8217;input field. In questo modo, il software comunica all&#8217;utente che tipo di informazione inserire nel campo.<\/p>\n<pre><code class=\"language-markup\">&lt;label for=\"firstname\"&gt;First name:&lt;\/label&gt;\n&lt;input type=\"text\" id=\"firstname\" \/&gt;\n&lt;label for=\"lastname\"&gt;Last name:&lt;\/label&gt;\n&lt;input type=\"text\" id=\"lastname\" \/&gt;<\/code><\/pre>\n<p><strong>Figura 5.1:<\/strong> Le label sono visivamente associate ai campi &#8220;input text&#8221; dalla loro prossimit\u00e0. Nel codice, le label sono &#8220;programmaticamente&#8221; connesse utilizzando l&#8217;elemento <code>&lt;label&gt;<\/code>, l&#8217;attributo <code>\u201cfor\u201d<\/code> e l&#8217;attributo <code>\u201cid\u201d<\/code> dell&#8217;input field, creando cos\u00ec il collegamento.<\/div>\n<div class=\"paragrafo\">\n<h2>Utilizzate WAI-ARIA per elementi complessi<\/h2>\n<p>Fino a poco tempo fa, non c&#8217;era a livello di pagina lo stesso supporto integrato per l&#8217;accessibilit\u00e0 di interazioni complesse che c&#8217;\u00e8 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\u00ec da essere accessibili agli utenti di tecnologie assistive.<\/p>\n<p>Per esempio, un pattern di interazione \u00e8 la widget &#8220;accordion&#8221;, 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\u00f9 nel contesto, senza saltare a pagine differenti o dover scrollare attraverso un&#8217;unica lunga pagina.<\/p>\n<p>ARIA fornisce dei codici che si possono utilizzare per identificare e descrivere dei componenti interattivi in maniera &#8220;programmatica&#8221; come una widget &#8220;accordion&#8221;, cos\u00ec che la tecnologia assistiva possa comunicare delle informazioni riguardanti tale componente ai suoi utenti. Per esempio, nel caso di una widget accordion, l&#8217;attributo <code>\u201caria-expanded\u201d<\/code> pu\u00f2 essere impostato a &#8220;true&#8221; o &#8220;false&#8221; &#8220;programmaticamente&#8221;, a seconda dello stato del componente.<\/p>\n<p><img decoding=\"async\" src=\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2014\/02\/389_fig52.png\" border=\"0\" alt=\"Figure 5.2: Example accessible accordion widget from OpenAjax Alliance\" width=\"100%\" \/> <strong>Figura 5.2<\/strong>: La <a href=\"http:\/\/www.oaa-accessibility.org\">OpenAjax Alliance<\/a> fornisce degli esempi e del codice scaricabile per molti design pattern comuni, inclusa una <a href=\"http:\/\/www.oaa-accessibility.org\/examplep\/accordian1\/\">widget &#8220;accordion&#8221; accessibile<\/a>.<\/p>\n<p>ARIA \u00e8 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&#8217;attributo <code>role=\u201calert\u201d<\/code>, cos\u00ec che gli utili messaggi di errore &#8220;in-line&#8221; possano essere annunciati agli utilizzatori di screen reader.<\/p>\n<p><img decoding=\"async\" src=\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2014\/02\/389_fig53.png\" border=\"0\" alt=\"Figure 5.3: Account sign-up form error message\" width=\"100%\" \/> <strong>Figura 5.3<\/strong>: in questo esempio di form di registrazione, gli avvisi (o &#8220;alert&#8221;) sono identificati &#8220;programmaticamente&#8221; utilizzando il &#8220;role attribute&#8221; di ARIA.<\/div>\n<div class=\"paragrafo\">\n<h2>Usate le feature della piattaforma tecnologica.<\/h2>\n<p>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&#8217;accessibilit\u00e0. Chi sviluppa utilizzando questi strumenti non deve far altro che usarli correttamente e progettare in maniera tale che sia possibile programmare l&#8217;interazione in maniera accessibile.<\/p>\n<p>Tuttavia, dovreste considerarne attentamente le implicazioni prima di allontanarvi dalle tecnologie standard. L&#8217;interazione \u00e8 necessaria per l&#8217;utilizzo e gli scopi del prodotto? Se s\u00ec, potete ottenere quello di cui avete bisogno usando codice standard? Esaurite ogni possibilit\u00e0 di utilizzo delle tecnologie web standard prima di impegnarvi con un formato non standard e quindi meno stabile e meno accessibile.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Date istruzioni e feedback accessibile<\/h2>\n<p>Nel Capitolo 4, <em>Organize code for clarity and flow<\/em>, abbiamo discusso come alcune modalit\u00e0 di interazione si basino su un accesso lineare e su come l&#8217;ordine del codice sia importante perch\u00e9 influenza l&#8217;ordine in cui vengono presentati gli elementi. Per esempio, la modalit\u00e0 audio di uno screen reader non pu\u00f2 presentare pi\u00f9 di un&#8217;informazione o pi\u00f9 di un&#8217;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.<\/p>\n<p>Non sono i dettagli dell&#8217;interazione stessa a creare una barriera, ma il modo in cui \u00e8 strutturata nel codice e presentata agli utenti. Una semplice regola pratica \u00e8 di progettare la pagina cos\u00ec in modo che qualsiasi cambiamento fatto dopo il suo primo caricamento accada &#8220;a valle&#8221; rispetto al cursore.<\/p>\n<p>La posizione nel codice fa davvero una gran differenza per l&#8217;accessibilit\u00e0 di form e messaggi d&#8217;errore. Per esempio, man mano che un utente compila una form, il codice controlla ogni &#8220;entry&#8221; per essere sicuro che sia valida. Potrebbe controllare che lo username sia disponibile, ma, se il feedback viene mostrato <em>sopra<\/em> 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 &#8220;modale&#8221; che deve essere chiusa dall&#8217;utente prima di correggere l&#8217;errore. Non avendo pi\u00f9 a disposizione il messaggio d&#8217;errore, l&#8217;utente deve provare a ricordarsi l&#8217;elenco dei problemi mentre cerca i campi da correggere.<\/p>\n<p>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\u00ec che si possano correggere tali errori. In alcuni casi, il programma posiziona il cursore sul campo in cui si \u00e8 generato l&#8217;errore. Sfortunatamente, il messaggio di errore viene mostrato in cima alla pagina: non solo la tecnologia assistiva non vedr\u00e0 il messaggio, ma anche la maggior parte degli utenti non lo vedr\u00e0.<\/p>\n<p>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\u00f9 delle volte, questo significa posizionare il feedback dopo l&#8217;elemento, in modo tale che sia l&#8217;item successivo nell&#8217;ordine dei tab e di lettura, cos\u00ec come \u00e8 necessario usare un ARIA role, come mostrato nella form di registrazione di esempio della Figura 5.3.<\/p>\n<p>La sequenza \u00e8 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&#8217;interazione, sia in maniera visuale sia nel codice.<\/p>\n<p>Le istruzioni e le label che appaiono all&#8217;interno del campo sono problematiche perch\u00e9 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\u00f9 visualizzati.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Supportate l&#8217;interazione da tastiera<\/h2>\n<p>Il modello di interazione &#8220;point-and-click&#8221; reso celebre dal mouse <em>non<\/em> \u00e8 universalmente usabile. Gli utenti con seri problemi di vista non possono puntare il mouse. Le persone con problemi di manualit\u00e0 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\u00f9 comodi e pi\u00f9 efficienti di un puntatore.<\/p>\n<h3>Create un ordine dei tab logico<\/h3>\n<p>Nel Capitolo 4, abbiamo parlato di come l&#8217;ordine del codice influenzi l&#8217;accesso lineare alle pagine web in <em>Organize code for clarity and flow<\/em>. L&#8217;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&#8217;utilizzo del tab \u00e8 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\u00f9 volte, fino ad arrivare all&#8217;elemento desiderato per poi premere Invio per attivare il controllo.<\/p>\n<p>Con le pagine web standard, l&#8217;ordine dei tab \u00e8 basato sulla sequenza degli elementi nell&#8217;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, \u00e8 importante testare l&#8217;ordine dei tab per essere sicuri che segua una progressione logica.<\/p>\n<p>Sebbene sia possibile impostare un ordine dei tab manualmente nel codice, l&#8217;approccio migliore consiste nel mettere nella giusta sequenza gli elementi, cos\u00ec che l&#8217;ordine naturale dei tab funzioni in maniera logica e usabile.<\/p>\n<h3>Non esigere l&#8217;interazione &#8220;point-and-click&#8221;<\/h3>\n<p>Supportare l&#8217;interazione da tastiera non vuol dire che non potete mai usare interazioni complesse come il &#8220;drag and drop&#8221;. Semplicemente, assicuratevi che tutte le interazioni abbiano un&#8217;opzione che non richieda il puntamento del mouse.<\/p>\n<p>Ecco alcune cose da tenere a mente quando progettate le interazioni:<\/p>\n<ul>\n<li><strong>Hover<\/strong>: alcuni device, come i touchscreen, non supportano lo stato &#8220;hover&#8221;. Potete passare sopra a qualsiasi cosa su un touchscreen, ma non succeder\u00e0 nulla! Le azioni &#8220;hover&#8221; possono anche dare fastidio quando vengono attivate inavvertitamente, come quando viene mostrato un menu semplicemente perch\u00e9 il puntatore del mouse ci \u00e8 passato sopra durante lo spostamento verso un&#8217;altra parte dello schermo. Gli &#8220;hover&#8221; possono anche distrarre le persone con disabilit\u00e0 cognitive o dell&#8217;attenzione.<\/li>\n<li><strong>Select<\/strong>: utilizzare &#8220;select&#8221; per attivare delle azioni \u00e8 problematico per gli utenti che usano solo la tastiera perch\u00e9 gli eventi vengono attivati inavvertitamente non appena vengono selezionati. Il miglior approccio consiste nell&#8217;utilizzare un modello di interazione &#8220;select\/activate&#8221;, in cui gli elementi sono selezionati ed identificati e poi esplicitamente attivati dall&#8217;utente. Usando questo modello, potete creare una modalit\u00e0 di interazione che funziona in maniera universale.<\/li>\n<li><strong>Drag and drop<\/strong>: questo stile di interazione rende semplice la manipolazione diretta degli oggetti, ma tipicamente richiede un device di puntamento e l&#8217;utilizzo delle mani senza problemi. Tuttavia, potete offrire un&#8217;alternativa accessibile da tastiera per spostare gli oggetti da un punto ad un altro (vedi Figura 5.5).<\/li>\n<\/ul>\n<p><img decoding=\"async\" src=\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2014\/02\/389_fig55.png\" border=\"0\" alt=\"Figure 5.5: Drag-and-drop bookmarking tool requires a mouse\" width=\"100%\" \/> <strong>Figura 5.5<\/strong>: Questa feature, raggruppare bookmark per oggetti correlati, richiede un mouse per fare &#8220;drag and drop&#8221; degli item nella lista. Un semplice pulsante &#8220;Aggiungi&#8221; renderebbe il tutto pi\u00f9 accessibile.<\/p>\n<h3>Mostrare quale elemento ha il focus da tastiera<\/h3>\n<p>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&#8217;elemento. Tuttavia, la keyboard usability pu\u00f2 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 &#8220;hover&#8221;, come ad esempio, quando il mouse o un altro device di puntamento sta &#8220;passando sopra&#8221; ad un elemento.<\/p>\n<pre><code class=\"language-css\">a:hover, a:active, a:focus { outline: 2px solid blue }<\/code><\/pre>\n<p><strong>Figura 5.6<\/strong>: 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 &#8220;mouse over&#8221; (hover), l&#8217;active o il focus da tastiera.<\/p>\n<h3>Non intrappolare il focus da tastiera<\/h3>\n<p>La &#8220;keyboard trap&#8221; avviene con gli oggetti &#8220;embedded&#8221;, come i video, le applet e Flash. Quando il focus \u00e8 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 &#8220;embedded&#8221;. Idealmente, l&#8217;entrata o l&#8217;uscita da un oggetto &#8220;embedded&#8221; 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&#8217;opzione da tastiera e documentatela in maniera tale che gli utenti da tastiera possano evitare di rimanere intrappolati.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Rendete i controlli sufficientemente grandi da poterli gestire facilmente<\/h2>\n<p>I controlli sullo schermo potrebbero non essere tridimensionali, tuttavia gli utenti hanno ancora bisogno di una certa manualit\u00e0 per azionarli. Condizioni fisiche quali l&#8217;artrite o i tremori possono rendere difficile l&#8217;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\u00f2 rendere difficile l&#8217;uso di tali controlli. Le persone che navigano sul web usando dispositivi mobili con touchscreen possono avere delle difficolt\u00e0 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.<\/p>\n<p>Le seguenti linee guida contribuiscono a rendere i controlli semplici da usare:<\/p>\n<ul>\n<li><strong>Minimizzate le capacit\u00e0 di movimento preciso richieste per gli elementi interattivi.<\/strong> Fate in modo che i pulsanti e i punti in cui si deve toccare siano sufficientemente grandi.<\/li>\n<li><strong>Controlli di spazio.<\/strong> Lasciate uno spazio sufficiente tra i controlli, cos\u00ec che gli utenti non attivino accidentalmente quello sbagliato.<\/li>\n<li><strong>Minimizzate la complessit\u00e0 dell&#8217;azione richiesta.<\/strong> 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.<\/li>\n<\/ul>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Lasciate che siano gli utenti a controllare il funzionamento dell&#8217;interfaccia<\/h2>\n<p>Cercate di evitare di fare cambiamenti che non siano attivati da una richiesta esplicita dell&#8217;utente. Per esempio, il &#8220;carosello&#8221; 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&#8217;interfaccia distrae e ha un impatto sulla comprensione. Alcuni utenti hanno bisogno di pi\u00f9 tempo per assorbire le informazioni, cos\u00ec, come minimo, rendete disponibile un metodo per fermare l&#8217;avanzamento automatico. (Vedi Capitolo 9, &#8220;Accessible Media&#8221; per ulteriori informazioni sul multimedia).<\/p>\n<p>Un approccio migliore consiste nel caricare la prima immagine e di fornire dei controlli chiari per l&#8217;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&#8217;utente a scegliere di farlo partire. L&#8217;autoplay non \u00e8 solo una distrazione, pu\u00f2 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).<\/p>\n<p>Un&#8217;altra pratica comune consiste nell&#8217;aprire i link in una nuova finestra, solitamente con l&#8217;intenzione di aiutare gli utenti a tornare al sito web originale perch\u00e9 possono farlo semplicemente chiudendo quest&#8217;ultima finestra. Sfortunatamente, l&#8217;apertura di una nuova finestra d\u00e0 il via a una nuova cronologia di navigazione. Quando gli utenti navigano in questa nuova finestra e cercano di usare il pulsante &#8220;Indietro&#8221; per tornare al primo sito web, non possono farlo, perch\u00e9 il primo sito web non \u00e8 nella cronologia della finestra che abbiamo aperto &#8220;programmaticamente&#8221;. Questa pratica potrebbe davvero risultare nell&#8217;esatto opposto dell&#8217;effetto desiderato perch\u00e9 gli utenti potrebbero non essere in grado di trovare la strada per tornare indietro.<\/p>\n<p>Decidere se aprire una nuova finestra \u00e8 la semplice illustrazione di un principio importante: <strong>Non fate azioni al posto degli utenti quando questi possono farle da soli.<\/strong><\/p>\n<p>Le persone che vogliono aprire i link in una nuova finestra possono farlo da soli, usando i controlli &#8220;built-in&#8221; nei browser. Le persone che non amano aprire link in una nuova finestra non possono non usare questo comportamento se lo programmate nell&#8217;interfaccia. Come designer, dobbiamo rispettare i limiti dell&#8217;ambiente dell&#8217;utente.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Progettate per le eventualit\u00e0<\/h2>\n<p>Proprio come gli allarmi antincendio e le uscite di sicurezza di un edificio, i prodotti digitali devono anch&#8217;essi essere creati cos\u00ec che quando qualcosa va storto, vengano minimizzati gli effetti dannosi o vengano prevenuti attraverso una risposta all&#8217;errore e un opportuno recovery.<\/p>\n<p>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 \u00e8 intuitiva per tutti gli utenti e nessun utente \u00e8 sempre il target.<\/p>\n<p>Progettare per le eventualit\u00e0 vuol dire utilizzare il design per minimizzare l&#8217;impatto degli errori e gli insuccessi di sistema quando non possono essere evitati.<\/p>\n<p>Per esempio, dovreste supportare gli utenti che stanno inserendo delle informazioni, ordinando un prodotto o postando un commento.<\/p>\n<ul>\n<li><strong>Mettete a disposizione una pagina di revisione<\/strong>. Permettete agli utenti di rivedere i dati che hanno inserito prima di inviarli.<\/li>\n<li><strong>Date delle opzioni per sistemare i dati inseriti<\/strong>. Supportate un processo iterativo di revisione\/editing per dare agli utenti tutto il tempo necessario e l&#8217;opportunit\u00e0 di essere sicuri dei dati inseriti.<\/li>\n<li><strong>Realizzate una pagina di conferma<\/strong>. Quando si invia l&#8217;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&#8217;interazione, ma funzionano anche come conversazione:<\/li>\n<\/ul>\n<blockquote>\n<p><strong>Utente:<\/strong> Vorrei fare un ordine. Ecco tutte le mie informazioni.<\/p>\n<p><strong>Sito:<\/strong> Grazie. Ricevute. Ti manderemo il tuo ordine in tre giorni.<\/p>\n<\/blockquote>\n<p>Una buona comunicazione pu\u00f2 anche rendere pi\u00f9 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.<\/p>\n<p>Se dovesse capitare un errore, fornite un feedback utile e accessibile in risposta agli errori di input. Il feedback dovrebbe apparire con l&#8217;elemento contenente un errore e dovrebbe fornire delle istruzioni chiare su come correggere l&#8217;input, come mostrato nella form di registrazione d&#8217;esempio della Figura 5.3.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Permettete agli utenti di prendersi pi\u00f9 tempo<\/h2>\n<p>Il tempo \u00e8 una sfida per molte persone. Potrebbe volerci pi\u00f9 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\u00f9 lentamente o aver bisogno di pi\u00f9 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\u00e9 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.<\/p>\n<p>Alcuni siti web hanno delle feature che vengono attivate dal tempo. Un esempio comune \u00e8 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&#8217;ora e controlla l&#8217;attivit\u00e0. Se un intervallo predeterminato passa senza attivit\u00e0 da parte dell&#8217;utente, il sistema va in timeout e chiude la sessione dell&#8217;utente.<\/p>\n<p>Un processo di timeout ben progettato avvisa gli utenti prima di chiudergli la sessione e gli d\u00e0 la possibilit\u00e0 di continuare la sessione corrente. Inoltre, se il sistema alla fine chiude effettivamente la sessione dell&#8217;utente, mette in cache qualunque attivit\u00e0 abbiano iniziato nel browser. Questo permette all&#8217;utente di riconnettersi al sistema e di ripartire da dove aveva lasciato.<\/p>\n<\/div>\n<p>Illustrazioni: {carlok}<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Che contribuiate alla user experience, allo sviluppo o alla strategia per un sito web, avete il dovere verso il vostro lavoro, la responsabilit\u00e0 etica e (in molti casi) legale di rendere il sito accessibile e un dovere altrettanto pressante verso gli stakeholder, la vostra creativit\u00e0 e la vostra carriera di rendere un sito accessibile emsenza\/em sacrificare un briciolo di design o di innovazione. Cosa deve fare, quindi, un creatore di siti o applicazioni? Tanto per cominciare, deve leggere questo libro! Siamo entusiasti di presentarvi in esclusiva un estratto dal Capitolo 5 di A Web for Everyone: Designing Accessible User Experiences di Sarah Horton e Whitney Quesenbery, disponibile presso Rosenfeld Media, con uno sconto del 20% per i lettori di ALA.<\/p>\n","protected":false},"author":818,"featured_media":7000723,"comment_status":"open","ping_status":"open","template":"","categories":[279,106,9,86],"tags":[],"coauthors":[411,412],"class_list":["post-439","article","type-article","status-publish","has-post-thumbnail","hentry","category-interaction-design","category-numero-89-26-febbraio-2014","category-usabilita","category-user-experience"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/439","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article"}],"about":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/types\/article"}],"author":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/users\/818"}],"replies":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/comments?post=439"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000723"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=439"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=439"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=439"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=439"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}