Diodati.org | Accessibilità e traduzioni dal W3C      Leggi Omega Centauri!

Sponsor ufficiale di Diodati.org: Hosting a partire da 3,33 Euro/mese | Domini a partire da 10,79 euro/anno | Server dedicati a partire da 40 euro/mese, VPS Hosting da 30 euro/mese

L'usabilità nacque negli anni '60 nell'ambito di studi di ergonomia che si occupavano del modo in cui l'uomo utilizza artefatti, cioè oggetti e sistemi prodotti dall'uomo stesso. Con la diffusione a livello mondiale dell'uso di strumenti informatici da parte di utenti non esperti, l'usabilità ha trovato un campo di applicazione privilegiato nell'analisi dell'interazione tra l'utilizzatore umano e le interfacce software. Con l'esplosione del fenomeno Internet, avutasi a partire dagli anni '90, i metodi dell'usabilità sono stati applicati con successo alle interfacce utente rappresentate dai siti Web. In questo ambito, il campo di applicazione dell'usabilità e quello dell'accessibilità finiscono spesso per sovrapporsi, in modi che rendono difficile tracciare confini netti tra le due discipline.

Il problema del rapporto tra usabilità e accessibilità non è affatto secondario. Ce ne occupiamo in questa guida proprio perché la chiarificazione di tale rapporto permetterà una migliore comprensione dei limiti attuali dell'accessibilità e di cosa è possibile fare per superarli.

Partiamo dalla definizione di "usabilità". Lo standard ISO 9241 ha definito l'usabilità come la misura in cui un prodotto può essere usato da determinati utenti per raggiungere determinati obiettivi con efficacia, efficienza e soddisfazione in un determinato contesto d'uso.

Trasportata in ambito Web, questa definizione ci dice che lo scopo dell'usabilità è quello di studiare l'interazione tra l'utente e il sito, o tra l'utente e la singola pagina web, con l'obiettivo di mettere in luce gli ostacoli che di volta in volta si frappongono ad un uso efficace, efficiente e soddisfacente delle informazioni e dei servizi contenuti nel sito o nella pagina. L'usabilità tende a suggerire, per mezzo di opportuni test e di raccomandazioni pratiche nate dall'esperienza complessiva accumulata negli anni, le tecniche per migliorare l'esperienza dell'utente ("user experience") in un determinato contesto d'uso.

La sovrapposizione tra gli obiettivi dell'usabilità e quelli dell'accessibilità si verifica non tanto per quelle raccomandazioni delle WCAG 1.0 che puntano a rendere accessibili a certe categorie di utenti contenuti che altrimenti non lo sarebbero, ma piuttosto per quelle raccomandazioni che puntano a migliorare l'accessibilità dei contenuti, cioè principalmente quelle associate a punti di controllo di priorità 3 (ma non solo). Rendere l'uso di una risorsa più semplice e soddisfacente è appunto anche lo scopo dell'usabilità.

La sovrapposizione appare più netta per quelle raccomandazioni di accessibilità che mirano agli aspetti cognitivi dell'interazione dell'utente con la pagina: fornire informazioni contestuali, chiari meccanismi di navigazione, utilizzare un linguaggio semplice e comprensibile. Sono questi anche scopi dell'usabilità, quando si applica all'analisi del rapporto tra gli utenti e una determinata interfaccia web.

Se negli obiettivi delle due discipline si ha in certi casi una più o meno ampia sovrapposizione, la differenza tra accessibilità e usabilità diviene più chiara quando si guarda ai rispettivi metodi. L'appendice A delle WCAG 1.0, dedicata ai modi per verificare il raggiungimento dei requisiti di accessibilità richiesti dalle quattordici raccomandazioni, propone una serie di metodi che consistono principalmente nella validazione automatica del codice della pagina per mezzo di appositi software e nell'effettuazione di una serie di prove tecniche, che - disponendo delle opportune attrezzature - possono essere compiute dallo stesso sviluppatore. Solo ai punti 9 e 10 dell'appendice si fa un riferimento a possibili test con utenti umani, ma senza suggerire specificamente il ricorso ai metodi sviluppati in questo campo dall'usabilità.

L'accessibilità, così come è concepita dalle WCAG 1.0, rivolge le sue raccomandazioni allo sviluppatore (il "content developer"), tralasciando più o meno completamente di occuparsi del rapporto tra il prodotto "accessibile" e l'utente finale - anzi le varie categorie possibili di utenti finali - il che costituirebbe invece il centro dell'interesse dell'usabilità, se applicata agli obiettivi dell'accessibilità.

La soluzione decisa dagli estensori delle WCAG 1.0 ha un indubbio vantaggio economico dal punto di vista dei costi di sviluppo di un sito: quanto più la cura dell'accessibilità può focalizzarsi - grazie all'adozione dei suggerimenti tecnici acclusi alle linee guida - sul codice e sulla struttura della pagina, piuttosto che sui risultati dell'interazione tra la pagina e gli utenti finali, tanto più sarà semplice e veloce portare a termine il lavoro.

Una buona analisi delle ragioni per cui l'accessibilità si rivolge essenzialmente allo sviluppatore, ed ha per suo oggetto la pagina web piuttosto che l'interazione tra questa e l'utente, è contenuta in un lungo ed interessante articolo di Jim e Pat Byrne, intitolato "What is an accessible website?".

L'articolo analizza i numerosi problemi e le contraddizioni che sorgono quando si tenta di realizzare in concreto un'accessibilità veramente universale. Riportiamo di seguito, per brevità, solo la traduzione in italiano delle conclusioni a cui giunge l'articolo.

• Cercare di rendere i nostri contenuti accessibili a tutti indistintamente è pressoché impossibile. L'accessibilità è un concetto relativo: dipende dal proprio pubblico di riferimento, dalla conoscenza che si ha dei suoi bisogni e dalle risorse che si hanno a disposizione.
• Non è possibile controllare il modo in cui una pagina sarà presentata all'utente finale; la sola cosa su cui è possibile avere un controllo assoluto è il codice di marcatura usato nelle pagine (per es. l'HTML).
• Tutti i contenuti arrivano all'utente attraverso un qualche tipo di computer e di browser.
• Il primo passo per creare siti accessibili è creare siti che siano accessibili alle macchine. La migliore chance per ottenere ciò è usare HTML standard.
• Quando il contenuto può essere divorziato dalla presentazione, usando i fogli di stile, il medesimo contenuto può essere presentato in molti modi differenti. Non occorre pertanto preoccuparsi di creare molteplici versioni di una stessa pagina per venire incontro ai bisogni di un pubblico diversificato.
• Le Linee Guida del W3C sull'accessibilità possono essere usate per rendere i vostri siti web, basati sugli standard, più flessibili e più capaci di soddisfare i diversi bisogni del vostro pubblico di riferimento.

Insomma, rendere una pagina web accessibile alle macchine (computer e browser) e flessibile nella struttura sono gli obiettivi principali a cui evidentemente puntano le raccomandazioni di accessibilità.

In ciò la differenza con l'usabilità è grande: quest'ultima infatti lavora essenzialmente sull'interazione tra la pagina e gli utenti, anzi le specifiche categorie di utenti considerate come pubblico di riferimento dei siti da testare.

Tuttavia una vera accessibilità, come si evince dalla ultime tre raccomandazioni delle WCAG 1.0, non è solo questione di codice standard e struttura di pagina flessibile. E' anche una questione di comprensibilità dei testi, di chiarezza di esposizione, di facilità di navigazione. Questi obiettivi non solo sono comuni all'usabilità, ma richiederebbero anche i metodi dell'usabilità - sebbene questo le WCAG 1.0 non lo dicano - perché qualcuno possa affermare con un accettabile grado di sicurezza di averli raggiunti.

Non bastano infatti la buona volontà e lo scrupolo professionale dello sviluppatore per asserire con certezza di aver prodotto pagine web scritte in modo chiaro e comprensibile, o dotate di meccanismi di navigazione facili e intuitivi da utilizzare. Molto meglio sarebbe organizzare opportuni test di usabilità e lasciare che siano questi a dire l'ultima parola in proposito, magari proponendo correzioni e miglioramenti suggeriti dall'interazione con utenti reali, che allo sviluppatore non sarebbero mai venuti in mente.

Proprio questo sorvolare completamente sulla contiguità di obiettivi tra l'accessibilità e l'usabilità, e sull'opportunità in certi casi di ricorrere ai metodi di quest'ultima, è a nostro avviso il limite principale delle WCAG 1.0.

Per la verità un accenno diretto all'usabilità è possibile trovarlo nella risposta numero 7 della pagina dedicata alle domande frequenti (FAQ, dall'inglese "frequently asked questions") sulle WCAG 1.0. Si legge nella seconda parte di questa risposta:

Molte caratteristiche delle linee guida miglioreranno in realtà l'usabilità dei siti Web per gli utenti non disabili, garantendo che i siti siano più facilmente navigabili e che vi si possa accedere attraverso una varietà di tipi differenti di periferiche piuttosto che soltanto attraverso un tradizionale browser grafico con un computer da tavolo.

Il documento da cui è tratto il testo sopra riportato è però un documento accessorio, informativo, non normativo. In sostanza, la questione del rapporto tra accessibilità e usabilità viene affrontata dalle WCAG 1.0 soltanto di sfuggita e in un contesto secondario.

Sembra però che il gruppo di lavoro che sta elaborando le WCAG 2.0 abbia deciso finalmente di assumere, fin dal documento normativo principale, una posizione esplicita in proposito. Nel paragrafo della bozza di lavoro delle WCAG 2.0 dedicato all'ambito di applicazione delle nuove linee guida, si può leggere infatti (traduciamo in italiano per comodità del lettore):

Queste linee guida coprono un'ampia gamma di temi e di raccomandazioni volti a rendere i contenuti web più accessibili. Includono raccomandazioni per produrre pagine accessibili e usabili da persone affette da ogni genere di disabilità. In generale, le linee guida non includono raccomandazioni standard di usabilità a meno che esse non abbiano specifiche ramificazioni per l'accessibilità che vadano oltre effetti standard di usabilità.

Non che quest'ultima frase sia chiarissima. Suona piuttosto indeterminata anche nell'originale inglese: ... the guidelines do not include standard usability recommendations except where they have specific ramifications for accessibility beyond standard usability impacts.

Da parte nostra - anche se questo non è scritto nelle WCAG 1.0 e, per ora, neppure nella bozza delle WCAG 2.0 - suggeriamo, ogni volta che sia possibile, di affiancare al lavoro sul codice degli specifici test di usabilità, mirati a conoscere la reale validità delle soluzioni di accessibilità messe in campo (soprattutto quelle che hanno a che fare con la comprensione del testo e dei meccanismi di navigazione). Test da svolgere su un campione di utenti, che sia rappresentativo del pubblico di riferimento previsto per il proprio sito.

Per chi non avesse la possibilità di effettuare simili test, diventa importantissimo sfruttare ogni minimo riscontro d'uso da parte dei propri utenti (p.es. le osservazioni ricevute tramite e-mail e forum di discussione), per correggere e migliorare gli eventuali difetti di accessibilità segnalati. Creare pagine accessibili non è infatti un lavoro da fare una tantum, che si possa considerare finito per sempre con la pubblicazione in Rete delle proprie pagine web. E' piuttosto un processo ininterrotto di verifica e miglioramento, che, partendo dalle raccomandazioni contenute nelle linee guida del W3C, si alimenta poi dei riscontri costanti ricevuti dagli utenti, i quali - occorre non dimenticarlo mai! - sono i veri destinatari di tutto il lavoro svolto sull'accessibilità.