Capitolo 2

Tutti coloro che si occupano della creazione di documenti HTML e più in generale della gestione di interi siti Web devono, una volta definiti i contenuti, avviare uno studio che porti alla definizione di modalità di presentazione tali da rendere interessante ed attraente la navigazione. Questo obiettivo, che può essere conseguito sfruttando adeguatamente gli strumenti messi a disposizione dal linguaggio HTML, in taluni casi viene raggiunto solo parzialmente. La quantità sempre maggiore di informazioni reperibili attraverso l'uso di Internet e, quindi, la necessità di confrontarsi con una concorrenza via via crescente, ha avviato una tendenza in base alla quale i webmasters sono portati ad usare in maniera indiscriminata tutte le funzionalità del linguaggio HTML. Il risultato di questo atteggiamento è quello di ottenere pagine Web che, pur essendo di sicuro effetto, possono provocare all'utente disagi sia di tipo tecnico sia di tipo logico. I primi sono identificabili con lunghi tempi di attesa per il caricamento delle pagine mentre i secondi, che sono dovuti alla scarsa chiarezza dei collegamenti ipertestuali, ostacolano la navigazione del sito.

La necessità di effettuare scelte tali da non creare disagi agli utenti si è fatta, dunque, maggiormente pressante. L'obiettivo da perseguire è stato definito nell'implementazione di un sito che, pur essendo semplice tanto nella sua struttura quanto nel codice HTML utilizzato per realizzarlo, sia accattivante ed attraente. Si è tentato, in un certo senso, di dimostrare che, nonostante la politica precedentemente descritta ed adottata da molti webmasters, semplice non significa necessariamente poco gradevole ed originale. Si è dunque cercato di far crescere il sito nella maniera più lineare ed omogenea possibile, definendo, a partire dalla radice, una directory per ognuno degli argomenti trattati da VOICE e ritenuti di rilevante importanza. Questa scelta progettuale ha portato ad ottenere un albero che, comprensivo della radice e dei suoi nodi figli, può essere visualizzato come segue:

I rami che si sviluppano a partire dai nodi/directory figli sono stati sottoposti ad un procedimento di "crescita" iterativo del tutto simile a quello descritto per la radice dell'albero. In ciascuno di essi è stato definito un file home.htm nel quale sono stati inseriti i collegamenti ipertestuali per iniziare la navigazione in quel sottoalbero. L'aumento graduale del numero di file in alcune directory, causato dal progressivo sviluppo del progetto, ha imposto, in taluni casi, la creazione di nuovi nodi all'interno delle directory stesse. Un esempio di tale approccio può essere osservato nel nodo Partners nel quale sono state create due directory nominate rispettivamente alfa e cecoev nelle quali sono stati inseriti tutti i documenti HTML relativi alle due associazioni. Tenendo presente quanto detto il disegno dell'albero può essere può essere aggiornato nel seguente modo:

Tutti gli sforzi profusi per consentire anche agli utenti più inesperti una facile visione del sito sono sfociati nella definizione di un template. Questo non è altro che una pagina HTML nella quale sono state applicate le regole di presentazione ritenute valide per ciascun file del sito e che quindi deve essere considerata quale base di partenza per ogni successivo caricamento di pagina. Si è pensato di riportare, nella parte finale di ciascun documento, dei link che diano all'utente la

Si osservi che il template è completato da due immagini che si trovano rispettivamente nella parte superiore e nella parte inferiore del documento e da un testo che indica la data dell'ultimo aggiornamento e consente di accedere ad una pagina nella quale sono indicati indirizzi utili per contattare tutti i responsabili del progetto. All'immagine che si trova nella parte superiore della pagina è stato associato un link al sito Web del CCR, mentre quella che è posizionata al termine della stessa rappresenta un puntatore al sito www.cast.org/bobby. Tale sito fornisce un sistema automatico in grado di verificare il livello di accessibilità dei documenti HTML. Maggiori dettagli ed informazioni in proposito verranno fornite nei paragrafi successivi. Tutti gli elementi descritti in precedenza, unitamente al contenuto testuale del documento HTML, sono inseriti in una tabella di 600 pixel di larghezza. In questo modo si riesce ad ottenere un controllo maggiore sul layout di pagina limitando al minimo l'uso delle barre di scorrimento. Tale soluzione risulta particolarmente utile per tutti gli utenti che dispongono di monitor di dimensioni ridotte.

In questo paragrafo si analizzano, in primo luogo, i problemi di accessibilità da parte di utenti con limitazioni funzionali causati dall'impiego delle varie funzionalità offerte dal linguaggio HTML e, secondariamente, si forniscono descrizioni delle tecniche adottabili per superare tali difficoltà. Alcune di esse verranno presentate sfruttando esempi tratti direttamente dal sito VOICE.

Quando si parla di rendere accessibile il World Wide Web (WWW) anche ad utenti con disabilità occorre tenere presente che il problema può essere affrontato in tre diverse fasi, corrispondenti ai tre componenti basilari del sistema di accesso al mondo WWW:

• il sorgente HTML;
• il collegamento;
• il browser.

Tutte e tre queste componenti sono importanti, e molti problemi di accessibilità si possono affrontare in più di una di queste fasi. Questo paragrafo è focalizzato soprattutto sulla prima di esse, in quanto cerca di fornire suggerimenti da tenere presenti al momento in cui le pagine HTML vengono scritte.

Verranno prese in considerazione le specifiche del linguaggio HTML versione 3.0 assieme ad alcune delle estensioni proposte e maggiormente usate dagli sviluppatori.

Attualmente, alcune delle caratteristiche del WWW non sono sfruttabili da disabili che usino uno qualsiasi dei browsers WWW oggi disponibili. I non vedenti, ad esempio, non possono usufruire della possibilità di integrare i testi con le immagini oppure, gli audiolesi non possono ascoltare i suoni eventualmente inseriti nella pagina. Inoltre, molti formati non supportano correntemente funzionalità di tipo annotazioni vocali o testuali che offrono descrizioni alternative di oggetti non direttamente usufruibili da parte di disabili (ad esempio trascrizioni letterali di suoni).

Il risultato di tutto ciò è che chi vuole scrivere delle pagine HTML accessibili anche a persone con disabilità deve, o evitare di usare le funzionalità non usufruibili da tutti, oppure mettere a disposizione dell'utente dei metodi alternativi per poter ottenere le informazioni direttamente accessibili dagli utenti normodotati.

Una soluzione valida sarebbe quella di integrare direttamente nei browsers meccanismi che permettano accessi alternativi alle pagine HTML, ma allo stato attuale solo alcuni di tali meccanismi sono stati realizzati dagli sviluppatori dei maggiori browsers disponibili. Questa proposta si presenta, quindi, solo come prospettiva futura: al momento coloro i quali vogliono rendere disponibili le proprie pagine per la lettura anche da parte di utenti disabili sono necessariamente obbligati ad inserire nei propri documenti delle informazioni supplementari e seguire i suggerimenti specificati nel seguito del capitolo.

I tipi di problemi di accessibilità ai documenti HTML possono essere suddivisi nelle categorie seguenti:

Quando in un file HTML si utilizza un link ipertestuale, indipendentemente dal fatto che rappresenti un anchor ad un documento locale oppure remoto, è necessario tenere presente due problemi:

Maggiori informazioni sull'articolo riportato di seguito

Le soluzioni per questo tipo di problemi impongono che la struttura della pagina debba restare semplice. Le tabelle possono comunque essere utilizzate, ma a condizione che non producano un layout di pagina contenente testo visualizzato su più righe in colonne adiacenti. La quasi totalità delle pagine presenti nel sito di VOICE può essere considerata come un esempio dell'uso "corretto" delle tabelle. Come già ricordato nel precedente paragrafo occorre osservare che tutti gli elementi presenti all'interno di un documento HTML sono racchiusi da una tabella ad una sola colonna.

Una soluzione proposta per il futuro comporta un ampliamento delle caratteristiche delle tabelle in cui ad ogni cella vengano associati degli indici di riga e di colonna che possano, in qualche modo, essere utilizzati dagli screen readers per organizzare la lettura della pagina. Purtroppo, al fatto che questi ampliamenti del HTML non sono stati ancora accettati, si deve aggiungere che gli attuali screen readers non sono al momento in grado di interpretare tale informazione aggiuntiva.

Le soluzioni a questi problemi risiedono in parte nei browsers e in parte in modifiche nel sorgente HTML.

Praticamente tutti i browsers utilizzati attualmente forniscono questa opportunità, che però può essere sfruttata al meglio solamente se chi ha scritto le pagine HTML ha utilizzato l'opzione ALT del tag <IMG>. Il significato di tale opzione è quello di fornire un testo da sostituire all'immagine specificata nel caso questa non debba, oppure non possa, essere visualizzata. Un esempio tratto dalla homepage del sito VOICE è il seguente:

In questo semplice esempio, un browser, in cui sia stato abilitato il caricamento delle figure, provvederà a prelevare la figura "cee_flag.gif" all'indirizzo specificato e la visualizzerà nella pagina. Nel caso il caricamento delle figure sia disabilitato, la descrizione alternativa indicata dall'opzione ALT verrà utilizzata per visualizzare la scritta "[The CEE Flag: 12 yellow stars on blue background]". Questo approccio funziona bene anche se l'utente utilizza un browser testuale, come Lynx, che non è in grado di visualizzare gli elementi grafici delle pagine.

Per quanto riguarda l'accessibilità di pagine per utenti non vedenti o con difficoltà visive, è ovvio che le funzionalità grafiche non possono essere sfruttate da queste categorie di utenti. Essi possono utilizzare però browsers testuali abbinati ad appositi programmi di lettura dello schermo (screen reader) che, mediante un sintetizzatore vocale, consentono di udire ciò che è presente sullo schermo sotto forma di testo. L'utilizzo dell'opzione ALT del tag <IMG> renderebbe quindi intelleggibili la maggior parte delle pagine contenenti parti grafiche anche da parte di utenti non vedenti.

Una soluzione complementare alla precedente si può applicare nel caso di immagini che fanno parte di un link. Oltre all'inserimento dell'opzione ALT del tag <IMG>, può essere utile aggiungere un link di tipo testuale accanto a quello di tipo immagine.

La struttura del codice HTML consigliata per questi casi risulta quindi:

In alcuni casi sia l'utilizzo dell'opzione ALT sia l'aggiunta di un link testuale non sono sufficienti: a volte le immagini vengono sfruttate utilizzando un layout della pagina tale per cui la semplice aggiunta, o sostituzione, di testo alle figure produce una pagina confusa e poco comprensibile. In questo caso, la soluzione alternativa sarebbe quella di creare due versioni di ogni pagina: una di tipo puramente testuale ed una grafica. Naturalmente questo approccio conduce ad una duplicazione delle informazioni con conseguenti problemi di coerenza tra le due versioni e il raddoppio dello sforzo nel momento in cui c'è bisogno di modificare l'informazione contenuta nella pagina stessa. Questo problema risulta di portata inferiore nel caso in cui le pagine vengano generate automaticamente tramite l'accesso ad un Data Base sfruttando un programma che, appositamente costruito, preveda le due modalità di generazione delle pagine. L'approccio descritto comporta, quale ulteriore inconveniente, un sovraccarico di lavoro a volte inaccettabile per il server, il quale deve mandare in esecuzione il programma ogni volta che si verifica un accesso alle pagine.

Gli svantaggi dell'uso di mappe non si hanno solamente quando si tratta di considerare l'accessibilità alle pagine WWW da parte di utenti con disabilità. Solitamente, infatti, le imagemaps hanno una dimensione considerevole e, se non si dispone di una connessione particolarmente veloce, spesso si rischia che l'utente si stanchi di attendere il caricamento dell'immagine.

In taluni casi, nelle pagine HTML sono presenti elementi grafici non visualizzabili direttamente dal browser e che vengono mostrati tramite programmi esterni.

Il problema principale di questi elementi, così come per le già citate immagini "in-line", è l'inaccessibilità da parte di persone non vedenti. Le soluzioni disponibili sono sostanzialmente due ed entrambe comportano la realizzazione di un documento HTML di descrizione per ogni immagine facente parte della categoria citata .

L'HTML è un linguaggio in continua evoluzione e periodicamente nuovi costrutti vengono introdotti per aumentare e rendere più flessibili le possibilità di scrivere le proprie pagine. Spesso chi introduce tali costrutti non tiene conto del fatto che questi potrebbero limitare pesantemente l'accesso ai documenti HTML per certe categorie di utenti. In particolare, in questo paragrafo verranno suggerite metodologie per superare, almeno parzialmente, i problemi di accessibilità provocati dall'uso dei suddetti costrutti speciali.

1. Sequenze Sonore: un metodo alternativo e complementare di fornire informazioni in una pagina WWW è quella di includere delle sequenze sonore. I problemi che questo tipo di informazioni presentano, sono dovuti al fatto che una persona non udente non può ovviamente avere accesso al sonoro. Non tutti i personal computer utilizzati per accedere alla pagina possono disporre di tutto l'hardware e il software necessari per poter riprodurre le sequenze audio. Le soluzioni proponibili sono del tutto simili a quelle indicate per gli elementi grafici da visualizzare con programmi esterni.

2. Sequenze Filmate: il filmato è un mezzo per fornire informazione scarsamente utilizzato nei documenti HTML. Sostanzialmente l'unico modo di rendere accessibili a persone disabili le informazioni contenute in un filmato è quello di incorporare informazioni aggiuntive sincronizzate ai dati che formano il filmato stesso. Si devono fornire rappresentazioni alternative dei due diversi tipi di informazioni presenti in un filmato: per quanto riguarda l'audio si potrebbero introdurre rappresentazioni testuali del contenuto sonoro; per quanto riguarda il video si potrebbe utilizzare una tecnica, detta del Descriptive Video, che prevede l'utilizzo di un narratore addizionale che descrive cosa sta avvenendo in quel momento nel video senza ovviamente disturbare l'informazione sonora già presente nel filmato.

3. Moduli da compilare: il tag FORM consente di creare pagine in cui all'utente viene data la possibilità di compilare on-line dei formulari con dei dati che tipicamente saranno poi spediti ed analizzati da un programma presso il server. Il problema principale è dovuto al fatto che non tutti gli elementi che possono far parte di un FORM sono riconosciuti ed interpretati dai browsers testuali e dagli screen readers utilizzati dai soggetti non vedenti. La soluzione parziale che si può proporre al momento attuale, e valida fino a quando screen readers e browsers testuali utilizzati dai non vedenti saranno in grado di interpretare correttamente questo costrutto, è quella di fornire all'utente un modo per poter ricevere la richiesta di informazioni sotto forma di messaggio di posta elettronica. L'utente provvederà poi a compilare la richiesta che rinvierà al mittente. Ovviamente dovrà essere creata tutta la struttura di programmi in grado di inviare, ricevere ed interpretare i dati con questa nuova modalità di scambio di informazioni. E' inoltre chiaro che con questo metodo non si potrà più ottenere un funzionamento in tempo reale della funzionalità realizzata da certe pagine basate su FORM.

5. Formati HTML non standard: per documenti in formati diversi dall'HTML, come ad esempio PDF (acrobat reader), PS (postscript), WORD (word per windows) sono previsti dei viewer esterni, come avviene per le immagini, ma mentre per una immagine è possibile utilizzare un "D-tag" che la descrive, per un documento, che può contenere un insieme di testo, grafici, immagini e suoni, la cosa diventa improponibile. Di conseguenza se è possibile rendere in formato HTML oppure ASCII il contenuto del documento non standard allora si può ricorrere ad una pagina alternativa che lo descriva, in caso contrario occorre evitare l'uso di questi formati.

Bobby è un programma grafico disponibile in rete realizzato dal CAST che aiuta tutti coloro i quali sviluppano siti web a realizzare pagine accessibili al maggior numero di utenti. Utilizzare questo sistema completamente automatico è piuttosto semplice. Una volta raggiunto il sito di Bobby e dopo aver compilato le opportune forms con l'indirizzo della pagina che si intende far analizzare è sufficiente richiedere l'esecuzione del programma. Durante la fase di runtime Bobby effettua due tipi di test: con il primo si propone di determinare in che modo la pagina esaminata può provocare problemi di accesso ad utenti con disabilità, mentre con il secondo intende prevenire problemi di incompatibilità tra il codice HTML ed i browsers maggiormente utilizzati. A questo proposito è importante ricordare che il browser con il quale valutare l'eventuale incompatibilità è un parametro che deve essere scelto dall'utente prima di mandare in esecuzione Bobby. Indipendentemente dal test che viene effettuato questo programma risulta particolarmente utile al web designer poiché evidenzia le parti di codice che sono ritenute responsabili dei problemi di accessibilità e di incompatibilità. Nell'ipotesi in cui la pagina esaminata superi brillantemente entrambe le prove, Bobby rilascia all'utente il permesso di inserire nella pagina stessa l'immagine riportante la dicitura: "Bobby Approved". Si riportano negli allegati, a titolo d'esempio, alcune prove effettuate sottoponendo al sistema la homepage del sito VOICE ed il file in cui è stata inserita la mappa del sito stesso. Con tali esempi, in particolare, si intende mostrare diversi risultati generati da Bobby a fronte dell'analisi di due pagine: la prima completamente accessibile, la seconda con alcuni problemi.

Un altro strumento, ugualmente utile ai webmasters per valutare l'accessibilità del loro sito, è il test di autovalutazione prodotto dalla DMD. A ciascuna delle domande proposte dal questionario gli sviluppatori devono rispondere assegnando un punteggio a seconda della modalità con cui le loro pagine rispondono alle indicazioni fornite. I punteggi parziali così stabiliti contribuiscono a definire un quoziente complessivo misurato in centesimi che, unitamente ad una tabella relativa all'accessibilità delle pagine, viene fornito al termine della prova. Il vantaggio che questo approccio, pur essendo estremamente soggettivo, presenta rispetto all'uso del sistema automatico Bobby è rappresentato dal coinvolgimento in prima persona degli sviluppatori i quali sono incoraggiati attivamente ad adottare tecniche accessibili per tutte le loro pagine web. Il test di autovalutaizione è riportato integralmente negli allegati.