Vai ai contenuti

LAU



Home > realizzare > accessibilità: codice HTML/XHTML > Realizzare form accessibili e...usabili?


Realizzare form accessibili e...usabili?

In questo articolo vengono esposti i principi utili alla progettazione di un buon form, al fine di ottenere applicativi che siano usabili ed accessibili.

a cura di: Luigi Panarace | 16 novembre 2005


1. Introduzione

Cuore degli applicativi, ma anche straordinari strumenti di interazione, i form meritano una particolare attenzione da parte di chi il web lo vuole realizzare non solo accessibile ma anche usabile.
Cimentandosi nella realizzazione di applicativi web, è immediato rendersi conto di quanti e quali ostacoli s'incontrano nella progettazione e realizzazione, e ci rende altresì conto che la maggior parte di tali problematiche deriva proprio dai form.
Data la loro importanza, quali strumenti di interazione con l'utente, errori di progettazione o realizzazione dei form possono pertanto compromettere la buona riuscita di un applicativo facendolo risultare poco comprensibile o persino indurre ad abbandonare la navigazione.
Realizzare un buon form è dunque un difficoltoso compito con il quale il progettista web si è sempre dovuto cimentare. Utile supporto a questo suo difficile compito, è oggi dato dalla recente normativa in tema di accessibilità ed usabilità, ovvero la ormai nota Legge Stanca (si rimanda il lettore ad un'attenta analisi della Legge e dei suoi Requisiti Tecnici come lettura propedeutica a quanto di seguito esposto).
I principi utili alla progettazione di un buon form, al fine di ottenere applicativi che siano usabili ed accessibili nella più opportuna accezione di questi termini, sarà quindi tema di questa mia trattazione, con esempi pratici ed analisi del codice da adottare. Il tutto, deriva in parte dall'esperienza personale nella realizzazione di applicativi web ed in parte da indicazioni emerse da test di accessibilità ed usabilità realizzati in collaborazioni con note associazioni di disabili come ASPHI.

torna all'indice

2. Principi generali

Nella realizzazione di un form, è prima di tutto buona norma far precedere sempre un titolo chiaro ed chiarificatore, che consenta di comprendere immediatamente che tipo di modulo si dovrà compilare. Oltre al titolo, è poi quasi sempre utile fornire una breve spiegazione introduttiva per far capire ulteriormente il motivo della richiesta dei dati o semplicemente per specificare l'obbligatorietà di alcuni campi.
Per casi più complicati che necessitano una spiegazione ulteriore e particolarmente lunga o elaborata, è consigliabile prevedere una guida, consultabile a parte, per poter approfondire la conoscenza del significato dei dati richiesti. Ad esempio, si pensi alla compilazione di moduli tributari dove la terminologia adottata per alcuni campi, può per molti risultare poco chiara o addirittura incomprensibile.
È un grave errore quello di costruire un form di cui l'utente non coglie immediatamente l'utilità in un determinato contesto. Far comprendere ed infondere fiducia in chi deve compilare un modulo on line, è indubbiamente il primo passo da compiere per evitare che l'utente si possa in qualche modo sentire più propenso all'abbandono che al proseguo della compilazione. In particolare poi, quando il form da trattare prevede l'inserimento di dati riservati per un'eventuale registrazione va sempre inserita la richiesta di assenso al trattamento dei dati personali. È vero che nella maggior parte dei casi l'utente non la leggerà, ma sarà in qualche modo rassicurato ed avrà più fiducia nel trasmettere via Internet i propri dati.
Un raggruppamento coerente dei campi da dover compilare, è poi un'altra importante prerogativa di un form ben concepito. Mescolare tra loro i dati, va da se, è un ottimo sistema per confondere l'utente!
Altra utile considerazione da farsi, come principio generale, è di dover badare alla lunghezza del form. In alcuni casi è utile suddividerlo in opportune sezioni, ma qui sta al buon senso e all'esperienza di ciascun progettista/navigatore del web. Suddividere un form troppo lungo, facendo quindi ricorso al cosiddetto splitting, è utile per non mettere a disagio o confondere l'utente. Si dovrà però tener presente che lì dove si attua tale metodo, sarà altresì utile ricorrere alla paginazione o all'indicazione degli step da percorrere, in modo da far comprendere quanto più o meno lunga sarà la compilazione e permettere all'utente di non perdersi nella navigazione.
Molto spesso, per poter disporre i moduli nella maniera più opportuna, è comodo ricorrere alle tabelle di impaginazione per poter soddisfare le esigenze grafiche dello sviluppatore. Un'alternativa più accessibile è, come ormai noto, data dall'utilizzo dei CSS per la presentazione visuale che consentono di ottenere un risultato estetico analogo a quello dato con l'uso delle tabelle.

È possibile oltre al resto ottenere un importante vantaggio: nel codice html rimangono i soli elementi strutturali del modulo con una conseguente agevolazione per l'interpretazione della pagina da parte di browser testuali e tecnologie assistive.
Ricordo inoltre che l'utilizzo dei frame, tanto cari e stra-utilizzati nel web vecchia maniera, sono ora fortemente deprecati. La composizione a "mosaico" di una pagina è fortemente disorientante per utenti non vedenti. È quindi indispensabile evitare che l'utente debba muoversi tra diversi frame per navigare il nostro sito e, a maggior ragione, per la compilazione di un modulo.
Infine, un ultimo suggerimento prima di passare ad analizzare gli elementi che possono comporre questi nostri form. Gli utenti possono essere portatori di disabilità ma non per questo motivo si devono estremizzare i concetti di accessibilità. Un buon progettista di interfacce accessibili non è colui che applica pedestremente le regole tecniche, ma piuttosto colui che, sensibile ai temi dell'accessibilità fa si che si possa tendere ad essa realmente e non solo per una superata validazione con motori automatici e magari all'esposizione di famigerati bollini.

torna all'indice

3. Come si realizza un form

Vediamo ora quali "buoni" principi devono essere adottati per la realizzazione dei form, analizzandone i vari elementi ed entrando nel merito del codice.

A. Campi di testo

Sono forse questi i più semplici ed i più utilizzati campi per la realizzazione di un form. I campi di inserimento testo infatti, permettono un'interazione semplice con l'utente poiché sono molto vicini alle sue abitudini. Infatti, in un certo qual modo, i campi di inserimento testo sono paragonabili ai campi che l'utente può incontrare anche in un modulo cartaceo.

<input name="testo" type="text" 
id="campotesto" 
value="" 
maxlength="25" />

Quali gli accorgimenti? Innanzitutto far sì che la lunghezza dei campi sia commisurata a ciò che dovranno contenere e quindi alla risposta che ci si attende. Credo che ognuno di noi si sia già imbattuto in campi troppo corti per cui per poter controllare quanto si è scritto bisogna ricorrere allo scorrimento del testo oppure, caso forse peggiore, sono i campi troppo lunghi che inducono a pensare: "Ma avrò scritto proprio tutto o non ho forse capito la domanda?"
Per quanto riguarda il codice, la lunghezza di un campo di testo è preferibile non impostarla tramite l'attributo "size", ma piuttosto con i CSS. Si può infatti ricorrere alla proprietà "width" per impostare la dimensione del campo e quindi separando effettivamente il contenuto dalla presentazione. Importante quanto utile il "maxlenght" quale attributo per impostare il numero massimo di caratteri che è possibile digitare. Per quanto è necessaria una certa attenzione nell'impostare questo parametro è facilmente intuibile l'utilità che può avere. In generale, nell'impostare questi parametri va sempre tenuto ben presente chi e come usa il form piuttosto che all'armonia del layout.
Sempre per quanto riguarda gli input di tipo testo, è in genere preferibile non predisporli con al loro interno del testo precompilato (Nell'esempio precedente è stato infatti impostato value="").
Viceversa l'utente si troverebbe costretto prima a cancellare il testo iniziale preimpostato (come ad esempio inserire qui il cognome) per poi cominciare la compilazione con i propri dati.

B. Text area

Altro elemento di interazione, per conversare con l'utente, è la text area. Con questo elemento è infatti possibile dar voce all'utente.
Le aree di testo, come noto, servono a permettere l'immissione di commenti, messaggi, codici ed altro. È in questo caso indispensabile stabilire il numero di colonne dell'area (larghezza) ed il numero di righe (altezza), ma la sintassi è molto semplice:

<textarea rows="10" cols="45" 
id="testo"> </textarea>

Come già detto per i campi input, anche in questo caso non è indispensabile l'utilizzo di un testo iniziale che, tra l'altro non potrebbe essere utile se non a dirci cose superflue come: "inserire qui il testo". È invece molto più utile ed importante dimensionare nella maniera più opportuna la text-area in funzione del contesto. Se è vero che l'utente non dovrà scrivere un romanzo, è anche auspicabile che in qualche modo non sia troppo limitato o che non debba continuamente ricorrere alla barra di scorrimento per verificare il testo inserito nel suo complesso.

C. Checkbox e Radio Button

Si o no? Vero o falso? Maschio o femmina? O ancora: quali di questi? Sono queste le domande che sostanzialmente si possono porre all'utente con gli elementi input di tipo checkbox o radio.
Nello specifico, i checkbox vanno utilizzati per rendere possibili selezioni multiple, mentre i radio vanno adottati per selezioni esclusive. Per quanto riguarda i radio va precisato che, è si vero che servono per risposte esclusive come si o no, ma è anche da tenere in considerazione che l'utente potrebbe non voler rispondere né si né no. Una volta però fatta la scelta di rispondere (o sì o no) non è più possibile deselezionare, quindi, per evitare crisi esistenziali all'utente, è opportuno in alcuni casi predisporre anche un radio per scelte alternative come: altro, non applicabile, ecc.

<input name="scelta1" type="radio" value="" />
<input name="scelta2" type="checkbox" value=""
checked="checked" />

Con Il parametro checked="checked" è possibile attribuire la selezione del radio come del checkbox.

D. Label

È un elemento che, se correttamente associato ad una select o ad input di tipo textarea, checkbox, radio, submit o text, consente a chi usa uno screen reader, un'immediata e chiara comprensione del tipo di dato da fornire ed una conseguente facilitazione nella compilazione.
È quindi chiaro come questo elemento sia molto importante nella realizzazione di form accessibili.
Regola aurea pertanto, è che dovrà essere sempre prevista ed associata in maniera univoca la label corrispondente a ciascun elemento di input di tipo textarea, checkbox, radio, submit o text.
Per fare ciò è necessario che il valore dell'attributo "for" della label coincida con il valore dell'attributo "id" dell'input: in questo modo si stabilisce un legame logico tra i due elementi. Ovvero:

<label for="idname">Testo</label>
<input type="text" id="idname" />

Esempio:

<form action="action.jsp" method="post" id="form1">
<p for="textfield">
<label for="cognome">Cognome</label>
<input type="text" name="textfield" id="cognome" />
<label for="nome">Nome</label>
<input type="text" name="textfield" id="nome" />
<label for="titolo">Titolo</label>
<input type="text" name="textfield" id="titolo" />
</p>

</form>

Nel caso delle select il codice tipo sarà:

<label for="select">LABEL</label>
<select name="select" id="select">
<option>option 1</option>
<option>option 2</option>
<option>option 3</option>
</select>

Come già detto, attribuire in maniera corretta le label ai campi input, facilita la comprensione e la compilazione dei form da parte di quegli utenti che la pagina non la vedono, ma la ascoltano con l'ausilio di uno screen reader il cui comportamento sarà il seguente:

Usando correttamente le <label> tag:

  • "Editare: Cognome"
  • "Editare: Nome"
  • "Editare: Titolo"

È chiaro quindi come l'utente che ascolta la lettura dei campi sarà in grado di comprendere il form e compilarlo agevolmente.

Non usando le <label> tag:

  • "Editare"
  • "Editare"
  • "Editare"

In quest'ultimo caso invece, muovendosi tra i vari campi, l'utente sentirà solo:
"Editare, Editare, Editare"…si ma cosa?!
L'altro vantaggio, apportato dal corretto utilizzo delle label, è dato dalla possibilità di selezionare il campo da compilare cliccando sulla label stessa. Ciò si traduce in un evidente vantaggio quando si tratta di checkbox o di radio button che, a volte, sono un bersaglio difficile da centrare.
In generale la regola per il posizionamento della label, è che va posta prima di un campo input; fanno eccezione, checkbox e radio button per i quali invece, la label va posta subito dopo.

<p><input id="check" type="checkbox" name="checkbox2" 
value="checkbox" />
<label for="check">label check</label>
</p>
<p><input id="radio" name="radio" type="radio" value="" />
<label for="radio">label radio</label></p>
<p><label for="testo">label testo</label><input id="testo"
name="testo" type="text" maxlength="50" /></p>
<p><label for="lista">label combo</label>
<select name="select">
<option>aaaaa</option>
<option>bbbbb</option>
<option>ccccc</option>
</select>
</p>

Nel caso di una tabella oltre a valere quanto detto, la label ed il campo input possono essere collocati in colonne differenti. Nell'esempio che segue si associa come label, il nome al relativo checkbox.

<form name="form1" id="form1" method="post" action="action.do">
<table summary="Tabella contente dati orinati per colonne">
<caption>Tabella di esempio</caption>
<tr>
<th scope="col">&nbsp;</th>
<th scope="col">nome</th>
<th scope="col">codice</th>
</tr>
<tr>
<td><input id="nome1" type="checkbox" name="checkbox" value="checkbox" /></td>
<td><label for="nome1">Tizio</label></td>
<td>14526</td>
</tr>
<tr>
<td><input id="nome2" type="checkbox" name="checkbox" value="checkbox" /></td>
<td><label for="nome2">Caio</label></td>
<td>12356</td>
</tr>
</table>
</form>
Tabella di esempio
  nome codice
14526
12356

La label tra l'altro, può essere attribuita al campo input in due modi differenti. Il primo è di includere il campo input all'interno dei marcatori della label stessa.

<label for="cognome1">Cognome
<input name="testo" type="text" id="cognome1" /></label>

Nel secondo caso label ed input sono separati ma in ogni caso associati in maniera univoca tramite l'id.

<p><label for="cognome" class="style1">Cognome</label></p>
<input name="testo" type="text" id="cognome" />

E. Select

L'elemento select (comunemente indicato come menu a tendina o meglio come combo box) si può quasi intendere come un jolly per ogni form. Tramite quest'elemento si può, infatti, guidare l'utente per agevolare notevolmente la compilazione di un modello.
Allo stesso tempo però, l'elemento select può facilmente risultare complicato da utilizzare ed invalidare quindi sia l'accessibilità sia l'usabilità se non realizzato e gestito nella maniera più opportuna.
Il primo problema può essere dato dall'attributo onchange. Tale attributo, se associato al select, è in grado di scatenare un evento in funzione del cambio di selezione ma, allo stesso tempo, rende difficoltoso lo scorrimento delle possibili voci del menu con l'utilizzo delle frecce della tastiera.
Un secondo problema nell'utilizzo dell'onchange, e lo dico anche per esperienza personale, nasce nel momento in cui si utilizza un mouse con rotella. Strumento molto utile, finché non si deve utilizzare un menu a tendina corredato di onchange.
Cosa succede? Che magari si guardano le opzioni, non si cambia la selezione, il focus rimane sulla select, così si va tranquilli con la rotella del mouse con l'intento di far scorrere la pagina (come d'abitudine) ma, a quel punto, è ormai troppo tardi: ci si trova rispediti, senza saperlo, su una nuova pagina del sito!
Per tutto ciò è dunque indispensabile non utilizzare l'onchange!

In che modo allora si può ovviare a questi problemi?

Una prima possibile soluzione è di associare al select un pulsante per confermare la selezione e quindi scatenare l'eventuale evento.
A livello di layout, questo pulsante va disposto nella maniera più intuibile ed usabile per l'utente. Dal punto di vista del codice invece, di seguito viene illustrato un esempio.

<form id="form" method="post" action="azione della select">
[…]
<label for=“dove”>Comune</label>
<select name="istat" id="dove">
<option selected=“selected” value="1">descrizione opzione</option>
<option value="2">descrizione opzione 1</option>
<option value="3">descrizione opzione 2</option>
</select>
[…]
<input class="pulsante" type="submit" value="verifica" />

In questo modo l'utente, sia navighi con la sola tastiera, sia utilizzi il mouse, dopo aver fatto la propria scelta tra le option della select dovrà premere il pulsante per confermare tale selezione ed eventualmente scatenare l'evento associato, come ad esempio la compilazione di un'ulteriore select dipendente dalla prima per contenuti.
Per comprendere al meglio la situazione si pensi, ad esempio, al caso in cui dopo aver selezionato da un menu la provincia si dovrà scegliere un comune di quella provincia. È proprio questo il caso di select dipendenti l'una dall'altra e dunque il pulsante sarà utile dopo la prima select, delle province, per scatenare l'evento di compilazione della seconda select, dei soli comuni di quella provincia.

Quanto detto finora, vale in linea di principio ogni volta che ci si trova nella condizione di dover far valorizzare un menu a tendina in funzione di una precedente scelta, ma se ci si dovesse trovare nella condizione di più select, l'una dipendente dalla precedente, allora è da valutare un'eventuale soluzione alternativa per evitare che la pagina sia infarcita di troppi pulsanti di conferma selezione e tenda quindi a somigliare ad un citofono.

Una possibile soluzione può essere quella di gestire quanto accade con l'onchange tramite altri gestori di eventi. In pratica alla select si dovranno associare i gestori d'eventi onclick, onfocus e onblur.
Lo scatenarsi dell'azione sarà quindi conseguente al click del mouse o all'invio da tastiera (onclick), oppure alla perdita del fuoco (onblur) quando ci si sposterà su un altro elemento con il tasto tab o, naturalmente, quando si sposta il focus con il puntatore del mouse.
Con onfocus invece, si farà solo in modo che il fuoco sia mantenuto sul menu a tendina fintanto che la selezione non è stata effettuata. In questo modo sia con il mouse, sia con la sola tastiera, la select risulta navigabile. Per fare poi in modo che il funzionamento della select non sia compromesso nel caso si escludessero (o non fossero disponibili) le funzioni javascript, allora tra tag noscript dovrà, in ogni caso, essere incluso il pulsante di cui si è già parlato. In questo modo si otterrà una combinazione di select dipendenti tra loro perfettamente navigabili con la sola tastiera e senza dover compromettere il layout grafico.
È da notare come con questa soluzione, l'utente che utilizza il mouse non troverà particolari differenze di funzionamento rispetto a select che adottano l'onchange.

Esempio:

<form action="inserimento.jsp" method="POST">
<select name="combo" onclick="onCBClick(document.forms[0].combo,'avvia','avvia','inserimento.jsp')" onfocus="inFocus(document.forms[0].combo)" onblur="lostFocus(document.forms[0].combo,'avvia','avvia','inserimento.jsp')">
<option value="1">LETTERE</option>
<option value="2">NUMERI</option>
</select>
<noscript>
<input type="submit" name="avvia" value="avvia">
</noscript>
<select name="combo2" disabled=”disabled” onclick="onCBClick(document.forms[0].combo2,'avvia','avvia','valorizzatore.jsp')" onfocus="inFocus(document.forms[0].combo2)" onblur="lostFocus(document.forms[0].combo2,'avvia','avvia','valorizzatore.jsp')">
<option value="A">A</option>
<option value="B">B</option>
</select>
</form>

Infine, consiglio di adottare elenchi con le checkbox anziché l'utilizzo delle selezioni multiple in una select (le cosiddette multi-select impostabili con l'attributo multiple="multiple" nel tag select).
É tra l'altro molto utile usare OPTGROUP per organizzare lunghe liste di opzioni di menù in gruppi più piccoli.

<label for="elenco">Elenco con gruppi</label>
<select id="elenco">
<optgroup label="Titolo 1">
<option value="1">voce 1A</option>
<option value="2">voce 2A</option>
</optgroup>
<optgroup label="Titolo 2">
<option value="1">voce 1B</option>
<option value="2">voce 2B</option>
</optgroup>
</select>

F. Fieldset

Come se fosse un contenitore, è questo l'elemento che consente, insieme all'elemento legend, il raggruppamento di gruppi omogenei di campi, come nel seguente esempio:

<form action="xxxx" method="post" name="form1" class="Stile1" id="form1">
<p for="textfield">
<fieldset>
<legend>Dati Anagrafici</legend>
<label for="cognome">Cognome</label>
<input type="text" name="textfield" id="cognome" />
<label for="nome">Nome</label>
<input type="text" name="textfield" id="nome" />
<label for="titolo">Titolo</label>
<input type="text" name="textfield" id="titolo" />
</fieldset>
</p>
</form>

G. I pulsanti

La possibilità di inviare un form al server, e permettere quindi l'elaborazione o l'acquisizione dei dati, avviene solitamente alla pressione di un pulsante. Questo pulsante può essere un input di tipo submit, un input di tipo reset oppure un button di tipo submit.

<input name="pulsante" type="submit" id="invia" />
<input name="reset" type="reset" id="canc" value="cancella" />
<button id="bottone" name="pulsante" type="submit">invia</button>

Quali le differenze e le peculiarità?
Sostanzialmente tra il primo ed il terzo elemento non ci sono differenze funzionali. Il secondo, di tipo reset, serve per cancellare e quindi rettificare se necessario, tutti i dati inseriti in un form.
È da notare che per questi elementi, se pur di tipo input, non va associata alcuna label!
Va ricordato che in alcuni browser HTML 3.2, l'elemento button non appare come una pulsante ma semplicemente come un campo di testo da inserire. Bisognerà quindi evitarne l'utilizzo se si vuole ottenere un form compatibile anche con browser datati.

H. Pių submit per uno stesso form

È questo il caso che si presenta quando a fronte di una serie di dati immessi in un unico form, è necessario poter scatenare diverse funzioni. Risulta allora necessario poter associare più input di tipo submit allo steso form.
Di seguito si riporta un caso tipico:

<form method="post" action="/cgi-bin/submit.cgi">
<label for=”cognome”>Cognome</label><input id=”cognome” type="text" name="cognome">
<label for=”nome”>Nome</label><input id=”nome” type="text" name="nome">
<input type="submit" name="buttonSalva" value="Salva">
<input type="submit" name="buttonElimina" value="Elimina">
<input type="submit" name="buttonOrdina" value="Ordina">
</form>

La soluzione proposta è quella di associare a ciascun elemento input di tipo submit l'attributo name per contraddistinguerlo e fare poi in modo che il server si accorga di quale tasto (submit) è stato premuto e attivi l'opportuna funzione. Sostanzialmente i name specificati per i pulsanti verranno passati al server come campi della form, ma solamente il nome del pulsante premuto per la submit avrà un valore diverso da null.
Esempio:

  • L'utente immette nel campo cognome: ROSSI
  • L'utente immette nel campo nome: MARIO
  • L'utente immette nel campo indirizzo: VIA ROMA 1
  • L'utente preme INSERISCI UTENTE

Lato server la struttura ricevuta è la seguente:

Nome campo Tipo Valore
Cognome stringa ROSSI
Nome stringa MARIO
Indirizzo stringa VIA ROMA 1
buttonSalva stringa INSERISCI UTENTE
buttonElimina stringa null
buttonOrdina stringa null

In questo modo quindi verrà attivata, lato server, la funzione di salvataggio dei dati ricevuti dal form.

torna all'indice

Articoli correlati

[ Torna all’inizio della pagina ]



Sito realizzato dal Laboratorio di Accessibilità e Usabilità del CSI-Piemonte - Privacy, cookies e accessibilità

[ Torna all’inizio della pagina ]