Come realizzare un form accessibile e con codice ottimizzato?
Dopo tanta teoria ed esempi di cosa non fare, oggi finalmente ci sporcheremo le mani con un po’ di codice , andando a vedere come realizzare un form accessibile e con codice standard.
Nella stragrande maggioranza dei casi infatti, i form che troviamo in giro non rispettano le regole di accessibilità riguardo i comandi da tastiera e per lo più vengono impaginati all’interno di tabelle: sembra che anche il web-designer più illuminato, davanti a un form abbia una sorta di blocco che lo costringe inevitabilmente a incarcerare gli innocenti campi di input all’interno di inutili e fastidiose celle.
Eppure è possibile, con molto meno codice e qualche linea di CSS, avere un form senza tabelle, accessibile, standard e volendo, anche accattivante… vediamo come!
Avvertenze sul codice
Nell’esempio uso xHTML Strict, per cui eventuali tag “a capo” saranno scritti in questo modo <br />, allo stesso modo saranno chiusi i campi input <input … /> e i checkbox o i radio-button conterranno l’attributo checked valorizzato, quindi checked=”checked”; se utilizzate HTML dovreste saperlo che <br> e <input … > si chiudono senza necessità dello slash (/) e checked non ha bisogno di essere necessariamente valorizzato; in ultimo, se utilizzate xHTML Transitional, potrete scrivere come preferite (essendo un linguaggio più elastico), anche se sarebbe preferibile la prima sintassi presentata.
Conoscere i tag propri del form
Ovviamente un tag fondamentale è il tag <form> che ha come attributo obbligatorio action, che dovrai valorizzare con la URL della pagina che processerà i dati. Se provassimo a inserire un qualsiasi tag direttamente all’interno del tag form otterremo un errore di validazione, eccezion fatta per i tag <fieldset> o <p>: dato che <fieldset> è un tag proprio dei form, che raggruppa appunto un set di campi (field), useremo questo.
<form action=""></span>
<pre>
<fieldset>
</fieldset>
</form>
A questo punto possiamo inserire i nostri campi <input>, corredati dalle loro etichette ovvero le <label> dove è obbligatorio inserire l’attributo for, che deve essere valorizzato con il valore dell’id del campo corrispondente. A parole può risultare un po’ ostico, per cui andiamo a vedere una dimostrazione.
<label for="nome"> Nome: <input id="nome" type="text" /> </label>
Il tag <label> può contenere il campo input come nell’esempio precedente, o esserne separato come segue: in entrambi i casi il codice è valido secondo gli standard del w3c.
<label for="nome"> Nome: </label> <input id="nome" type="text" />
Per comodità nell’impostare successivamente lo stile CSS, io preferisco la prima alternativa.
L’etichetta (il tag label) è importante sotto il profilo accessibilità perché cliccando su di esso si attiva il campo input relativo.
Abbiamo cominciato mostrando il tag input più usato, e cioè <input type=”text” />; decidere quando e perché usarlo è molto facile: per tutti i dati in forma di stringa come nome, cognome, numero di telefono, e-mail e via dicendo… passiamo invece al altri tipi di tag che a volte innescano qualche dilemma, iniziando dai checkbox.
<fieldset>
<legend>Interessi</legend>
<label for="arte"> <input id="arte" type="checkbox" /> Arte</label>
<label for="tecnologia"> <input id="tecnologia" type="checkbox" /> Tecnologia</label>
<label for="musica"><input id="musica" type="checkbox" /> Musica</label>
</fieldset>
In questo esempio (come nel successivo) ho utilizzato un altro fieldset (annidato nel fieldset principale) per raggruppare i vari input che compongono la risposta e per sfruttare il tag <legend> nel quale inserire la richiesta.
Per chiarire la scelta di utilizzo tra checkbox e radio-button specifichiamo le differenze: i checkbox vengono utilizzati per selezionare nessuna, una o più voci, (scelta multipla) mentre i radio-button si usano quando è possibile selezionare obbligatoriamente solo un’alternativa tra quelle presenti (scelta singola).
<fieldset>
<legend>Sesso</legend>
<label for="sesso_m"><input id="sesso_m" type="radio" value="m" checked="checked" name="sesso" />Maschile</label>
<label for="sesso_f"><input id="sesso_f" type="radio" value="f" name="sesso" />Femmile</label>
</fieldset>
Per ragioni di accessibilità è consigliabile selezionare già una scelta (attributo checked) quando è necessario specificare una scelta come nell’esempio appena mostrato. In questo caso abbiamo aggiunto anche l’attributo name, necessario per far sì che i due radio-button vengano collegati e non sia possibili selezionarli entrambi. L’attributo name è utile generalmente per leggere i dati (ad esempio con PHP).
L’uso dei radio-button andrebbe limitato a casi in cui non ci siano troppe scelte possibili, indicativamente, oltre le 5 sarebbe consigliabile usare il menu di opzioni – select (il cosiddetto menu a tendina).
<label for="occupazione">Occupazione
<select name="occupazione" >
<option selected="selected">--</option>
<option value="operaio">Operaio</option>
<option value="impiegato">Impiegato</option>
<option value="studente">Studente</option>
<option value="disoccupato">Disoccupato</option></pre>
</select>
</label>
Tramite l’attributo selected=”selected”, impostiamo una opzione di default vuota, in modo che l’utente non si trovi ad aver “già dato” una risposta che in realtà non è la sua.
Nel caso in cui le scelte siano davvero tante, è preferibile suddividerle in gruppi utilizzando il tag <optgroup>: ad esempio le province d’Italia possono essere divise per regione, e rendere quindi la consultazione dell’elenco più semplice (per ovvi motivi l’esempio è limitato).
<label for="provincia">Provincia
<select name="provincia">
<option selected="selected">--</option>
<optgroup label="Lazio">
<option value="RM">ROMA</option>
<option value="LT">LATINA</option>
<option value="FR">FROSINONE</option>
<option value="VT">VITERBO</option>
<option value="RI">RIETI</option>
</optgroup>
<optgroup label="Campania">
<option value="NA">NAPOLI</option>
<option value="CE">CASERTA</option>
<option value="SA">SALERNO</option>
<option value="AV">AVELLINO</option>
<option value="BN">BENEVENTO</option>
</optgroup>
</select>
</label>
C’è la possibilità di utilizzare il select anche per la scelta multipla: in questo caso la tendina verrà visualizzata aperta mostrando l’elenco delle voci (spesso da scorrere tramite scroll-bar) che potranno essere selezionate tramite la pressione del tasto ctrl o cmd e click; tuttavia il funzionamento non è di immediata comprensione (poco usabile) e non è una scelta molto accessibile per le persone persone con capacità motoria ridotta, in quanto basta anche un click battuto per errore che vengono deselezionate le scelte fatte fino a quel momento, per cui anche se le opzioni sono tante, nel caso di scelta multipla è preferibile utilizzare i checkbox.
A seguire, ci interessano i pulsanti, che possono essere inseriti in due maniere: o con il tag <input> o con il tag <button>.
<input type="submit" value="Invia" /> <input type="reset" value="Annulla" />
sono uguali a
<button type="submit">Invia</button> <button type="reset">Annulla</button>
Io preferisco e consiglio il secondo modo, cioè di utilizzare il tag button, per un’impostazione migliore dei CSS: infatti per dare ai pulsanti uno stile diverso rispetto ai campi input potremmo utilizzare gli pseudo-selettori o aggiungere una classe, ma avendo a disposizione un tag apposito per i pulsanti, perché non usarlo?
Tanto per finire la presentazione dei vari tag componenti il form abbiamo ancora la <textarea>, che come suggerisce il nome è un’area di testo (tag con apertura e chiusura, in cui rows=”” e cols=”” sono obbligatori, anche se è possibile non valorizzarli); il tag <input type=”file” /> che permette di allegare un file al modulo caricandolo dal proprio computer; il tag <input type=”password” /> che oscura il testo che viene digitato mostrando solo un pallino corrispondente a ogni digitazione per impedirne la lettura ad altre persone presenti davanti allo schermo; infine il tag <input type=”hidden” /> che serve per passare dei valori nascosti all’utente (meno esperto).
Strutturare il form
Ora che abbiamo visto quali sono i tag da utilizzare e come utilizzarli, decidiamo le informazioni che andremo a richiedere nel nostro form: nome (text), cognome (text), sesso (radio-button), provincia di residenza (select con optgroup), consenso al trattamento dei dati personali (checkbox), messaggio personale (textarea).
Nell’esempio ho preparato il form non formattato di questi dati (più o meno).
Rendere il form accessibile ed usabile
In linea teorica, per migliorare l’accessibilità e la navigabilità di un sito esistono l’attributo accesskey e l’attributo tabindex andiamo ora a vedere cosa sono e perché utilizzarli o meno.
Accesskey
L’attributo accesskey può essere aggiunto ad ogni elemento attivo della pagina (anchor-link, input…) e serve per navigare tra essi mediante delle scorciatoie da tastiera: come tutte le scorciatoie si preme un tasto, alt o ctrl, diverso a seconda del browser o del sistema operativo, e la lettera o il numero scelti come valore dell’attributo. Nel caso in cui valorizzassi accesskey=”a”, premendo ctrl/alt + “A”, attiverei l’elemento relativo.
Si potrebbe scegliere ad esempio di dare l’accesskey “N” al campo di input nome, “C” al cognome, e così via.
<input type="text" id="nome" accesskey="n" /> <input type="text" id="cognome" accesskey="c" />
Dato che la relazione tra il tasto e l’elemento è una scelta completamente libera, bisognerebbe fornire un manuale all’utente in modo che possa sapere come utilizzare le scorciatoie. Bisogna anche tener conto che usando sempre la logica delle iniziali si potrebbero creare conflitti: ad esempio se nel menu abbiamo la pagina “Chi siamo” con l’accesskey “C”, questa entrerebbe in conflitto col campo di input cognome.
Perché non lo utilizziamo
L’uso dell’attributo accesskey era un requisito per l’accessibilità nelle WCAG 1.0, ma nelle WCAG 2.0 tale requisito è sparito per trasformarsi in un suggerimento.
Questo può farci dormire sonni tranquilli, ma il motivo è che più che facilitare la consultazione dei contenuti, l’uso dell’accesskey sembra complicarlo.
Come abbiamo detto già, la scelta dei tasti (lettere o numeri) da utilizzare è completamente libera: questo comporta che potremmo decidere di utilizzare una logica per la quale scegliamo l’accesskey sulla base delle iniziali, o altrimenti sull’ordine del contenuto nella pagina, o ancora senza alcuna logica. Ciò vuol dire che non c’è alcuno standard e che comunque l’utente dovrebbe consultare un manuale ogni volta che si approccia a un nuovo sito, e possibilmente impararlo piuttosto che aprirlo ogni volta che vuole cambiare pagina; a volte può essere ostico addirittura trovare il manuale che consenta la navigazione… e allora, cosa dovrebbe fare il nostro utente? Affidarsi al caso?
Oltre ai possibili conflitti interni al sito, non sono infrequenti i conflitti con le scorciatoie proprie dei browser (ad esempio i tasti veloci per aggiungere un sito ai preferiti, cercare un testo nella pagina, salvare…), e che ogni browser si comporta a modo suo in fatto di precedenza.
Insomma, nell’uso di accesskey si tende spesso a fare più confusione che altro.
A tali riguardi consiglio un articolo di Tommaso Baldovino (post-WCAG 2.0) e questo articolo del LAU (pre-WCAG 2.0) che evidenziano problemi e perplessità in maniera più approfondita.
Tabindex
L’attributo tabindex, come l’accesskey, può essere aggiunto ad ogni elemento attivo della pagina e serve per navigare tra essi semplicemente con la pressione del tasto tab: il suo utilizzo nel form è molto comodo, dato che per compilare il modulo l’attività maggiore è quella tramite tastiera, per cui una volta completato un campo risulta molto più semplice passare al campo successivo con la pressione del tasto tab. La valorizzazione dell’attributo non è altro che l’ordine in cui si interagisce con gli elementi – in questo caso attivare i campi del form in modo da essere compilati, in altri casi aprire i link – e consiste in un numero crescente.
Purtroppo capita di incontrare dei form che non gestiscono bene la navigazione tramite tastiera, per cui premendo il tasto tab vengono saltati dei campi; questo problema si presenta maggiormente nel caso in cui il form sia impaginato all’interno di tabelle (se va bene solo una, sennò tabelle annidate): se infatti non viene specificato il tabindex, alla pressione del tasto viene attivato il campo successivo nel codice, che potrebbe non corrispondere a quello successivo nella presentazione.
Un altro problema deriva probabilmente da form scopiazzati senza controllare effettivamente il codice e quindi di mettere gli input con le relative tabindex in ordine sparso, valutando solo gli id, e quindi di creare un ordine che tanto ordine non è: mi è capitato di incontrare form dove si passava dal primo al penultimo campo, poi di nuovo al secondo, all’ultimo, al terzo e poi invia, o anche di dover premere più di una volta per attivare un qualsiasi altro campo successivo. Quando mi succede qualcosa del genere, personalmente maledico la persona che ha realizzato il codice e mi rassegno ad utilizzare il mouse, ma l’utente medio si sente frustrato e non riesce a capire cosa non funziona, trovandosi un sito che non risponde come dovrebbe ai comandi standard che lui ha assimilato. Se poi volessimo parlare di un possibile utente con limitate capacità motorie, ti lascio immaginare…
Regalare i dati sensibili ai vari siti che compongono la rete è una delle attività più odiate dagli utenti: i vari timori sulla privacy e il sapere che probabilmente inizierà a ricevere altre e-mail da spostare nel cestino sono già dei freni alla registrazione o alla compilazione di un modulo… aggiungiamoci le difficoltà che si possono incontrare nel compilare un form realizzato senza le dovute attenzioni e la frittata è fatta!
Perché non lo utilizziamo
Ora che ti ho spiegato cos’è il tabindex, probabilmente ti starai chiedendo perché nel nostro esempio non c’è.
Presto detto: non ci serve.
Non ci serve perché i campi da compilare sono già in ordine: per presentare il form utilizzeremo i CSS e non delle tabelle che mischino i campi, rendendo oltretutto la pagina inutilmente pesante; in realtà il mark-up è già tutto qui, o quasi.
Se utilizzassimo l’attributo tabindex in questo caso non dovremmo far altro che inserire i numeri a partire da 1 a seguire nell’ordine in cui già si succedono gli elementi.
<input type="text" id="name" tabindex="1" />
Okay, ma mi avevi detto che avremmo reso il form accessibile, quindi che devo fare?
Hai ragione, ma sai qual è la verità? Il form, così com’è, è già accessibile.
In realtà adesso si tratta solo di dargli un po’ di stile e di aggiungere quel poco mark-up in più per farlo apparire come vogliamo… ed è quello che faremo nella seconda parte di questo articolo!
Conclusione
In questo articolo abbiamo dato uno sguardo veloce ai tag che compongono un form e l’abbiamo realizzato con un codice (x)HTML pulito e preciso, senza tabelle annidate, senza div e senza tanti elementi di mark-up essenzialmente inutili. Abbiamo visto come gli attributi che dovrebbero aiutarci a creare un sito più accessibile siano in realtà poco utili rispetto ai vantaggi di un codice standard ed ottimizzato.
Sei curioso di conoscere come farai a trasformare questo brutto anatroccolo in uno splendido cigno (sto parlando del form!!)?
E come ti comporti con la progettazione dei form? Utilizzi gli attributi tabindex e accesskey, o prendi in considerazione altri accorgimenti? A te la parola!
Letture consigliate
Web Design elements: I form – le basi
L'autore
Articoli correlati
Potresti essere interessato anche ai seguenti articoli:
27 commenti
Trackback e pingback
-
Form accessibile: la validazione e uno sguardo al futuro | Your Inspiration Web
[...] qua, al terzo appuntamento con la realizzazione di un Form accessibile: dopo aver visto il codice (x)HTML ottimizzato per…
Brava Anna , i miei complimenti… ps auguri :D
Grazie Rocco. Accipicchia, eri in pole-position per commentare ;)
Bell’articolo, hai affrontato l’argomento in maniera molto dettagliata e non è mai facile riuscirci.
Per un web migliore io mi accontenterei di vedere form con label associate ai campi input: sono sempre troppi i siti che non rispettano nemmeno queste regole di base.
Ciao Tommaso,
grazie mille per il tuo commento; a dirti la verità non ho potuto fare a meno di approfondire, e cercare di darci un taglio è stata davvero dura!
Purtroppo hai ragione, spesso e volentieri le label non vengono nemmeno utilizzate…
Proprio in questo periodo non faccio altro che vivere tra form e codici vari.
Articoli come questi sono una manna per non scordarsi nella fretta le cose importanti.
Ciao Zaso, felice di esserti utile! Grazie del tuo commento e non perderti i prossimi articoli, mi raccomando
Piacevole post…interessante…cercavo una cosa simile ultimamente..cadi a fagiuolo come si suol dire… Grazie Anna….e AUGURISSIMI X OGGI! ;)
Grazie mille Ale!
Sinceramente penso che la parte successiva dell’articolo sarà ancora più interessante: il form è un ottimo esempio che può aiutarci ad aprire gli occhi su quanto spesso vengano usati div e classi inutili, quando sarebbe molto più facile sfruttare il mark-up che abbiamo già.
Ciao, alla prossima :)
Una piccola “pro” tip. Oggi sempre più spesso si vede il campo label sparire anche in ambiti piuttosto seri. Se per “necessità” non può essere usato il campo label un’alternativa (ripeto è un’alternativa non l’ottimo) può essere quella di mettere il campo title all’input. In questo modo si può raffazzonare un minimo per quanto riguarda gli screen-reader. Queste pratiche sono sempre più comuni sopratutto alla luce di nuovi modi di fare form con il label contenuto nell’input (trasposizione più o meno fedele di interazioni nate fondamentalmente per gli smartphone per motivi di spazio).
Ciao Elmook,
utile suggerimento anche se ovviamente il discorso andrebbe approfondito un po’: mi permetto di correggerti, il title nel campo input non è utile agli screen-reader perché le label in questo caso si potrebbero usare (non avendo, di fatto, nessun problema di spazio), basterebbe poi nascondere il testo della label nel CSS destinato al mobile; oltretutto l’attributo title di per sé non basta per identificare i campi visivamente quindi bisognerebbe o valorizzare l’attributo value oppure aggiungere un’immagine di sfondo con il testo dell’etichetta che sul focus diventa bianca.
Ma trattandosi di aspetti presentazionali, ne parleremo più approfonditamente nel prossimo articolo.
Grazie mille comunque per il commento molto utile, è un ottimo spunto!
@Anna:
non mi correggi affatto:
http://www.w3.org/TR/WCAG-TECHS/H65.html
Ci sono casi in cui i label non possono proprio essere usati e lo dico sia da coder che da consulente per l’accessibilità. Spesso ci si ritrova a dover mettere mano su codici assurdi e l’unica cosa che si può fare è “limitare i danni”. Il title nell’input viene letto da Jaws e Windows Eye. Il resto del tuo discorso io lo davo per scontato (non discuto la tecnica del labeling dentro l’input nè come può essere attuata).
Forse per l’ultima parte mi hai frainteso. Il comportamento del labeling viene usato sì in ambito mobile ma viene ripreso anche in ambito non mobile non sto parlando di progressive enhancement ma proprio di comportamenti mutuati e spesso ripresi da grafici e WD per questioni di spazio e stile (meno testo da posizionare).
Concludo dicendo che molto spesso si pensa all’accessibilità come una cosa che può essere fatta da zero ma nel mondo reale spesso invece si viene messi davanti al fatto che il codice già c’è nella migliore delle ipotesi generato da un CMS x e l’unica cosa che si può fare è cercare di limare quanto più possibile per cercare di arrivare ad un grado di accessibilità per lo meno decente. La tecnica che ho illustrato io si inserisce proprio in questi termini che in Italia rappresentano il 90% dei casi.
Credo che anche tu abbia frainteso me: lungi da me dire che gli screen-reader non leggono l’attributo title, intendevo “non utile” nel senso che non è necessario in vista della label (ove questa ci sia ovviamente).
Per quanto riguarda l’ambito non-mobile non sono d’accordo per motivi di spazio: gli schermi sono grandi e lo diventano sempre di più, non inserire le label in un form è una scelta sbagliata IMHO. L’unica eccezione può essere costituita dalla barra di ricerca presente in ogni pagina.
Per quanto riguarda la tua conclusione, conosco bene la situazione di dover mettere delle toppe su del codice già scritto, ma fidati che molti lo scrivono di sana pianta senza nessuna attenzione all’accessibilità, agli standard e quant’altro.
E poi, perdonami la presunzione, scrivo questi articoli proprio sperando che le persone che scrivono un codice del genere (o applicazioni che lo generano), diventino una minoranza rispetto alla situazione attuale.
Decisamente un articolo molto utile e completo in tutti i suoi dettagli.
Ti faccio i miei complimenti Anna!
Grazie mille del tuo commento e dei complimenti Andrea :)
Ottimo, grazie Anna!
Grazie a te del commento!
eh si Anna…bell’articolo ;)
Grazie mille Ciro :)
Ciao Anna, bell’articolo. Avevo scritto anch’io una serie in due parti proprio su questo argomento, ma il tuo è sicuramente più completo ;)
http://www.mynamespace.it/categoria/web-design/
Interessante, darò sicuramente uno sguardo.
Ciao Carlo, grazie
ciao Anna, grazie per l’utilissimo tutorial!
Una domanda però! Ho provato a fare un form come da indicazioni, usando il che uso di solito, ma poi nell’invio mi dà errore. La mail in realtà arriva lo stesso, con però indicati solo i campi “sesso”, “occupazione” e “provincia”. Da cosa può dipendere secondo te?
Siliva
…usando il … form method=”POST” action=”….
Ciao Silvia, grazie a te per il commento.
Non vedendo il codice è difficile darti una risposta, ma posso azzardare: in questo esempio non ho ancora specificato (credo che lo farò nella 3^ parte dell’articolo) che per inviare i dati a una pagina PHP bisogna specificare l’attributo name (a piacere o con lo stesso valore di id), esempio: input type=”text” id=”nome” name=”nome”
può essere questo il tuo problema?
Anna! Aggiungendo l’attributo name dove mancava, il tutto funziona alla perfezione! Anche l’invio non mi dà più l’errore. Non avevo proprio notato che fosse quella la differenza!
Grazie mille per la celere risposta e indicazione =)
…e attento i prossimi tutorial!
Sono contenta di averti aiutato e di aver azzeccato al primo colpo ;)
A presto col prossimo tutorial!
CIAO ANNA TI FACCIO UNA DOMANDA , IO DEVO METTERE UN FORM ALL’INTERNO DI UN SITO CREATO CON WEB SITE X5 COME DEVO FARE SOPRATUTTO COME FUNZIONA, MAGARI SE ME LO SCRIVI IN MODO DA COPIARE I CODICI GRAZIE IN ANTICIPO