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.

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 <label>

L’uso della marcatura <label> 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 <label> 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 <label> 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:

Riepilogo della frequenza di utilizzo di diverse tecniche di navigazione durante i compiti in 16 utenti ciechi. Dettagli nel testo.

Si nota che mentre l’uso del tab e delle freccie per navigare una pagina, e l’uso della funzione maschera (indispensabile per usare i form) sono praticamente usate da tutti (la funzione maschera quasi da tutti), altre strategie sembrano marcare un netto confine fra utenti più e meno evoluti. L’uso delle funzioni per l’estrazione di titoli è infatti minoritaria, quella per l’estrazione dei link svolta da poco più della metà dei nostri utenti, così come la consapevolezza dei salti iniziali al contenuto. Addirittura una tecnica semplice come cercare nella pagina con la funzione di ricerca del browser (CTRL+F) è usata nel nostro campione solo da un utente su 3 circa.

Questo dato indica l’importanza di offrire formazione informatica all’uso degli strumenti tecnici: usare bene le tecnologie assistive è importante almeno quanto una pagina costruita bene. E forse anche di più.

Non è insomma corretto, da parte dei decisori politici, gestire il tema dell’accessibilità esclusivamente organizzando formazione per i webmaster, perché rischia di avere più impatto la formazione diretta ai disabili: quelli più esperti hanno infatti dimostrato di cavarsela senza problemi anche con pagine che non rispondevano ai requisiti tecnici di accessibilità.

Questo significa organizzare corsi per i disabili, oltre che fornire loro strumentazione adeguata. O direttamente, o supportando le associazioni di disabili che fanno formazione sul territorio, facendo in modo di incoraggiare anche la collaborazione con i vari sportelli e uffici dedicati ai disabili sul territorio.

L’evidenza di un divario generazionale interno ai disabili ciechi

Un questionario sulle attività svolte online da questi utenti ciechi ha messo in luce che i più giovani si comportano online più o meno come i coetanei vedenti: vi è cioè una prevalenza di attività evolute o “2.0”, per usare un’etichetta di moda, come frequentare chat, gestire blog, partecipare a wiki, acquistare e giocare online. I più maturi, invece, si limitano ad attività più tradizionali, informative (visitare siti), a scaricare moduli, partecipare a mailing list, limitando l’interattività offerta dai servizi più recenti.

Che la differenza nel comportamento non dipenda, nel nostro piccolo campione, né dall’accessibilità dei servizi (molti dei servizi 2.0 anzi sono almeno formalmente meno accessibili di quelli tradizionali per il massiccio ricorso a javascript, per l’uso di molti form, come nei wiki e nella gestione di blog), né dall’expertise, cioè dal numero di anni trascorsi al computer, lo dimostra un test statistico opportunamente condotto: non è il numero di anni passati al computer, ma l’età, a spiegare meglio il differenziale del comportamento.

Questo evidenzia da un lato che un corretto uso delle tecnologie assistive riesce ad essere più efficace di una pagina progettata secondo i rigidi criteri di accessibilità (abbiamo avuto esempi di utenti ciechi che visitavano regolarmente youtube, e ci hanno anche caricato video…), dall’altra sostiene la tesi di un digital divide che si stratifica, anziché normalizzarsi, all’interno alle società avanzate. L’ipotesi di Laura Sartori (autrice de Il divario digitale, Il Mulino, 2006) di una stratificazione che vede i più esperti e precoci progredire nellla qualità dell’uso di internet, mentre i nuovi arrivati si fermano a livelli di utilizzo più primitivi, viene qui integrata da una nuova forma di stratificazione, generazionale. Si suggerisce cioè che non siano solo l’expertise e il tempo di utilizzo, ma anche fattori generazionali, cioè le attività in voga fra i più giovani al momento, a decidere cosa fa la gente online. Naturalmente questo è un dato che va verificato con altri pubblici e campioni grandi, ma offre una ipotesi di interpretazione più complessa dei comportamenti online.

Altri dati e ulteriori dettagli sull’indagine svolta si trovano naturalmente sul sito del LAU.

Le “linee guida per l’accessibilità dei contenuti web” (WCAG) 1.0 sono lo standard ufficiale consigliato dal W3C per la produzione di contenuti web accessibili. Il gruppo di lavoro per le WCAG non pubblica però informazioni su quali ricerche con utenti i suoi membri abbiano utilizzato per stilare le WCAG 1.0. Allo stesso modo, molti dei centinaia di esperti di accessibilità web non conducono – o almeno non citano – ricerche a sostegno delle proprie raccomandazioni.

Dopo aver personalmente osservato alcuni utenti disabili interagire con i siti web in modi inaspettati, mi sono convinto del grande valore che potrebbe avere in questo settore la ricerca con gli utenti – e a sospettare che forse non ne sappiamo poi molto, a dispetto di quanto credevamo, sull’accessibilità nel cosiddetto “mondo reale”.

L’anello mancante

Poiché il WCAG-WG non elenca pubblicamente gli studi sui quali le raccomandazioni sono basate, ho chiesto tempo fa ad un autorevole membro del working-group su quali ricerche fossero effettivamente basate le WCAG. La sua risposta è stata che “le WCAG sono basate su molte cose”, il che è senz’altro positivo, ma non risponde realmente alla domanda. Che cos’erano esattamente quelle “molte cose”?

In una successiva risposta è stata nominata la ben nota ricerca del Nielsen Norman Group sugli utenti con disabilità. Il problema è che lo studio del NNG è del 2001, mentre le WCAG 1.0 sono state pubblicate nel 1999.

Non possiamo quindi contare alcuna ricerca ufficialmente menzionata nelle nostre amate linee guida, e i miei tentativi di raccogliere informazioni direttamente alla fonte non hanno sortito effetto. Possiamo sicuramente assumere che degli studi con utenti siano stati utilizzati nella preparazione delle WCAG 1.0, ma non siamo in grado di esaminarli. Per di più, questa mancanza di discussione pubblica sulla ricerca ha portato come conseguenza a molte discussioni sugli aspetti tecnici e a quasi nessuna riflessione sul reale comportamento degli utenti.

I seguenti esempi sono dunque solo alcuni degli usi poco chiari del web che ho notato e che non sono in alcun modo previsti dalle WCAG. Queste esperienze sono frutto di osservazioni personali basate su una manciata di utenti, ma persino un campione limitato come questo suggerisce che la nostra conoscenza sull’accessibilità dei contenuti sia parziale.

L’elemento title e l’elemento h1

Un utente cieco che stavo osservando navigare su alcune pagine, ha riferito che sentire il contenuto dell’elemento h1 in cima ad ogni pagina fosse noioso e ridondante. Poiché lo screen-reader leggeva per primo il contenuto dell’elemento title, quell’elemento serviva come titolo effettivo del documento, mentre l’h1 – che ripeteva il contenuto del title – era inutile. Naturalmente, questo risultava vero solo se l’elemento title conteneva informazioni utili e pertinenti.

Date queste informazioni, una buona linea guida potrebbe suggerire che l’elemento title debba contenere sempre le informazioni essenziali per l’orientamento, compreso il nome del sito e della specifica pagina. L’elemento h1 dovrebbe a quel punto essere preceduto da un link alle principali aree del documento, come “vai al: contenuto, alla navigazione principale, alla navigazione secondaria, al piè di pagina”, per permettere agli utenti ciechi di saltare le informazioni potenzialmente ridondanti (nel nostro esempio, l’h1 ripetitivo).

Questo non viene esplicitamente detto dalle WCAG; si dice solo che gruppi ripetuti di link dovrebbero presentare dei link per evitarli (skip link). Questo può essere vero, ma non è sufficiente, e persino un test con utenti molto rudimentale può aiutare a definire linee guida un po’ più dettagliate in questo settore.

Davvero la navigazione dovrebbe venire per prima?

Lo stesso utente cieco dimostrò un comportamento inaspettato, mentre tentava di trovare uno specifico link su una pagina web. Sapeva cosa cercare, e si aspettava di trovarlo nei primi link della pagina. Siccome però il blocco della navigazione veniva dopo il blocco del contenuto, l’utente ascoltò i primissimi link all’interno del contenuto e seguì il primo di questi che a suo parere sembrava non troppo distante dal suo obiettivo.

E’ importante notare questo comportamento, perché in realtà il link che l’utente stava cercando si trovava proprio nella sezione di navigazione, cioè sotto il contenuto. Durante l’intera sessione lui non si è mai reso conto dell’esistenza stessa di quella sezione, proprio perché la sua strategia di navigazione era basata sull’assunto che i link più importanti dovessero stare in cima alla pagina. Molti consigli di accessibilità suggeriscono che il blocco di contenuto vada presentato per primo, ma alcune ricerche suggeriscono che alcuni utenti di screen-reader e di browser testuali si aspettino invece per prima la navigazione. Questo non basta per dire che la navigazione dovrebbe venire sempre e comunque per prima, ma dimostra quantomeno che la ricerca con utenti può portare a mettere in dubbio alcune delle nostre radicate convinzioni sull’accessibilità.

E, naturalmente, l’ordine dei blocchi di contenuto non è minimamente menzionato nelle WCAG 1.0.

La dimensione conta, ma conta pure lo spessore

Un altro esempio riguarda invece gli utenti ipovedenti. Alcuni anni fa, chiesi a Franco Frascolla, un esperto dei problemi informatici degli utenti ipovedenti e ipovedente anch’esso, di revisionare un sito su cui stavo lavorando.

Con mia grande sorpresa, Franco mi segnalò che il testo non si poteva ingrandire abbastanza in alcune zone del mio sito. Tentando di confrontare il mio sito con altri che lui giudicava adeguati, non riuscivo proprio a capire quale fosse la differenza: alla dimensione normale, sia i testi “buoni” che quelli “cattivi” apparivano simili. Dopo un paio di prove ebbi una specie di illuminazione. Il problema non era soltanto quello della dimensione del testo, ma anche della sua “grossezza” (o meglio, dello spessore del tratto) alla nuova ingrandita dimensione, se visto con Internet Explorer per Windows.

Internet Explorer per Windows è infatti l’unico browser che pone un limite al numero di volte in cui si può ingrandire un testo sui siti web: sono possibili solo 5 dimensioni. Sfortunatamente, IE è il browser più usato dagli ipovedenti, soprattutto se non sono esperti informatici. Se alla dimensione “molto grande” il testo non è grande abbastanza, allora molti ipovedenti non riescono semplicemente a leggerlo.

E’ emerso dunque che se la grandezza è importante, anche lo spessore lo è. Infatti, un testo ingrandito che non risulti anche più spesso, è meno leggibile di un testo della stessa dimensione il cui tratto è però anche ingrossato (solitamente le aste passano da 1 ad almeno 2 pixel). Confrontate il testo nell’immagine seguente per capire cosa intendo.

Google visto in IE/Win con la più grande dimensione del testo consentita da questo browser.

In questo esempio, la maggior parte del testo è ingrossata (appare in grassetto), ma non tutto: “Advanced search,” “Preferences,” “Language Tools,” e “(c) 2006 Google” sono grandi, ma non abbastanza spessi. Che ne dite del testo dentro i pulsanti?

E’ piuttosto facile stabilire se un sito supera questo test; guardatelo con IE6¹, scegliete “Visualizza > testo > molto grande” e chiedetevi se tutti i testi nella vostra pagina appaiano ora come fossero in grassetto. Supponiamo che questo sia vero per la maggior parte dei vostri testi, ma non, poniamo, per il piè di pagina. In quel caso, il piè di pagina non risulterà leggibile per buona parte degli ipovedenti.

C’è qualche linea guida ufficiale che si occupa di questo ostacolo piuttosto elementare per gli utenti ipovedenti? Assolutamente no. Gli ipovedenti non sono presi in considerazione nemmeno nella Section 508, né dalla legge italiana². Ma come si vede, anche delle verifiche con utenti molto semplici possono consentire di identificare problemi come questo.

La necessità di ricerca con utenti sull’accessibilità

Gli esempi descritti derivano dalla mia personalissima e parziale esperienza di osservazione o interazione con utenti disabili. Si tratta di esempi estremi per utenti in situazioni molto particolari? Probabilmente no, e, anche se non sappiamo esattamente quanti utenti siano interessati da questi problemi, possiamo immaginare, data la loro natura, che essi siano abbastanza comuni.

Dato che il W3C ha passato più di otto anni a discutere di WCAG 1.0 e WCAG 2.0, mi aspetterei che queste – e probabilmente molte altre – situazioni probabilmente piuttosto comuni siano affrontate nelle nostre linee guida, ma non lo sono.

Così tanti esperti, così poca ricerca…

Qual è il motivo per questa mancanza di linee guida esplicitamente basate sui risultati di test con utenti? Personalmente, non credo certo sia per cattiva volontà. Credo semplicemente che, come esperti, stiamo usando il metodo sbagliato.

Come vengono sviluppate infatti le linee guida? Attraverso la pubblica discussione, per lo più. Questo può andar bene per la maggior parte delle raccomandazioni tecniche, ma potrebbe non essere il metodo giusto per definire linee guida che riguardano l’esperienza degli utenti nel mondo reale. Propongo dunque che il metodo corretto debba essere quello di osservare gli utenti disabili, parlare con loro, e condurre con essi della ricerca sia formalizzata che informale. Dovremmo inoltre documentare la ricerca in modo da renderla replicabile, nonché pubblicare i risultati in modo da poter smettere di doverci basare su assunti dalla solidità sperimentale tanto incerta.

Perché questo non è ancora stato fatto, almeno non in un modo visibile? Credo sia dovuto soprattutto al background tecnico di molte delle persone che partecipano a questa discussione. Certo, ci possono essere anche ragioni economiche a scoraggiare la ricerca, ma un sacco di ricerca con utenti è stata fatta in passato in maniera relativamente economica.

Un sociologo potrebbe anche dire che si tratta di una ragione politica: di potere. La ricerca, infatti, a volte è controintuitiva. I suoi risultati possono mettere in crisi alcune nostre certezze. Può rendersi necessario riorganizzare il nostro modo di pensare e riscrivere le nostre linee guida basandoci sull’esperienza reale degli utenti.

Fare i test, qui e ora

Quali che siano le ragioni di questa mancanza di attenzione all’esperienza reale degli utenti, è importante iniziare fin da subito a fare ricerca con le persone disabili. Abbiamo la necessità assoluta di aumentare la nostra comprensione di cosa sia importante in materia di accessibilità, e di includere queste informazioni nelle nostre linee guida. Solo in questo modo potremo anche capire perché alcune ricerche³ sui disabili sembrano dare risultati tanto divergenti dalle nostre attese.

In sintesi, abbiamo bisogno di meno discussioni e di più ricerca con gli utenti. Specialmente se, come ora, le linee guida sono alla base delle legislazioni nazionali in materia di accessibilità, dobbiamo essere assolutamente sicuri che siano fondate sulla reale esperienza degli utenti. E nel frattempo, consentitemi una piccola esortazione a tutti gli esperti di accessibilità: quando possibile conduciamo – e poi pubblichiamo! – un maggior numero di ricerche con utenti per dare forza alle nostre raccomandazioni!

Nel tentativo di perseguire una miglior accessibilità dei contenuti
sul web ed un markup che conservi il più possibile un valore semantico
(cioè che dica chiaramente cos’è e a cosa serve la parte
di testo che contiene) il W3C
ha introdotto alcuni marcatori che sono ancora poco usati dagli sviluppatori:
fra essi, ABBR e ACRONYM definiscono, appunto, abbreviazioni o acronimi.
Il loro utilizzo, in apparenza ovvio, presenta però più
di qualche problema. In questo articolo vedremo come funzionano, quali
problemi pongono, quale sia il supporto degli user agent e come sopperire
alle loro eventuali carenze; infine ci occuperemo dei casi nei quali potrebbero
addirittura creare significativi problemi di usabilità, che vanno
dunque evitati con attenzione.

Le basi: cosa sono e come funzionano

ABBR e ACRONYM sono marcatori usati per definire abbreviazioni o acronimi.
Attraverso l’attributo TITLE è possibile fornire l’espressione
completa a cui si riferisce l’acronimo o l’abbreviazione. Secondo le specifiche
di html 4.0, dove per la prima volta questi marcatori sono comparsi, il
browser è incaricato di presentare, per lo più attraverso
una piccola finestrella o un fumettino che compare quando il mouse passa
sopra all’elemento, il testo contenuto nel TITLE. Dunque la sintassi corretta
si presenta in questo modo:

<abbr title="confronta">cfr.</abbr>
<acronym title="Rapid Eye Movement">REM</acronym>

In teoria, una volta imparato questo, si è pronti per lanciarsi
nel promettente mondo delle abbreviazioni e degli acronimi. I problemi
però iniziano quasi subito: precisamente, non appena tentiamo di
decidere cosa sia un acronimo e cosa non lo sia.

Secondo una definizione parafrasata dal dizionario, un acronimo è
una sigla formata dalle iniziali delle parole che compongono un’espressione:
WCAG è dunque un acronimo, quando si riferisce alle iniziali di
Web Content Accessibility Guidelines. Anche CSS dovrebbe, secondo la definizione,
essere un acronimo: sta per Cascading Style Sheet (fogli di stile a cascata).
Cambiando settore, in ambito medico TAC è l’acronimo di Tomografia
Assiale Computerizzata; sempre dall’ambito medico (o da quello musicale,
a seconda delle vostre attitudini…) è tratto l’esempio di cui
sopra (REM: Rapid Eye Movement).

Un’abbreviazione è invece qualunque riduzione di una parola o
di una frase per mezzo di un’altra forma convenzionale: solitamente una
sigla, una stringa di parole. Ad es., ecc., ad lib., cfr., sono tutte
forme che in italiano sono abbreviazioni di espressioni più lunghe:
ad esempio, eccetera, ad libitum, confronta.

L’acronimo non deve necessariamente essere una parola pronunciabile (CSS
si legge "Ci-esse-esse"), né legale. Ovvero non deve
rispettare le regole della fonetica di una certa lingua. In ogni lingua
alcune sequenze di lettere sono parole "legali" e altre no.
In italiano capiamo tutti che "cogomolo" è una parola
legale: anche se non esiste potrebbe esistere, perché rispetta
le regole fonetiche dell’italiano, mentre cgmfhloprv non lo è,
perché non le rispetta.

In alcune lingue (per esempio nell’inglese) si stabilisce che un’abbreviazione
– diversamente da un acronimo – può accettare prefissi e suffissi,
e può dar vita a neologismi (HTMLl-er, per HTML-ista) a differenza
dell’acronimo. In diverse lingue queste regole cambiano, e può
diventare molto difficile stabilire se una parola è un acronimo
o un’abbreviazione. Una scuola
di pensiero sostiene che HTML o XML sono acronimi, mentre un’altra
sostiene che siano abbreviazioni – forse solo perché è
possibile usarle con una desinenza: HTMLer per HTMLista, appunto. Nella
nostra lingua tale distinzione non pare appropriata.
Il W3C non fa dal canto
suo molto per dirimere la questione. Considera HTML un’abbreviazione,
ma senza
fare chiarezza nelle definizioni.

Siccome c’è poca speranza di risolvere definitivamente la questione,
e d’altra parte non ha molto senso coinvolgere gli sviluppatori in dispute
degne degli accademici della Crusca, potrebbe non essere male poter disporre
di un marcatore unico che indichi genericamente delle sigle: sia un acronimo
che un’abbreviazione sono infatti sigle, espressioni sintetiche, per cui
tale ipotetico marcatore potrebbe andar bene per tutti questi tipi di
contenuti. Ma al momento è improbabile che questo si verifichi:
quindi per la lingua italiana è bene attenersi al concetto che
un acronimo è una parola formata dalle iniziali di altre parole,
e le abbreviazioni tutto il resto. Ma senza scandalizzarsi se qualcuno
usa ABBR per marcare HTML…

Ricordati che esistono i browser…

Naturalmente questo riguarda gli autori di pagine. E i browser? Non si
comportano certo meglio.
In assenza di un marcatore adeguato o di un criterio risolutore, Microsoft
ha pensato bene di tagliare la testa al toro e di non supportare affatto
ABBR sui suoi browser (dunque su Explorer, proprio il più diffuso).
Il che rende ancora più problematico l’uso corretto di questi marcatori,
dato che, nel dubbio, è comunque preferibile usare ABBR anche al
posto di ACRONYM, che viceversa: infatti un acronimo è pur sempre
un caso particolare di abbreviazione, mentre non è vero il contrario.

Un altro problema riguarda la capacità dei lettori vocali di leggere
correttamente la sigla. Infatti un acronimo potrebbe essere pronunciato
da questi software in due diversi modi:

1. come una sequenza di lettere (Ci-esse-esse, acca-ti-emme-elle)
2. come una parola dotata di senso (NATO, TAC, REM).

Come decidere, di volta in volta? Lo stesso w3c riconosce che la pronuncia
di un acronimo è spesso idiosincratica, cioè in alcuni casi
avviene lettera per lettera, in altri come parola intera. Per semplificare
la vita agli sviluppatori (anche se suona più come una presa in
giro…) è stata dunque introdotta una specifica proprietà
CSS2 per gli user agent appartenenti ai media aural (in pratica per i
lettori vocali, non per i browser visuali). La proprietà è
speak, e può assumere il valore normal,
nel caso la parola venga letta come parola, e spell-out nel
caso del lettera per lettera:

ABBR.parola, ACRONYM.parola {speak: normal;}
ABBR.sigla, ACRONYM.sigla {speak: spell-out;}

(NB: Speak può assumere
anche i valori none e inherit, ma non è
questo il luogo per addentrarsi in dettagli).

Assegnando le classi opportune ai diversi ABBR e ACRONYM nel testo, è
possibile accertarsi che vengano letti nella maniera appropriata. Questo
se i dispositivi di lettura supportassero questi marcatori, e queste specifiche
di stile!

Sfortunatamente, infatti, anche i browser vocali o i lettori di schermo
più diffusi hanno uno scarso o nullo supporto di questi standard…
Jaws fino alla versione 4.02 non supporta nessuno dei due marcatori, né
lo fa Home Page Reader. Non abbiamo provato l’ultima versione di Jaws,
la 4.5, ma le note tecniche non menzionano tale supporto fra le nuove
feature.

Tutto inutile, dunque? No: usare appropriatamente questi ABBR e ACRONYM
aiuta sicuramente la comprensione dei testi agli utenti che utilizzano
i browser visuali, dunque è sicuramente una comodità in
più, ma come sempre è meglio non farsi troppe illusioni:
il fatto che aiuti realmente chi ha problemi di accessibilità,
è più che altro una buona intenzione. Diventa insomma più
un’attenzione di usabilità, che di accessibilità, anche
se le WCAG 1.0 prescrivono di usare il markup in maniera appropriata –
e dunque per rispettarle bisogna usarli.

Parlando di usabilità, diventano tuttava cruciali altre considerazioni,
non menzionate né previste esplicitamente nelle WCAG 1.0, ma non
per questo meno vitali per i vostri utenti.

Usabilità: rendere percepibile e comprensibile

Ammesso e non concesso che riusciamo a districarci nella selva di decisioni
che precedono l’uso di questi marcatori, ci si pone un altro problema.
Infatti se la presenza di un elemento ABBR o ACRONYM non viene segnalato
in qualche modo al lettore, come fa costui a sapere che posizionandocisi
sopra potrà vedere la finestrella con l’estensione della sigla?

Il browser Mozilla ha risolto autonomamente
la questione segnalando gli elementi con un piccolo bordo inferiore, dello
stesso colore del testo. Purtroppo Explorer, al contrario, non solo non
riconosce ABBR, ma non fa nulla di default per segnalare ACRONYM: il testo
viene presentato come testo normale.

Sta emergendo così l’uso fra gli sviluppatori di definire attraverso
i fogli di stile una proprietà
che, ispirandosi almeno in parte al comportamento di Mozilla, stabilisca
una regola di visualizzazione, nella speranza che assurga il prima possibile
allo status di convenzione, e che magari venga implementata anche da Explorer
e dagli altri browser.

ABBR, ACRONYM {border-bottom: 1px dotted black;}

Questa dichiarazione crea un bordo inferiore punteggiato (usando dashed
invece che dotted, si crea un bordo tratteggiato, comunque
accettabile, anche perché explorer, solo per dimensioni di 1px,
tratta dotted esattamente come dashed…). L’aspetto
è molto diverso da un link, ed è importante perché
le parole usate come acronimi o abbreviazioni non devono indurre in errore
l’utente spingendolo a cliccare. Ecco perché il colore dev’essere
quello del testo o comunque un colore diverso da quello dei link, e la
sottolineatura dev’essere tratteggiata e non continua come nei link. Anche
la forma che si usa far assumere al cursore quando ci si posiziona sull’elemento
(non la manina, ma un punto interrogativo) allontana l’idea di una ‘zona
cliccabile’:

ABBR, ACRONYM {border-bottom: 1px dotted black; cursor: help;}

Queste convenzioni sono poco praticate, ma qualora vogliate usare questi
marcatori nei vostri siti, è bene mantenerle: solo con un’ampia
coerenza fra i siti gli utenti potranno, poco alla volta, imparare a riconoscere
a colpo d’occhio un’abbreviazione o un acronimo e abituarsi al loro funzionamento.
Se, al contrario, non definite alcuna specifica di stile per ABBR e ACRONYM,
i vostri utenti non ne potranno trarre alcun beneficio.

Possibili soluzioni: superare i limiti di Explorer

Poiché ABBR non viene supportato da Explorer, ci si può
trovar davanti due strade:

la prima è ignorare la cosa, e usare il tag correttamente, in
attesa che le versioni future lo supportino.
La seconda è usare un trucchetto: inserire uno SPAN dentro l’elemento
ABBR, e definire lo stile di quello span allo stesso modo.

<abbr title="confronta"><span class="abbreviazione"
title="confronta">cfr.</span></abbr>

e nel CSS:

ABBR, ACRONYM, SPAN.abbreviazione {border-bottom: 1px dotted black;
cursor: help;}

La soluzione è ridondante, sporca il codice con marcatori inutili,
e non la raccomandiamo, dato che la questione non è di quelle che
fanno perdere le notti ai vostri utenti. Ma è un’altra buona occasione
per sottolineare come vivremmo tutti molto meglio se i browser fossero
coerenti nel supporto degli standard web.

Mal di testa? Per vostra fortuna le WCAG 1.0 suggeriscono di usare questi
marcatori solo la prima volta che usate l’espressione in una pagina. D’altra
parte, per evitare di porsi continuamente la questione dell’uso corretto
di acronimi e abbreviazioni, è bene stilare una guida editoriale
e di stile per il vostro sito, che tenga conto delle convenzioni
diffuse, e che vi sia di supporto per le scelte future. In questa guida
di stile, è bene però considerare almeno un caso in cui
l’uso di abbreviazioni e acronimi è assolutamente sconsigliato:
per le voci di menu.

Cosa non fare: menu e voci di navigazione

Anche se rispettiamo le convenzioni di formattazione, acronimi e abbreviazioni
non sono adatti a essere usati come voci nei menu di navigazione per almeno
una semplice ragione: sono puro ostrogoto per chi non è già
un esperto della materia.

Il che rende il menu semplicemente incomprensibile: le voci non riescono
a predire all’utente quale sarà la destinazione della pagina, condizione
indispensabile di ogni buon link. Certo, l’utente può posizionarsi
sulla voce di menu per far comparire un fumetto esplicativo, ma è
un’azione ulteriore: non è detto che l’utente sappia della convenzione,
né che comunque lo faccia. Preferisce esplorare visivamente la
pagina, e si aspetta che ciò che riguarda la navigazione sia comprensibile
senza ulteriori sforzi.

Anche se lo facesse, si porrebbe il problema di quale informazione presentare,
ovvero quale attributo title preferire: quello dell’elemento
A o quello dell’elemento ABBR (o ACRONYM)? In caso di presenza di entrambi
i title, Explorer privilegia quello dell’elemento più
interno:in ogni caso una delle due informazioni non viene presentata.

Infine, anche qualora utilizzassimo una sigla molto conosciuta, un menu
composto dalla sola sigla (abbreviazione od acronimo che sia) non ci direbbe
comunque cosa troveremmo nella pagina di destinazione: una spiegazione
della sigla? Una sezione che ci parli dell’argomento? Specifiche tecniche?
O che altro? Dovremmo affidarci a dei title particolarmente
esplicativi, ma naturalmente è molto meglio se la destinazione
si capisce a partire dalla sola lettura del link. La conclusione è
una sola: una semplice sigla (abbreviazione o acronimo) non è una
buona label di navigazione.

C’è un’eccezione a questa regola: le sigle e gli acronimi possono
ragionevolmente essere usate come voci di menu, previe opportune verifiche,
esclusivamente in siti molto targetizzati e con utenza molto specialistica,
come alcune intranet o come i siti di supporto agli help-desk telefonici,
dove operatori esperti riconoscono certamente il significato di quelle
espressioni, e, anzi, esse aiutano la sintesi e l’efficacia nella ricerca
di informazioni. In ogni caso questi elementi non devono essere usati
come voci di navigazione quando il sito intende rivolgersi ad un’utenza
ampia, e abbia scopi comunicativi o divulgativi al di fuori di una cerchia
specialistica di utenti controllati.

Usabilità, accessibilità e limiti delle linee guida

Ci sono alcune considerazioni da fare. Perseguire l’accessibilità
è un obiettivo importante, che tutti i siti dovrebbero porsi, non
solo quelli pubblici, che peraltro già raramente se lo pongono.
Tuttavia, da questi esempi emerge che:

1. Seguire alla lettera le wcag1.0, ovvero le raccomandazioni del w3c
per l’accessibilità dei contenuti web, non è sempre così
facile, a causa di ambiguità e limiti delle linee guida stesse,
ma anche di inadeguato supporto da parte degli user agent
2. seguirle non garantisce comunque l’usabilità delle vostre pagine.
Se non vi ponete anche ulteriori problemi legati alla qualità dell’esperienza
dell’utente sul vostro sito, o meglio ancora, se non testate le pagine
con degli utenti reali, potreste produrre pagine valide e accessibili
formalmente, ma che creano significativi ostacoli ad una corretta navigazione
anche ad utenti normodotati.

Aggiungiamo, ad onor del vero, che le WCAG 1.0 prevedono fra le linee
guida che la navigazione del sito debba essere semplice e intuitiva, e
che il linguaggio debba essere comprensibile. Sfortunatamente, queste
linee guida assomigliano di più a delle euristiche che a vere e
proprie linee guida controllabili. A quali condizioni la navigazione è
intuitiva e semplice? Quando il linguaggio si può considerare comprensibile?
E chi deve preoccuparsi di verificarlo – e come? A queste domande le WCAG
1.0 non rispondono, e richiamano ad un semplice controllo umano, cioè
non basato sul codice. Ecco perché i validatori automatici dell’accessibilità,
pur essendo strumenti utili e addirittura indispensabili per sgravare
lo sviluppatore da compiti altrimenti tediosissimi, non possono dar conto
della qualità dell’esperienza dell’utente, e difficilmente possiamo
immaginare dei valutatori automatici dell’usabilità. Proprio perché
essa dipende spesso da scelte semantiche, logiche, scarsamente operazionalizzabili
e variabili a seconda del contesto e del tipo di pubblico.

Questo ci riporta ad un limite tutto interno all’accessibilità,
per come è attualmente normata dal WAI: quello di non prevedere
per il momento forme di verifica sul campo del lavoro svolto, a differenza
dell’usabilità che fa invece dei test con gli utenti l’arma migliore
per la scelta di soluzioni di efficacia pratica e non solo teorica.

Capita molto spesso di sentir sovrapporre i concetti di usabilità
e accessibilità in ambito web, quasi vi sia la diffusa convinzione
che entrambe queste discipline puntino allo stesso obiettivo. Qualcuno
sembra anche pensare che prima o poi una delle due si fonderà nell’altra,
dato che crede che abbiano gli stessi fini.

E’ un equivoco che può portare a delle convinzioni piuttosto strane.
Si può finir col credere che un sito web che rispetti le verifiche
di accessibilità WAI sia automaticamente un sito usabile, o che
qualunque sito, per essere usabile, debba rispettare le norme di accessibilità
WAI.

In questo articolo cercherò di discutere i motivi per i quali
questo non è vero, e perché l’equivoco si sia generato.
Infine, ci porremo alcune domande sul reale ambito delle due discipline.

Due parole sulle parole…

Definiamo prima di tutto di cosa parliamo, e facciamolo in maniera sintetica.
Grazie al cielo, per accessibilità dei siti web si intende qualcosa
di molto specifico e ben definito, per merito del WAI (Web Accessibility
Initiative), un gruppo di lavoro costituito dal W3C, il consorzio per
il web diretto da Tim Berners-Lee. Il WAI ha generato il WCAI (Web Content
Accessibility Initiative). Il WCAI ha rilasciato a più riprese
una serie di documenti contenenti principi e linee guida cui attenersi
per realizzare contenuti web che siano accessibili al maggior numero di
persone possibili. In particolare, i contenuti dovrebbero essere accessibili
da utenti con vari gradi di disabilità fisiche e cognitive, il
che porta come beneficio accessorio una maggior facilità di visualizzazione
anche per chi ha dotazioni software e hardware minoritarie.

Per quanto riguarda le disabilità, esse possono andare dall’impossibilità
a dirigere un mouse, fino a cecità totali o selettive ai colori,
per arrivare ai non vedenti veri e propri. L’incidenza di queste disabilità
nella società è più ampia di quanto si pensi, e in
attesa, per l’Italia, dei dati del censimento in corso, ci atteniamo alle
stime del WAI. Secondo queste stime, gli utenti interessati in qualche
modo a questi problemi variano dal 10 al 20% della popolazione. Si pone
dunque un reale problema di democrazia dell’accesso alle risorse di rete.

Per quanto riguarda le dotazioni hardware/software, la variabilità
va da computer molto vecchi e lenti, fino ai nuovissimi dispositivi portatili,
come palmari o cellulari di ultima generazione. La variabilità
di visualizzazione che è comunque una regola nel web, diventa ancora
più grande se pensiamo che questi dispositivi hanno browser dedicati,
display piccolissimi e un numero di colori spesso più basso di
quello cui ci siamo abituati con i recenti monitor da tavolo.

Accessibilità, ma come?

Appare subito evidente che rendere tutto ciò che gira in rete
accessibile a tutta questa enorme varietà di utenti, è un’impresa
davvero impegnativa. Eppure, l’approccio del WAI è molto razionale
e, per una volta, realistico. Si fonda su un principio fondamentale: non
tutti possono vedere allo stesso modo tutto, ma il nocciolo del contenuto
dovrebbe comunque essere reso accessibile a tutti.

In pratica, secondo il WAI le pagine web dovrebbero essere costruite
secondo 2 criteri:

1. consentire un’elegante trasformazione della pagina (da parte di browser
   particolari, ad esempio)
2. i contenuti dovrebbero essere resi facilmente navigabili e comprensibili
   (che è il principale obiettivo dell’usabilità)

Non solo un testo può essere reso accessibile ad un utente cieco
attraverso un browser vocale che lo legga, ma anche un’immagine o una
tabella di dati possono essere descritte dallo stesso software, a patto
che il progettista della pagina abbia costruito il codice di quella tabella
o di quell’immagine in maniera da facilitare la vita a questo software
specifico.

L’accessibilità web così definita ed articolata in linee
guida anche molto specifiche, viene ad essere una questione che si basa
in larga parte sui concetti di compatibilità e portabilità
del codice. Ma non solo. Il WCAI entra anche nel merito della strutturazione
e della comprensibilità dei contenuti: aree delle quali, guarda
caso, si occupa anche l’usabilità. Volendo azzardare un po’, si
potrebbe sostenere che l’usabilità è un sottoinsieme dell’accessibilità
nella misura in cui ne approfondisce un aspetto. Contemporaneamente, però,
utilizza metodi molto differenti, che la caratterizzano peculiarmente.

Ed è qui che probabilmente inizia la confusione.

Obiettivi parzialmente sovrapposti, metodi differenti

Le differenze fra usabilità e accessibilità diventano
molto evidenti quando si passa ad analizzarne i rispettivi metodi.
Non vi è infatti nelle norme di accessibilità alcun accenno
allo user model né alla pratica di testing con gli utenti finali
per ridefinire procedure e navigazione. Nella pratica, gli unici strumenti
che l’accessibilità propone sono le linee guida.
E’ quindi una disciplina sì molto normata (e per questo gradita
ai tecnici molto più dell’usabilità, perché verificabile
in maniera quasi automatica, senza bisogno di procedure di selezione e
testing di utenti, giudicate troppo dipendenti dal valutatore – poco oggettive),
ma questa normatività è anche un tranello. Infatti, come
fare per verificare l’aderenza ai principi di navigabilità e chiarezza
dei testi? Certo, ci sono le linee guida, ma è più facile
a dirsi che a farsi. Le linee guida, in fin dei conti, tracciano una strada,
ma non garantiscono che il singolo progettista sappia scrivere in maniera
sintetica e chiara semplicemente seguendo una norma. Né che l’argomento
sia reso effettivamente fruibile agli utenti o che la navigazione rispecchi
il modello concettuale dell’utente.

Le linee guida tracciano una strada, danno una mano. Ma non garantiscono
il risultato. Inoltre, i siti sono enormemente differenti fra loro, e
non tutti i contenuti o i modelli di navigazione si adattano ai diversi
casi.

A riprova, va notato che anche la verifica automatica di accessibilità
online sul sito www.cast.org/bobby
si limita ad una compatibilità di codice, non di progettazione
del contenuto o del servizio, com’è ovvio. Ci avverte anzi che
la verifica dev’essere continuata da valutatori umani, che verifichino
proprio se il contenuto è chiaro e comprensibile. La navigabilità
riguarda questioni di struttura profonda del sito, e non può essere
risolta da una valutazione automatica.

Morale: l’accessibilità indica la meta e inizia a spiegarci come
avviarcisi. Non ci offre però tutti gli strumenti per arrivarci.
Non solo: lavorare seguendo esclusivamente delle linee guida – senza considerare
l’utente finale nello sviluppo del progetto – può portare a trascurare
possibili problemi inaspettati, legati soprattutto al modo in cui un utente
gradisce utilizzare il servizio o il contenuto e non prevedibili sulla
base delle sole linee guida.

L’usabilità come strumento

L’usabilità, al contrario, non è quasi una questione di
codice e di compatibilità. Suo obiettivo è che il sito risponda
alle esigenze dell’utente. Non necessariamente di tutti gli utenti,
ma di quelli per i quali il sito è stato pensato. A meno di non
credere che ogni servizio e contenuto presente in internet sia ‘per tutti’
(e soprattutto per tutti allo stesso modo…) indipendentemente dalle
differenti esigenze, motivazioni e caratteristiche individuali, è
chiaro che il problema dell’accessibilità può essere uno
di quelli che chi fa usabilità si può trovare a dover affrontare,
ma non necessariamente: dipende dalla natura del progetto.

Oltre a queste differenze, curiosamente l’usabilità offre però
strumenti e metodi che possono essere utilizzati per completare quello
che l’accessibilità lascia soltanto indicato. Gli strumenti
sono l’osservazione strutturata degli utenti-target, quelli per i quali
il sito è stato costruito. Attraverso l’osservazione dell’interazione
fra sito e utente, l’usabilità registra errori e fraintendimenti
di progettazione. Tramite colloqui con gli utenti indaga sulle ragioni
di questi errori, e può così stilare una lista di suggerimenti
migliorativi, in un continuo processo di prova/errore.

Un processo evolutivo continuo, l’esatto contrario della prescrittività
di cui troppo spesso l’usabilità viene accusata. Solo scovando
gli errori e riparandovi, un prodotto può migliorare, solo osservando
e parlando con gli utenti possiamo sapere se un contenuto era chiaro,
se è stato capito, se il sito è navigabile.

Un problema di metodo, dunque, e non solo di obiettivi.
Il fatto che anche l’usabilità proponga delle linee guida o dei
principi di progettazione deriva da esigenze di praticità ed economia.
Tali linee guida sono infatti il sunto di intense pratiche di test, e
derivano (o dovrebbero derivare…) dall’osservazione sistematica degli
utenti. E’ solo per facilitare il lavoro dei progettisti che alcuni dei
risultati più ricorrenti nelle fasi di test vengono riassunti in
linee guida: si tratta però di strumenti di secondo livello, certamente
utili, ma non attendibili quanto l’osservazione diretta di una persona.
Del resto, è anche vero che l’osservazione di un numero basso di
utenti spesso non consente di identificare tutti i possibili problemi:
ecco dunque che le linee guida possono fungere da liste di controllo.

L’accessibilità è allora sia una questione di compatibilità/portabilità
tecnica, sia una questione di chiarezza di comunicazione e navigazione
che mira ad un accesso universale, standardizzato.
L’usabilità invece si occupa degli utenti finali, può disinteressarsi
(entro certi limiti) del codice, e tenta piuttosto di capire cosa va e
cosa non va nell’interazione, nell’interfaccia. Vi saranno elementi che
andranno certamente standardizzati, ma altri che andranno progettati caso
per caso, sulle specifiche esigenze degli utenti-target.

Così facendo, però, l’usabilità finisce per offrire
strumenti precisi anche a chi vuole costruire siti accessibili: testando
navigazione e comprensibilità, aiutando nella messa a punto delle
procedure meno intuitive: purché scelga il target di utenti più
appropriato.

Tuttavia le differenze fra le due discipline non sono tutte qui. Sarebbe
troppo bello! Dovrebbe essere ovvio che possa capitare anche che usabilità
e accessibilità non si concilino, anzi: che per migliorare l’accessibilità
si peggiori l’usabilità e viceversa!

Accessibilità contro usabilità: primo round

Pensiamo ad esempio ai menu. Ebbene, sia l’accessibilità
sia le osservazioni di usabilità indicano che i menu verbali
sono preferibili ai menu basati su icone.
Però un menu verbale può essere realizzato in due modi:

1. Come testo html, oppure
2. Con un’immagine che rappresenti il testo scritto.

Ebbene, le norme di accessibilità richiedono naturalmente che
i menu siano scritti in testo html, in maniera che tutti i browser,
anche quelli non grafici, possano leggerli con efficacia. Se si usasse
l’immagine, si dovrebbe utilizzare l’attributo ALT per fornire una descrizione
testuale dell’immagine, e comunque permarrebbero problemi di visualizzazione
su monitor con risoluzioni più basse.

D’altra parte, però, con l’utilizzo di menu in solo testo, si
rende cliccabile soltanto l’area della parola utilizzata, e non i
suoi dintorni. In diversi test con soggetti non esperti ho verificato
molte volte che gli utenti sono tutt’altro che precisi nell’utilizzo
del mouse. Sebbene a qualcuno possa sembrare impossibile, ho visto
spesso utenti CREDERE di cliccare su una parola/link, e mancarla senza
accorgersene, cliccando leggermente a lato! Da ciò, solitamente,
deriva una certa confusione, perché l’utente crede di aver sbagliato
nell’identificare il link, di dover cercare da un’altra parte, e così
via.

Al contrario, un’immagine che contiene la rappresentazione del testo,
può essere ritagliata a piacere. E tutta l’area dell’immagine,
anche attorno al testo, sarà ugualmente cliccabile. La probabilità
che gli utenti ‘manchino’ il link diventa così molto minore.

Utilizzare appropriatamente delle immagini con una certa abbondanza attorno
al testo rende così maggiormente cliccabile la parola, e la pagina
più usabile: ma diminuisce l’accessibilità!

Compromessi e felici

Si tratta solo di un esempio banale, ma è indicativo delle contraddizioni
che possono nascere da un’errata interpretazione di accessibilità
e usabilità. Progettare siti diventa infatti molto spesso una questione
di scelte e compromessi legati agli obiettivi. Non si può
dimenticare che molti siti aziendali non sono rivolti ‘a tutti’: il marketing
si fonda proprio sulla segmentazione del mercato, e quindi dei propri
utenti. Di conseguenza, i requisiti di accessibilità non possono
essere gli stessi di un sito di servizio, ad esempio quello di una pubblica
amministrazione, che per definizione deve essere rivolto a tutti i cittadini.

Attenzione: queste considerazioni non vogliono incoraggiare l’adozione
nei siti commerciali di tecnologie proprietarie, spesso altrettanto inusabili
che inaccessibili. Ma è importante capire che accessibilità
e usabilità NON sono la stessa cosa. Se in alcuni progetti l’accessibilità
può non essere l’obiettivo primario, questo non può
mai essere vero per l’usabilità. Infatti l’usabilità
è un prerequisito che tutti i siti dovrebbero avere per poter essere
fruiti dal proprio pubblico, che può essere anche molto specifico
e minoritario.

Il primo passo per migliorare davvero i siti e i servizi che rivolgiamo
ai nostri utenti è dunque quello di capire entrambe le discipline,
per poterne trarre gli appropriati vantaggi a seconda delle nostre esigenze
e dei nostri obiettivi.