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

Web Design elements: I form – design

Web Design elements: Validare i form con jQuery

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:

27 commenti

  1. Zaso
  2. Silvia
    • Silvia
    • Silvia
  3. GABRIELE

Trackback e pingback

  1. 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…

Lascia un Commento