Tecniche e Best Practice nella costruzione di Form accessibili per il Web

Tecniche e Best Practice nella costruzione
di Form accessibili per il Web

Roberto Zucchetto – consulenza e formazione ICT

L’approccio dello speech

• Information Visualization (Dynamic Query, FishEye
View, TreeMap): un’area di ricerca che fornisce gli
strumenti e le metodologie necessarie per poter
rappresentare al meglio notevoli quantità di dati;
• Eye Tracking: Un sistema di eye tracking è un
dispositivo che permette di tracciare la posizione della
pupilla e di risalire al punto osservato dall’utente;
• User Experience (UX): ossia la progettazione centrata
sugli utenti e finalizzata a valutarne tutti gli aspetti di
interazione degli stessi con un prodotto/servizio: come
viene percepito, compreso e utilizzato.

Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it

Simboli e non solo…….
• La parola normodotato è abolita (…cosa vuol dire?)
• La parola disabile o meglio diversamente abile è troppo generica per
“valutare” un prodotto/servizio web (o informatico in genere). Quindi le
diverse soluzioni proposte NON saranno catalogate in base allo status
dell’utente ma al senso con cui accede/fruisce del web e la modalità di
interazione:
chi il web lo vede, non importa se con stile standard o ad alto contrasto, a
caratteri ingranditi o con ausili per l’ipovisione, ecc.
chi il web lo “ascolta” attraverso ausili diversi come: screen reader, TTS (sintesi
vocale), tastiere braille, ecc.
chi interagisce con la tastiera convenzionale o speciale (a tasti ingranditi, ecc.)
chi interagisce con un sistema di puntamento tradizionale (mouse, joystick,
ecc.) o speciali con simulazione di click (a testa, a naso, a occhio, ecc.)
chi interagisce con sistemi di input vocale


Un mondo pieno di <FORM>

• letteralmente “modulo”
• sono l'interfaccia di un'applicazione che consente
all'utente di inviare i dati inseriti dallo stesso
• web form sono la principale e spesso l'unica via per
inviare dati dai siti web:
– moduli di registrazione utente
– modulo contatti (informazioni, richieste, segnalazioni, ecc.)
– motori di ricerca sul web o interni al sito
– ricerca o acquisto nei siti di e-commerce
• In altre parole “il modulo o la scheda da compilarequot; per
inserire (fornire) i dati


Un mondo pieno di <FORM>


La struttura dell’elemento <FORM>
<form action=“ ” method=“ ” enctype=“ ” accept=“ ” accept-charset=“ ” >
<fieldset><legend>Titolo del Form</legend>
…..
….(testo, codice di marcatura e controlli)
….
</fieldset>
</form>

Gli attributi: (HTML 4.01 e XHTML 1.0 con DTD strict)
action= URI di destinazione ossia il gestore del modulo lato server
method=get|post ossia il metodo HTTP di inoltro dei dati del modulo (default è get)
enctype= rappresenta il content type dei dati spediti con post. Il valore di default è
application/x-www-form-urlencoded. Nell’invio di file utilizzare multipart/form-data
accept= lista di content type separati da virgole (es. nell’invio di file diversi)
accept-charset= lista di codifiche di caratteri (encodings) dei dati inviati e accettati
dal server (ISO 10646 =UCS (Universal Character Set), UTF-8, UTF-16)


La struttura dell’elemento <FORM>

<form>
<fieldset><legend>Registrazione – Dati Utente</legend>
…..
….
</fieldset>
<fieldset><legend>Dati per l’accesso al servizio</legend>
…..
….
</fieldset>
</form>

Il tag <fieldset> consente il raggruppamento di gruppi omogenei di campi
identificati tramite il tag <legend>. La leggenda migliora l'accessibilità quando il
fieldset viene nascosto ad esempio con l’uso dei fogli di stile (CSS)
È utile durante la compilazione (chiarisce le diverse sezioni dei dati)
È fondamentale per il riconoscimento delle diverse sezioni di dati
Esempio


I controlli dell’elemento <FORM>
<form>
<fieldset><legend>Registrazione – Dati Utente</legend>
<input type=quot;textquot; id=quot;nomequot; />
<input type=quot;radioquot; value=quot;Maschioquot; />
<input type=quot;checkboxquot; value=“Noquot; />
<input type=quot;passwordquot; id=quot;passwordquot; />
<input type=quot;hiddenquot; />
<input type=quot;filequot; class=“cssfilequot; />
<input type=quot;submitquot; value=quot;INVIAquot; />
<button type=quot;resetquot; >Cancella</button>
<select id=“provinciaquot;>
<optgroup label=quot;Lombardiaquot;>
<option>Milano</option>
<option>Bergamo</option>
<option>Brescia</option>
</optgroup>
<optgroup label=quot;Venetoquot;>
<option>Venezia</option>
<option>Padova</option>
<option>Treviso</option>
</optgroup>
</select>
<textarea name=quot;quot; cols=quot;quot; rows=quot;quot;></textarea>
</fieldset>
</form>


I controlli dell’elemento <FORM>
L’elemento <INPUT> a seconda del suo attributo type
• text: casella di testo a riga singola
• password: casella di testo “nascosto”, ossia valore visualizzato è **********
• checkbox: caselle di spunta. Obbligatori l’attributo value (valore iniziale)
• radio: radiocomandi. Obbligatori l’attributo value (valore iniziale)
• file: selettore di file, ad es. per upload di file
• hidden: controlli nascosti. Es. per memorizzare dati negli scambi client/server
• image: pulsante di inoltro di tipo grafico. L'attributo src specifica l'URI dell'immagine
• submit: pulsante di inoltro dei dati
• reset: pulsante di ripristino, solitamente associati a value “Annulla” o “Cancella”
• button: pulsante di comando, solitamente associati a value “Salva” o “Elimina”

L’elemento <SELECT> consente di creare un menu. Nei controlli con molte voci è consigliato
l’uso delle etichette <optgroup> per una migliore usabilità dello stesso.

L’elemento <TEXTAREA> crea un controllo multiriga per l'immissione di testo.

L’elemento <BUTTON> crea un pulsante del tipo inoltro, comando o ripristino a seconda del
valore assegnato all’attributo type = submit|button|reset. Esso può avere un contenuto (ad es.
un'immagine), riprodurre i pulsanti in rilievo e con un movimento su/giù quando cliccati.
Esempio

L’elemento <LABEL>
L'elemento <LABEL> (etichetta) può essere usato per allegare informazioni ai
controlli. Ogni elemento <LABEL> è associato a uno e uno solo dei controlli
presenti nel modulo mentre più di una etichetta può essere associata con il
medesimo controllo creando così riferimenti multipli.

L’associazione al controllo DEVE avvenire in modo esplicito (requisito n. 14[1])
tramite l’attributo for = “IDcontrollo” dove IDcontrollo deve essere uguale al valore
assegnato all’attributo id del controllo da associare, così:
<label for=quot;nomequot;>Nome</label><input type=quot;textquot; id=quot;nomequot; />

L’utilizzo delle LABEL, oltre ad essere un requisito obbligatorio per i siti della PA,
Facilita l’inserimento dei dati nel modulo per gli utenti con un livello di
conoscenza di internet media mentre è fondamentale per gli utenti poco esperti e
per gli anziani
È fondamentale per l’inserimento dei dati nel modulo. Risponde alla domanda:
dove e che cosa debbo inserire in questo controllo?
Esempio
[1] Legge “Stanca” (Legge 9 gennaio 2004, n. 4 “Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici”)


Gli attributi per tutti i controlli <FORM>
tabindex = numero (compreso tra 0 e 32767)
Questo attributo definisce l'ordine in cui i controlli riceveranno il focus quando l'utente
utilizza la tastiera per “navigare”. Questi gli elementi HTML che lo supportano: A,
AREA, BUTTON, INPUT, OBJECT, SELECT e TEXTAREA. Esempio:
<label for=quot;nomequot;>Nome</label><input type=quot;textquot; id=quot;nomequot; tabindex=quot;1quot; />
<label for=quot;cognomequot;>Cognome</label><input type=quot;textquot; id=quot;cognomequot; tabindex=quot;2quot; />

Facilita la compilazione del modulo definendo una sequenza di compilazione
oltre che dare un senso complessivo ai dati inseriti
La sequenza interessa meno ma il non rispetto della sequenza potrebbe
facilmente far venir meno il senso dei dati inseriti o ancor peggio una errata
valutazione (immaginate ad es. dopo aver inserito il vostro nome e cognome di
selezionare il sesso della persona convivente e poi il vostro a causa di un’inversione
dell’ordine di tabulazione dei controlli)
L’utilizzo di tabindex è contenuta nel requisito n. 21 della legge “Stanca”.
Per siti dinamici e/o per siti gestiti con CMS non è semplice rispettare questa regola.
Soluzione: impostare i tabindex per le parti “fisse”: skip, header e logo, menu e
sottomenu e utilizzare l’ordine naturale di inserimento degli oggetti nel body.
Esempio

Gli attributi per tutti i controlli <FORM>
accesskey = carattere
Questo attributo assegna un tasto di accesso ad un elemento della pagina. Questi
gli elementi HTML che lo supportano: A, AREA, BUTTON, INPUT, LABEL,
LEGEND e TEXTAREA. Esempio:
<label for=quot;nomequot;>Nome </label><input type=quot;textquot; id=quot;nomequot; accesskey =“Nquot; />
<label for=quot;cognomequot;>Cognome </label><input type=quot;textquot; id=quot;cognomequot; accesskey =“Cquot; />
L’utilizzo di accesskey è contenuta nel requisito n. 21 della legge “Stanca”.
Oggi questo attributo è fortemente criticato e quindi spesso disapplicato, risultando in taluni
casi la sua applicazione addirittura meno accessibile.
In sintesi queste le motivazioni contrarie al suo uso:
• non vi è un uso uniforme dei tasti rapidi (chi preferisce le lettere tipo h=home, chi invece i
numeri come 1=home);
• i tasti scelti spesso vanno in conflitto e/o si sovrappongono a quelli del browser o dello
screen reader;
• non vi è una modalità comune di attivazione dei tasti rapidi tra i diversi browser;
• non è chiara la loro esplicitazione (visualizzazione) agli utenti che non utilizzano uno screen
reader.
E’ attualmente preferibile definire solo pochi tasti di scelta rapida per i soli link principali
rendendo il più possibile chiara la loro definizione attraverso l’uso dell’attributo title, della
sottolineatura del carattere (tasto), dei CSS (:after) e di una legenda in evidenza. Esempio


Diamo uno stile al <FORM>

Una delle regole d’oro dell’accessibilità è: separare
i comportamenti (JavaScript) dalla presentazione
(CSS) e dalla struttura (X-HTML) usando il metodo
del potenziamento progressivo[1].
Quindi definiamo uno stile CSS che presenti
completamente e al meglio il nostro modulo.

Utilizzare soprattutto i selettori classe (oltre alle proprietà associate ai tag HTML) per ridurre la
complessità (e il peso) del CSS, si ridurranno così i tempi di manutenzione ed intervento e
quindi i costi complessivi. In altri termini aumenterà il ROI (redditività del capitale investito o
ritorno degli investimenti) del nostro sito web. Ad es. per uno stile di form definiremo nel css:
• le proprietà per gli elementi form, fieldset, legend, label
• le proprietà per una classe da applicare ai contenitori <div> dei controlli casella di testo e simili
• le proprietà per una classe da applicare ai contenitori <div> dei controlli radio e checkbox
• le proprietà per una classe da applicare ai contenitori <div> dei controlli button

[1] Michele Diodati “Accessibilità – guida completa” – www.diodati.org
Esempio

Miglioriamo Design e Accessibilità del <FORM>

Aggiungiamo un secondo foglio di stile e due javascript
• Aumentiamo la riconoscibilità dei campi rispetto allo sfondo della pagina
• Evidenziamo il campo che ottiene il focus (ossia quello in fase di modifica)
• Indichiamo i campi obbligatori
• Inseriamo degli aiuti per la compilazione dei campi complessi o con regole come il
formato data, valuta, numero intero/decimale, lunghezza min/max, caratteri ammessi
• Raggruppiamo all’inizio del modulo i messaggi di anomalia dei dati inseriti
• Evidenziamo esplicitamente i campi che presentano dati anomali (o mancanti)

Non c’è nessuna legge che ci impone di fare questo se non quella del buon senso

Esempio Esempio Help Esempio Help1


La validazione dei dati <FORM>

La validazione dei dati lato client
Viene solitamente eseguita con javascript costruiti ad hoc o sempre più spesso
utilizzando framework come Mootools, jQuery, TIBCO, ecc.
Usate il javascript che volete ma utilizzare gestori evento INDIPENDENTI dal
dispositivo di input, ossia: onblur e onfocus (requisito n. 16[1])
In alternativa:
accoppiare onclick a onkeypress
accoppiare onclick a onfocus
accoppiare onmousedown a onkeydown
accoppiare onmouseup a onkeyup
accoppiare onmouseover a onfocus
accoppiare onmouseout a onblur
Mai usare ondblclick in quanto non esiste l’equivalente evento da tastiera.

[1] Legge “Stanca” (Legge 9 gennaio 2004, n. 4 “Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici”)


L’ Eye Tracking nei <FORM>

Quali le conclusioni dell’Eye Tracking nei FORM di ricerca[1]

www.google.it

www.ebay.it

www.flickr.com

[1] Fonte Matteo Penzo – Direttore di Design e Sviluppo al Research Center - http://uxmatters.com



Quali le conclusioni dell’Eye Tracking nei FORM di ricerca[1]

Le label: gli utenti poco esperti e quelli medi cercano l’etichetta (label) del campo di
ricerca e si aspettano di trovarla a sinistra del controllo stesso mentre gli utenti esperti,
se presenti, le ignorano;
Elenchi a discesa: catturano molto l’attenzione dell’utente. Valutare attentamente la
loro implementazione e se si vuole costruire un semplice modulo di ricerca evitare il loro
uso in quanto, molto spesso, rendono meno chiaro il sistema di ricerca in se e la ricerca
(risultato) desiderata;
Compattezza del form: per tutti gli utenti e in particolare per quelli che utilizzano screen
reader per navigare, esplorano tutta la pagina prima di capirne il significato (cosa posso
fare qui?). Quindi i risultati migliori si ottengono (vedi flickr.com) con form compatte, in
cui il controllo è dotato di label allineata a sinistra appena sopra alla casella di testo;
Posizionamento standard: posizionare il form di ricerca in una delle posizioni standard
(in alto a destra o al centro) aiuta notevolmente la sua comprensione ed utilizzo anche
in assenza della etichetta.

[1] Fonte Matteo Penzo – Direttore di Design e Sviluppo al Research Center - http://uxmatters.com



Quali le conclusioni dell’Eye Tracking nei FORM [1]
Posizionamento delle label
• per la riduzione tempi di completamento e per chi “conosce” i dati di input il posizionamento
migliore è label sopra i campi (con allineamento a sinistra rispetto agli stessi)

• quando la dimensione verticale dello schermo è limitata il posizionamento migliore è label
allineate a destra e in linea con i campi

• per chi non ha familiarità con il modulo (non conosce i dati), o per una articolata immissione
di dati, il posizionamento migliore è label allineate a sinistra e in linea con i campi

[1] Fonte Luke Wroblewski – Best Practices for Form Design - http://www.lukew.com




Indicazione campi obbligatori
• evitare, se possibile, i campi opzionali
• se la maggior parte dei campi è obbligatoria: esplicitare solo quelli opzionali
• se la maggior parte dei campi è facoltativa: esplicitare solo quelli obbligatori
• il testo (obbligatorio) sarebbe la migliore indicazione, ma forse ci siamo abituati a *
• associare gli indicatori obbligatorio/opzionale alle etichette dei campi

Lunghezza dei campi
• quando possibile, assegnare ai campi una lunghezza “più che sufficiente” al loro
scopo (tipo di dato da inserire)
• in caso contrario assegnare una lunghezza coerente con il contesto ma sufficiente
all’inserimento del dato stesso





Contenuti ed Organizzazione
• raggruppare i gruppi omogenei di dati/campi
• ridurre al minimo il numero di campi necessari allo scopo
• evitare l’inserimento (o l’attivazione) dei pulsanti per le azioni successive. In caso
contrario rendere chiaro il loro scopo

Aiuti (Help&Tips) alla compilazione
• minimizzare la quantità di aiuti e consigli necessari per compilare un modulo
• una “guida” [?] visibile ed adiacente al campo è una cosa utile
• valutare, dove possibile, la sostituzione degli help statici con un aiuto dinamico alla
compilazione (modifica dinamica del form a seconda dei dati inseriti)



Conclusioni sui <FORM>

• L’accessibilità è possibile e non costa di più
• Un sito accessibile è anche più usabile
• Un sito accessibile ha un ROI più elevato
• Le tecniche di Eye Tracking confermano molti dei
principi (regole) dell’accessibilità

• …..e se deciderete di applicare queste best practice,
ricordate che non basta una “somma” di buone regole
per ottenere un buon risultato; alla base è indispensabile
una preventiva e buona progettazione: non bastano dei
bravi musicisti a far grande un’orchestra.


Cos’è IWA/HWG

IWA/HWG è un’Associazione professionale no profit riconosciuta leader
mondiale nella fornitura dei principi e delle certificazioni di formazione per i
professionisti della Rete Internet; è presente in 100 paesi, con 130 sedi
ufficiali in rappresentanza di più di 165.000 associati.

La sua missione
•Fornire programmi formativi di qualità
•Fornire agli associati supporto e collaborazione a livello regionale, nazionale
e internazionale, nonché un marchio di affiliazione riconosciuto a livello
mondiale
•Promuovere i principi universali di etica e di pratica professionale per tutti i
professionisti della Rete Internet
•Fornire supporto per la definizione e lo studio di normative nei Paesi in cui è
presente


Cos’è IWA/HWG

Partecipazioni e Attività

Network:
http://www.iwa.it - http://webaccessibile.org - http://www.itlists.org -
http://blog.iwa.it - http://www.skillprofiles.eu

Contatti:
comunicazione@iwa.it


Termini e licenza del documento

GRAZIE

Per informazioni mi potete contattare via mail a info@studiozucchetto.it

Le slide e gli ESEMPI li potete scaricare da www.studiozucchetto.it

Quest'opera è stata rilasciata sotto la licenza Creative Commons Attribuzione-Non commerciale-Non opere
derivate 3.0 Unported. Per leggere una copia della licenza visita il sito web
http://creativecommons.org/licenses/by-nc-nd/3.0/ o spedisci una lettera a Creative Commons, 171 Second
Street, Suite 300, San Francisco, California, 94105, USA.
Diritti, marchi registrati e siti web riportati in immagini e url sono riservati e proprietà dei diretti interessati e
relative aziende.
IWA/HWG e l’associazione IWA Italy non sono direttamente o indirettamente responsabili dei contenuti
riportati nel presente documento che sono ad esclusiva cura e responsabilità del relatore.


Tecniche e Best Practice nella costruzione di Form accessibili per il Web

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (12)

Similaire à Tecniche e Best Practice nella costruzione di Form accessibili per il Web

Similaire à Tecniche e Best Practice nella costruzione di Form accessibili per il Web (20)

Dernier

Dernier (9)

Tecniche e Best Practice nella costruzione di Form accessibili per il Web