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!