Iniziamo con un modulo di registrazione. La maggior parte delle aziende desidera relazioni a lungo termine con i propri utenti. Per fare ciò hanno bisogno che gli utenti si registrino. E per farlo , hanno bisogno di dare valore in cambio agli utenti. Nessuno vuole iscriversi al tuo servizio: vogliono solo accedere a tutto ciò che offri o alla promessa di un'esperienza più veloce la prossima volta che visiteranno.

Nonostante l'aspetto di base del modulo di registrazione, ci sono molte cose da considerare: gli elementi primitivi che compongono un modulo (etichette, pulsanti e input), i modi per ridurre lo sforzo (anche su moduli piccoli come questo), fino al modulo convalida.

Nella scelta di una forma così semplice, possiamo ingrandire le qualità fondamentali che si trovano in forme ben progettate.

## Come potrebbe apparire

Il modulo è composto da quattro campi e un pulsante di invio. Ogni campo è composto da un controllo (l'input) e dalla relativa etichetta.

Ecco l'HTML:

 <form> <label for="firstName">First name</label> <input type="text" name="firstName"> <label for="lastName">Last name</label> <input type="text" name="lastName"> <label for="email">Email address</label> <input type="email" name="email"> <label for="password">Create password</label> <input type="password" name="password" placeholder="Must be at least 8 characters"> <input type="submit" value="Register"> </form>

Le etichette sono il punto in cui inizia la nostra discussione.

## Etichette

In Accessibility For Everyone , Laura Kalbag stabilisce quattro parametri generali che migliorano l'esperienza dell'utente per tutti:

• Visuale : semplifica la visualizzazione.
• Uditivo : facilita l'ascolto.
• Motore : facilita l'interazione.
• Cognitivo : facilita la comprensione.

Osservando le etichette da ciascuno di questi punti di vista, possiamo vedere quanto siano importanti le etichette. Gli utenti vedenti possono leggerli, gli utenti ipovedenti possono ascoltarli utilizzando uno screen reader e gli utenti con problemi motori possono concentrarsi più facilmente sul campo grazie all'area colpita più ampia. Questo perché facendo clic su un'etichetta si imposta lo stato attivo sull'elemento del modulo associato.

Per questi motivi, ogni controllo che accetta input dovrebbe avere un ausiliario <label> . I pulsanti di invio non accettano input, quindi non necessitano di un'etichetta ausiliaria: l'attributo value , che esegue il rendering del testo all'interno del pulsante, funge da etichetta accessibile.

Per collegare un input a un'etichetta, l' id dell'input e l'attributo dell'etichetta for devono corrispondere ed essere univoci per la pagina. Nel caso del campo email, il valore è “email”:

 html < label for = "email" > Email address </ label > < input id = "email" >

Non inserire un'etichetta significa ignorare le esigenze di molti utenti, compresi quelli con disabilità fisiche e cognitive. Concentrandoci sulle barriere riconosciute alle persone con disabilità, possiamo rendere i nostri moduli più facili e più robusti per tutti.

Ad esempio, un'area colpita più ampia è fondamentale per gli utenti con problemi motori, ma è più facile da colpire anche per quelli senza disabilità.

## Segnaposto

L'attributo placeholder ha lo scopo di memorizzare un suggerimento. Fornisce agli utenti una guida aggiuntiva durante la compilazione di un campo, particolarmente utile per i campi che hanno regole complesse come un campo password.

Poiché il testo segnaposto non è un valore reale, è disattivato in modo che possa essere differenziato dai valori inseriti dall'utente.

A differenza delle etichette, i suggerimenti sono facoltativi e non dovrebbero essere usati come una cosa ovvia. Solo perché l'attributo placeholder esiste non significa che dobbiamo usarlo. Non è necessario un segnaposto di "Inserisci il tuo nome" quando l'etichetta è "Nome": è una duplicazione inutile.

I segnaposto sono attraenti per la loro estetica minimale e salvaspazio. Questo perché il testo segnaposto viene posizionato all'interno del campo. Ma questo è un modo problematico per dare un suggerimento agli utenti.

Innanzitutto, scompaiono quando l'utente digita. Il testo che scompare è difficile da ricordare, il che può causare errori se, ad esempio, l'utente dimentica di soddisfare una delle regole della password. Gli utenti spesso scambiano il testo segnaposto per un valore, provocando l'eliminazione del campo, che di nuovo causerebbe errori in seguito. Il testo grigio su bianco manca di contrasto sufficiente, il che lo rende generalmente difficile da leggere. E per finire, alcuni browser non supportano i segnaposto, alcuni screen reader non li annunciano e il testo del suggerimento lungo potrebbe essere tagliato.

Questo è un sacco di problemi per quello che essenzialmente è solo testo. Tutti i contenuti, in particolare un suggerimento sul modulo, non dovrebbero essere considerati belli da avere. Quindi, invece di usare i segnaposto, è meglio posizionare il testo del suggerimento sopra il controllo in questo modo:

 <div class="field"> <label for="password"> <span class="field-label">Password</span> <span class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</span> </label> <input type="password" name="password"> </div>

Il suggerimento viene posizionato all'interno dell'etichetta e all'interno di un <span> in modo che possa avere uno stile diverso. Posizionandolo all'interno dell'etichetta, verrà letto dagli screen reader e ingrandirà ulteriormente l'area colpita.

Come per la maggior parte delle cose nel design, questo non è l'unico modo per ottenere questa funzionalità. Potremmo usare gli attributi ARIA per associare il suggerimento con l'input:

 <div class="field"> <label for="password">Password</label> <p class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</p> <input type="password" name="password"> </div>

L'attributo aria-describedby viene utilizzato per collegare il suggerimento tramite il suo id , proprio come l'attributo for per le etichette, ma al contrario. Viene aggiunto all'etichetta del controllo e letto dopo una breve pausa. In questo esempio, "la password [pausa] deve contenere più di otto caratteri con almeno un numero e una lettera maiuscola".

Ci sono anche altre differenze. Innanzitutto, facendo clic sul suggerimento (a <p> in questo caso) non si metterà a fuoco il controllo, il che riduce l'area colpita. In secondo luogo, nonostante il crescente supporto di ARIA, non sarà mai supportato così bene come gli elementi nativi. In questo caso particolare, Internet Explorer 11 non supporta aria-describedby . Questo è il motivo per cui la prima regola di ARIA è non usare ARIA:

"Se puoi utilizzare un elemento o un attributo HTML nativo con la semantica e il comportamento che richiedi già integrati , invece di riutilizzare un elemento e aggiungere un ruolo, stato o proprietà ARIA per renderlo accessibile, fallo ."

Etichette galleggianti

Il modello di etichetta float di Matt Smith è una tecnica che utilizza l'etichetta come segnaposto. L'etichetta inizia all'interno del controllo, ma fluttua sopra il controllo mentre l'utente digita, da cui il nome. Questa tecnica è spesso lodata per le sue qualità eccentriche, minimaliste e salvaspazio.

Sfortunatamente, ci sono diversi problemi con questo approccio. Primo, non c'è spazio per un suggerimento perché l'etichetta e il suggerimento sono la stessa cosa. In secondo luogo, sono difficili da leggere, a causa del loro scarso contrasto e del testo piccolo, poiché sono generalmente progettati. (È necessario un contrasto inferiore in modo che gli utenti abbiano la possibilità di distinguere tra un valore reale e un segnaposto.) Terzo, come i segnaposto, possono essere scambiati per un valore e potrebbero essere ritagliati.

E le etichette float in realtà non fanno risparmiare spazio. L'etichetta ha bisogno di spazio in cui muoversi in primo luogo. Anche se hanno fatto risparmiare spazio, non è certo una buona ragione per diminuire l'usabilità dei moduli.

"Sembra un grande sforzo quando potresti semplicemente mettere le etichette sopra gli input e ottenere tutti i vantaggi/nessuno dei problemi".
— Luke Wroblewski sulle etichette float

Le interfacce eccentriche e minimaliste non fanno sentire gli utenti fantastici: le interfacce ovvie, inclusive e robuste lo fanno. Ridurre artificialmente l'altezza di forme come questa è poco convincente e problematico.

Invece, dovresti dare la priorità a fare spazio a un'etichetta sempre presente e prontamente disponibile (e un suggerimento se necessario) all'inizio del processo di progettazione. In questo modo non dovrai spremere i contenuti in un piccolo spazio.

Tra poco parleremo di diverse tecniche meno artificiali per ridurre le dimensioni dei moduli.

## Il protocollo delle domande

Un modo efficace e naturale per ridurre le dimensioni di un modulo consiste nell'utilizzare un protocollo di domande. Ti aiuta a sapere perché stai ponendo tutte le domande o includendo un campo modulo.

Il modulo di registrazione deve raccogliere nome, cognome, indirizzo email e password? Ci sono modi migliori o alternativi per richiedere queste informazioni che semplifichino l'esperienza?

Con ogni probabilità, non è necessario richiedere il nome e il cognome dell'utente per la registrazione. Se hai bisogno di queste informazioni in seguito, per qualsiasi motivo, chiedile allora. Rimuovendo questi campi, possiamo dimezzare le dimensioni del modulo. Il tutto senza ricorrere a schemi nuovi e problematici.

### Accesso senza password

Un modo per evitare di chiedere agli utenti una password consiste nell'utilizzare il modello di accesso senza password . Funziona sfruttando la sicurezza della posta elettronica (che necessita già di una password). Gli utenti inseriscono solo il loro indirizzo e-mail e il servizio invia un collegamento speciale alla loro casella di posta. In seguito, accede immediatamente all'utente nel servizio.

Questo non solo riduce le dimensioni del modulo a un solo campo, ma evita anche agli utenti di dover ricordare un'altra password. Sebbene ciò semplifichi il modulo in isolamento, in altri modi aggiunge ulteriore complessità per l'utente.

In primo luogo, gli utenti potrebbero avere meno familiarità con questo approccio e molte persone sono preoccupate per la sicurezza online. In secondo luogo, dover passare dall'app al tuo account di posta elettronica è prolisso, soprattutto per gli utenti che conoscono la propria password o utilizzano un gestore di password.

Non è che una tecnica sia sempre migliore dell'altra. È che un protocollo di domande ci spinge a pensare a questo come parte del processo di progettazione. Altrimenti, aggiungeresti senza pensare un campo password sul modulo e finirai con esso.

### Passphrase

Le password sono generalmente brevi, difficili da ricordare e facili da decifrare. Gli utenti spesso devono creare una password di più di otto caratteri, composta da almeno una lettera maiuscola e una minuscola e un numero. Questa micro-interazione non è certo l'ideale.

"Scusa ma la tua password deve contenere una lettera maiuscola, un numero, un haiku, un segno di banda, un geroglifico e il sangue di una vergine."
— Meme Internet anonimo

Invece di una password, potremmo chiedere agli utenti una passphrase. Una passphrase è una serie di parole come “monkeysinmygarden” (scusate, è la prima cosa che mi viene in mente). In genere sono più facili da ricordare delle password e sono più sicure grazie alla loro lunghezza: le passphrase devono contenere almeno 16 caratteri.

Lo svantaggio è che le passphrase sono usate meno comunemente e, quindi, non familiari. Ciò può causare ansia agli utenti che sono già preoccupati per la sicurezza online.

Che si tratti del modello di accesso senza password o delle passphrase, dovremmo allontanarci dalle convenzioni solo dopo aver condotto una ricerca sugli utenti approfondita e diversificata. Non vuoi scambiare una serie di problemi con un'altra inconsapevolmente.

## Stile del campo

Il modo in cui stili i componenti del modulo sarà, almeno in parte, determinato dal prodotto o dal marchio dell'azienda. Tuttavia, la posizione dell'etichetta e gli stili di messa a fuoco sono considerazioni importanti.

### Posizione etichetta

I test di eye-tracking di Matteo Penzo hanno mostrato che il posizionamento dell'etichetta sopra (anziché accanto) il controllo del modulo funziona meglio.

"Posizionare un'etichetta proprio sopra il suo campo di input ha consentito agli utenti di catturare entrambi gli elementi con un solo movimento dell'occhio".

Ma ci sono altri motivi per mettere l'etichetta sopra il campo. Su piccoli oblò non c'è spazio accanto al controllo. E su finestre di grandi dimensioni, l'ingrandimento aumenta la possibilità che il testo scompaia fuori dallo schermo.

Inoltre, alcune etichette contengono molto testo, il che lo fa avvolgere su più righe, il che interromperebbe il ritmo visivo se posizionato accanto al controllo.

Anche se dovresti mirare a mantenere le etichette concise, non è sempre possibile. L'uso di uno schema che si adatta a contenuti variabili, posizionando le etichette sopra il controllo, è una buona strategia.

### Guarda, dimensioni e spazio

I campi del modulo dovrebbero assomigliare ai campi del modulo. Ma cosa significa esattamente?

Significa che una casella di testo dovrebbe apparire come una casella di testo. Le scatole vuote significano "riempimi" in virtù del fatto di essere vuote, come un libro da colorare. Questo fa parte del motivo per cui i segnaposto non sono utili. Rimuovono l'affordance percepita che altrimenti fornirebbe una casella di testo vuota.

Ciò significa anche che lo spazio vuoto deve essere inscatolato (bordato). La rimozione del bordo, o l'avere solo un bordo inferiore, ad esempio, rimuove le possibilità percepite. Un bordo inferiore potrebbe inizialmente sembrare un separatore. Anche se sai che devi compilare qualcosa, il valore va sopra o sotto la linea?

A livello spaziale, l'etichetta dovrebbe essere la più vicina al controllo del modulo, non al controllo del campo precedente. Le cose che sembrano vicine suggeriscono che appartengano. Avere una spaziatura uguale potrebbe migliorare l'estetica, ma sarebbe a scapito dell'usabilità.

Infine, l'etichetta e la casella di testo stessa dovrebbero essere abbastanza grandi da poter essere lette e toccate. Questo probabilmente significa una dimensione del carattere di almeno 16 pixel e idealmente un target di tocco complessivo di almeno 44 px.

### Stili di messa a fuoco

Gli stili di messa a fuoco sono una prospettiva più semplice. Per impostazione predefinita, i browser delineano l'elemento a fuoco in modo che gli utenti, in particolare quelli che utilizzano una tastiera, sappiano dove si trovano. Il problema con lo stile predefinito è che spesso è debole e difficile da vedere e alquanto brutto.

Anche se questo è il caso, non essere tentato di rimuoverlo, perché così facendo diminuirà notevolmente l'esperienza dell'utente per coloro che attraversano lo schermo con la tastiera. Possiamo sovrascrivere lo stile predefinito per renderlo più chiaro ed esteticamente più gradevole.

 input:focus { outline: 4px solid #ffbf47; }

## Il campo e-mail

Nonostante il suo aspetto semplice, ci sono alcuni dettagli importanti che sono entrati nella costruzione del campo che influenzano l'esperienza.

Come notato in precedenza, alcuni campi hanno un suggerimento oltre all'etichetta, motivo per cui l'etichetta si trova all'interno di un intervallo figlio. La classe field-label ci consente di modellarlo tramite CSS.

 <div class="field"> <label for="email"> <span class="field-label">Email address</span> </label> <input type="email" name="email"> </div>

L'etichetta stessa è "Indirizzo e-mail" e utilizza la maiuscola. In "Creare un caso per il caso delle lettere", John Saito spiega che il caso della frase (al contrario del caso del titolo) è generalmente più facile da leggere, più amichevole e rende più facile individuare i nomi. Se ascolti questo consiglio dipende da te, ma qualunque sia lo stile che scegli, assicurati di usarlo in modo coerente.

L'attributo del type di input è impostato su email , che attiva una tastiera su schermo specifica per email sui dispositivi mobili. Ciò offre agli utenti un facile accesso a @ e . simboli (punto) che ogni indirizzo email deve contenere.

Le persone che utilizzano un browser non di supporto vedranno un input di testo standard ( <input type="text"> ). Questa è una forma di miglioramento progressivo, che è una pietra angolare nella progettazione di esperienze inclusive.

### Miglioramento progressivo

Il miglioramento progressivo riguarda gli utenti. Capita solo di semplificare anche le nostre vite di designer e sviluppatori. Invece di stare al passo con una serie di browser e dispositivi (cosa impossibile!), possiamo concentrarci solo sulle funzionalità.

Innanzitutto, il miglioramento progressivo consiste nel fornire sempre agli utenti un'esperienza ragionevole, indipendentemente dal browser, dal dispositivo o dalla qualità della connessione. Quando le cose vanno male - e succederà - gli utenti non ne risentiranno perché possono ancora fare le cose.

Ci sono molti modi in cui un'esperienza può andare storta. Forse il foglio di stile o lo script non viene caricato. Forse tutto viene caricato, ma il browser dell'utente non riconosce alcuni HTML, CSS o JavaScript. Qualunque cosa accada, l'utilizzo del miglioramento progressivo durante la progettazione delle esperienze impedisce agli utenti di passare momenti particolarmente difficili.

Inizia con HTML per struttura e contenuto. Se CSS o JavaScript non si caricano, va bene perché il contenuto è lì.

Se tutto viene caricato correttamente, forse vari elementi HTML non vengono riconosciuti. Ad esempio, alcuni browser non comprendono <input type="email"> . Va bene, però, perché gli utenti riceveranno invece una casella di testo ( <input type="text"> ). Gli utenti possono comunque inserire un indirizzo email; semplicemente non ottengono una tastiera specifica per e-mail sui dispositivi mobili.

Forse il browser non comprende alcuni CSS fantasiosi e li ignorerà semplicemente. Nella maggior parte dei casi, questo non è un problema. Supponiamo che tu abbia un pulsante con border-radius: 10px . I browser che non riconoscono questa regola mostreranno un pulsante con angoli angolati. Probabilmente, l'affordance percepita del pulsante è ridotta, ma gli utenti rimangono illesi. In altri casi potrebbe essere utile utilizzare le query di funzionalità.

Poi c'è JavaScript, che è più complicato. Quando il browser tenta di analizzare i metodi che non riconosce, genererà un attacco sibilante. Ciò può causare il fallimento degli altri script (validi e supportati). Se lo script non verifica prima che i metodi esistano (rilevamento delle funzionalità) e funzionino (test delle funzionalità) prima di utilizzarli, gli utenti potrebbero ottenere un'interfaccia non funzionante. Ad esempio, se il gestore dei clic di un pulsante chiama un metodo non riconosciuto, il pulsante non funzionerà. Questo è male.

È così che migliori. Ma la cosa migliore è non aver bisogno di un miglioramento. HTML con un po' di CSS può offrire agli utenti un'esperienza eccellente. È il contenuto che conta e non hai bisogno di JavaScript per questo. Più puoi fare affidamento sul contenuto (HTML) e sullo stile (CSS), meglio è. Non posso sottolinearlo abbastanza: così spesso, l'esperienza di base è la migliore e la più performante. Non ha senso migliorare qualcosa se non aggiunge valore (vedi principio di progettazione inclusiva 7).

Naturalmente, ci sono momenti in cui l'esperienza di base non è così buona come potrebbe essere: è allora che è il momento di migliorare. Ma se seguiamo l'approccio sopra, quando un pezzo di CSS o JavaScript non viene riconosciuto o eseguito, le cose funzioneranno comunque.

Il miglioramento progressivo ci fa pensare a cosa succede quando le cose falliscono. Ci consente di costruire esperienze con la resilienza incorporata. Ma allo stesso modo, ci fa pensare se sia necessario un miglioramento; e se lo è, come farlo al meglio.

## Il campo della password

Utilizziamo lo stesso markup del campo e-mail discusso in precedenza. Se stai utilizzando un linguaggio modello, sarai in grado di creare un componente che soddisfi entrambi i tipi di campo. Questo aiuta a far rispettare il principio di progettazione inclusiva 3, essere coerenti .

 <div class="field"> <label for="password"> <span class="field-label">Choose password</span> <span class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</span> </label> <input type="password" name="password"> </div>

Il campo della password contiene un suggerimento. Senza uno, gli utenti non capiranno i requisiti, il che potrebbe causare un errore una volta che tentano di procedere.

L'attributo type="password" maschera il valore dell'input sostituendo ciò che l'utente digita con piccoli punti neri. Questa è una misura di sicurezza che impedisce alle persone di vedere ciò che hai digitato se si trovano nelle vicinanze.

### Una rivelazione della password

Oscurare il valore mentre l'utente digita rende difficile correggere gli errori di battitura. Quindi, quando ne viene eseguita una, è spesso più facile eliminare l'intera voce e ricominciare. Questo è frustrante poiché la maggior parte degli utenti non utilizza un computer con una persona che si guarda alle spalle.

A causa del maggior rischio di errori di battitura, alcuni moduli di registrazione includono un campo aggiuntivo "Conferma password". Questa è una misura precauzionale che richiede all'utente di digitare la stessa password due volte, raddoppiando lo sforzo e degradando l'esperienza dell'utente. Invece, è meglio consentire agli utenti di rivelare la propria password, che parla dei principi 4 e 5, di dare rispettivamente il controllo e l' offerta di scelta . In questo modo gli utenti possono scegliere di rivelare la propria password quando sanno che nessuno sta guardando, riducendo il rischio di errori di battitura.

Le versioni recenti di Internet Explorer e Microsoft Edge forniscono questo comportamento in modo nativo. Dato che creeremo la nostra soluzione, dovremmo sopprimere questa funzione usando CSS in questo modo:

 input[type=password]::-ms-reveal { display: none; }

Innanzitutto, dobbiamo iniettare un pulsante accanto all'input. L'elemento <button> dovrebbe essere il tuo elemento di riferimento per modificare qualsiasi cosa con JavaScript, tranne, cioè, per cambiare posizione, a cui servono i collegamenti. Quando viene cliccato, dovrebbe alternare l'attributo type tra password e text ; e l'etichetta del pulsante tra "Mostra" e "Nascondi".

 function PasswordReveal(input) { // store input as a property of the instance // so that it can be referenced in methods // on the prototype this.input = input; this.createButton(); }; PasswordReveal.prototype.createButton = function() { // create a button this.button = $('<button type="button">Show password</button>'); // inject button $(this.input).parent().append(this.button); // listen to the button's click event this.button.on('click', $.proxy(this, 'onButtonClick')); }; PasswordReveal.prototype.onButtonClick = function(e) { // Toggle input type and button text if(this.input.type === 'password') { this.input.type = 'text'; this.button.text('Hide password'); } else { this.input.type = 'password'; this.button.text('Show password'); } };

#### Sintassi JavaScript e note architettoniche

Poiché ci sono molte versioni di JavaScript e modi diversi per progettare i componenti, analizzeremo le scelte utilizzate per costruire il componente di rivelazione della password e tutti i componenti imminenti nel libro.

Innanzitutto, stiamo usando un costruttore. Un costruttore è una funzione scritta convenzionalmente in maiuscolo: PasswordReveal , non passwordReveal . Viene inizializzato utilizzando la new parola chiave, che ci consente di utilizzare lo stesso codice per creare diverse istanze del componente:

 var passwordReveal1 = new PasswordReveal(document.getElementById('input1')); var passwordReveal2 = new PasswordReveal(document.getElementById('input2'));

In secondo luogo, i metodi del componente sono definiti sul prototipo, ad esempio PasswordReveal.prototype.onButtonClick . Il prototipo è il modo più efficace per condividere metodi su più istanze dello stesso componente.

In terzo luogo, jQuery viene utilizzato per creare e recuperare elementi e ascoltare eventi. Anche se jQuery potrebbe non essere necessario o preferito, usarlo significa che questo libro può concentrarsi sui moduli e non sulle complessità dei componenti cross-browser.

Se sei un designer che codifica un po', l'ubiquità e la bassa barriera all'ingresso di jQuery dovrebbero essere utili. Allo stesso modo, se preferisci non usare jQuery, non avrai problemi a refactoring dei componenti in base alle tue preferenze.

Potresti anche aver notato l'uso della funzione $.proxy . Questa è l'implementazione di jQuery di Function.prototype.bind . Se non usiamo questa funzione per ascoltare gli eventi, il gestore dell'evento verrebbe chiamato nel contesto dell'elemento ( this ). Nell'esempio sopra, this.button non sarebbe definito. Ma vogliamo che this sia invece l'oggetto di rivelazione della password, in modo da poter accedere alle sue proprietà e metodi.

#### Opzioni di interfaccia alternative

L'interfaccia di rivelazione della password che abbiamo costruito sopra alterna l'etichetta del pulsante tra "Mostra password" e "Nascondi password". Alcuni utenti di screen reader possono confondersi quando viene modificata l'etichetta del pulsante; una volta che un utente incontra un pulsante, si aspetta che il pulsante persista. Anche se il pulsante è persistente, la modifica dell'etichetta fa sembrare che non lo sia.

Se la tua ricerca mostra che questo è un problema, potresti provare due approcci alternativi.

Innanzitutto, utilizza una casella di controllo con un'etichetta persistente di "Mostra password". Lo stato sarà segnalato dall'attributo checked . Gli utenti dello screen reader sentiranno "Mostra password, casella di controllo, selezionata" (o simili). Gli utenti vedenti vedranno il segno di spunta della casella di controllo. Il problema con questo approccio è che le caselle di controllo servono per inserire dati, non per controllare l'interfaccia. Alcuni utenti potrebbero pensare che la loro password verrà rivelata al sistema.

Oppure, in secondo luogo, cambia lo state del pulsante, non l'etichetta. Per trasmettere lo stato agli utenti di screen reader, puoi cambiare l'attributo aria-pressed tra true (premuto) e false (non premuto).

 <button type="button" aria-pressed="true"> Show password </button>

Quando si mette a fuoco il pulsante, le utilità per la lettura dello schermo annunceranno "Mostra password, pulsante di commutazione, premuto" (o simili). Per gli utenti vedenti, puoi impostare lo stile del pulsante in modo che appaia premuto o non premuto di conseguenza utilizzando il selettore di attributi in questo modo:

 [aria-pressed="true"] { box-shadow: inset 0 0 0 0.15rem #000, inset 0.25em 0.25em 0 #fff; }

Assicurati solo che gli stili non pressati e pressati siano ovvi e differenziati, altrimenti gli utenti vedenti potrebbero avere difficoltà a distinguere tra loro.

### Microcopia

L'etichetta è impostata su "Scegli password" anziché su "Password". Quest'ultimo è alquanto confuso e potrebbe richiedere all'utente di digitare una password che già possiede, il che potrebbe essere un problema di sicurezza. In modo più sottile, potrebbe suggerire che l'utente è già registrato, facendo sì che gli utenti con disabilità cognitive pensino invece di eseguire l'accesso.

Laddove "Password" è ambiguo, "Scegli password" fornisce chiarezza.

## Stili di pulsanti

Cos'è un pulsante? Ci riferiamo a molti diversi tipi di componenti in una pagina web come a un pulsante. In effetti, ho già trattato due diversi tipi di pulsanti senza richiamarli. Facciamolo ora.

I pulsanti che inviano i moduli sono "pulsanti di invio" e sono generalmente codificati come <input type="submit"> o <button type="submit"> . L'elemento <button> è più malleabile in quanto puoi annidare altri elementi al suo interno. Ma raramente ce n'è bisogno. La maggior parte dei pulsanti di invio contiene solo testo.

Nota: nelle versioni precedenti di Internet Explorer, se disponi di più <button type="submit"> s, il modulo invierà il valore di tutti i pulsanti al server, indipendentemente da quale è stato cliccato. Avrai bisogno di sapere quale pulsante è stato cliccato in modo da poter determinare la giusta linea di condotta da intraprendere, motivo per cui questo elemento dovrebbe essere evitato.

Altri pulsanti vengono inseriti nell'interfaccia per migliorare l'esperienza con JavaScript, proprio come abbiamo fatto con il componente di rivelazione della password discusso in precedenza. Anche quello era un <button> ma il suo type era impostato su button (non submit ).

In entrambi i casi, la prima cosa da sapere sui pulsanti è che non sono collegamenti. I collegamenti sono in genere sottolineati (dagli stili del programma utente) o posizionati in modo speciale (in una barra di navigazione) in modo da essere distinguibili dal testo normale. Quando si passa con il mouse su un collegamento, il cursore si trasformerà in un puntatore. Questo perché, a differenza dei pulsanti, i link hanno un'affordance percepita debole.

In Resilient Web Design , Jeremy Keith discute l'idea di onestà materiale. Dice: “Un materiale non dovrebbe essere usato come sostituto di un altro. Altrimenti il ​​risultato finale è ingannevole”. Far sembrare un collegamento un pulsante è materialmente disonesto. Dice agli utenti che link e pulsanti sono gli stessi quando non lo sono.

I link possono fare cose che i pulsanti non possono fare. I collegamenti possono essere aperti in una nuova scheda o aggiunti ai segnalibri per dopo, ad esempio. Pertanto, i pulsanti non dovrebbero apparire come collegamenti, né dovrebbero avere un cursore puntatore. Invece, dovremmo fare in modo che i pulsanti assomiglino a pulsanti, che hanno un'affordance percepita naturalmente forte. Se hanno angoli arrotondati, ombre discendenti e bordi dipende da te, ma dovrebbero comunque apparire come pulsanti.

I pulsanti possono comunque fornire feedback al passaggio del mouse (e sulla messa a fuoco) modificando, ad esempio, il colore dello sfondo.

### Posizionamento

I pulsanti di invio sono generalmente posizionati nella parte inferiore del modulo: con la maggior parte dei moduli, gli utenti compilano i campi dall'alto verso il basso e quindi inviano. Ma il pulsante dovrebbe essere allineato a sinistra, a destra o al centro? Per rispondere a questa domanda, dobbiamo pensare a dove gli utenti lo cercheranno naturalmente.

Le etichette dei campi e i controlli dei moduli sono allineati a sinistra (nelle lingue di lettura da sinistra a destra) e vengono eseguiti dall'alto verso il basso. Gli utenti cercheranno il campo successivo sotto l'ultimo. Naturalmente, quindi, anche il pulsante di invio va posizionato in quella posizione: a sinistra e direttamente sotto l'ultimo campo. Questo aiuta anche gli utenti che ingrandiscono, poiché un pulsante allineato a destra potrebbe scomparire più facilmente fuori dallo schermo.

### Testo

Il testo del pulsante è importante tanto quanto il suo stile. Il testo dovrebbe descrivere esplicitamente l'azione intrapresa. E poiché è un'azione, dovrebbe essere un verbo. Dovremmo mirare a usare il minor numero di parole possibile perché è più veloce da leggere. Ma non dovremmo rimuovere le parole a costo della chiarezza.

Le parole esatte possono corrispondere al tono di voce del tuo marchio, ma non scambiare chiarezza con eccentricità.

Un linguaggio semplice e chiaro è facile da capire per tutti. Le parole esatte dipenderanno dal tipo di servizio. Per il nostro modulo di registrazione "Registrati" va bene, ma a seconda del servizio "Unisciti" o "Registrati" potrebbe essere più appropriato.

## Convalida

Nonostante i nostri sforzi per creare un'esperienza di registrazione inclusiva, semplice e senza attriti, non possiamo eliminare l'errore umano. Le persone commettono errori e quando lo fanno, dovremmo rimediare il più facilmente possibile.

Quando si tratta di convalidare un modulo, ci sono una serie di dettagli importanti da considerare. Dalla scelta di quando fornire un feedback, a come visualizzare quel feedback, fino alla formulazione di un buon messaggio di errore, tutte queste cose devono essere prese in considerazione.

### Convalida HTML5

La convalida HTML5 è in circolazione da un po' di tempo. Aggiungendo solo alcuni attributi HTML, i browser di supporto contrassegneranno i campi errati quando il modulo viene inviato. I browser non supportati ricorrono alla convalida lato server.

Normalmente consiglierei di utilizzare le funzionalità che il browser fornisce gratuitamente perché è spesso più performante, robusto e accessibile. Per non parlare del fatto che diventa più familiare agli utenti man mano che più siti iniziano a utilizzare la funzionalità standard.

Sebbene il supporto per la convalida di HTML5 sia abbastanza buono, non è implementato in modo uniforme. Ad esempio, l'attributo obbligatorio può contrassegnare i campi come non validi sin dall'inizio, il che non è desiderabile. Alcuni browser, come Firefox 45.7, visualizzeranno l'errore "Inserisci un indirizzo e-mail" anche se l'utente ha inserito qualcosa nella casella, mentre Chrome, ad esempio, dice "Includi una '@' nell'indirizzo e-mail", che è più utile.

Vogliamo anche fornire agli utenti la stessa interfaccia indipendentemente dal fatto che vengano rilevati errori sul server o sul client. Per questi motivi progetteremo la nostra soluzione. La prima cosa da fare è disattivare la convalida HTML5: <form novalidate>

### Gestione dell'invio

Quando l'utente invia il modulo, dobbiamo verificare se ci sono errori. Se ci sono, dobbiamo impedire che il modulo invii i dettagli al server.

 function FormValidator(form) { form.on('submit', $.proxy(this, 'onSubmit')); } FormValidator.prototype.onSubmit = function(e) { if(!this.validate()) { e.preventDefault(); // show errors } };

Tieni presente che stiamo ascoltando l'evento di invio del modulo, non l'evento di clic del pulsante. Quest'ultimo impedirà agli utenti di inviare il modulo premendo Invio quando lo stato attivo si trova all'interno di uno dei campi. Questo è anche noto come invio di moduli impliciti .

### Visualizzazione feedback

Va benissimo rilevare la presenza di errori, ma a questo punto gli utenti non sono più saggi. Ci sono tre parti disparate dell'interfaccia che devono essere aggiornate. Parleremo di ciascuno di questi ora.

#### Titolo del documento

Il <title> del documento è la prima parte di una pagina web che può essere letta dagli screen reader. In quanto tale, possiamo usarlo per informare rapidamente gli utenti che qualcosa è andato storto con il loro invio. Ciò è particolarmente utile quando la pagina viene ricaricata dopo una richiesta del server.

Anche se stiamo migliorando l'esperienza dell'utente rilevando gli errori sul client con JavaScript, non tutti gli errori possono essere rilevati in questo modo. Ad esempio, controllare che un indirizzo email non sia già stato preso può essere verificato solo sul server. E in ogni caso, JavaScript è soggetto a errori, quindi non possiamo fare affidamento esclusivamente sulla sua disponibilità.

Laddove il titolo della pagina originale potrebbe leggere "Registrati per [servizio]", in caso di errore dovrebbe leggere "(2 errori) Registrati per [servizio]" (o simile). La formulazione esatta dipende in qualche modo dall'opinione.

Il seguente JavaScript aggiorna il titolo:

 document.title = "(" + this.errors.length + ")" + document.title;

Come notato sopra, questo è principalmente per gli utenti di screen reader, ma come spesso accade con il design inclusivo, ciò che aiuta un gruppo di utenti aiuta anche tutti gli altri. Questa volta, il titolo aggiornato funge da notifica nella scheda.

Riepilogo errori

Rispetto all'elemento del titolo, il riepilogo dell'errore è più evidente, che dice agli utenti vedenti che qualcosa è andato storto. Ma è anche responsabile di consentire agli utenti di capire cosa è andato storto e come risolverlo.

È posizionato nella parte superiore della pagina in modo che gli utenti non debbano scorrere verso il basso per vederlo dopo un aggiornamento della pagina (se si verifica un errore sul server). Convenzionalmente, gli errori sono colorati di rosso. Tuttavia, fare affidamento sul solo colore potrebbe escludere gli utenti daltonici. Per attirare l'attenzione sul riassunto, considera anche l'utilizzo di posizione, dimensione, testo e iconografia.

Il pannello include un'intestazione "C'è un problema" per indicare il problema. Nota che non dice la parola "Errore", che non è molto amichevole. Immagina di compilare i tuoi dati per acquistare un'auto in uno showroom e di aver commesso un errore. Il venditore non direbbe "Errore" - in effetti sarebbe strano se lo dicesse.

 <div class="errorSummary" role="group" tabindex="-1" aria-labelledby="errorSummary-heading"> <h2>There's a problem</h2> <ul> <li><a href="#emailaddress">Enter an email address</a></li> <li><a href="#password">The password must contain an uppercase letter</a></li> </ul> </div>

Il contenitore ha un role di group , che viene utilizzato per raggruppare un insieme di elementi dell'interfaccia: in questo caso, l'intestazione e i collegamenti di errore. L'attributo tabindex è impostato su -1 , quindi può essere focalizzato a livello di codice con JavaScript (quando il modulo viene inviato con errori). Ciò garantisce che il pannello di riepilogo degli errori venga visualizzato. In caso contrario, l'interfaccia sembrerebbe non rispondente e non funzionante al momento dell'invio.

Nota: l'utilizzo di tabindex="0" significa che sarà permanentemente attivabile tramite il tasto Tab , che è un errore WCAG 2.4.3 Focus Order. Se gli utenti possono selezionare qualcosa, si aspettano che farà effettivamente qualcosa.

 FormValidator.prototype.showSummary = function () { // ... this.summary.focus(); };

Sotto, c'è un elenco di collegamenti di errore. Facendo clic su un collegamento si metterà a fuoco il campo errato, che consente agli utenti di saltare rapidamente nel modulo. L'attributo href del collegamento è impostato sull'id del controllo, che in alcuni browser è sufficiente per impostare lo stato attivo su di esso. Tuttavia, in altri browser, facendo clic sul collegamento si farà semplicemente scorrere l'input nella visualizzazione, senza focalizzarlo. Per risolvere questo problema, possiamo focalizzare l'input in modo esplicito.

 FormValidator.prototype.onErrorClick = function(e) { e.preventDefault(); var href = e.target.href; var id = href.substring(href.indexOf("#"), href.length); $(id).focus(); };

Quando non ci sono errori, il pannello di riepilogo dovrebbe essere nascosto. Ciò garantisce che ci sia sempre un solo pannello di riepilogo sulla pagina e che appaia coerentemente nella stessa posizione indipendentemente dal fatto che gli errori vengano visualizzati dal client o dal server. Per nascondere il pannello dobbiamo aggiungere una classe di hidden .

 <div class="errorSummary hidden" ...></div>

 .hidden { display: none; }

Nota: puoi utilizzare l'attributo/proprietà hidden per attivare o disattivare la visibilità di un elemento, ma c'è meno supporto per esso. Il design inclusivo riguarda il prendere decisioni che, sai, difficilmente escludono le persone. L'uso di una classe è in linea con questa filosofia.

#### Errori in linea

Dobbiamo inserire il messaggio di errore pertinente appena sopra il campo. Ciò evita agli utenti di scorrere su e giù per la pagina per controllare il messaggio di errore e li fa scorrere verso il basso nel modulo. Se il messaggio fosse posizionato sotto il campo, aumenteremmo le possibilità che venga oscurato dal pannello di completamento automatico del browser o dalla tastiera su schermo.

 <div class="field"> <label for="blah"> <span class="field-error"> <svg width="1.5em" height="1.5em"><use xmlns:xlink="https://www.w3.org/1999/xlink" xlink:href="#warning-icon"></use></svg> Enter your email address. </span> <span class="field-error">Enter an email address</span> </label> </div>

Come il modello di suggerimento menzionato in precedenza, il messaggio di errore viene inserito all'interno dell'etichetta. Quando il campo è focalizzato, gli utenti dello screen reader ascolteranno il messaggio nel contesto, in modo che possano spostarsi liberamente attraverso il modulo senza dover fare riferimento al riepilogo.

Il messaggio di errore è rosso e utilizza un'icona di avviso SVG per attirare l'attenzione degli utenti. Se avessimo utilizzato solo un cambio di colore per indicare un errore, ciò escluderebbe gli utenti daltonici. Quindi funziona davvero bene per gli utenti vedenti, ma per quanto riguarda gli utenti di screen reader?

Per offrire agli utenti vedenti e non vedenti un'esperienza equivalente, possiamo utilizzare l'attributo aria-invalid ben supportato. Quando l'utente mette a fuoco l'input, ora annuncerà "Non valido" (o simile) negli screen reader.

 <input aria-inval>

Nota: il modulo di registrazione è composto solo da input di testo. Nel capitolo 3, "Un modulo di prenotazione del volo", vedremo come inserire gli errori in modo accessibile per gruppi di campi come i pulsanti di opzione.

### Invio di nuovo del modulo

Quando si invia il modulo per la seconda volta, è necessario eliminare dalla visualizzazione gli errori esistenti. In caso contrario, gli utenti potrebbero visualizzare errori duplicati.

 FormValidator.prototype.onSubmit = function(e) { this.resetPageTitle(); this.resetSummaryPanel(); this.removeInlineErrors(); if(!this.validate()) { e.preventDefault(); this.updatePageTitle(); this.showSummaryPanel(); this.showInlineErrors(); } };

### Inizializzazione

Dopo aver finito di definire il componente FormValidator , siamo ora pronti per inizializzarlo. Per creare un'istanza di FormValidator , devi passare l'elemento form come primo parametro.

 var validator = new FormValidator(document.getElementById('registration'));

Per convalidare il campo e-mail, ad esempio, chiama il metodo addValidator() :

 validator.addValidator('email', [{ method: function(field) { return field.value.trim().length > 0; }, message: 'Enter your email address.' },{ method: function(field) { return (field.value.indexOf('@') > -1); }, message: 'Enter the 'at' symbol in the email address.' }]);

Il primo parametro è il name del controllo e il secondo è una matrice di oggetti regola. Ogni regola contiene due proprietà: method e message . Il method è una funzione che verifica varie condizioni per restituire true o false . False pone il campo in uno stato di errore, che viene utilizzato per popolare l'interfaccia con errori come discusso in precedenza.

#### Perdona gli errori banali

In The Design of Everyday Things , Don Norman parla del design per errore. Parla del modo in cui le persone parlano:

“Se una persona dice qualcosa che riteniamo falsa, ci mettiamo in discussione e discutiamo. Non diamo un segnale di avvertimento. Non suoniamo. Non diamo messaggi di errore. […] Nelle normali conversazioni tra due amici, gli errori sono considerati normali, come approssimazioni a ciò che si intendeva veramente”.

A differenza degli umani, le macchine non sono abbastanza intelligenti da determinare il significato della maggior parte delle azioni, ma spesso perdonano gli errori molto meno di quanto dovrebbero. Jared Spool fa una battuta su questo in "Il design è metricamente opposto?" (circa 42 minuti in):

"Ci vuole una riga di codice per prendere un numero di telefono ed eliminare tutti i trattini, le parentesi e gli spazi, e ci vogliono dieci righe di codice per scrivere un messaggio di errore in cui le hai lasciate."

Il metodo addValidator (mostrato sopra) mostra come progettare regole di convalida in modo che perdonino errori banali. La prima regola, ad esempio, taglia il valore prima di verificarne la lunghezza, riducendo l'onere per l'utente.

### Convalida in linea in tempo reale

La convalida in linea in tempo reale fornisce agli utenti un feedback durante la digitazione o quando lasciano il campo ( onblur ). Ci sono alcune prove per dimostrare che la convalida in linea in tempo reale migliora l'accuratezza e riduce i tempi di completamento nei moduli lunghi. Ciò ha in parte a che fare con il fornire feedback agli utenti quando i requisiti del campo sono freschi nella mente degli utenti. Ma la convalida in linea dal vivo (o la convalida dal vivo in breve) pone diversi problemi.

Per le voci che richiedono un certo numero di caratteri, la prima sequenza di tasti costituirà sempre una voce non valida. Ciò significa che gli utenti verranno interrotti in anticipo, il che può indurli a cambiare contesto mentale, dall'immissione di informazioni alla correzione.

In alternativa, potremmo attendere che l'utente inserisca un numero sufficiente di caratteri prima di mostrare un errore. Ma questo significa che gli utenti ricevono feedback solo dopo aver inserito un valore corretto, il che è alquanto inutile.

Potremmo aspettare che l'utente lasci il campo ( onblur ), ma è troppo tardi poiché l'utente si è preparato mentalmente (e spesso ha iniziato a digitare) il campo successivo. Inoltre, alcuni utenti cambiano finestra o utilizzano un gestore di password quando utilizzano un modulo. In questo modo si attiverà l'evento sfocatura, causando la visualizzazione di un errore prima che l'utente abbia terminato. Tutto molto frustrante.

Ricorda, non ci sono problemi nel fornire feedback agli utenti senza un aggiornamento della pagina. Né c'è un problema con l'inserimento dei messaggi di errore in linea (accanto ai campi): l'abbiamo già fatto. Il problema con il feedback dal vivo è che interrompe gli utenti troppo presto o troppo tardi, il che spesso si traduce in un'esperienza stridente.

Se gli utenti vedono spesso errori, probabilmente c'è qualcosa che non va altrove. Concentrati sull'abbreviazione del modulo e sulla fornitura di una guida migliore (buona etichettatura e testo di suggerimento). In questo modo gli utenti non dovrebbero vedere più dell'errore dispari. Vedremo forme più lunghe nel prossimo capitolo.

### Schema di affermazione della lista di controllo

Una variazione della convalida in tempo reale prevede la spuntatura delle regole (contrassegnandole come complete) mentre l'utente digita. Questo è meno invasivo della convalida in tempo reale, ma non è adatto a tutti i tipi di campo. Ecco un esempio del modulo di iscrizione di MailChimp, che utilizza questa tecnica per il campo della password.

Dovresti mettere le regole sopra il campo. In caso contrario, la tastiera su schermo potrebbe oscurare il feedback. Di conseguenza, gli utenti potrebbero interrompere la digitazione e nascondere la tastiera per quindi controllare il feedback.

### Una nota sulla disabilitazione dei pulsanti di invio

Alcuni moduli sono progettati per disabilitare il pulsante di invio fino a quando tutti i campi non diventano validi. Ci sono diversi problemi con questo.

In primo luogo, gli utenti si chiedono cosa c'è di sbagliato nelle loro voci. In secondo luogo, i pulsanti disabilitati non sono attivabili, il che rende difficile la scoperta del pulsante da parte degli utenti non vedenti che navigano utilizzando il tasto Tab . In terzo luogo, i pulsanti disabilitati sono difficili da leggere poiché sono disattivati.

Poiché stiamo fornendo agli utenti un feedback chiaro, quando l'utente se lo aspetta, non c'è alcuna buona ragione per togliere il controllo all'utente disabilitando comunque il pulsante.

### Creazione di un buon messaggio di errore

Non c'è niente di più importante del contenuto. Gli utenti non vengono sul tuo sito Web per godersi il design. Vengono per godersi il contenuto o il risultato dell'utilizzo di un servizio.

Anche l'esperienza più ponderata, inclusiva e ben progettata non conta nulla se ignoriamo le parole usate per creare messaggi di errore. Uno studio ha mostrato che la visualizzazione di messaggi di errore personalizzati ha aumentato le conversioni dello 0,5%, pari a oltre £ 250.000 di entrate annuali.

"Il contenuto è l'esperienza dell'utente."
— Ginny Redish

Come etichette, suggerimenti e qualsiasi altro contenuto, un buon messaggio di errore fornisce chiarezza con il minor numero di parole possibile. Normalmente, dovremmo guidare la progettazione di un'interfaccia basata sul contenuto, non il contrario. Ma in questo caso, capire come e perché mostri i messaggi di errore influenza il design delle parole. Questo è il motivo per cui Jared Spool afferma che "contenuti e design sono partner di lavoro inseparabili".

Stiamo mostrando i messaggi nel riepilogo nella parte superiore dello schermo e accanto ai campi. Mantenere due versioni dello stesso messaggio è una vendita difficile per un guadagno poco convincente. Invece, progetta un messaggio di errore che funzioni in entrambi i posti. "Inserisci un simbolo 'at'" ha bisogno del contesto dell'etichetta del campo per avere un senso. "Il tuo indirizzo email ha bisogno di un simbolo 'at'" funziona bene in entrambi i posti.

Evita i convenevoli, come iniziare ogni messaggio di errore con "Per favore". Da un lato, questo sembra educato; dall'altro, si intromette e implica una scelta.

Qualunque sia l'approccio adottato, ci sarà qualche ripetizione a causa della natura del contenuto. E il test di solito comporta l'invio del modulo senza inserire alcuna informazione. Questo rende la ripetizione palesemente ovvia, il che potrebbe farci capovolgere. Ma quante volte è così? La maggior parte degli utenti non sta cercando di interrompere l'interfaccia.

Errori diversi richiedono una formattazione diversa. Istruzioni come "Inserisci il tuo nome" sono naturali. Ma "Inserisci un nome di 35 caratteri o meno" è più lungo, più prolisso e meno naturale di una descrizione come "Il nome deve essere di 35 caratteri o meno".

Ecco una lista di controllo:

• Sii conciso. Non usare più parole del necessario, ma non tralasciare le parole a scapito della chiarezza.
• Sii coerente. Usa lo stesso tono, le stesse parole e la stessa punteggiatura in tutto.
• Sii specifico. Se sai perché qualcosa è andato storto, dillo. "L'e-mail non è valida." è ambiguo e grava sull'utente. "L'e-mail ha bisogno di un simbolo 'at'" è chiaro.
• Sii umano, evita il gergo. Non usare parole come non valido, proibito e obbligatorio.
• Usa un linguaggio semplice. I messaggi di errore non sono un'opportunità per promuovere il tono di voce umoristico del tuo marchio.
• Usa la voce attiva. Quando un errore è un'istruzione e dici all'utente cosa fare. Ad esempio, "Inserisci il tuo nome", non "Deve essere inserito il nome".
• Non incolpare l'utente. Fai sapere loro cosa è andato storto e come risolverlo.

## Sommario

In questo capitolo abbiamo risolto diverse sfide fondamentali per la progettazione dei moduli che sono applicabili ben oltre un semplice modulo di registrazione. Per molti aspetti, questo capitolo è stato tanto su cosa non fare, quanto su cosa dovremmo. Evitando schemi salvaspazio nuovi e artificiali per concentrarci sulla riduzione del numero di campi che includiamo, evitiamo diversi fallimenti di usabilità e allo stesso tempo rendiamo le forme più piacevoli.

### Cose da evitare

• Utilizzo dell'attributo placeholder come meccanismo per memorizzare l'etichetta e il testo del suggerimento.
• Utilizzo di tipi di input errati.
• Lo stile di pulsanti e collegamenti è lo stesso.
• Convalida dei campi durante la digitazione degli utenti.
• Disabilitare i pulsanti di invio.
• Utilizzo di gergo complesso e microcopia influenzata dal marchio.

E questo è tutto. Se ti è piaciuto questo primo capitolo dei Form Design Patterns , puoi ricevere subito il libro. Buona lettura!