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

3,201 views

Published on

L'accessibilità dei web form nel solo codice html.

Published in: Technology
  • Be the first to comment

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

  1. 1. Tecniche e Best Practice nella costruzione di Form accessibili per il Web Roberto Zucchetto – consulenza e formazione ICT
  2. 2. 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
  3. 3. 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 Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  4. 4. 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 Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  5. 5. Un mondo pieno di <FORM> Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  6. 6. 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) Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  7. 7. 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 Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  8. 8. 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> Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  9. 9. 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 Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  10. 10. 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”) Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  11. 11. 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 Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  12. 12. 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 Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  13. 13. 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 Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  14. 14. 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 Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  15. 15. 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”) Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  16. 16. 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 Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  17. 17. L’ Eye Tracking nei <FORM> 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 Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  18. 18. L’ Eye Tracking nei <FORM> 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 Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  19. 19. L’ Eye Tracking nei <FORM> Quali le conclusioni dell’Eye Tracking nei FORM [1] 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 [1] Fonte Luke Wroblewski – Best Practices for Form Design - http://www.lukew.com Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  20. 20. L’ Eye Tracking nei <FORM> Quali le conclusioni dell’Eye Tracking nei FORM [1] 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) [1] Fonte Luke Wroblewski – Best Practices for Form Design - http://www.lukew.com Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  21. 21. 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. Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  22. 22. 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 Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  23. 23. 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 Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it
  24. 24. 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. Roberto Zucchetto – consulenza e formazione ICT - info@studiozucchetto.it

×