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.