Form accessibile: la validazione e uno sguardo al futuro

Form accessibile

Eccoci qua, al terzo appuntamento con la realizzazione di un Form accessibile: dopo aver visto il codice (x)HTML ottimizzato per la struttura, i metodi CSS per posizionare gli elementi e per dare “anche all’occhio la sua parte”,  oggi daremo “dinamicità” al nostro form. Ti parlerò della validazione, dei vari modi per attuarla e quale tra di essi è il migliore, andando a scoprire che i vari linguaggi non sono vincenti come giocatori singoli, ma lo sono se li usiamo come una squadra, una formazione, dove ognuno ha il proprio ruolo specifico e contribuisce alla causa.

Form accessibile: Linguaggi lato server

Presumibilmente, i dati che il form trasmetterà alla pagina indicata nell’attributo action saranno processati da un linguaggio lato server (PHP, ASP, JSP, io parlerò di PHP perché è il linguaggio che uso e conosco) che ne farà quello che avrai deciso di fargli fare (immagazzinarli in un DB, utilizzarli per spedire una e-mail, ecc).

Per far sì che questi linguaggi riescano a carpire i dati inviati dal form, è necessario che ogni campo input abbia un attributo name differente, eccezion fatta per i radio-button che avranno lo stesso name ma valore (value) diverso a seconda di quale è selezionato; il campo name può avere lo stesso valore del campo id.

Sarà quindi il caso di aggiungere al nostro vecchio esempio i vari attributi name dove mancano (già che c’ero, ho aggiunto gli asterischi ai campi obbligatori), visivamente il risultato non sarà molto diverso.

Fatto questo,  il nostro linguaggio lato server, ad esempio PHP, sarà in grado di interpretare i dati che gli saranno passati e di processarli a nostro piacimento: un uso sicuramente utile sarebbe quello di verificare la validità dei dati; potremmo infatti controllare che un campo sia stato compilato (trim($_POST[‘nick’]!=””)), che sia numerico (is_numeric($_POST[‘eta’])), che sia un’e-mail valida (tramite le espressioni regolari) e via dicendo.

In caso di risultato positivo potremmo restituire un messaggio di conferma dell’operazione (o mandare a una pagina che lo contenga) mentre in caso contrario potremmo ritornare alla pagina del form restituendo un messaggio d’errore, anche personalizzato in base agli errori da correggere.

Messaggio di successo

Feedback di messaggio inviato

Questo metodo è sicuramente completo, nonché necessario: a prescindere da quali siano i controlli impostati sul nostro form, non c’è un modo più sicuro di questo che ti possa dare la certezza che una volta incontrato un errore si interrompa lo script, proseguendo magari nell’inviare una mail vuota o andando a inserire un utente senza password o senza e-mail nel tuo database.

Purtroppo però, per quanto si possa impostarlo bene, questo metodo ha dei limiti in termini di usabilità e nel generare traffico effettivamente inutile, in quanto lo script viene richiamato a prescindere dal fatto che ci siano le condizioni o meno per eseguirlo: di fatto già la verifica delle condizioni diventa parte dello script da eseguire.

E’ meglio quindi effettuare dei controlli preventivi con un linguaggio client-side.

Javascript

Javascript è appunto un linguaggio lato client, che ci permette di effettuare dei controlli preventivi sul completamento dei campi e sulla correttezza del loro contenuto.

La relazione tra javascript e i form è molto duratura, anche se è cambiata (migliorata) negli anni: inizialmente la validazione javascript veniva implementata prettamente tramite alert-box, che, come loro abitudine, si aprivano al centro dello schermo accompagnate da un suono poco rassicurante. Il messaggio, personalizzato, ci indicava quale fosse l’errore commesso e una volta premuto “OK” in genere ci si trovava con un auto-focus sul campo incriminato. Questa gestione degli errori non è un granché, già solo per il terrore che incute l’apertura di un’alert; oltretutto, nei casi peggiori, il messaggio può essere vago o addirittura inesistente. Fortunatamente ci siamo evoluti.

Alert-box

Un'altert-box poco chiara

Le librerie javascript

In realtà le funzioni innovative  di cui sto per parlare non sono appannaggio unicamente delle librerie js, ma in questo contesto ci risparmiano un bel po’ di codice oltre a darci dei risultati ottimi. Conoscerai sicuramente jQuery, MooTools o Prototype e a seconda di quella che utilizzi, c’è un plug-in che si occupa di gestire gli errori di validazione sul form.

Io ho provato jQuery validate (su cui qui puoi trovare un ottimo tutorial firmato JustB) e LiveValidation, che esiste sia come plug-in di Prototype che  in versione stand-alone; sono entrambi di facile implementazione e dotati di ampia documentazione a riguardo. Per completare il nostro esempio, io ho scelto di utilizzare LiveValidation Stand-alone.

Completiamo il nostro esempio

Come dicevo, l’implementazione è molto semplice, basterà scaricare il file livevalidation_standalone.js e richiamarlo nel nostro file html come segue.

<script type="text/javascript" language="javascript" src="js/livevalidation_standalone.js"></script>

Per l’utilizzo effettivo occorre aggiungere del codice dopo i campi input che vogliamo controllare, per cui a fine pagina andrà benissimo. Questo codice assegnerà all’input -tramite l’id- il metodo di validazione (presenza, numerico, combinazione, lunghezza minima o massima, corrispondenza tra due campi…), eventuali opzioni, il tempo di risposta (in millisecondi, di default è immediato) e la possibilità di modificare i messaggi di errore o di successo.

Quindi, ora l’idea sarebbe di assegnare i controlli ai vari campi che abbiamo impostato come obbligatori, il codice è il seguente, da ripetere per ogni campo interessato, tranne i radio-button (che non ne hanno bisogno) e il select, vedremo poi perché.

var nick = new LiveValidation('nick');
nick.add( Validate.Presence );

A questo punto il risultato sarà questo qui, ora prova a lasciare bianco uno dei campi obbligatori – nell’esempio noterai che ho aggiunto il campo “ripeti password”, l’ho fatto per sperimentare la corrispondenza tra i due campi.

Riempendo i campi o meno, noterai i messaggi “Thankyou!” o “Can’t be empty”: la cosa noiosa sarà adesso aggiungere ad ognuno dei campi i nostri messaggi personalizzati, dovremmo quindi modificare ognuno in questo modo:

var nick = new LiveValidation('nick', { validMessage: " "} );
nick.add( Validate.Presence,{ failureMessage: "Compila il campo" } );

Per quanto riguarda il “validMessage” è uno spazio vuoto, per lasciar posto a un segno di spunta che aggiungeremo poi con i CSS: mi sembra superfluo sostituire il “Thankyou!” con un “Grazie” altrettanto inutile e ridondante. Per il “failureMessage”  invece non basta una X rossa che indichi l’errore: è necessario specificare quale sia l’errore nella compilazione; la frase da usare va scelta a seconda del contesto: “Inserire/definire/specificare un valore” suona un po’ troppo asettico specialmente per chi non è dell’ambiente (ma se è una community per programmatori va più che bene),”Compila il campo” è più o meno soddisfacente; ma in realtà la cosa migliore è definire per ogni input una sua frase: “Inserisci il nickname”, “Inserisci la tua età”, “Inserisci l’indirizzo e-mail” e via dicendo. Questo il risultato: noterai che alcuni avvisi si spostano su due linee, ma più tardi sistemeremo questo “problema estetico” con i CSS.

Errore troppo generico

Un errore troppo generico è inutile e frustrante

Allo stesso modo, aggiungeremo i metodi che controllano che:

  1. il campo età sia numerico (eta.add( Validate.Numericality ););
  2. il campo e-mail sia effettivamente un indirizzo e-mail (email.add( Validate.Email ););
  3. il campo password sia di almeno 4 caratteri (password.add( Validate.Length, { minimum: 4 } ););
  4. il campo ripeti password sia uguale al campo password (password2.add( Validate.Confirmation, { match: ‘password’ } );).

Anche ad ognuno di questi controlli bisognerà dare un failureMessage personalizzato, rimpiazzando così quello inglese; ecco il codice.

var nick = new LiveValidation('nick', { validMessage: " "} );

nick.add( Validate.Presence,{ failureMessage: "Inserisci il nickname desiderato" } );

var eta = new LiveValidation('eta', { validMessage: " "} );

eta.add( Validate.Presence,{ failureMessage: "Inserisci la tua età" } );

eta.add( Validate.Numericality,{ notANumberMessage: "Deve essere un numero" } );

var email = new LiveValidation('email', { validMessage: " ", wait: 1400} );

email.add( Validate.Presence,{ failureMessage: "Inserisci la tua e-mail" } );

email.add( Validate.Email,{ failureMessage: "Indirizzo e-mail non valido" } );

var password = new LiveValidation('password', { validMessage: " "} );

password.add( Validate.Presence,{ failureMessage: "Inserisci la password" } );

password.add( Validate.Length, { minimum: 4,tooShortMessage: "La password deve essere di almeno 4 caratteri" } );

var password2 = new LiveValidation('password2', { validMessage: " "} );

password2.add( Validate.Presence,{ failureMessage: "Inserisci nuovamente la password" } );

password2.add( Validate.Confirmation, { match: 'password', failureMessage:"Le password devono coincidere"} );

Ed ecco il risultato con i nuovi controlli impostati. Noterai che alcune righe contengono cose di cui non abbiamo parlato, come  il notANumberMessage:”” nella validazione dell’età, che permette di impostare un messaggio di errore nel caso in cui si inserisca un carattere non-numerico e tooShortMessage nella validazione della password che imposta il messaggio di errore per una stringa troppo corta.

Vediamo ancora il wait: 1400 nell’e-mail: questo serve per dare un ritardo di 1400 millisecondi (1,4″) nel responso, che altrimenti sarebbe immediato dando un esito negativo già solo scrivendo la prima lettera e continuando a segnalare l’errore fino a che non si fosse completata la scrittura dell’indirizzo corretto, in questo modo invece l’errore viene segnalato solo quando si smette di scrivere per almeno 1,4″ rendendo il tutto più usabile e gradevole.

messaggio d'errore per e-mail

Di default l'errore viene visualizzato appena inizio a digitare... è fastidioso!

Ci sono molte impostazioni che possono essere cambiate, come il decidere di dare un feedback sull’inserimento dei dati solo nel momento in cui si fa il submit, piuttosto che in tempo reale: è possibile conoscere le varie opzioni negli esempi pubblicati sul sito LiveValidation.

I CSS

Le varie classi CSS utilizzate dalla libreria e che andremo a modificare sono:

  • LV_validation_message – questa classe è aggiunta a tutti i messaggi di validazione
  • LV_valid – questa classe è aggiunta ai messaggi di successo
  • LV_invalid – questa classe è aggiunta ai messaggi di errore
  • LV_valid_field – questa classe viene aggiunta ai campi validi
  • LV_invalid_filed – questa classe viene aggiunta ai campi non validi

Con queste classi avrai la possibilità di modificare l’aspetto dei messaggi e di evidenziare le differenze tra un messaggio positivo e uno d’errore: ci interessa nello specifico modificarne la posizione, i colori per dare un maggiore feedback visivo e aggiungere l’immagine come avevo già anticipato.

Per quanto riguarda la posizione sarà meglio tenere i messaggi di errore, contenenti del testo a volte anche un po’ esteso, al di sotto del campo di input incriminato, come di fatto succede già.

Le classi di LiveValidation sono assegnate a un tag span che viene creato tramite JS,  ed ereditano quindi lo stile che abbiamo assegnato nei precedenti articoli all’elemento span, tra cui la regola dei 250px di larghezza: per questo motivo spesso il testo si dispone su due righe. Per evitare questo fastidioso effetto, sarà necessario specificare una larghezza più ampia per la classe LV_invalid.

Dato che poi è convenzione associare il colore rosso a un errore (di che colore era la penna con cui la tua maestra ti correggeva i compiti?) o a un pericolo, assegneremo il colore rosso al testo contenuto in questa classe, ed useremo il rosso anche per segnare il contorno del campo input errato. In questo modo l’errore sarà rapidamente individuato.

Ecco il codice:

.LV_invalid {
    color:#900;
    width:350px;
}
.LV_invalid_field,
input.LV_invalid_field:hover,
input.LV_invalid_field:active,
textarea.LV_invalid_field:hover,
textarea.LV_invalid_field:active {
     border-color:#C00;
}

Viceversa, per il bordo dei campi validi useremo il verde, mentre per il messaggio (che avevamo lasciato vuoto), cioè la classe LV_valid, potrai impostare un’immagine di sfondo (ad esempio un check verde), assegnando alla stessa classe una larghezza e un’altezza uguale a quella dell’immagine scelta.

Ecco il mio codice:

.LV_valid {
	width:12px;
	height:12px;
	margin-top:6px;
	background:url(checkmark.gif) no-repeat;
}

.LV_valid_field,
input.LV_valid_field:hover,
input.LV_valid_field:active,
textarea.LV_valid_field:hover,
textarea.LV_valid_field:active {
    border-color:#090;
}
   

E’ necessario però che sia LV_valid, che LV_invalid siano floattate a destra, ma è inutile ripetere due volte questa regola in quanto basta assegnarla alla classe LV_validation_message, alla quale, a gusto personale, si possono aggiungere anche gli stili che vogliamo abbia il testo.

 .LV_validation_message{
	font-style:italic;
	float:right;
	}

Questo è il risultato finale. E con questo è finito il nostro esempio.

Uno sguardo al futuro: le possibilità HTML5

HTML5  permetterà una gestione dei form più semplice, grazie a nuovi tipi di campi input come <input type=”tel”>, <input type=”number”>, <input type=”email”>; nuovi attributi come “placeholder” che permette di inserire un suggerimento su come compilare il campo all’interno dello stesso e l’attributo “required” che permette di controllare la presenza dei dati all’interno dei campi.

Tutto questo permetterà, un domani, di snellire molto il codice, migliorare l’usabilità, e senza alcuna necessità di codice javascript in quanto l’HTML5 sarà (è) in grado da solo di interpretare la validità dei campi.

Va ricordato che HTML5 è ancora una bozza, giustamente non ancora pienamente compatibile con tutti i browser, meno che mai IE (per rendere alcuni metodi HTML5 compatibili con IE è possibile utilizzare delle librerie js, come Modernizr). Per approfondire il discorso HTML5, ti consiglio la lettura di quest’articolo di Nando.

Considerazioni finali

Abbiamo visto come utilizzare LiveValidation per verificare la correttezza dei dati inviati dal nostro form, abbiamo parlato dei vari modi in cui è possibile farlo sempre tramite js, jQuery o HTML5: a prescindere dal risultato visivo finale, ogni metodo è simile nel fatto che se c’è un problema nella compilazione, il form non viene inviato, e nel fatto che al momento dipendono comunque tutti (anche HTML5) da javascript.

Questa è un aspetto molto importante da tenere sempre a mente: javascript non è un linguaggio su cui fare affidamento, ma solo un miglioramento; è possibile infatti che il supporto a javascript sia disabilitato o filtrato da proxy e firewall e nel caso in cui tu non abbia un salvagente, una funzionalità certa come PHP, potresti andare incontro a diversi problemi!

Abbiamo parlato anche dell’importanza di messaggi d’errore chiari: quest’aspetto spesso viene trascurato nella realizzazione di un form, generando incomprensioni e frustrazione nell’utente finale, che non capisce dov’è che sbaglia.

Anni fa non riuscivo ad entrare nel sito della banca per gestire il mio conto: premendo il tasto “Entra” , dopo aver inserito le mie password, non avevo alcun responso e veniva semplicemente ricaricata la pagina. Neanche un generico “Dati errati”. Ho controllato più volte l’esattezza dei miei codici, per la paura che mi bloccassero l’accesso… alla fine il sito non era compatibile con Firefox.

A te, da utente, è mai capitata un’esperienza simile? E ha cambiato in qualche modo il tuo approccio al web-design?

Gli altri articoli della serie “Form accessibile”

Tag: , ,

L'autore

Appassionata di web-design e web-designer di professione, ha una conoscenza approfondita dell'(x)HTML/CSS, ama sperimentare script in PHP e javascript ed è sempre pronta ad apprendere nuove tecniche. Per i siti preferisce uno stile sobrio con particolare attenzione all'accessibilità e all'usabilità, e soprattutto a quello che c'è sotto la scocca: il codice, rigorosamente standard.

Sito web dell'autore | Altri articoli scritti da

Articoli correlati

Potresti essere interessato anche ai seguenti articoli:

14 commenti

  1. Riccardo
  2. Zaso
  3. macene

Trackback e pingback

Non ci sono trackback e pingback disponibili per questo articolo

Lascia un Commento