Accessibilità e inaccessibilità

Questo primo capitolo spiega cos’è e a cosa serve l’accessibilità per il Web. Lo fa in due modi: teoricamente, analizzando i significati delle parole “accessibile” e “accessibilità”, e praticamente, mostrando esempi di inaccessibilità.

Il significato comune della parola “accessibile”

Per impadronirsi di una materia esistono due sistemi: iniziare dalla teoria, per esempio leggendo libri sull’argomento che si desidera approfondire; o iniziare dalla pratica, per esempio facendosi assumere come praticante da qualcuno che già opera nel settore. Il fatto che stiate leggendo un libro sull’accessibilità dimostra che vi interessa l’approccio teorico (i “praticoni”, al contrario, non leggono mai le istruzioni prima dell’uso).

Cominceremo dunque dalla teoria, per arrivare poi ad esempi concreti che ne illustreranno le applicazioni. Entrambi gli ambiti – teoria e pratica – sono infatti indispensabili per arrivare a padroneggiare in modo corretto un sapere, qualsiasi esso sia, compreso quello sull’accessibilità: la teoria da sola, infatti, produce “esperti” senza esperienza, cioè senza una capacità di giudizio affinata dalla pratica e dai compromessi che questa talvolta richiede; la pratica da sola, dal canto suo, produce “esperti” senza una visione globale e coerente della materia di cui si occupano.

Ciò premesso, un approccio teorico non può che partire dalla ricerca di una definizione per l’oggetto di questo libro: l’accessibilità.

Il proposito si scontra però subito con una difficoltà. L’uso del termine “accessibilità” in senso specialistico è infatti molto recente, e tale accezione manca completamente nei vocabolari della lingua italiana. Se consultiamo per esempio il De Mauro e il Garzanti, entrambi si limitano a dare di “accessibilità” la medesima stringata definizione: “l’essere accessibile”. Un po’ come dire che l’umanità è l’essere uomini: troppo generico!

Anche il Vocabolario Treccani della lingua italiana ripete la medesima definizione, aggiungendovi solo: “possibilità di facile accesso”.

Il dizionario di De Mauro, consultabile in Rete, incorre però in un’incoerenza particolarmente curiosa: da un lato offre una definizione di “accessibilità” assolutamente generica, quale quella sopra riportata, dall’altro mostra ben visibile, sulla prima pagina del proprio sito internet, la seguente avvertenza:

Accessibilità. Coloro che per la navigazione utilizzano strumenti diversi da monitor, mouse o tastiera, che utilizzano un browser testuale o che hanno difficoltà visive possono inviare le proprie impressioni d’uso al webmaster.

Insomma, la parola “accessibilità”, almeno per i curatori del sito del De Mauro Paravia online, ha un evidente significato specialistico, del quale però non si trova riscontro nella corrispondente definizione del dizionario. Una situazione che ricorda un po’ l’imbarazzo di Sant’Agostino, consapevole di sapere benissimo cosa fosse il tempo solo finché non gli si chiedesse di definirlo.

Per non trovarci con l’accessibilità nella stessa situazione di Sant’Agostino col tempo, occorre allora che ci rivolgiamo a un’altra parola, seguendo l’implicito consiglio dei vocabolari: se, cioè, l’accessibilità è la proprietà dell’essere accessibile, forse possiamo saperne di più capendo cosa vuol dire “accessibile”.

Riguardo a questa parola, la situazione è per fortuna molto più chiara. Accanto ad alcuni significati figurati (“persona accessibile” nel senso di affabile, cordiale, disponibile, e “prezzo accessibile” nel senso di modico), tutte le fonti concordano nel riportare due significati, uno proprio e uno figurato.

Per il Vocabolario Treccani della lingua italiana, il significato proprio di “accessibile” è:

A cui è possibile accedere, che è di facile accesso: “una località poco accessibile; rocca accessibile da due lati”.

In modo simile, il De Mauro riporta:

a cui si può accedere, raggiungibile: “spiaggia accessibile solo dal mare”.

E così anche il Dizionario Garzanti:

cui si può accedere; raggiungibile: “un luogo accessibile; una città non accessibile dal mare”.

Tutte e tre le fonti sono d’accordo anche sul significato figurato della parola:

Di nozione che s’intende facilmente: “sono concetti accessibili anche ai fanciulli” (Treccani). Di qualcosa comprensibile: “libri accessibili anche ai bambini” (De Mauro). Comprensibile: “concetto accessibile” (Garzanti).

Abbiamo ora abbastanza informazioni per arrivare a una prima importante certezza: “accessibile” significa raggiungibile, ma non raggiungibile con difficoltà, come sarebbe la vetta di un’alta montagna innevata, ma raggiungibile con facilità, senza troppi sforzi, come per esempio un citofono montato alla nostra altezza.

Inoltre “accessibile” può significare sia raggiungibile fisicamente, per mezzo del corpo, come il citofono di cui sopra, sia raggiungibile mentalmente, con la comprensione, come un libro scritto con semplicità.

Tale duplicità di significati non riguarda solo la lingua italiana, ma anche, per esempio, le altre lingue neolatine e l’inglese. Il francese accessible, lo spagnolo accesible, l’inglese accessible indicano tutti un qualcosa che può essere raggiunto con il corpo oppure compreso intellettualmente, ma sempre con facilità.

Inizio pagina

L’accessibilità, un sapere giovane e in trasformazione

Nel lettore può sorgere a questo punto una legittima obiezione: perché cercare il significato di “accessibile” e “accessibilità” nei dizionari invece che in una qualsiasi fonte tecnica e specialistica sull’argomento? Visto che si fanno da anni siti web che sono, o pretendono di essere, accessibili, ci dovrà pur essere qualche documento tecnico che spieghi cos’è e come si raggiunga l’accessibilità di un sito.

Certo, documenti simili esistono, e li analizzeremo in dettaglio nel prosieguo del libro. Tuttavia vi sono almeno due valide ragioni che giustificano la nostra iniziale ricerca di significati nei dizionari e nei vocabolari.

La prima ragione è mostrare che l’accessibilità di cui ci occuperemo in questo libro è un sapere ancora giovane e tuttora in via di definizione anche nei suoi tratti essenziali: oggetti e metodi sono in evoluzione; è normale, tutto sommato, che non vi sia ancora un’accezione specialistica della parola “accessibilità” nei vocabolari. Ciò vuol dire che per gli autori di vocabolari l’accessibilità per ora non è una scienza, come lo sono invece, e da molto tempo, l’astronomia e la fisica, né una tecnologia, come lo sono la televisione e il telefono, né un sapere empirico, come può essere la mnemotecnica, né tantomeno un’arte come la pittura o la scultura. Certamente nell’ambito specialistico dei suoi cultori l’accessibilità è qualcosa – e vedremo cosa – ma ufficialmente, cioè nella formalizzazione e sistemazione operata dai dizionari, non è ancora alcunché di certo e di inequivocabile. È appunto solo, come abbiamo visto, la proprietà dell’essere accessibile. Spetta allora agli “accessibilisti”, cioè ai cultori di questo nuovo sapere, lo sforzo di trarre l’accessibilità fuori dagli inevitabili equivoci e dalle incertezze dello stadio “adolescenziale”, e condurla a una condizione di maturità, conferendole un significato chiaro, univoco, condiviso e duraturo, tale da poter essere compreso senza ambiguità anche dai non addetti ai lavori. Sarà a quel punto che il significato specialistico della parola “accessibilità” uscirà dalla cerchia degli “iniziati”.

La seconda ragione consiste nel mettere in chiaro fin dall’inizio che le raccomandazioni per l’accessibilità che analizzeremo in seguito riprendono esattamente, anche se non esplicitamente, la duplicità di significati dell’aggettivo “accessibile”: alcune raccomandazioni, infatti, mirano a rendere i contenuti fisicamente accessibili (cioè percepibili); altre mirano invece a renderli comprensibili, cioè mentalmente accessibili; altre ancora mirano a favorire entrambi gli ambiti simultaneamente. Possiamo dire perciò che la ridefinizione specialistica di “accessibile” sta avvenendo senza contraddire i significati comuni dell’aggettivo, così come sono riportati dai vocabolari. Ciò è importante, perché indica che il lavoro di standardizzazione portato avanti negli ultimi anni dagli specialisti dell’accessibilità tende a creare una serie di raccomandazioni e tecniche che poggiano – sia pure forse inconsapevolmente – sul fondamento del senso comune: cioè i significati proprio e figurato di “accessibile”, noti anche a un pubblico di non addetti ai lavori (anche se, come vedremo meglio in seguito, l’uso specialistico dei termini “accessibile” e “accessibilità” è confinato principalmente a situazioni che coinvolgono gli utenti del Web con disabilità).

Inizio pagina

L’accessibilità secondo le WCAG 1.0

Siamo pronti ora per addentrarci nei significati specialistici delle parole “accessibile” e “accessibilità”, così come si ricavano dai documenti tecnici sulla materia, cominciando da quello che è il documento di riferimento ufficiale a livello internazionale.

Finché non saranno pubblicate le WCAG 2.0, tale riferimento è e rimane la raccomandazione del W3C intitolata Web Content Accessibility Guidelines 1.0, più brevemente WCAG 1.0, pubblicata il 5 maggio 1999 (http://www.w3.org/TR/WCAG10/ ).

È curioso notare che all’interno delle WCAG 1.0 la parola accessibility, corrispettivo inglese dell’italiano “accessibilità”, ricorre ben 57 volte, senza che il suo significato venga mai definito esplicitamente. Il significato della parola deve quindi essere dedotto dall’insieme dei contenuti del documento. Per fortuna, il glossario incluso nelle WCAG 1.0 contempla la definizione di accessible (l’equivalente inglese dell’italiano “accessibile”):

Content is accessible when it may be used by someone with a disability.

Ovvero, tradotto in italiano: Un contenuto è accessibile quando può essere usato da qualcuno con una disabilità.

Ecco dunque il primo e fondamentale elemento che caratterizza il concetto specialistico di “accessibile” (e, per conseguenza, di “accessibilità”): il rapporto con la disabilità. Non viene considerato accessibile un contenuto genericamente usabile, ma un contenuto che sia usabile da qualcuno affetto da una disabilità.

I beneficiari dell’accessibilità

Ma a quali disabilità si rivolgono le WCAG 1.0? Certamente non a tutte: una persona che abbia perso l’uso delle gambe, ma perfettamente lucida mentalmente, dotata di una vista normale e in grado di usare le mani, si trova, nel navigare sul Web, esattamente nelle medesime condizioni di una persona del tutto priva di disabilità.

Le categorie di disabili che vengono citate nelle WCAG 1.0 come interessate dai benefici di una corretta applicazione delle raccomandazioni sull’accessibilità sono le seguenti:

• i ciechi;
• i sordi;
• i sordociechi;
• gli ipovedenti;
• i disabili motori (almeno per quel che influenza la possibilità di usare il mouse o la tastiera);
• i malati di epilessia fotosensibile (le cui crisi possono essere scatenate da luci in movimento o oggetti lampeggianti);
• individui affetti da non meglio specificate disabilità cognitive o dell’apprendimento.

L’accessibilità tratteggiata dalle WCAG 1.0 non è però solo una ricetta per rimediare agli svantaggi nell’uso del Web causati dalle disabilità appena elencate. È, o vuole essere, anche un tentativo di risolvere problemi di accesso al Web che nulla hanno a che fare con la disabilità. Per comprendere quanto sia ampio lo spettro di situazioni considerato da questa raccomandazione del W3C, non c’è di meglio che riportare in traduzione italiana l’elenco che compare nell’introduzione del documento.

A beneficio di chi non ha familiarità con le questioni di accessibilità che riguardano la progettazione di pagine web, si consideri che molti utenti possono trovarsi a operare in contesti molto differenti dal proprio:

• possono non essere in grado di vedere, sentire, muoversi, o possono non riuscire a elaborare, facilmente o del tutto, alcuni tipi di informazioni;
• possono avere difficoltà nella lettura o nella comprensione dei testi;
• possono non avere la tastiera o il mouse, oppure non essere in grado di adoperarli;
• possono avere uno schermo solo a caratteri, uno schermo piccolo o una connessione lenta a Internet;
• possono non parlare o comprendere in modo fluente la lingua in cui il documento è scritto;
• possono trovarsi in situazioni in cui la vista, l’udito o le mani sono occupati o ostacolati (per esempio, guidano per lavoro o lavorano in un ambiente rumoroso ecc.);
• possono avere una versione precedente di un browser, un browser del tutto differente, un browser vocale o un diverso sistema operativo.

L’accessibilità non riguarda allora solo le disabilità permanenti (cecità, sordità ecc.), come alcuni suppongono, ma una serie di altre situazioni che, per ragioni che non hanno nulla a che fare con eventuali deficit fisici o psichici dell’utente, sono causa di limitazioni più o meno gravose della possibilità di fruire dei contenuti del Web.

Basandoci sull’elenco precedente, possiamo ricavare, dunque, le categorie generali di utenti che le WCAG 1.0 considerano beneficiarie dell’accessibilità:

• persone con disabilità fisiche e/o cognitive permanenti;
• persone che per ragioni contingenti (hanno le mani o gli occhi impegnati, lavorano in ambienti rumorosi, non conoscono bene una lingua) incontrano difficoltà simili a quelle di chi è affetto da disabilità fisiche o cognitive permanenti;
• persone che usano tecnologie potenzialmente “invalidanti” (computer o programmi obsoleti o poco comuni, connessioni a Internet molto lente).

L’estensione dei beneficiari dell’accessibilità a categorie di persone non disabili comporta anche l’estensione del significato di “accessibile”, di cui proponiamo la seguente definizione: accessibile è un contenuto web che può essere fruito da un utente indipendentemente da disabilità o limitazioni fisiche e/o cognitive, occasionali o permanenti, e indipendentemente dal tipo di tecnologia utilizzato per collegarsi alla Rete.

Ciò ci consente di definire l’accessibilità come la proprietà di un contenuto web accessibile, intendendo per “accessibile” esattamente quanto specificato qui sopra.

I destinatari dell’accessibilità (intesa come insieme di raccomandazioni e tecniche)

Accertato chi sono i beneficiari dell’accessibilità, il passo successivo consiste nell’individuare chi sono i destinatari delle linee guida incluse nelle WCAG 1.0, chi sono cioè coloro a cui spetta l’onere di applicarle concretamente. Ci viene in aiuto il brano seguente, tratto dalle prime righe del documento:

Le linee guida si rivolgono a tutti gli sviluppatori di contenuti per il Web (autori di pagine e progettisti di siti) e agli sviluppatori di strumenti autoriali.

Delle due categorie di destinatari individuate dalle WCAG 1.0, gli sviluppatori di contenuti per il Web (Web content developers), sono i destinatari diretti, quelli che materialmente producono siti e contenuti; lavoro che svolgono usando programmi creati dagli sviluppatori di strumenti autoriali (authoring tools developers): programmi, per esempio, come editor HTML, strumenti di conversione dei documenti da un formato a un altro, applicazioni che generano contenuti per il Web estraendoli da basi di dati.

Ai creatori di strumenti autoriali, invece, l’accessibilità dei contenuti interessa solo in modo indiretto: non spetta a loro, infatti, produrre contenuti accessibili; a loro serve conoscere le caratteristiche generali dell’accessibilità dei contenuti quel tanto che basta per realizzare strumenti autoriali che consentano di implementare tali caratteristiche.

Gli strumenti autoriali, dal canto loro, devono non solo consentire a chi li usa di realizzare contenuti accessibili, ma devono essere essi stessi intrinsecamente accessibili, cioè utilizzabili da utenti che rientrano nelle categorie elencate nel paragrafo I beneficiari dell’accessibilità. A tale scopo il W3C ha prodotto una seconda raccomandazione, pubblicata il 3 febbraio 2000 e intitolata Authoring Tool Accessibility Guidelines 1.0, in breve ATAG 1.0, la quale si rivolge espressamente agli sviluppatori di strumenti autoriali, con un duplice intento:

• assistere gli sviluppatori nel progettare strumenti autoriali in grado di produrre contenuti accessibili per il Web;
• assistere gli sviluppatori nel creare un’interfaccia autoriale accessibile.

Eccoci quindi con due diverse raccomandazioni e due diversi destinatari: le WCAG, destinate principalmente agli autori di contenuti, e le ATAG, destinate agli sviluppatori di strumenti autoriali.

Il cerchio però non è ancora chiuso: per garantire una piena accessibilità, non basta infatti che i contenuti siano sviluppati seguendo le WCAG e usando strumenti autoriali conformi alle ATAG. Occorre anche che i programmi usati per navigare, a partire dai browser, diano una mano agli utenti, offrendo loro caratteristiche atte a favorire l’accessibilità. È per questo che il W3C ha prodotto una terza raccomandazione sull’accessibilità, pubblicata il 17 dicembre 2002 con il titolo di User Agent Accessibility Guidelines 1.0, abbreviato in UAAG 1.0. Lo scopo di tale raccomandazione, come si legge nelle prime righe del documento, è:

(...) fornire linee guida per progettare programmi utente [user agents] in grado di abbassare le barriere verso l’accessibilità del Web a vantaggio di persone con disabilità (visive, uditive, fisiche, cognitive e neurologiche). I programmi utente includono i browser HTML e altri tipi di programmi in grado di recuperare e rappresentare contenuti web. Un programma utente conforme a queste linee guida favorirà l’accessibilità sia attraverso la propria interfaccia utente sia attraverso altri strumenti interni, compresa la capacità di comunicare con altre tecnologie (in particolar modo tecnologie assistive).

Tre raccomandazioni del W3C per tre diversi destinatari e tre diversi oggetti da rendere accessibili... Le cose cominciano a complicarsi un po’: l’accessibilità, dunque, non è solo la proprietà di un contenuto reso accessibile seguendo le WCAG, ma anche la proprietà di uno strumento autoriale accessibile secondo le indicazioni delle ATAG e la proprietà di un programma utente (un browser, per esempio) accessibile secondo le indicazioni delle UAAG.

E non è finita: c’è un’altra distinzione di cui occorre tenere conto. La medesima parola “accessibilità” viene usata spesso per indicare non l’essere accessibile di un contenuto o di un programma, ma l’insieme di linee guida, raccomandazioni, suggerimenti, tecniche, per produrre contenuti accessibili, strumenti autoriali accessibili, programmi utente accessibili. Il titolo stesso del libro che avete tra le mani è un esempio di questa seconda accezione della parola “accessibilità”: si riferisce infatti all’accessibilità come materia, come insieme di raccomandazioni e tecniche di sviluppo, non all’accessibilità come proprietà di un contenuto o di un programma.

Un’ultima e importante distinzione da tener presente è che l’accessibilità di cui si occupano le raccomandazioni del W3C, e anche questo libro, riguarda esclusivamente il mondo digitale: i contenuti e i programmi che le linee guida W3C mirano a rendere accessibili, anche quando possono essere utilizzati offline (cioè non connessi a Internet), come per esempio un CD-ROM, sono e rimangono oggetti digitali, fatti di bit, nati per essere fruiti per mezzo di attrezzature elettroniche e digitali, o comunque per mezzo di strumenti in grado di interfacciarsi con attrezzature elettroniche e digitali. Tutto ciò che riguarda invece l’accessibilità del mondo fisico – barriere architettoniche, ingressi per disabili, scivoli, parcheggi riservati, servizi igienici speciali ecc. – non ha nulla a che fare con l’accessibilità promossa dal W3C e rimane completamente al di fuori dell’argomento di questo libro.

Inizio pagina

Esempi di contenuti inaccessibili

Dopo aver esaminato in lungo e in largo i significati delle parole “accessibile” e “accessibilità”, è tempo di passare dalla teoria alla pratica, mostrando alcuni esempi di contenuti poco o nulla accessibili: il loro scopo è illustrare a grandi linee il tipo di “malattia” di cui l’accessibilità può essere considerata la cura.

La navigazione “invisibile”

Cominciamo con quelli che sembrano dei normali menu di navigazione, tratti dal sito web del Comune di Marcianise .

La pagina mostrata in Figura 1.1 B è stata ottenuta usando una funzione presente in un’estensione del browser Firefox chiamata Web Developer Toolbar (esamineremo l’estensione nel Capitolo 22). La funzione utilizzata sostituisce ogni immagine nel documento con i corrispondenti testi alternativi. Il motivo per cui tutti i menu e i titoli visibili in Figura 1.1 A scompaiono una volta attivata questa funzione è che ognuno di questi elementi è composto da oggetti grafici che, nel codice di marcatura, sono privi di testo alternativo.

È accessibile un sito di questo tipo? Purtroppo no, perché, senza immagini e senza testi alternativi, scompare il contenuto, come i desolati spazi bianchi di Figura 1.1 B eloquentemente dimostrano. Senza testi alternativi, il contenuto delle immagini rimane ignoto per chi non può vederle.

Siamo fiduciosi che il nuovo sito del Comune di Marcianise, che nella home page del sito attuale è dichiarato in allestimento, conterrà opportuni testi alternativi per i contenuti grafici, risolvendo quello che è in assoluto uno dei problemi più gravi nel campo dell’accessibilità.

Il Capitolo 4 del libro è dedicato a una dettagliata analisi dei vari tipi di alternative che è possibile fornire per i contenuti web non testuali.

Inizio pagina

Non si finisce mai di installare...

Uno degli ostacoli più subdoli che si frappongono tra l’utente e i contenuti del Web sono i moduli aggiuntivi che spesso occorre installare, per poter fruire di determinati contenuti codificati con linguaggi che i browser non sono in grado di interpretare nativamente.

Un caso tipico è illustrato in Figura 1.3. Nella home page del sito web del Comune di Buggiano è presente sulla destra un blocco che rimane vuoto al caricamento della pagina, se nel computer che si sta utilizzando non è installato un modulo per la gestione di contenuti Java.

Il browser che abbiamo utilizzato per questa prova, Firefox 2.0.0.4, cerca di venire incontro all’utente, localizzando da solo il programma accessorio adatto a visualizzare i contenuti mancanti. All’utente resta però l’obbligo di attivare il meccanismo d’installazione e, soprattutto, l’incombenza di comprendere il senso dell’avvertimento lanciato dal browser: Fare clic qui per scaricare il plugin (la frase è circondata nell’immagine da un ovale). Un avvertimento di analogo significato viene mostrato anche nella riga alla sommità della pagina web (Per visualizzare i contenuti di questa pagina sono richiesti dei plugin aggiuntivi).

Purtroppo il linguaggio adoperato è tutt’altro che chiaro per un utente alle prime armi, il quale sa senz’altro cosa vuol dire “fare clic”, ma ignora con altrettanta certezza cosa sia un plug-in, termine tecnico per la cui definizione rimandiamo al Glossario disponibile online.

Posto che la curiosità porti l’utente ad avviare l’installazione anche se non ha capito bene cosa sta facendo, quello che succede dopo non è davvero il massimo dell’accessibilità. Si apre la finestra Servizio recupero plugin, mostrata in Figura 1.3, che offre la scelta di scaricare qualcosa che si chiama Java Runtime Environment, oggetto sconosciuto per chiunque non si interessi più o meno attivamente di informatica e di tecnologie per il Web.

Molti utenti inesperti si fermerebbero a questo punto, temendo di compiere operazioni potenzialmente dannose per il buon funzionamento del computer, ma noi non ci spaventiamo e, nonostante l’ulteriore avvertimento che dice: Alcuni plugin potrebbero richiedere informazioni aggiuntive durante l’installazione, premiamo il pulsante Avanti.

Si apre una nuova finestra chiamata Installazione software (Figura 1.4), contenente messaggi ancora più preoccupanti: l’utente viene avvertito che il software di cui è richiesta l’installazione non è firmato e che si dovrebbe installare esclusivamente software proveniente da siti fidati. L’effetto di simili messaggi su qualcuno che non sappia cosa sia Java Runtime Environment né se il fornitore possa essere annoverato tra i “siti fidati” è facilmente immaginabile. Comunque, poiché siamo temerari (in realtà sappiamo che Java non costituisce un pericolo per la sicurezza), premiamo il pulsante Installa adesso.

L’installazione automatica, tuttavia, fallisce perché, per qualche ragione che non conosciamo, il plug-in individuato da Firefox non risulta disponibile, come avverte la finestra di dialogo mostrata in Figura 1.5.

Occorre allora provare l’installazione manuale, la quale crea problemi molto complessi a un utente con scarse competenze informatiche, soprattutto se la navigazione avviene attraverso tecnologie assistive.

La pagina del sito Sun, il produttore di Java a cui si viene rimandati, contiene infatti numerose scelte, tra le quali è possibile orientarsi solo se si ha una conoscenza relativamente approfondita delle caratteristiche del proprio sistema operativo (per esempio se è un sistema Windows a 32 o a 64 bit). Scegliamo di scaricare una versione del software per Windows, ma otteniamo alla fine del procedimento un altro errore, di cui rendono conto le due finestre di dialogo mostrate in Figura 1.6.

Non è questa la sede per chiarire il tipo di errore (-203) verificatosi. La cosa importante ai fini dell’accessibilità è comprendere che la fruizione di contenuti codificati con linguaggi che il browser non interpreta nativamente richiede all’utente l’esecuzione di un procedimento complesso, per il quale occorrono competenze informatiche non banali, e che, soprattutto, può non andare a buon fine.

Procedure e comportamenti dei browser, di fronte alla necessità di installare programmi accessori, sono i più diversi, il che contribuisce a spiazzare l’utente. Di fronte al medesimo plug-in mancante, Internet Explorer 7 ha mostrato semplicemente il blocco di contenuti vuoto, senza accompagnarlo con alcun messaggio per l’utente.

Opera 9.21, invece, ci ha guidato a un’installazione del programma accessorio relativamente semplice, completata con successo (Figura 1.7). Tra l’altro, il messaggio di avviso presentato da Opera è dei più chiari e ci sembra alla portata anche di un utente alle prime armi (Per visualizzare l’intero contenuto di questa pagina è necessario installare Java. Si desidera scaricarlo adesso?).

Finalmente, riusciamo con Opera a visualizzare il contenuto nel blocco Java presente nella home page del Comune di Buggiano. Si tratta di una foto, che cambia a ogni caricamento di pagina (visibile in Figura 1.8, circondata dall’ovale).

Questo lungo resoconto ci è servito per dimostrare con un esempio pratico quanto possa essere difficile fronteggiare l’installazione nei browser di programmi accessori (i cosiddetti plug-in). Tale difficoltà riguarda sicuramente gli utenti con scarse conoscenze informatiche, ma riguarda anche gli utenti disabili che sono costretti a usare tecnologie assistive che non consentono di avere una visione d’insieme di ciò che accade sullo schermo.

Un caso esemplare è quello degli utenti sordociechi, che accedono ai contenuti di una pagina web, messaggi di avviso compresi, tramite un display Braille che legge una riga di testo alla volta: si veda il Capitolo 2 per informazioni su questa tecnologia, ma si rilegga soprattutto la testimonianza di Antonio Russo, riportata nell’Introduzione, per capire fino a che punto possa essere disorientante scontrarsi con la richiesta, proveniente dal browser o dal sistema operativo, di installare programmi dei quali non si conoscono in anticipo lo scopo, le funzionalità e le modalità d’installazione.

Con questo non intendiamo condannare come inaccessibile tout court l’inserimento in una pagina web di contenuti che, per essere utilizzati, richiedono l’installazione di programmi accessori. Ci sembra, tuttavia, incontestabile che le operazioni di ricerca e installazione di tali programmi rendono più complesso, talvolta troppo complesso, soprattutto se si è utenti con disabilità, il normale uso di un sito web. Ciò dovrebbe indurre i produttori di contenuti accessibili a ridurre allo stretto necessario l’inserimento di oggetti codificati in formati che i browser non sono in grado di interpretare nativamente.

Per il momento, almeno finché non saranno stati resi pubblici quegli elenchi di tecnologie con supporto per l’accessibilità a cui fanno riferimento le linee guida WCAG 2.0 (si veda in proposito il Capitolo 20), è lasciata alla sensibilità e all’esperienza degli sviluppatori, e spesso alle disponibilità economiche del momento, la scelta di quali tecnologie utilizzare nel costruire le proprie pagine web.

In molti casi però – è bene saperlo – sono disponibili soluzioni semplici, che non richiedono all’utente di installare programmi accessori e che, allo stesso tempo, non penalizzano né l’estetica né il contenuto informativo. Per ritornare all’esempio mostrato in questo paragrafo, è possibile visualizzare in un riquadro una serie casuale di immagini prelevate da un archivio senza costringere l’utente a installare un’estensione Java per il proprio browser. Uno degli strumenti adatti allo scopo è JavaScript, che è supportato nativamente da tutti i browser grafici recenti e meno recenti; meglio ancora, uno script lato server (PHP, ASP ecc.) permetterebbe di ottenere il medesimo risultato anche in un browser grafico che avesse il supporto per JavaScript disabilitato.

Inizio pagina

Amici di un solo browser

Chi prova a consultare con un browser che non sia Internet Explorer i registri della mortalità per tumore in Liguria , tenuti dall’Istituto Nazionale per la Ricerca sul Cancro di Genova, si trova di fronte alla pagina mostrata in Figura 1.9. Qualsiasi sforzo di accedere ai contenuti del sito è inutile: non c’è infatti un solo collegamento o pulsante che permetta una sia pur limitata forma di navigazione. Naturale chiedersi se serva a qualcosa una pagina del genere.

Il mistero è risolto, se si prova a visitare il sito con Internet Explorer. Dall’alto e dal basso, con agili movimenti, piovono scritte e collegamenti, visibili in Figura 1.10. Diventa così possibile consultare le sezioni “Eventi” e “Didattica”, oltre che i registri “Mortalità”, “Tumori”, “Tumori origine professionale” e “Mesoteliomi”. Diventa persino possibile visitare una versione in inglese del sito.

Perché questa differenza di comportamento tra i browser? Perché chi ha progettato il grazioso effetto di comparsa animata dei link, ha pensato bene di utilizzare allo scopo una funzione JavaScript, datata nella concezione e tarata per funzionare con Internet Explorer ma non con altri browser oggi in uso, come per esempio Firefox e Opera.

Del resto, l’inclinazione degli autori del sito per i browser di casa Microsoft è intuibile dal pie’ di pagina, che annuncia una visione ottimale con Internet Explorer dalla versione 4 in poi, alla risoluzione di 1024×768 pixel.

È quasi superfluo aggiungere che un simile modo di costruire un sito web è tutto meno che accessibile. Sono almeno tre gli errori di accessibilità che meritano di essere segnalati. È sbagliato vincolare l’accesso ai contenuti:

1. alla disponibilità del supporto per JavaScript;
2. all’uso di un determinato browser;
3. a una particolare risoluzione (il che vale soprattutto per i contenuti interni del sito del registro tumori, che sono strutturati a frame).

Come spiegheremo nei capitoli successivi, l’accessibilità dei contenuti web è strettamente legata alla possibilità che essi siano fruibili in maniera indipendente dal dispositivo. Per una trattazione approfondita di tale concetto, rimandiamo alla lettura della parte conclusiva del Capitolo 2 Superare i limiti della carta stampata.

Inizio pagina

L’arcano dei nomi dei frame

Il sito www.urbinoeprovincia.com offre una quantità di materiali utili sulla città di Urbino e dintorni (storia, università, arte, annunci pubblicitari ecc.). Il sito, tuttavia, è costruito con una complessa struttura a frame, che, per essere accessibile, avrebbe richiesto l’uso di alcune precauzioni, che invece mancano.

La home page contiene infatti ben nove elementi IFRAME, i cui contenuti sono prelevati da altrettante pagine web esterne: in un browser grafico, gli IFRAME vengono visualizzati come riquadri all’interno della pagina contenitore, indistinguibili dal contenuto che fa parte nativamente di quella.

Invece, navigando con un browser testuale, ciò che l’utente incontra è soltanto il nome dei frame, che nel caso del sito in questione non è significativo. Il contenuto di ogni frame può essere poi raggiunto seguendo il collegamento posto sul nome stesso del frame.

Un esempio è mostrato in Figura 1.11. Il riquadro evidenziato dall’ovale nella vista grafica corrisponde all’IFRAME di cui, nella pagina caricata nel browser testuale Lynx, appare solo il nome “I4”. Tale nome è ricavato automaticamente dall’attributo name, che il browser testuale estrae dal codice di marcatura allo scopo di fornire al lettore una qualche informazione utile in merito al frame.

Se gli autori del sito avessero curato di più l’accessibilità, avrebbero dato un titolo significativo a ciascun elemento IFRAME. Invece, non solo questi titoli mancano, come mostra la finestra di dialogo in Figura 1.12, ma è stata aggiunta a ciascun frame un’informazione testuale che serve solo a mettere fuori strada il lettore che usa browser alternativi (Questa pagina contiene frame; il tuo browser non li supporta).

È vero che un browser testuale come Lynx non può mostrare il contenuto di un frame direttamente all’interno del documento contenitore, ma ha comunque una forma di supporto per i frame: permette, infatti, di raggiungerne i contenuti, anche se, per una navigazione efficace, è importante che i frame abbiano nomi significativi.

In conclusione, è preferibile per l’accessibilità evitare in generale i siti costruiti a frame, perché sono macchinosi e difficili da navigare con browser alternativi e screen reader. Tuttavia tali siti possono essere resi discretamente accessibili con un’organizzazione razionale dei contenuti e inserendo nomi e descrizioni dei frame. Non serve, invece, fornire messaggi che dichiarano una presunta mancanza di supporto, come avviene nel sito che abbiamo preso ad esempio. Simili messaggi possono solo infastidire chi naviga con strumenti alternativi: presuppongono, infatti, che l’unica navigazione possibile sia quella in modalità grafica, il che è profondamente contrario agli scopi e ai metodi dell’accessibilità.

Inizio pagina

Quell’articolo che non arriva mai

La Figura 1.13 mostra una schermata tratta dal sito web di Repubblica.it. È un breve articolo su una notizia di cronaca, visualizzato tramite uno dei browser grafici più diffusi (Internet Explorer 6 su Windows XP): una situazione di consultazione davvero comune, che sembra non presentare alcun problema per l’utente.

La lettura dell’articolo diventa però molto più lenta e faticosa se, invece di usare un browser grafico, dobbiamo ascoltare serialmente, cioè uno dopo l’altro, tutti i contenuti della pagina per mezzo di uno screen reader (per informazioni su questa e altre tecnologie assistive, si veda il Capitolo 2).

Un’approssimazione dell’effetto ci è data dall’uso del solito browser testuale. La Figura 1.14 mostra lo stesso breve articolo caricato in Lynx. Occorre arrivare addirittura alla quinta schermata, su sei complessive, prima di trovare il contenuto principale del documento, cioè l’articolo intitolato Norvegia: scatta l’allarme, spento reattore. Ciò significa che un utente non vedente interessato a leggere questa notizia, se non è particolarmente esperto di scorciatoie e comandi alternativi per velocizzare la navigazione, è costretto ad ascoltare pazientemente un interminabile rosario fatto di oltre sessanta “grani”, tra menu e sottomenu di navigazione, informazioni pubblicitarie e campi modulo, prima di arrivare alla lettura del contenuto che gli interessa.

La tortura acustica di ascoltare oltre sessanta elementi di navigazione prima di arrivare al contenuto vero e proprio potrebbe essere facilmente evitata all’utente, inserendo un cosiddetto link di salto (skip link) proprio all’inizio del documento: un banale collegamento ipertestuale interno, del tipo “Vai all’articolo”, ancorato al titolo dell’articolo medesimo. Il punto di controllo 13.6 delle WCAG 1.0 – le già citate linee guida per l’accessibilità dei contenuti web – suggerisce appunto di creare meccanismi per saltare gruppi ripetitivi di link (si veda sull’argomento il paragrafo Meccanismi per saltare gruppi di contenuti ripetitivi, nel Capitolo 18).

Inizio pagina

La balena nella scatola di tonno

Prendiamo a prestito dall’amico Franco Frascolla, ipovedente e studioso dei problemi di navigazione legati all’ipovisione, la metafora che dà il titolo al paragrafo (per una sintesi dei problemi di navigazione degli ipovedenti, si veda la testimonianza di Frascolla nel Capitolo 2).

La balena della metofora è una pagina web inverosimilmente affastellata di contenuti, soprattutto collegamenti ipertestuali, pigiati l’uno contro l’altro in spazi spesso ridottissimi, con testi scritti per lo più con caratteri microscopici. La scatola di tonno è il contenitore, o più precisamente l’interfaccia utente attraverso la quale la “balena” incontra l’utente. Nel caso di un ipovedente, per esempio, tutto il corpo della “balena”, ridotto per così dire a “tranci”, deve passare attraverso la piccola zona di schermo che l’ingranditore (che funge da “scatola di tonno”) riesce di volta in volta a visualizzare.

È possibile intuire le difficoltà che deve fronteggiare un utente che naviga con un ingranditore di schermo nel cercare di leggere una pagina concepita in stile “balena”, osservando con attenzione la Figura 1.15.

La figura mostra una situazione di navigazione tipica per un utente ipovedente. Uno schermo impostato alla risoluzione di 1280×1024 pixel è suddiviso orizzontalmente in due metà: nella parte superiore, grazie al software di ingrandimento incluso in Windows Vista, viene visualizzata, ingrandita di tre volte, una parte del contenuto visibile nella parte inferiore dello schermo.

I tre rettangoli di evidenziazione applicati sulla figura mostrano visivamente quanto è grande l’area di schermo che viene letta con l’ingranditore rispetto all’area visualizzata dal browser nella parte inferiore dello schermo e, soprattutto, rispetto all’area complessiva occupata dal blog Macchianera , a cui abbiamo attribuito in questo esempio il ruolo della balena.

Ci perdonerà l’autore di questo interessantissimo blog, che leggiamo da anni, per averlo tirato in ballo come esempio di inaccessibilità, ma Macchianera è, tra i siti italiani più noti, quello che probabilmente si presta meglio a illustrare il concetto che stiamo cercando di spiegare: con un’area di sei milioni e cinquecentomila pixel, corrispondente a un rettangolo di 1000 pixel orizzontali per 6500 pixel verticali, con i suoi circa 700 link, le 972 righe sviluppate nel browser testuale Lynx, gli oltre 400.000 byte di peso totale per 60 oggetti complessivi (sommando testo, immagini, script, fogli di stile ecc.), che richedono 78 secondi e mezzo per il caricamento completo con un modem a 56 Kbps, la home page di Macchianera è veramente una balena del Web.

Per coprire completamente una pagina di queste dimensioni con riquadri uguali all’area dello schermo occupata nel nostro esempio dall’ingranditore, servirebbero novanta (!) riquadri, e ancora resterebbe fuori qualcosa. E questo è solo l’aspetto matematico della questione. Dobbiamo considerare, poi, l’aspetto funzionale: navigando con un ingranditore, è difficile gestire lo scorrimento verticale della pagina nel browser e, soprattutto, è difficoltosa la lettura dei testi, quando le righe sono più larghe dell’area coperta dall’ingranditore (come si vede chiaramente in Figura 1.15). Non parliamo poi della difficoltà di “maneggiare” effetti particolari, come le finestre di anteprima che si aprono al passaggio del puntatore su alcuni collegamenti e che rimangono quasi sempre parzialmente o totalmente al di fuori dell’area coperta dall’ingranditore.

Leggere pagine “balena” non è un problema solo per gli ipovedenti, ma anche per altri tipi di utenti con disabilità. Scorrere, infatti, 700 collegamenti ipertestuali su 972 righe di testo con un sintetizzatore vocale o, peggio ancora, con una barra Braille, è un’impresa titanica e, ancor più, lo è trarre da una simile navigazione un’idea unitaria della pagina o informazioni mnemonicamente riutilizzabili, soprattutto quando i contenuti non sono stati opportunamente strutturati né trattati per l’accessibilità. E altrettanto titanica è l’impresa di navigare interamente una pagina “balena” se si è affetti da disabilità motorie: è impensabile, infatti, che una persona a cui ogni singola pressione di un tasto richiede uno sforzo fisico possa premere centinaia di volte di seguito il tasto Tab, per scorrere i vari collegamenti nel tentativo di selezionare quelli di proprio interesse.

Insomma, una pagina web è tanto più inaccessibile quanto più è affastellata di contenuti, soprattutto se questi contenuti sono stati assemblati senza considerare le limitazioni a cui è soggetto chi naviga con tecnologie assistive. Ci riferiamo in particolare alla lentezza della navigazione, alla difficoltà di formarsi un’idea precisa della composizione e dell’ordine dei contenuti, alla difficoltà di isolare e selezionare ciò che interessa.

Il concetto di fondo che ci preme sottolineare è che l’accessibilità non riguarda soltanto la possibilità tecnica di accedere a un contenuto per mezzo di uno strumento (da questo punto di vista chi naviga con un ingranditore di schermo è più o meno sullo stesso piano di chi non ne fa uso), ma riguarda anche la facilità e l’efficienza dell’accesso, due condizioni che non è possibile non considerare.

Ricorrendo a un paragone, un conto è togliere cinque litri d’acqua da un recipiente usando un grosso mestolo, un conto è togliere la stessa quantità d’acqua usando un cucchiaino da caffè. In certi casi navigare con una tecnologia assistiva equivale alla seconda condizione: le informazioni contenute nella pagina “balena” sono l’acqua da vuotare, e il cucchiaino da caffé è la porzione di schermo visibile attraverso l’ingranditore o la singola riga di testo per volta che è possibile scorrere con un display Braille.

Sta alla sensibilità e all’esperienza di chi si occupa di accessibilità all’interno di un progetto mantenere le pagine web entro limiti di complessità accettabili, che non pongano all’utente di tecnologie assistive sfide defatiganti.

Inizio pagina

La struttura che non c’è

Passiamo a un esempio tratto dal sito web del Corriere della Sera. La Figura 1.16 mostra un articolo dell’edizione online, visualizzato in un browser grafico. Basta uno sguardo veloce alla pagina per farsi un’idea del contenuto dell’articolo anche senza leggerlo.

Occhiello, titolo e sommario, infatti, formattati e spaziati con stili grafici diversi dal corpo del testo, risaltano all’occhio del lettore:

Relazione annuale del presidente dell’Antitrust (occhiello);

Banche e assicurazioni nel mirino del garante (titolo);

Secondo Catricalà emerge una “fitta rete di intrecci azionari che può evidenziare conflitti di ruolo” (sommario).

Il testo dell’articolo segue poi immediatamente sotto, a suggellare lo stretto rapporto tra gli elementi di titolazione e i paragrafi di testo che compongono l’articolo.

Chiediamoci ora: la struttura dell’articolo – in particolare la differenza tra occhiello, titolo e sommario – è ugualmente percepibile anche in modalità non grafica, cioè se la pagina viene letta con un browser testuale o con uno screen reader? Purtroppo no, come si evince dalla Figura 1.17, che mostra l’inizio dello stesso articolo in una schermata del browser testuale Lynx.

Perché in modalità testuale il titolo dell’articolo non è più riconoscibile come tale? E perché, poi, il testo non segue più occhiello, titolo e sommario, come avviene invece nella vista grafica del documento?

A causa di alcuni errori strutturali, che risaltano scorrendo il codice di marcatura. Senza addentrarci in un discorso troppo tecnico, gli errori di accessibilità che ci interessa segnalare sono due:

1. i contenuti testuali non sono marcati con gli appropriati elementi strutturali di HTML. Il titolo dell’articolo è marcato con un DIV invece che con un elementoH1; i titoletti interni sono marcati con SPAN; non c’è una divisione in paragrafi del contenuto dell’articolo, che è racchiuso in un unico DIV, le cui suddivisioni interne sono separate solo graficamente per mezzo di elementi BR;
2. la sequenza dei contenuti nel codice di marcatura non rispecchia l’ordine logico. Il blocco degli strumenti (“Versione stampabile”, “I più letti”, “Invia questo articolo”) non fa parte logicamente dell’articolo e perciò, nella vista grafica, appare correttamente decentrato sulla destra. Questo blocco, però, è posizionato nel codice di marcatura tra il blocco del titolo e il testo dell’articolo ed è proprio in quella posizione innaturale, che spezza l’ordine di lettura, che chi naviga con un browser testuale o con una sintesi vocale lo incontrerà. Molto meglio sarebbe stato posizionare il blocco, a livello di codice, dopo la fine dell’articolo: grazie ai fogli di stile, sarebbe stato comunque possibile farlo “migrare” in un qualsiasi altro punto della pagina grafica, ritenuto esteticamente e funzionalmente appropriato.

Entrambi gli errori segnalati fanno capo a un medesimo e più generale errore di accessibilità: quello di ritenere che l’unica struttura che si possa e si debba attribuire ai contenuti di una pagina web sia la struttura che è visibile in modalità grafica. In altre parole, l’errore consiste nel pensare che formattazione e struttura possano coincidere, che basti per esempio imporre il grassetto e un corpo più grande a una certa stringa di testo per aver fatto un titolo.

Purtroppo un simile errore è molto diffuso e penalizza gravemente l’accessibilità dei contenuti, dal punto di vista di chi naviga con uno screen reader. La navigazione con questa tecnologia assistiva, infatti, beneficia grandemente della presenza di una marcatura strutturale, cioè dell’uso di elementi HTML o XHTML che identificano esattamente la funzione logica svolta da un certo blocco di contenuto. Per esempio, se tutti i titoli di una pagina sono marcati con gli opportuni elementi H1-H6, l’utente di screen reader dispone di comandi per saltare agevolmente dall’uno all’altro, il che gli consente di farsi un’idea generale dei contenuti del documento e di poter scegliere rapidamente quale sezione della pagina leggere. Al contrario, se i titoli sono tali solo graficamente, come accade per gli articoli nel sito del Corriere della Sera, allora all’utente di screen reader non resta che ascoltare pazientemente tutta la pagina, non avendo strumenti per ricavare in modo rapido l’ordine e la struttura dei contenuti.

Inizio pagina

O vedi o non accedi

L’accessibilità ha da qualche anno un nemico con un nome difficile. Si chiama CAPTCHA, acronimo di Completely Automated Public Turing Test to Tell Computers and Humans Apart. In breve, si tratta di un sistema di verifica automatica, presente a completamento di una gran quantità di moduli di iscrizione a servizi online, che serve per discriminare se chi sta cercando di iscriversi è un umano oppure un computer. Solo l’umano viene accettato come iscritto: lo scopo è impedire l’iscrizione a robot che mirano a carpire dati privati o a riempire i siti di pubblicità indesiderata.

Un CAPTCHA si presenta di solito all’utente come un’immagine bitmap nella quale sono tracciati segni poco leggibili, che formano una parola o una serie di numeri privi di senso compiuto. Data la notevole quantità di elementi grafici di disturbo messi ad arte, si presume che solo un umano sia in grado di decifrare il testo nascosto e di copiarlo nel campo modulo a ciò predisposto: se il codice immesso dall’utente corrisponde a quello nell’immagine bitmap, l’iscrizione va a buon fine.

È evidente che un simile sistema penalizza gli ipovedenti, i ciechi ai colori e soprattutto i non vedenti. Le persone con tali disabilità in genere possono completare l’iscrizione solo con l’aiuto di qualcuno che abbia una vista normale, il che va contro qualsiasi raccomandazione di accessibilità. In Figura 1.18 è mostrato il modulo d’iscrizione al notissimo servizio di condivisione video di YouTube. In basso a destra, circondato dall’ovale, è visibile il riquadro con il codice del CAPTCHA. Subito sotto compare una sorta di aiuto: il link “Non riesci a leggere?”. Attivandolo, si cambia la combinazione di colori del CAPTCHA: può essere utile per chi soffre di cecità ai colori, ma è di nessun aiuto per i non vedenti, per i quali risulta perciò impossibile iscriversi da soli a YouTube (forse i gestori pensano che un cieco non sia interessato a iscriversi a un servizio di condivisione di brani audiovideo).

Da notare che altri grossi fornitori di servizi e contenuti web hanno già attivato procedure per rendere possibile l’iscrizione anche a chi non è in grado di decifrare visivamente il codice del CAPTCHA. Google, per esempio, ha reso disponibile in alternativa un brano audio contenente un codice equivalente, che può essere avviato cliccando sull’icona – abusata, sgradevole, ma in questo caso utile – di un omino in carrozzella.

Soluzioni per rendere accessibili i CAPTCHA fortunatamente esistono e ne discuteremo nel Capitolo 4.

Inizio pagina

Cultura gratis, ma solo per chi ha occhi buoni

Non sempre Google riesce a evitare discriminazioni nella fornitura dei suoi molteplici servizi, uno dei più potenti dei quali è la Ricerca Libri, disponibile in versione beta (cioè non definitiva) all’URI http://books.google.com/ . Si tratta davvero di uno straordinario servizio, che offre la possibilità di consultare gratuitamente le pagine di un’immensa quantità di opere a stampa, per lo più in inglese, che da qualche anno Google sta digitalizzando, dopo aver stipulato complessi accordi con editori e biblioteche di tutto il mondo.

Cercando per esempio il nome “Einstein” su Ricerca Libri, vengono fuori ben 44.700 titoli. Restringendo la ricerca ai soli testi disponibili in versione integrale, si scende a 566 tra libri e riviste scientifiche, che pure non sono pochi: testi che l’utente – volendo – può leggere gratis, dalla prima all’ultima pagina, grazie a Google. Ma più che “volendo”, sarebbe meglio dire “potendo”. Il sistema di consultazione delle opere digitalizzate dal colosso di Mountain View è infatti, al momento, per chi soffre di problemi di vista, quanto di più inaccessibile si possa immaginare.

La Figura 1.19 cerca di dare un’idea della situazione: tutte le pagine digitalizzate sono disponibili solo come immagini bitmap, e per giunta con un livello di dettaglio piuttosto basso. I non vedenti sono esclusi completamente dalla lettura, non esistendo un sistema alternativo alle immagini per fruire dei testi (l’anteprima della pagina mostrata in figura non è selezionabile né copiabile né può essere letta da un sintetizzatore vocale).

Non resta che sperare che Google riesca a trovare un compromesso con biblioteche e case editrici, per fornire i libri in una modalità accessibile: è un gran peccato che un servizio così utile per la diffusione del sapere sia reso di proposito così poco fruibile e così discriminante per gli utenti con disabilità visive.

Inizio pagina

Scacco matto all’accessibilità

Non sono moltissimi i giochi disponibili sul Web che possono essere giocati da un non vedente o da un disabile motorio. La grande maggioranza di essi si basa infatti sulla coordinazione occhio-mano, come i classici sparatutto. C’è però un gioco antichissimo e nobile che sembra fatto apposta per essere giocato con soddisfazione anche da chi non può vedere o da chi non può usare il mouse: gli scacchi. Esiste infatti una semplicissima notazione, la scaccografia, che, associando le colonne alle lettere da A a H e le righe ai numeri da 1 a 8, proprio come nel gioco della battaglia navale, consente di identificare con precisione le caselle di partenza e di arrivo dei pezzi.

Vi sono campioni di scacchi che, usando questa notazione, sono in grado di giocare – e vincere – decine di partite alla cieca contemporaneamente. E vi sono innumerevoli siti web che permettono di giocare a scacchi contro il computer o contro avversari umani, grazie ad applet Java o altre applicazioni che creano interfacce utente che simulano una scacchiera, i cui pezzi possono essere mossi dai giocatori trascinandoli con il mouse dalla casella di partenza a quella di arrivo. Purtroppo però queste applicazioni sono spesso mute e inaccessibili per gli screen reader e impossibili da comandare da tastiera.

In Figura 1.20 è illustrato a titolo di esempio un gioco degli scacchi disponibile sul sito olandese Lokasoft. Navigando con uno screen reader, la scacchiera, generata da un’applet Java, è inutilizzabile: non viene fornita all’ascoltatore alcuna informazione contestuale né è possibile muovere i pezzi con comandi da tastiera.

Un gioco progettato evidentemente senza l’accessibilità in mente.

Inizio pagina

Multimedia senza alternative

Con la progressiva diffusione delle connessioni a banda larga, cresce esponenzialmente in Rete l’offerta di contenuti multimediali: telegiornali, notiziari radio, estratti dalle più seguite trasmissioni televisive, contributi audiovideo pensati esclusivamente per gli internauti, e così via. Cresce anche la qualità delle immagini e dell’audio, rendendo il Web – almeno per chi ha l’ADSL, la strumentazione hardware e software necessaria, vista e udito normali – un valido sostituto dell’informazione televisiva e radiofonica. Purtroppo però la quasi totalità dei fornitori di contenuti multimediali non si preoccupa di fornire alternative per chi non vede e/o non sente: mancano trascrizioni testuali, sottotitolazioni, informazioni contestuali di orientamento, manca spesso un’accettabile navigabilità da tastiera.

La Figura 1.21 mostra una schermata tratta da Rai.tv, corposo contenitore multimediale della RAI. I numerosi contributi audiovideo presenti nel sito, comprendenti interi cicli di trasmissioni, sono forniti all’interno di una complessa interfaccia Flash e non presentano né trascrizioni né sottotitolazioni.

Per una trattazione delle misure di accessibilità richieste per il Web multimediale, si vedano, nel Capitolo 4, i commenti ai punti di controllo 1.3 e 1.4 delle WCAG 1.0 e, nel Capitolo 19, il paragrafo La lingua dei segni, anzi le lingue dei segni.

Inizio pagina

La festa degli sfondi grafici

A parte l’uso di una struttura a frame, di per sé non consigliabile per l’accessibilità, il sito web del Consiglio di Stato e dei Tribunali Amministrativi Regionali presenta un’altra caratteristica esemplare dal punto di vista dell’inaccessibilità: la presenza costante di sfondi grafici sotto i testi (Figura 1.22).

Con la loro disomogeneità, gli sfondi grafici rendono impossibile garantire una leggibilità uniforme dei testi e penalizzano gravemente gli utenti affetti da disabilità visive. Non stiamo dicendo che gli sfondi grafici sono in assoluto nemici dell’accessibilità, ma che dovrebbero essere usati solo nelle parti della pagina che non contengono blocchi di testo. In altre parole, è di gran lunga preferibile per l’accessibilità che i testi siano posizionati su sfondi (ben contrastati) di colore uniforme.

Il Capitolo 5 è dedicato a una trattazione dettagliata delle regole per una gestione accessibile del colore e del rapporto tra primo piano e sfondo.

Inizio pagina

Prigionieri di un solo stile

Uno dei maggiori vantaggi del Web rispetto alla carta stampata – ne parleremo diffusamente alla fine del Capitolo 2 – è la possibilità di personalizzare l’esperienza di navigazione nei modi più disparati. Tra le personalizzazioni più utili, vi sono sicuramente le modifiche dei colori predefiniti di finestre, menu, testo e sfondi, nonché delle grandezze dei caratteri, che gli utenti con difficoltà visive possono impostare servendosi di numerosi software, tra cui sistemi operativi e tecnologie assistive.

I sistemi operativi Microsoft, per esempio, consentono di impostare una configurazione personalizzata (Figura 1.23), che influenza l’apparenza generale di tutte le finestre e dei loro contenuti, browser e pagine web compresi, basata sul contrasto invertito.

I siti web, per rimanere navigabili e leggibili anche se visti con configurazioni di colori a contrasto invertito, devono essere progettati con cognizione di causa, ovvero inserendo in anticipo opportune contromisure, che consistono essenzialmente in un uso accorto delle immagini e dei fogli di stile.

È tuttavia facile trovare sul Web siti che sono concepiti come se dovessero essere navigati esclusivamente con la combinazione di stili prevista dal progettista. Se l’utente personalizza gli stili, ovvero modifica i colori e la grandezza dei caratteri, rischia di non riuscire a leggere più nulla: un serio problema di accessibilità.

Le Figure 1.24 e 1.25 mostrano un caso esemplare: i contenuti del sito della Cassa nazionale di previdenza e assistenza forense sono chiaramente leggibili, se navigati usando gli stili grafici predefiniti. Basta però passare a una combinazione di colori a contrasto invertito per generare una vera e propria catastrofe dal punto di vista della leggibilità: finestre che diventano trasparenti e voci di menu che perdono lo sfondo contribuiscono a rendere completamente inaccessibili i contenuti.

Inizio pagina

I lampi della pubblicità

Un articolo di BBC News del 5 giugno 2007 avvisa i lettori che Un segmento del filmato animato che promuove le Olimpiadi del 2012 è stato rimosso dal sito web degli organizzatori dopo i timori che potesse scatenare crisi epilettiche (Figura 1.26).

L’articolo, disponibile all’indirizzo http://news.bbc.co.uk/2/hi/uk_news/england/london/6724245.stm , prosegue spiegando che Il prof. Graham Harding, che ha sviluppato il test usato per misurare i livelli di fotosensitività nel materiale televisivo, ha detto che [il filmato] non dovrebbe essere più trasmesso.

Il filmato incriminato, che chi non soffre di epilessia fotosensibile può visionare online sul sito di Repubblica.it , ha come idea portante l’inserzione di disegni geometrici dai colori vivaci all’interno di una serie di riprese che mostrano luoghi e persone in movimento. Il problema, dal punto di vista dell’accessibilità, è che i disegni geometrici compaiono nel filmato con dei lampeggiamenti rapidissimi, che, soprattutto quando si verificano entro un determinato spettro di frequenze, possono scatenare crisi epilettiche nei soggetti predisposti.

Tratteremo dettagliatamente l’argomento nel Capitolo 10. Per ora basti sapere che è un fondamentale requisito di accessibilità evitare di inserire in una pagina web oggetti lampeggianti. Purtroppo, si tratta di un requisito che è poco conosciuto e ancor meno rispettato.

In ambito Web, il settore che più spesso fa uso di oggetti lampeggianti è quello della pubblicità online. La cosa è del resto spiegabile. L’utente che apre una pagina web per leggere un articolo dispone la propria attenzione a ricercare e scorrere il testo dell’articolo, evitando il più delle volte deliberatamente di guardare gli oggetti accessori che riempiono la pagina. Chi acquista spazi pubblicitari tenta perciò di dirottare in ogni modo l’attenzione del lettore verso i propri striscioni pubblicitari (o banner, per usare il termine tecnico appropriato). E cosa c’è di meglio che una serie di lampi colorati per attirare l’attenzione di un lettore distratto?

Gli esempi da citare sarebbero innumerevoli, ma preferiamo non fare un’ulteriore pubblicità, per giunta gratuita, a prodotti e marche che non la meritano, visto il pericoloso espediente che adottano per reclamizzarsi sul Web.

Resta il fatto che, per un sito accessibile che affitta i propri spazi pubblicitari senza conoscere cosa precisamente esporranno gli inserzionisti, esiste il rischio reale di veicolare attraverso le proprie pagine materiali dannosi per la salute degli utenti. Sarebbe auspicabile, pertanto, che i gestori di siti accessibili stabilissero, nei loro contratti con i fornitori di pubblicità, dei vincoli ben precisi per la realizzazione di banner pubblicitari. Tra i vincoli dovrebbe essere inserito il divieto di introdurre oggetti lampeggianti alle frequenze pericolose o, in subordine, comandi per consentire all’utente di fermare o saltare movimenti e lampeggiamenti, prima che possano indurre crisi epilettiche.

Inizio pagina

Linguaggi ai confini della realtà

Finora abbiamo presentato esempi di inaccessibilità che riguardano la struttura dell’interfaccia utente e la mancanza di valide alternative per alcuni tipi di contenuto: fattori che influenzano, cioè, la percepibilità dei contenuti da parte dell’utente. L’accessibilità, però, come è stato spiegato all’inizio del capitolo, riguarda anche (e forse soprattutto) la comprensibilità dei contenuti.

Completiamo, dunque, il capitolo con alcuni esempi che illustrano le oscurità in cui si avvitano alcuni linguaggi settoriali, molto usati sul Web. Da tali oscurità derivano difficoltà di accesso non solo per gli utenti con problemi cognitivi, ma anche per chiunque abbia uno scarso livello di competenza linguistica generale o, più semplicemente, sia nuovo della materia.

Si tratta di oscurità che potrebbero senz’altro essere eliminate, se solo ci fosse negli autori la consapevolezza del problema e la volontà di scrivere in maniera accessibile (comprensibile).

Il burocratese

Con il termine “burocratese” s’intende la degenerazione del linguaggio formale con cui le Pubbliche Amministrazioni comunicano tra loro e con il cittadino. Il burocratese è un indigesto pastone, fatto di impersonale solennità, di sintassi contorta, di qualche tecnicisimo necessario (cioè parole che hanno uno specifico significato e che non possono essere sostituite con altre di uso comune) e di molti tecnicismi collaterali inutili.

Abbiamo trovato di recente uno splendido esempio di burocratese, quasi un inno al tecnicismo collaterale, in un libro di grande successo, La casta di Luigi Rizzo e Gian Antonio Stella (Rizzoli, 2007). Vale la pena di riportare integralmente il capoverso in cui compare l’esempio (pag. 181):

Vanno matti, in Sicilia, per le consulenze. Un giorno, davanti al diluvio di oltre 200 esperti esterni pagati da una Regione che ha già 16.000 dipendenti, il difensore civico Lino Buscemi ha preso carta e penna e chiesto quanto venissero pagati. La risposta di Salvatore Taormina, capo di gabinetto della presidenza della Regione, resta immortale. E merita di essere riportata integralmente, punteggiatura compresa: In merito a quanto richiesto con la nota in riferimento, di cui all’oggetto, indirizzata anche ai destinatari della presente, si richiede alla S.V. di far conoscere allo scrivente ufficio il contenuto delle indicazioni operative sulla scorta delle quali l’ufficio richiedente ha ritenuto di avviare il processo ricognitivo di cui in oggetto. Ciò nella considerazione che le attivazioni inerenti la fattispecie in parola – in ragione della loro delicatezza e complessità correlabile, anche, alla disomogeneità funzionale degli atti che avviano i rapporti privatistici di interesse per la norma in oggetto – di certo, necessitano di opportuni approfondimenti tesi a focalizzare sia il reale ambito di riferimento operativo, sia il soggetto, per opportunità sistematica, competente alla trattazione, sia le modalità procedurali da attivare conseguentemente. In tal senso, le indicazioni operative di cui in premessa, laddove rese, risulteranno stimolo di riflessione prezioso per le determinazioni presidenziali che si riterranno opportune.

La risposta del capo di gabinetto Salvatore Taormina, epurata dalle contorsioni linguistiche in cui è avvolta, si potrebbe riassumere brevemente così: Fammi capire bene perché vuoi sapere quanto paghiamo i consulenti esterni. In base a ciò che mi dirai, rifletteremo col presidente sulla migliore risposta da darti. È chiaro che in un caso del genere l’oscurità del burocratese è un mezzo per un fine: tergiversare il più possibile di fronte alla richiesta di trasparenza delle informazioni sui pagamenti, richiesta dal difensore civico.

Il problema è che, in un Web veramente accessibile, per il burocratese – qualsiasi sia la sua giustificazione: tentativo di rimestare le acque o semplice abitudine – non dovrebbe esserci posto. I rappresentanti delle amministrazioni pubbliche dovrebbero profondere ogni sforzo nel cercare di semplificare il linguaggio con cui, attraverso migliaia di siti web, si rivolgono quotidianamente ai cittadini.

Molto per la verità si è già fatto, a partire dagli anni Novanta del secolo scorso e indipendentemente dall’accessibilità del Web, anche grazie a interventi diretti dei governi, consapevoli dell’assoluta necessità di rendere più semplici le comunicazioni tra amministrazioni e cittadini. Ma molto resta ancora da fare: chi scrive per conto di ministeri, comuni ed enti continua a usare un linguaggio che spesso è contorto e poco accessibile, riempiendo gli archivi dei siti web di leggi, regolamenti, circolari, determine e risposte al cittadino che tutto sono fuorché semplici e chiare.

Uno tra i numerosissimi esempi possibili ci viene dal sito della Federazione Regionale degli Ordini degli Architetti del Veneto. È una risposta a un quesito di un cittadino , fornita da un responsabile della Direzione Regionale del Veneto dell’Agenzia del Territorio:

A seguito della nota sopra evidenziata relativa all’oggetto, si informa la S.V. che la scrivente ha trasmesso una direttiva a tutti gli Uffici di propria competenza precisando che, poiché nelle relative norme non è specificato quale debba essere il tipo di supporto che deve contenere la copia dell’estratto autenticato della mappa catastale, non si intravede alcun motivo ostativo all’accettazione, da parte degli stessi uffici, di tale copia su supporto opaco.

Può sembrare incredibile, ma vuol dire semplicemente che l’amministrazione accetta le fotocopie delle mappe catastali. Il burocratese – che Calvino definiva giustamente un’antilingua – ripudia le formule semplici e chiare. Piuttosto che scrivere un banale “si accettano”, il burocrate preferisce avvitarsi nella pesante oscurità di “non si intravede alcun motivo ostativo all’accettazione”. Ne deriva una semplice equazione: più burocratese = meno accessibilità.

Informazioni e suggerimenti per scrivere in maniera accessibile costituiscono l’argomento della prima parte del Capitolo 19 di questo libro.

I linguaggi settoriali della scienza e della tecnologia

Un cenno meritano anche i linguaggi settoriali della scienza e della tecnologia. Dove non esistono glossari, note e chiarimenti, si rischia il buio totale della comprensione, se non si è più che addentro alla materia. Un esempio, tratto da un noto sito specializzato nella valutazione di componenti di computer, aiuterà a capire il senso della precedente affermazione:

Mentre la velocità di default di tutti i processori Socket 939 è di 200 MHz e il moltiplicatore di 5x è applicato per raggiungere i 1000 MT/s (equivalente a 1000 MHz) per direzione (2000 MT/s o 2000 MHz bidirezionali), molte motherboard Socket 939 recenti basate sugli attuali chipset permettono un considerevole overclock. Abbiamo bloccato il moltiplicatore del processore a x6 per evitare di overcloccare mentre constatavamo la velocità di clock più elevata impostabile. Lasciando il Link HTT in automatico, abbiamo effettuato lievi regolazioni al bus HyperTransport.

Come è facile constatare, si tratta di una terminologia del tutto inaccessibile ai non iniziati: per chi non ha idea di cosa siano processori, moltiplicatori, motherboard, chipset, clock e overclock (da cui il neologismo “overcloccare”), si ha quasi l’impressione di trovarsi di fronte a un codice cifrato. Se un sito web che tratta simili argomenti aspira all’accessibilità, è indispensabile che i suoi autori corredino gli articoli di dettagliati glossari e di rimandi contestuali ad appositi articoli per principianti.

Inizio pagina