L'accessibilità osservata con utenti reali

http://www.usabile.it:80/472010.htm

08\01\2010

Ed ora, un po' di pubblicità

un'esperienza sul campo
[di Maurizio Boscarol]
Qualche tempo fa ho collaborato ad un’indagine sull’accessibilità con utenti disabili condotta dal LAU del CSI Piemonte. Gli scopi erano diversi: dal capire di più sull’accessibilità osservando utenti disabili interagire con pagine web, a raccogliere dati sulle abitudini di navigazione, fino a esplorare una possibile metodologia di ricerca empirica sull’accessibilità. La ricerca ha visto la partecipazione complessiva di una cinquantina di utenti disabili, fra ciechi, ipovedenti e disabili motori. Non si tratta in alcun modo di un panel completo, perché mancano alcune tipologie di disabilità, ma offre comunque risultati interessanti e spunti per approfondimenti futuri.
I risultati sono presentati in maggior dettaglio sul sito del Lau. Più sinteticamente, però, è possibile trarre alcune interessanti indicazioni sulla progettazione accessibile, alcune delle quali confermano pratiche note, mentre altre no.
Risultati principali
Usare i tag di titolazione (h1-h6) per introdurre sezioni distinte di contenuto
Usare per i link parole chiave omettendo gli articoli o altri elementi grammaticali non significativi all’inizio
Link interni (vai a…) alle sezioni
Uso dei form: marcatura
Uso del javascript
L’esperienza conta
L’evidenza di un divario generazionale interno ai disabili ciechi
Usare i tag di titolazione (h1-h6) per introdurre sezioni distinte di contenuto
L’uso dei tag di titolazione è particolarmente utile agli utenti ciechi o ipovedenti che usano Jaws (la totalità dei ciechi con cui abbiamo interagito usano quel programma). Jaws offre alcune funzionalità comode, che, probabilmente perché insegnate ai corsi di Jaws, sono usate abbastanza spesso (ma non sempre, come vedremo poi) dagli utenti. Una di queste, è quella estrarre i titoli presenti in pagina, per scorrerli e andarvi rapidamente, o usare i tasti numerici corrispondenti ai livelli di titolazione, in modo da navigare in sezioni o blocchi interni al documento.
Dunque, se si usano i DIV per separare sezioni di documento, ma ogni DIV importante non è introdotto da un titolo marcato con H1-H6, gli utenti ciechi potrebbero non avere consapevolezza di quella sezione.
La legge 4/2004 parla di marcatura strutturale e di rispetto del valore semantico (al requisito tecnico n.1), ma non viene esplicitamente sottolineata la decisiva importanza dell’uso dei titoli nell’economia della pagina.
Usare per i link parole chiave omettendo gli articoli o altri elementi grammaticali non significativi all’inizio
Un’altra funzione di Jaws è quella di estrarre con una specifica funzione tutti i link presenti in una pagina e di consentire di scorrerli usando i tasti alfabetici corrispondenti alla prima lettera della prima parola presente nel link. Ecco perché usare link come “Gli eventi”, o “I concerti”, “Le proiezioni” è più problematico che usare direttamente “Eventi”, “Concerti”, “Proiezioni”. Nel primo caso, cercando esplicitamente eventi, l’utente estrae i link e preme “E”, ma non riesce ad accedere al link “Eventi” perché è ordinato sotto la “G” (“Gli Eventi”). Quindi può rapidamente concludere che non esista un link diretto agli eventi. Nel secondo caso, invece, il link viene correttamente identificato premendo la lettera “E”.
Tutti i link, sia quelli di navigazione che quelli contestuali, vengono estratti e ordinati alfabeticamente. Ovviamente è più facile (e forse utile) seguire queste indicazioni soprattutto per i link di navigazione.
Questa indicazione non mi risulta mai fornita da altre linee guida sull’accessibilità presenti in letteratura (se qualcuno trovasse un precedente ce lo segnali).
Link interni (vai a…) alle sezioni
Particolarmente interessante è stata la sperimentazione dell’utilizzo dei link interni alla pagina che vengono presentati in cima al documento (e solitamente nascosti agli utenti vedenti) per andare direttamente a specifiche sezioni della pagina (normalmente, come visto al punto 1, marcate come titolo). L’esempio tipico (qui senza link) è:
Vai a:
Contenuto
Casella di ricerca
Navigazione
Informazioni
Ognuna di queste voci poi dovrebbe corrispondere ad un link ad una sezione della pagina.
Questi link costituiscono una specie di menu rapido della pagina, e offrono anche un’overview di cosa la pagina contiene. Ebbene, nell’esecuzione di una serie di compiti, solo una metà circa di utenti ha usato questi link. Ma questi utenti hanno ottenuto un tasso di successo significativamente superiore a quelli che non li hanno usati, a indicare che saper usare i link interni porta a prestazioni migliori, o forse, che gli utenti più esperti usano strategie più differenziate, tra cui l’uso dei link interni, arrivando così a risultati migliori.
Interessante notare che anche alcuni di coloro che di fatto non hanno usato i link interni, a successiva domanda dichiarano che tali link sono utili.
Al contrario, i link successivi ad ogni titolo che introduce un sezione della pagina, e che consentono di saltare quella sezione andando alla successiva (una moda che era sorta all’inizio del dibattito sull’accessibilità, alcuni anni fa, e che non è ormai molto praticata), non vengono usati da nessuno. A dispetto del fatto che, in un’intervista preliminare, alcuni utenti ciechi avevano dichiarato che anche quell’espediente è molto utile.
Non tutti i tipi di link interni hanno insomma uguale utilità ed efficacia. Quelli che, posti in cima alla pagina, riassumono la struttura dell’intera pagina e consentono di andare alla specifica sezione, certamente sì.
Va poi detto che, come effetto collaterale, l’uso di link interni complica la percezione della pagina. Alcuni utenti parlavano di link interni come se fossero link fra pagine, non cogliendo appieno il fatto che si stavano muovendo all’interno dello stesso documento. Come però si può dedurre dalla maggior efficacia dimostrata da questi utenti, questo problema non impedisce affatto di portare a termine i compiti che dovevano completare.
Uso dei form: marcatura
L’uso della marcatura per gli elementi di un form non ha portato ad alcun mutamento di efficacia o di comportamento rispetto alla sua assenza. Nessun disabile si è anzi accorto di alcuna differenza, usando pagine con o senza tale marcatura.
Questo non significa che non si debba usare per gli elementi di form: ma questi sono necessari soprattutto per gli elementi selezionabili (radio button e checkbox), e comunque non per utenti ciechi, ma per utenti che usano il mouse (aumenta l’area cliccabile, riducendo il tempo di click per effetto della legge di Fitts). Infatti, tale utilizzo, se correttamente eseguito, rende selezionabile il campo anche cliccando sulla label, aumentando quindi la facilità di utilizzo complessiva.
Tuttavia, non sembra essere un espediente in alcun modo utile per utenti ciechi. Per la verità, nemmeno gli utenti disabili motori hanno tratto vantaggio da questa marcatura: questi utenti infatti, operano in modo molto lento e molto preciso, cliccando esattamente sull’oggetto target (la casellina di spunta o il pulsante di opzione). Per gli utenti disabili che abbiamo osservato la legge di Fitts non vale, perché il movimento non è composto da due momenti, uno rapido e uno più lento, come la legge prevede.
Il numero e la tipologia di utenti osservati non consente naturalmente di escludere che vi siano altre tipologie di utenti disabili che traggono vantaggio da questa marcatura: ma per quanto abbiamo potuto osservare, l’uso del non influenza in alcun modo la prestazione.
Uso del javascript
Abbiamo identificato un caso in cui non solo non vi è la possibilità di prevedere un’alternativa all’uso del javascript, come linee guida e requisiti tecnici richiedono, ma addirittura l’uso del javascript rende più facile l’utilizzo della pagina.
Si tratta di uno script che elimina ed eventualmente ripristina il testo di segnaposto presente in una casella di inserimento testuale. Se il testo di segnaposto è presente, e non viene eliminato via javascript nel momento un cui un utente ci si posiziona, si verificano con buona frequenza errori di invio: l’utente cieco infatti spesso invia il testo inserito assieme al testo di segnaposto, non rendendosene conto.
Non è possibile evidentemente eliminare il problema gestendolo lato server. L’alternativa senza javascript è evitare il testo di segnaposto, che però può offrire informazioni utili ad utenti vedenti (in tal caso le informazioni equivalenti dovrebbero essere fornite in altro modo).
L’esperienza conta
Abbiamo visto che gli utenti ciechi non si comportano tutti nello stesso modo. I più esperti nell’uso di jaws e abituati a navigare usano strategie più evolute e raffinate, ottenendo risultati migliori. In particolare, ecco un riepilogo di quanti utenti ciechi (su 16 direttamente osservati) hanno usato differenti tecniche: