Accessibilità o usabilità? Istruzioni per l'uso | Usabile.it

Usabile.it

usabilità, accessibilità e interaction-design per il web

home » Articoli » Accessibilità o usabilità? Istruzioni per l'uso

4/11/2001

Accessibilità o usabilità? Istruzioni per l'uso

[di Maurizio Boscarol]

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.

Articoli correlati:

torna su Torna su