ACCESSIBILITÀ DI SITI WEB a cura di Laura Burzagli e Paolo Graziani
"The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect."
Tim Berners-Lee, direttore del Consorzio W3C e ideatore del World Wide Web
Con questo lavoro gli autori intendono rivolgersi a tutti coloro che, pur avendo conoscenze nel campo informatico e telematico, conoscono solo parzialmente o ignorano del tutto le potenzialità di questi mezzi per l'integrazione delle persone con disabilità, come pure il pericolo delle grandi barriere che possono inavvertitamente essere introdotte e che ostacolano di fatto tale integrazione. Molte organizzazioni internazionali che operano in questo settore stanno da tempo portando avanti un approfondito lavoro teso ad abbattere tali barriere e ad aumentare le potenzialità d'accesso di ogni categoria di utenti, compresi quelli "marginali". Questo lavoro ha già dato numerosi risultati positivi, purtroppo spesso sconosciuti alla maggior parte degli utenti e degli operatori. A noi è parso fondamentale che questi risultati non rimanessero dominio di pochi, ma fossero diffusi fra tutti coloro che operano in questo settore, qualunque sia il loro ruolo. Siamo infatti convinti che anche da studi tecnicamente molto complessi si possono sempre ricavare delle regole comprensibili ed applicabili da chiunque. D'altronde, è proprio dalla massiccia e sistematica applicazione delle regole messe a punto da questi lavori di ricerca che dipende il buon esito di un processo di generale miglioramento dell'accessibilità delle sorgenti di informazione e dei mezzi tecnologici.
Anche se ci limiteremo in questa sede a considerare l'accessibilità di un settore specifico delle applicazioni tecnologiche che è quello dell'informazione disponibile in Internet, esso costituisce un valido esempio di come si possa affrontare con successo il problema della accessibilità con risultati applicabili anche in altri settori. I principi qui richiamati sono applicabili a molti altri settori dell'informazione.
Ci baseremo principalmente sui documenti prodotti dal progetto WAI (Web Accessibility Initiatives) del Consorzio W3C e di altre organizzazioni che verranno citate nel seguito, dai quali cercheremo di estrarre le regole principali di accessibilità, fornendo al tempo stesso delle chiavi di lettura per la diretta consultazione di questi documenti. A questo aggiungeremo dei suggerimenti pratici applicativi, frutto di esperienza sul campo.
Per garantire una completa comprensione dei dettagli tecnici che dovremo introdurre, daremo anche dei cenni in generale sul problema dell'accesso dei disabili al mondo dell'informazione e dei mezzi informatici. Per coloro poi che volessero approfondire la loro conoscenza sull'argomento, verrà fornita una accurata bibliografia che permetterà di recuperare informazioni ancor più dettagliate in proposito e di aggiornare periodicamente il panorama. Infatti è chiaro che questa nostra descrizione non può essere niente più di una fotografia della situazione nel momento in cui viene scritta, utile come punto di partenza e di riferimento, ma che necessita di un continuo aggiornamento, via via che la tecnologia si evolve e gli sforzi di adattamento producono nuove soluzioni.
Il principio ispiratore di questo lavoro è quello della "progettazione universale". Tale concetto trova la sua origine in architettura e nel design dei prodotti, dove la possibilità di mettere in pratica certi principi dipende dalla capacità di soddisfare un numero più grande di utenti. I progettisti che applicano il principio della progettazione universale creano edifici e prodotti che sono concepiti all'origine per essere usati da tutti gli individui, compresi quelli con disabilità. La pianificazione a priori delle necessità dei diversi utenti evita di effettuare interventi a posteriori sulle strutture esistenti per abbattere le barriere che sono di ostacolo alla fruizione da parte di qualche sotto-insieme della popolazione, una pratica costosa che generalmente dà luogo a soluzioni inadeguate ed esteticamente disastrose. Tra l'altro la progettazione che tiene conto anche delle necessità degli utenti marginali si riflette in un miglioramento generale dell'utilizzo per tutti. L'esempio classico è quello delle rampe d'accesso. Progettate inizialmente per favorire la mobilità degli utenti in carrozzina , risultano utili per coloro che spingono carrelli per merci o passeggini con bambini, per coloro che hanno il bastone ed anche per il pedone qualunque. Le regole centrali della progettazione universale sono state estese ed applicate nello sviluppo di molti prodotti, nei mezzi di trasporto, negli edifici pubblici e privati e nel progetto di sistemi elettronici e siti web. L'obiettivo è quello di migliorare l'utilizzo da parte delle persone con bisogni e preferenze particolari.
I principi della progettazione universale, listati in Appendice, sono molto generali, ma si concretizzano in specifiche applicazioni nei vari campi dell'attività umana, come ad esempio quello dello sviluppo delle interfacce uomo macchina, HCI (Human-Computer Interaction). Di questo specifico settore fanno parte anche le problematiche di accesso ad Internet, ai documenti ipertestuali e multimediali, nonché alle interfacce utente dei programmi di navigazione, argomenti principali di questo lavoro.
Per una migliore comprensione del problema dell'accessibilità al web, occorre fare un cenno preliminare ai problemi specifici di accesso agli elaboratori da parte delle varie categorie di persone disabili. Questo faciliterà nel proseguo del documento la comprensione delle raccomandazioni relative agli elementi specifici del mondo web. Questo capitolo non è strettamente necessario al fine dell'applicazione delle regole di accessibilità definite dal WAI, ma può comunque aiutare a comprendere meglio l'origine di uno specifico problema o può essere una conoscenza preliminare (il punto di partenza) per tutti coloro che vogliono estendere i concetti di accessibilità ad altre applicazioni informatiche diverse da quelle relative al Web.
Gli utenti con disabilità possono essere ricondotti ai seguenti profili: disabilità sensoriali (vista, udito), disabilità motorie (impedimenti vari all'uso delle mani) e disabilità psichiche o cognitive.
La disabilità della vista comprende tipicamente due classi di utenti: i non vedenti e gli ipovedenti. Tale distinzione ha la sua ragion d'essere nel fatto che i problemi di accesso all'elaboratore sono profondamente diversi nei due casi. Infatti le persone ipovedenti utilizzano comunque il monitor come dispositivo d'uscita dell'informazione, anche se mediante l'applicazione di accorgimenti particolari come l'aumento della dimensione del font usato, l'utilizzo di software di ingrandimento generale dello schermo oppure l'impostazione di colori particolarmente adatti ad esaltare le varie parti della presentazione a video.
Al contrario, per i non vedenti occorre ricorrere a dispositivi di output fisicamente diversi dal monitor basati su un'uscita audio, come un sintetizzatore vocale, o su un'uscita tattile, come il display Braille. In ambedue i casi c'è alla base un'operazione di ristrutturazione dell'informazione, così come viene presentata sullo schermo, un'operazione di filtraggio che permette di selezionare e rileggere in forma sequenziale quello che l'utente normale abbraccia con la vista in modo panoramico. Questa operazione di sequenzializzazione risulta relativamente semplice in ambiente testuale (come il DOS), nel quale l'intero contenuto dello schermo è costituito da una matrice di 25 righe di 80 caratteri. Tale impostazione è stata completamente superata dall'avvento delle interfacce grafiche (come Windows o Macintosh) le quali sostituiscono il concetto di carattere con quello di punto dello schermo (pixel). Il carattere diventa dunque un insieme di punti e come tale non immediatamente traducibile, per cui anche la ricostruzione di un testo e la sua trasduzione sequenziale aumenta enormemente di complessità. Inoltre, allo scopo di offrire un modo "amichevole" di interazione con l'elaboratore, tutte le operazioni si svolgono mediante una manipolazione di oggetti grafici di significato intuitivo, anziché mediante sequenze di caratteri da tastiera. Questo complica ulteriormente l'interpretazione e la trasduzione in forma alternativa sonora o tattile, poiché tutto è progettato per la modalità visiva.
Per fortuna non mancano nemmeno in questo secondo caso gli strumenti atti a compiere l'interpretazione della presentazione sul video e la trasduzione opportuna mediante quei particolari dispositivi d'uscita. I programmi che effettuano questa rilettura dello schermo prendono appunto il nome di "screen reader" e sono disponibili sia in ambiente testuale che grafico. Tuttavia il loro grado di efficienza dipende dalla complessità della struttura dell'informazione presentata sullo schermo e comunque non riescono completamente a riprodurre in forma alternativa l'aspetto "amichevole" della interfaccia utente.
Nel caso di uso di programmi di accesso a siti Web, la complessità delle pagine ipertestuali influenza direttamente la loro accessibilità per chi usa uno screen reader per sintesi vocale o per display Braille.
A questo punto si pone l'intervento dell'autore delle pagine web, che può, con un'oculata progettazione della pagina, facilitare la conversione da parte dei programmi di screen reader. Vedremo poi in dettaglio come.
Ma c'è un altro aspetto di particolare rilevanza che va ricordato: nonostante che l'ambiente grafico sembri ormai lo standard per tutti, molti utenti non vedenti (ma anche utenti vedenti dotati di macchine con funzionalità più modeste) preferiscono lavorare ancora in ambiente testuale, perché garantisce loro un accesso completo e più semplice rispetto a quello a carattere grafico. Esistono per questo degli ottimi prodotti per tale ambiente, come il browser Lynx, che garantiscono ugualmente una buona navigazione in Internet. Ovviamente il modo testuale di presentare l'informazione è completamente diverso, privo delle possibilità di strutturazione così intensamente utilizzate negli ambienti grafici. Perciò, affinché un documento mantenga sempre inalterato tutto il suo contenuto occorre che già in fase di progettazione si tenga conto delle sue varie forme di visualizzazione che l'utente può scegliere e garantirsi che comunque niente vada perso.
Va sottolineato che si assiste ad un crescente interesse per questo tipo di approccio alla progettazione di pagine HTML, dato dal fatto che si vanno diffondendo sempre più dispositivi di accesso ad Internet da automobili o altri mezzi, con terminali diversi dal personal computer, come un semplice apparecchio telefonico, quindi via audio o con l'ausilio di piccoli display, per cui, ancora una volta, quello che era il problema per un ristretto numero di utilizzatori diventa invece un problema che riguarda l'intera utenza.
I problemi degli utenti con disabilità dell'udito, dovuti ad una sordità parziale o completa, sono da mettere in relazione con il crescente impiego di componenti audio nelle presentazioni multi-mediali, come i file audio, che fanno da corredo sonoro alla grafica, oppure registrazioni dalla viva voce del protagonista di conversazioni, esibizioni o altro. Di particolare rilievo la difficoltà d'accesso a filmati che contengono audio e video, di cui la parte audio diventa una componente essenziale.
Quando i suoni veicolano importanti informazioni, come segnali di allarme od altro, possono essere sostituiti o accompagnati da opportune segnalazioni visive. In particolare, una conversazione o la colonna sonora di un filmato possono essere rese accessibili mediante il classico metodo della sotto-titolazione.
Per i sordi congeniti, vanno tenute presenti comunque anche le difficoltà di apprendimento del linguaggio, dovute alla mancanza di feedback uditivo, la cui conseguenza è spesso una difficoltà di comprensione anche del testo scritto, specialmente quando tratta argomenti astratti o fa uso di frasi molto elaborate.
L'arco delle disabilità di tipo fisico è piuttosto ampio e va da una modesta paralisi su un arto, all'incapacità di controllare i propri movimenti a causa di spasmi nervosi, sino nel peggiore dei casi ad una mobilità residua quasi nulla che permette di interagire col computer solo mediante l'invio di un comando d'assenso, come il battito dell'occhio o il soffio in una cannuccia per la selezione dell'azione proposta dal computer con una lista di possibilità. In tutti questi casi la difficoltà di accesso si presenta per ciò che riguarda i dispositivi d'ingresso dei comandi da parte dell'utente.
La tecnologia ha già dato delle risposte altamente significative anche in questo campo, mettendo a punto dei dispositivi come tastiere di dimensioni maggiorate e con accorgimenti per evitare pressioni accidentali di tasti, emulatori di mouse particolari, per sfruttare al meglio le capacità residue dell'utente colpito da questo tipo di menomazione. Per coloro che possono interagire con la macchina solo mediante comandi di tipo sì/no, sono state sviluppate soluzioni software di emulazione di tastiera mediante presentazione di matrici di caratteri sullo schermo. Una scansione automatica, regolabile in velocità, provvede a presentare in sequenza i tasti virtuali per la loro selezione; algoritmi di previsione possono ridurre il campo di scelta in funzione dei caratteri già selezionati: dopo "str" il carattere successivo sarà sicuramente una vocale e dopo "naturalm" quasi sicuramente il resto della parola è "ente". Per migliorare l'efficienza di comunicazione con comandi di tipo sì/no, si fa uso anche di linguaggi iconici o ideografici, come i simboli di Bliss, che permettono di selezionare intere parole o concetti con una singola azione.
Per la manipolazione di oggetti grafici, come bottoni, icone e scroll bars, un utente con ridotta capacità motoria si può servire di un emulatore di mouse, un dispositivo hardware e software in grado di produrre movimenti programmati del puntatore del mouse, controllati con comandi elementari simili a quelli citati per la selezione di tasti virtuali.
Riguardo alle possibilità di interazione con interfacce grafiche, poiché la difficoltà maggiore risiede comunque nella capacità di selezione da parte dell'utente con disabilità motorie, occorre evidenziare come la scelta di elementi con dimensione troppo piccola e estremamente vicini tra loro comporta problemi non indifferenti. Analogamente portano problemi tutte quelle procedure dotate di timeout troppo brevi, non compatibili con i tempi di reazione e la limitata velocità di movimento del soggetto che deve interagire servendosi di questi ausili speciali. Le stesse difficoltà saranno incontrate nella navigazione in documenti Web.
Anche questo ambito è molto vasto e differenziato. Si può tentare di evidenziare con molta prudenza degli aspetti comuni. L'utente affetto da tale disabilità farà fatica ad accedere, cioè a capire pagine web troppo complesse, o in cui le componenti in movimento siano troppo veloci, perché le sue capacità residue potrebbero non consentirgli di cogliere fino in fondo tutti gli aspetti dell'informazione introdotta nella pagina. Ad esempio un'immagine piuttosto che una lunga scritta può essere un modo migliore, più sintetico per seguire un certo itinerario di navigazione in rete. Così come effetti lampeggianti possono comportare un'incapacità di afferrare il senso dell'informazione ivi contenuta.
Per maggiori dettagli, vedi [7].
3.2 Criteri generali di approccio al problema
Premesse queste nozioni di carattere generale, occorre fare un'altra importante precisazione: non esistono soluzioni del problema realizzabili con la sola applicazione di determinate regole, sia pure molto dettagliate, ma occorre acquisire un'esperienza in materia che guidi nella composizione dei documenti.
In altre parole, l'applicazione dei concetti di accessibilità non è un fatto meccanico. Richiede una certa conoscenza del linguaggio HTML, dei suoi sviluppi, e una certa sensibilità che si ottiene solo con una esperienza di lavoro nel settore.
Bisogna tener conto infatti che l'uso dei "sistemi autore" di documenti ipertestuali, mentre aiuta notevolmente nella compilazione delle pagine HTML, spesso impedisce all'operatore di verificare direttamente tutti gli effetti delle scelte di composizione, mostrando solo l'aspetto esteriore del documento. Un minimo di conoscenza di come vengono scritte in realtà le pagine HTML permette di verificare la corretta traduzione in questo linguaggio dei comandi ad alto livello del sistema di sviluppo e permette anche di sapere come utilizzare correttamente il sistema stesso per completare le informazioni introdotte con quelle alternative e integrative di supporto alla accessibilità. Solo così è possibile applicare quel principio di progettazione universale introdotto nel capitolo precedente.
Va comunque sottolineato che, creare documenti accessibili non significa rinunciare a qualcosa, ma al contrario, arricchire il documento stesso con componenti che lo completano e lo rendono più adatto alla consultazione in qualunque circostanza. Ad esempio, contrariamente a quanto si ritiene con un diffuso luogo comune, un documento accessibile ai ciechi non deve essere necessariamente un documento puramente testuale. Può contenere immagini, grafici, può essere strutturato in modo razionale; basta che le sue componenti orientate alla vista siano accompagnate da informazioni alternative che ne descrivano la funzione e che non siano quindi di impedimento all'orientamento nel documento stesso, come meglio dettagliato nei capitoli successivi. Un analogo concetto vale per la struttura del testo per la quale si può anzi aggiungere e ribadire che, se ben progettata per la navigazione da parte di una persona non vedente, ne trarranno vantaggio tu tti gli altri utenti.
Il principio fondamentale da applicare ai fini dell'accessibilità è che gli autori non devono essere scoraggiati dall'usare elementi multimediali, ma piuttosto incoraggiati a farne uso in modo tale da assicurare che quel materiale che essi pubblicano sia accessibile all'utenza più vasta possibile o comunque che un elemento che risulti inaccessibile per qualche classe di utenti non impedisca l'accesso ad altre parti di un documento.
Per introdurre questo argomento occorre subito far presente che esistono in proposito dei documenti prodotti dal progetto WAI che possono essere consultati come riferimento completo sulle norme di accessibilità dei documenti del web. La consultazione di questi documenti e l'applicazione di tali norme presenta tuttavia alcune difficoltà, dato che la loro estrema completezza e specificazione impedisce in molti casi di capire subito quelli che sono i criteri basilari e le metodologie di applicazione. Per questo il presente documento fa di quelle norme una propria rielaborazione, certamente parziale, ma forse con una terminologia, almeno nei nostri intenti, più semplice e diretta. A coloro i quali interessa invece la documentazione completa forniamo l'indirizzo web di riferimento: http://www.w3.org/WAI.
Il primo aspetto pratico da sottolineare è che le linee guida prendono come punto di riferimento le specifiche del linguaggio HTML nelle varie versioni, ad es. 2.0, 3.0, 3.2, 4.0. Questo implica che anche negli esempi di codice presentati non si fa un riferimento particolare ad un browser, o ad un tool di editing dei documenti, ma alla stesura di un documento fatta a partire dal linguaggio. Nella pratica si sa bene che non tutti i browser gestiscono tutti gli elementi e tutti gli attributi delle specifiche del linguaggio, e anche se le gestiscono nelle versioni più avanzate possono non farlo nelle versioni più vecchie, ma che possono essere ancora largamente utilizzate da molti utenti. Questo vuol dire che ci si può trovare di fronte alla presunta soluzione di taluni problemi mediante l'adozione di particolari elementi, i quali però finora nella pratica non vengono gestiti da alcun prodotto o solo da pochi di essi. Un progettista di siti web che vuol progettare rispettando criteri di accessibilità non può quindi prescindere dal cercare un compromesso tra quello che sarebbe un documento astrattamente accessibile secondo le regole e un documento realmente accessibile alla luce delle prestazioni dei programmi di navigazione e della tecnologia adattiva attualmente presenti sul mercato.
I due punti cardine dell'accessibilità sono i seguenti:
Si sottolinea che nel proseguo del documento verranno citati elementi ed attributi del linguaggio HTML.
La prima delle due linee guida indica la proprietà insita in una pagina di potersi adeguare alle diverse modalità di rilettura, che possono essere impostate dall'utente o vincolate dalla tecnologia utilizzata. Questo vuol dire, per fare un esempio, che un computer privo di capacità audio, non potrà trasmettere informazione di questo tipo. Per questo la pagina che contiene informazioni audio dovrà essere fornita di informazione ridondante che presenti il contenuto audio in altro formato. In altre parole questa linea guida è l'esatto contrario della scritta che troviamo di frequente nei siti "Best viewed with xxx browser". La pagina dovrebbe essere "Best viewed with ¼ every browser".
Per specificare meglio possiamo dire che i documenti che si comportano in questo modo sono quelli capaci di essere percepiti interamente sia in modo visivo che attraverso mezzi sonori. E' bene sottolineare che questo non significa assolutamente che sia necessario duplicare il contenuto del documento con la creazione di un'intera versione sonora del sito. Infatti i dispositivi di screen reader sono già in grado di tradurre in forma audio tutta l'informazione presente sulla pagina in formato testuale. Quindi per avere una versione sonora è sufficiente tradurre solo le porzioni d'informazione non trasformabili in audio con i mezzi di tecnologia adattiva.
Un altro aspetto fondamentale dei documenti così creati è la loro capacità di essere adoperati su tipi diversi di hardware, cioè con computer senza mouse, con schermi con bassa risoluzione o in bianco e nero, con uscita solo in voce o in testo, oppure senza schermo.
Si elencano nel seguito i principi base la cui applicazione, grazie alla flessibilità insita nel progetto delle tecnologie W3C, rendono le pagine capaci di auto-adattarsi alle diverse piattaforme dell'utente.
Nota: a premessa di tutte le note sui corrispondenti testuali va sottolineato che il testo è considerato accessibile da quasi tutti gli utenti perchè può essere elaborato da screen reader e browser non-visuali e presentato in forma sonora o tattile. E' una buona norma , mentre si progetta un documento che contiene informazione non testuale (immagini, grafica, applet, suoni, ecc.) pensare di integrare l'informazione con l'equibvalente testuale laddove sia possibile. Ci sono diversi tipi di integrazione testuale da considerare, dettagliati nel seguito: il testo alternativo (A1), le long description (A2) e le pagine alternative testuali (A13.2).
Il testo alternativo non è una descrizione dell'elemento grafico, quanto piuttosto del suo valore logico all'interno della pagina. Il logo di una ditta, ad esempio, avrà certamente un valore informativo diverso da un grafico che riporta l'andamento della borsa nel corso di una giornata. Conoscere in dettaglio la composizione del logo non sarà così necessario ai fini della comprensione della pagina come conoscere i valori rappresentati dal grafico della borsa.
Parlando di immagini, va sottolineato che tra di esse vanno compresi tutti quei piccoli simboli o elementi di grafica che servono a sottolineare gli elementi di una lista, o vengono usati come separatori di paragrafi o semplicemente per arricchire la presentazione grafica. Molte volte anche alcune porzioni del testo vengono in realtà costruite come immagini e quindi anche per esse occorre introdurre le regole di accessibilità che elenchiamo qui di seguito.
Per applicare questo principio occorre seguire i seguenti criteri:
A1.1 fornire il testo alternativo a tutte le immagini ( attraverso l'attributo "alt" degli elementi IMG o attraverso "title" o all'interno del contenuto di OBJECT).
A1.2 fornire testi alternativi per tutte le applet e gli altri oggetti di programmazione (in HTML attraverso l'attributo "alt" degli elementi IMG o attraverso "title" o all'interno del contenuto di OBJECT).
A1.3 per tutti i link delle mappe immagini fornire il testo alternativo (attraverso l'attributo "alt" dell'elemento "AREA").
A1.4 per tutti i link delle mappe immagini fornire link testuali ridondanti. Non usare mappe immagini per creare una serie di bottoni in un form.
A1.5 al contrario usare bottoni o immagini separate (accompagnate da testo alternativo).
A1.6 sostituire gli ASCII art con un'immagine e il relativo testo alternativo.
Ciò serve a garantire che informazioni importanti presentate in forma grafica (come diagrammi di flusso, ecc.) siano percepibili anche da utenti non vedenti, ipovedenti e da coloro che hanno scelto di escludere determinate caratteristiche di visualizzazione come immagini, script, applet.
Questa descrizione, fornita su una pagina separata, prende il nome di "long description", (v.A.1) ed ha una funzione diversa dal testo alternativo. Essa fornisce la descrizione dell'informazione visuale dell'immagine, mentre il testo alternativo esprime solo la funzione dell'immagine stessa nel contesto del documento.
Si suggerisce quindi di realizzare una long description di tutta la grafica, gli script e le applet che trasportano informazione importante mediante l'attributo "longdesc" sull'IMG, con un d-link o come contenuto di OBJECT.
Quando l'audio presente nel documento è associato con una presentazione visuale (filmato o animazione), sincronizzare l'equivalente testuale (sottotitoli) con la presentazione visuale. Altrimenti si escludono gli utenti sordi, o coloro i quali usino terminali privi di sistema audio.
Le video-descrizioni sono usate principalmente da persone non vedenti per seguire l'azione e altre informazioni visive nel materiale video. La descrizione degli elementi visuali chiave deve essere sincronizzata con le immagini e deve avvenire senza interferire con il dialogo e le altre componenti audio già presenti nel filmato. Gli elementi visuali chiave includono le azioni, le posizioni dei personaggi, il linguaggio del corpo, la grafica e il testo visualizzato.
Sempre con riferimento ai filmati, è utile fornire anche un testo alternativo che riunisca sia le descrizioni dei dialoghi e dei suoni sia quelle delle immagini e situazioni, citate in a3 e a4, a beneficio di chi ha problemi sia di vista che di udito ed anche per chi usa un browser solo testuale. Si noti che, se si sono seguite le raccomandazioni A3 e A4, il materiale per costituire questo testo alternativo è già disponibile e quindi la sua realizzazione risulta poco onerosa.
Il problema sorge in due casi principali. Il primo quando il colore porta un'informazione. Consideriamo il caso di una tabella in cui per ogni elemento di una lista l'avere o meno una certa proprietà viene rappresentato con un colore anziché con una scritta del tipo sì/no. In questo caso gli utenti affetti da disturbi di percezione cromatica ( o coloro che hanno un computer con monitor b/n o dispositivo d'uscita non visivo) non riceveranno l'informazione.
Un secondo caso di inaccessibilità si verifica quando i colori di sfondo e di primo piano sono troppo vicini allo stesso livello di luminosità. In questo caso possono non avere sufficiente contrasto quando vengono visualizzati su schermi in bianco e nero o da utenti che hanno problemi di riconoscimento dei colori.
Evitare quindi l'uso di colori per trasportare informazione, a meno che la stessa informazione non risulti chiara anche dal testo o da altri tipi di mark up, ed usare colori di sfondo e di primo piano con sufficiente contrasto.
Questo argomento è molto importante, anche se talvolta di non facile comprensione.
L'architettura del documento e la sua visualizzazione sono due aspetti che devono essere tenuti ben distinti, sia dal punto di vista concettuale sia nell'uso degli elementi del codice HTML. Ci sono infatti elementi del linguaggio dedicati alla struttura ed altri alla visualizzazione su schermo o su altra periferica; è importante fare un corretto uso delle due classi di codici per non generare confusione. I primi servono a strutturare il documento in parti ben definite, quali titolo, paragrafi, liste e così via, mentre i secondi permettono di scegliere la forma di presentazione di certe parti del documento, come il font da usare, il colore ecc... Nel HTML 4.0 sono stati introdotti gli "Style sheets" proprio per dare risalto a questa differenza fra elementi del codice e mettere a disposizione una gamma più vasta di scelte a vari livelli della forma di visualizzazione, in modo indipendente dalla struttura del documento. L'utilizzo corretto degli e lementi di strutturazione fa si che i browser possano garantire una migliore navigazione nel documento. Un esempio di uso scorretto è quello di servirsi dell'elemento H1 per ottenere un testo a caratteri grandi e in grassetto, mentre questo elemento deve essere usato solo per identificare una frase di rilievo nella strutturazione del documento, come il titolo di un capitolo, distinguendolo da quello dei sottocapitoli che possono essere organizzati in una struttura gerarchica fino a 6 livelli (H1-H6). Se usati correttamente, gli elementi Hn permettono al browser di evidenziare una struttura ad albero, con i nodi e le ramificazioni rappresentati dai vari livelli di titoli, molto utile per la navigazione per chi usa una presentazione alternativa come la sintesi vocale o la riga Braille. L'esempio sopra riportato di uso di un elemento H1 per ottenere solo un effetto visivo, distorce l'architettura del documento e genera disorientamento. Viceversa, anche l'uso di elementi di formatt azione e visualizzazione per ottenere effetti strutturali sullo schermo è altrettanto errato, come ad esempio l'uso di testo pre-formattato per rappresentare tabelle, nonostante siano disponibili i codici di struttura delle tabelle stesse. Per chi è costretto a rileggere sequenzialmente una rappresentazione del genere, come chi usa una sintesi vocale, l'assenza di codici e attributi di riferimento alla struttura della tabella impedisce la sua corretta interpretazione. Altri esempi di uso improprio di elementi HTML sono riportati sotto, fra le raccomandazioni specifiche.
Suggerimenti e verifiche:
A6.1 nidificare adeguatamente gli heading (H1-H6)
A6.2 codificare la struttura e i componenti di una lista con gli elementi appropriati. (in HTML UL, LI, ecc)
A6.3 identificare le citazioni con gli elementi Q e BLOCKQUOTE in HTML, evitando invece di usare questi ultimi per creare effetti di rientro del testo.
A6.4 usare style sheet per l'impaginazione e la presentazione non appena la maggior parte dei browser li gestisca. Gli autori dovrebbero usare gli style sheet per la formattazione del testo piuttosto che convertire il testo in immagini. Per esempio un testo con uno stile particolare su uno sfondo colorato può essere creato con gli style sheet invece che con un'immagine. Questo fornisce flessibilità alle persone di vedere il testo in una forma che sia leggibile anche ingrandita, con un particolare font o in bianco e nero. Tuttavia se si usa un testo- immagine per creare un particolare effetto di testo, deve essere reso accessibile. E se non è possibile rendere tale immagine accessibile, occorre fornire una pagina alternativa. Rendere accessibile vuol dire munirla di una versione testuale dello stesso testo rappresentato come immagine.
A6.5 Occorre preferire il dimensionamento e il posizionamento relativo ( valori percentuali) piuttosto di quello assoluto ( pixel).
Una tabella in HTML viene concepita come un insieme di dati organizzati per righe e ogni riga organizzata per celle. Questa struttura è molto chiara a livello visivo, ma comporta numerosi problemi quando questa organizzazione deve essere riprodotta per via audio. Per comprendere il problema dell'esplorazione sequenziale di una tabella, si devono distinguere due tipi di rilettura: quella basata sulla interpretazione del codice, effettuata da browser testuali come lynx, e quella basata sulla rilettura dello schermo, quale quella effettuata dagli screen reader sotto Windows che agiscono in coppia con browser grafici come IE o NS. Nel primo caso, il browser provvede a rileggere il contenuto delle singole celle di ogni riga, una riga alla volta, essendo in grado di identificarle una ad una grazie al codice. Nel secondo caso invece la rilettura viene effettuata per righe complete dello schermo, poiché lo screen reader vede la tabella così come è; riprodotta dal browser, senza poter accedere all'informazione sulla struttura, cosa che può far confondere il contenuto di celle adiacenti.
Ad esempio se abbiamo una tabella del tipo:
cella 1: il mare cella 2: splende
è agitato il sole
viene riletta per righe : il mare splende, è agitato il sole.
Per questo, ai fini dell'accessibilità l'elemento tabella resta un elemento piuttosto critico, tenuto conto anche che le tabelle sono ancor oggi usate per l'impaginazione dei documenti (anche se in fase di sostituzione da parte degli style sheet). Infatti, spesso assistiamo all'uso nidificato di tabelle per ottenere il posizionamento degli elementi nei punti desiderati dello schermo. Le specifiche dell'HTML 4 offrono molti elementi ed attributi atti a favorire il riconoscimento delle relazioni tra i vari elementi all'interno della tabella, di cui faremo menzione nel seguito. Va però subito evidenziato che, a fronte di specifiche spesso molto dettagliate, non fa riscontro una applicazione delle stesse da parte dei browser che talvolta non interpretano neppure gli elementi e gli attributi particolari come "summary" o similari. La comunità internazionale si è posta il problema se continuare a consigliare agli utenti l'adozione di questi elem enti. La risposta è stata affermativa perché, essendo queste regole dettate da specifiche internazionali, nel tempo dovrebbero trovare una loro applicazione. Nel frattempo noi pensiamo di consigliare una regola pratica applicabile sin da ora, che consiste nel capire come i dati vengono organizzati dai browser e cercare quindi di evitare una loro composizione che possa generare confusione.
Un esempio può essere quello di un orario del treno. E' quasi istintivo pensare ad una sua rappresentazione in modo tabellare. L'importante è assegnare ad ogni cella un solo valore disposto su una sola riga, in modo tale che la rilettura avvenga correttamente.
Nel caso in cui si renda necessaria la strutturazione della pagina con tabelle tali da comportare dei reali problemi di comprensione dell'informazione, conviene fornire una pagina alternativa testuale che riproduca la stessa informazione in modo accessibile, (v. A13).
Suggerimenti e verifiche:
A7.1 se una tabella viene usata a scopo di impaginazione (layout) non usare alcun markup strutturale per la formattazione visiva. Per esempio non usare l'elemento HTML TH table header per far si che il contenuto di una cella sia presentato centrato e in grassetto, perché questo elemento identifica un'intestazione.
A7.2 identificare le intestazioni per righe e colonne (elementi html TD e TH)
A7.3 se le tabelle hanno delle divisioni strutturali più complesse l'HTML offre la possibilità di fornire un sommario per le tabelle (ad esempio l'attributo "summary" dell'elemento html TABLE), anche se tale attributo non viene ancora gestito da molti browser.
A7.3 Laddove le tabelle hanno divisioni strutturali ulteriori rispetto a quelle in righe e colonne, si può pensare di usare dei mark up definiti nell'HTML 4 per identificare queste divisioni (es. THEAD, TFOOT, TBODY, COLGROUP e gli attributi "axis", "scope" e "header").
Il mondo del web si è evoluto molto rapidamente e non sempre tutte le sue componenti sono aggiornate simultaneamente. Così può accadere che un nuovo elemento del linguaggio non sia letto da browser più vecchi, ma ugualmente utilizzati da molti utenti. E spesso in presenza di tecniche più moderne questi presentano una pagina bianca o incomprensibile.
Suggerimenti e verifiche:
A8.1 Per le persone vedenti i frame possono essere usati per organizzare una pagina in differenti aree. Per gli utenti non vedenti le relazioni tra i contenuti dei frame (ad esempio un frame per l'indice e un altro per la presentazione delle pagine associate alle voci dell'indice stesso) devono essere fornite con altri mezzi. Per questi elementi si può fornire una pagina alternativa ( usando l'opzione NOFRAMES in HTML alla fine di ciascun frame).
A8.2 Assicurarsi che il sorgente di ciascun frame sia un file di mark up in HTML e non un file di altro tipo, come PDF o altro.
A8.3 Per gli script che presentano informazioni o funzioni critiche, cioè fondamentali, fornire una presentazione o un meccanismo equivalente (usando il NOSCRIPT in HTML o uno script server-side).
A8.4 Per le pagine che usano gli style sheet assicurarsi che il contenuto di ciascuna pagina sia ordinato e strutturato in modo tale da essere letto in modo ordinato anche senza style sheet .
Nonostante la raccomandazione A6, occorre prevedere un modo temporaneo di presentazione fino al momento in cui gli style sheet acquisteranno una maggiore diffusione. Ad esempio, la formattazione della pagina può essere realizzata con semplici tabelle con testo in immagine (bit-map) corredato di testo alternativo.
A8.5 Per le applet e gli oggetti di programmazione, seguire le tecniche di testo alternativo e descrizione alternativa, quando necessario.
A8.6 Per le applet e gli oggetti di programmazione, fornire quando possibile una funzione o una presentazione alternativa in un formato diverso.
Sono molte le osservazioni a questo proposito. Persone con difficoltà cognitive o con disabilità della vista sono incapaci di leggere un testo in movimento.Il movimento può causare distrazione che rende il resto della pagina illeggibile da persone con disabilità. Dispositivi come gli screen reader, che permettono l'accesso ai non vedenti, non riescono a leggere testo in movimento. Persone con disabilità fisiche possono non essere in grado di muoversi con sufficiente velocità per interagire con tali oggetti. Le persone affette da epilessia fotosensitiva possono avere attacchi provocati da sfarfallii nella gamma da 4 a 59 flash/sec con un picco di sensibilità di 20 flash/sec così come da veloci cambiamenti dal buio alla luce.
Suggerimenti e verifiche:
A9.1 Per pagine che si auto aggiornano o con un contenuto temporalizzato fornire una seconda copia della pagina in cui l'aggiornamento della pagina avviene solo mediante la selezione di un link.
A9.2 Evitare variazioni del documento che causino fenomeni di sfarfallio.
A9.3 I movimenti dovrebbero essere evitati quando possibile, ma se necessari, dovrebbe essere fornito agli utenti un meccanismo che blocchi il moto o l'auto-aggiornamento dovuto a qualsiasi applicazione.
L'accessibilità degli oggetti presenti nei documenti del web che hanno un'interfaccia propria, come i file PDF o Real Audio non possono usufruire delle caratteristiche di accessibilità fornite dal browser. Così devono averne di proprie.
A questo fine l'applicazione va costruita di per se accessibile o altrimenti ne va fornita una presentazione alternativa.
Se la navigazione di tutta la pagina è prevista solo via mouse, utenti che per vari motivi non possono usufruire di questo dispositivo saranno impossibilitati ad accedervi.
Suggerimenti e verifiche:
A11.1 Per le mappe immagini, fornire il testo alternativo ai link.
A11.2 Se possibile, assicurarsi che tutti gli elementi che hanno una interfaccia propria siano gestibili via tastiera.
A11.3 Creare un ordine di tabulazione logico attraverso i link, i controlli dei form e gli oggetti ( in HTML attraverso l'attributo "tabindex"o attraverso il progetto logico delle pagine).
A11.4 Fornire comandi rapidi (shortcut) da tastiera ai link, inclusi quelli nelle mappe immagini client-side,controlli sui form e gruppi di controlli dei form, mediante l'attributo "accesskey".
Alcuni browser di vecchia generazione sono incapaci di gestire via "TAB" le aree di editing, aree di testo e liste di link consecutivi, rendendo impossibile agli utenti l'accesso. Gli utenti che non operano in ambiente grafico sono disorientati dal fatto di entrare in una nuova finestra senza avvisi.
Suggerimenti e verifiche:
A12.1 Non usare finestre di pop-up, finestre nuove o cambiamenti nella finestra attiva senza che l'utente ne sia avvertito.
A12.2 Includere valori di default nelle aree di testo e di input .
A12.3 Includere caratteri di testo, come virgole o parentesi, per separare i link adiacenti, altrimenti uno screen reader potrebbe non distinguere fra loro i link stessi.
A12.4 Finché gli user agent e gli screen reader non saranno capaci di trattare il testo presentato colonna per colonna, tutte le tabelle che strutturano il testo in colonne richiedono una trascrizione lineare alternativa dello stesso testo.
Molte tecniche non-HTML (come PDF, Shochwave ecc.) usate per codificare informazioni richiedono o plug-in o applicazioni stand-alone che creano spesso pagine cui non si può accedere usando tool di accesso standard. Ci sono comunque casi nei quali le stesse tecnologie W3C possono dar luogo a pagine che non si trasformano adeguatamente ( ad esempio perché le componenti visuali sono troppo complesse o perché i browser non possiedono una determinata caratteristica). Evitando caratteristiche non standard, come elementi, attributi, proprietà gestite solo da un particolare browser e assicurandosi che tutte le componenti si trasformino opportunamente, le pagine saranno accessibili da un maggior numero di persone con una vasta gamma di hardware e software.
Suggerimenti e verifiche:
A13.1 Se si usano tecnologie W3C, laddove è possibile usare le più recenti.
A13.2 Se si usano tecnologie W3C, evitare l'utilizzo di componenti disapprovate dal consorzio.
A13.2 Se, pur con tutti gli sforzi, non si può evitare di usare tecnologie diverse da quelle W3C o di usare queste in forma non accessibile, allora si deve fornire un link ad una pagina alternativa che:
usi tecnologie W3C,
sia accessibile,
abbia informazioni equivalenti
sia aggiornata quanto quella inaccessibile originale.
A13.3 Quando viene inserito nella pagina un link ad una risorsa che non è di tecnologia W3C indicare quale tipo di risorsa sa per essere linkata. Per esempio per fare un link ad un documento PDF da un documento HTML, attivare l'attributo "type a "application/pdf" sull'elemento A.
La seconda linea guida invita a rendere massima la possibilità di utilizzo fornendo informazioni sul contesto e l'orientamento e semplificando la presentazione delle informazioni.
Fornire informazioni sul contesto e sulla presentazione significa aggiungere informazioni per aiutare gli utenti a comprendere l'aspetto generale di una pagina, una tabella, un frame o un form. Spesso gli utenti sono limitati a vedere solo una porzione della pagina, sia perché stanno accedendo alla pagina stessa parola per parola (con sintetizzatore vocale o display braille) o una sezione alla volta (display piccoli o usati con ingranditori).
Relazioni complesse tra gli elementi di una pagina possono essere di difficile interpretazione per persone con disabilità cognitive. Il raggruppamento di elementi e informazioni contestuali circa le loro relazioni, possono essere utili per tutti gli utenti.
Suggerimenti e verifiche:
B1.1 Dare un nome a ciascun frame cosicché gli utenti possano tenere traccia dei frames per nome (ad esempio attraverso l'attributo "title" sugli elementi html FRAME) (che però al momento non è interpretato dalla maggior parte dei browsers).
B1.2 Descrivere lo scopo dei frame e come i frame stanno in relazione tra loro se non è implicito nello stesso nome.
B1.3 Raggruppare i controlli dei form, in HTML con gli elementi elementi FIELDSET e LEGEND per radio buttons e checkbox.
B1.4 Associare etichette esplicitamente con loro controlli
B1.5 Creare una gerarchia di liste di scelta (esiste per esempio in HTML 4.0, con l'elemento OPTGROUP, anche se finora non sempre interpretato dai browser).
Attraverso un buon progetto, aumentare le possibilità di una persona di trovare ciò che sta cercando e di poter facilmente navigare all'interno del sito. Una struttura di navigazione chiara porterà benefici non solo alle persone con disabilità cognitive, ma a chiunque visita il sito.
Suggerimenti e verifiche:
B2.1 Dove possibile, fare le frasi di link chiare se lette a sé stanti. Evitare espressioni senza senso del tipo "clicka qui". Una tecnica di esplorazione di una pagina Web mediante uno screen reader è quella di usare i comandi per saltare da un link all'altro, con lettura della parola o frase linkata; se questa è significativa, permette di capire subito dove conduce il link associato senza bisogno di leggere il contesto.
B2.2 Usare una struttura di navigazione chiara e coerente.
B2.3 Offrire una barra di navigazione per un accesso facile alla navigazione nella struttura.
B2.4 Offrire una rappresentazione dell'intera struttura del sito, spesso indicata col termine "mappa" del sito, indipendentemente dalla sua natura grafica o testuale. Deve comunque essere anch'essa accessibile.
B2.5 Fornire una descrizione dell'impaginazione (layout) generale del sito, le caratteristiche di accesso usate, e come usarle.
B2.6 Offrire tipi diversi di ricerca per livelli diversi di obiettivi e preferenze, perché gli utenti possono ricercare all'interno del sito informazione di tipo diverso. Ad esempio nel sito di un giornale si può accedere per consultare la prima pagina dell'edizione del giorno, così come cercare un'edizione passata, o cercare la presenza di articoli di un determinato giornalista. I tre obiettivi richiedono ovviamente strutture di navigazione diverse. La prima prevede la messa in linea dell'informazione con un certo risalto, rintracciabile senza dover ricorrere a troppi link successivi, perché scoraggerebbe l'utente. La seconda richiede la strutturazione di archivio del quotidiano, organizzato per giorni o per mesi, in cui l'utente possa selezionare il numero desiderato. La terza richiede l'utilizzo di un motore di ricerca che compia l'opera di ricerca sugli autori. Ogni tipo di navigazione deve essere individuato in fase di progetto de l sito.
B2.7 Facilitare la navigazione off-line creando un singolo file da scaricare per documenti strutturati in forma di insieme di pagine separate (con l'elemento LINK o creando un archivio compresso).
B2.8 Raggruppare i link correlati, come i link usati per creare una barra di navigazione, e porre un titolo significativo sull'elemento che crea il gruppo.
B2.9 Fornire un link all'inizio di un gruppo di link in relazione tra loro, per oltrepassare tutto il gruppo. Questo alleggerisce la navigazione, perché qualora un gruppo di link non fosse d'interesse dell'utente potrebbe essere superato in blocco.
Anche questo settore richiede alcune precisazioni.
I file html sono dei semplici file ASCII, editabili con un qualunque editor di testo. Tuttavia molti autori, la maggioranza ormai, utilizzano i molti programmi di sviluppo di pagine Web presenti oggi sul mercato. In genere questi strumenti operano in ambiente grafico e non testuale, e permettono la creazione di documenti spesso senza che l'utente debba scrivere nemmeno una riga di codice html, semplicemente usando tecniche grafiche. Tra i più noti certamente FrontPage di Microsoft e il Composer di Netscape.
Se l'adozione di questi strumenti rende la programmazione a portata di tutti perché non impone la conoscenza del linguaggio, però può comportare maggiori difficoltà alla realizzazione delle pagine in modo accessibile.
Evidenziamo a questo proposito quattro punti di riflessione:
1. usare strumenti che si basano sulla grafica può trarre in inganno riguardo al modo con cui queste pagine possono essere "rilette". Quello che appare in fase di composizione o di preview è solo uno dei modi con cui il documento può essere rivisto dall'utente.
2. In molti tools, non tutti gli attributi ed elementi necessari per l'accessibilità possono essere introdotti dalle finestre di pop up presentate dal tool, per esempio per richiedere il nome dell'immagine. Quindi bisogna conoscere a priori l'esistenza di questi elementi ed attributi e ne va prevista l'introduzione direttamente sul codice html. Le ultime versioni di numerosi tool prevedono anche la possibilità di editare il codice html senza ricorrere a editor esterni, facilitando così questo compito.
3. Occorre controllare il file HTML risultante perché in alcuni casi è stato riscontrato che il file salvato dal programma non mantenga tutti i tag introdotti poiché necessari all'accessibilità, specialmente quando i file vengono aperti per una correzione e nuovamente salvati. Se avviene un inconveniente di questo genere occorre procedere a rieditare il file con altro programma.
4. I tool non forniscono grossi aiuti per creare pagine accessibili, perché l'accessibilità non è per il momento un requisito obbligatorio delle pagine e quindi non c'è un interesse specifico a far si che le pagine prodotte siano tali.
Su questo ultimo punto sottolineiamo che importanti caratteristiche al riguardo sono possedute dal noto tool autore HotMetal 5.0, che prevede la possibilità di eseguire test di accessibilità sul documento in costruzione o di attivare un'opzione per suggerire i principali inserimenti necessari. Informazioni più dettagliate all'indirizzo www.softquad.com.
Tutte queste osservazioni portano alla conclusione che indipendentemente dal programma di composizione usato le regole dell'accessibilità vanno conosciute e pensate già in fase di progetto della pagina.
Per il test delle pagine si può seguire una serie di procedimenti.
1) Usare un tool di validazione automatico. Anche se i criteri per l'accessibilità non possono essere applicati in modo meccanico, ma richiedono una conoscenza dell'argomento, tuttavia esistono degli strumenti automatici che permettono di effettuare una prima valutazione dell'accessibilità del documento creato e della compatibilità con particolari browser. Sono i cosiddetti tool di validazione. Tra i principali possiamo citare:
Bobby
Questo programma effettua un controllo sia sulla conformità del documento con una determinata versione del linguaggio sia con le principali regole dell'accessibilità. Da più parti è stato sottolineato che il programma BOBBY possa essere considerato solo un primo passo per la valutazione dell'accessibilità del documento, non una garanzia completa. La versione on-line, previo riempimento di un form con l'indirizzo della pagina, manda indietro una copia della pagina, sottolineando i punti che possono creare problemi d'accessibilità. C'è anche la possibilità di scaricare l'applicazione e verificare le pagine localmente sul proprio computer.
Bobby è un servizio gratuito fornito da CAST (Centre for Applied Special Technology) che si
può trovare all'indirizzo http://www.cast.org/bobby.
Lo stesso sito fornisce anche una piccola immagine da caricare sul proprio sito a garanzia dell'accessibilità verificata col loro programma.
W3C HTML Validation Service
Un altro servizio di validazione è il cosiddetto W3C HTML Validation Service, all'indirizzo http://validator.w3.org/. Questo servizio di validazione è fornito direttamente dal consorzio W3C. Permette di verificare la conformità delle pagine rispetto alle norme dell'HTML4.0.
LynxIt
Un altro servizio, LynxIt, permette di visualizzare le pagine come le presenterebbe un browser testuale.
[http://www.home.unix-ag.org/sfx/lynxit.html]
2) Testare le pagine con un browser testuale come lynx.
3) Usare diversi browser grafici, con:
suoni e grafica caricata,
grafica non caricata,
senza mouse,
con frame, script e style sheet non caricati.
4) Usare diversi browser, nelle versioni più vecchie e più avanzate.
5) Controllare le pagine con uno spell checker.
6) Se, dopo tutti questi test e con le conseguenti modifiche nel progetto, ci si accorge che la pagina non è ancora accessibile, è obbligo creare una pagina alternativa accessibile.
Le regole espresse in precedenza sono genericamente rivolte agli "autori" di pagine web. In realtà occorre sottolineare come le categorie interessate ad esse comprendano tutti coloro che lavorano col web, perché possono influenzarne l'applicazione, sia pure a titoli diversi. Tra queste è utile distinguere:
Questa categoria è certo la prima che deve conoscere certe avvertenze per applicarle direttamente sui documenti che produce.
Per facilitare il loro lavoro vengono fornite nel seguito delle tavole sinottiche che permettono di rivedere le regole in funzione dei singoli elementi del documento. Questo può indubbiamente essere utile in fase di composizione del documento, anche se non è sufficiente a garantire l'accessibilità completa del documento stesso.
Un aspetto da non trascurare è che dalla conoscenza dei problemi dell'accessibilità può derivare per questi operatori anche una migliore conoscenza del linguaggio HTML. Infatti, la facilità con cui si riescono a costruire dei documenti spesso fa rinunciare ad un maggiore approfondimento della materia. Ci si limita a rimanere alla superficie. Questo impedisce un arricchimento professionale, utile nel presente e soprattutto utile per interpretare in modo migliore gli sviluppi futuri del settore. Sul web è piuttosto facile copiare le cose prodotte da altri, perché il codice sorgente e le componenti grafiche sono facilmente scaricabili. Resta il problema di crearsi uno stile proprio e questo si può raggiungere solo se si approfondisce la conoscenza dei linguaggi, dei tool e se ne acquista una grande padronanza. L'accessibilità offre per via indiretta anche questa possibilità.
Un'altra importante categoria investita da questo argomento è senz'altro quella dei docenti dei corsi sul web. In molti casi gli autori delle pagine, siano essi in forza ad un provider o collaboratori della compagnia che vuole costruire e gestire un nuovo sito, vengono introdotti all'argomento attraverso corsi di formazione che insegnano loro come utilizzare al meglio gli authoring tool. Se gli insegnanti di tali corsi sono a conoscenza di queste problematiche, e fin dall'inizio ne fanno partecipi i futuri autori, l'apprendimento del progetto di siti web avviene in parallelo con quello dei principi di accessibilità. Assorbirli successivamente vuol dire comunque cambiare l'approccio che i nuovi autori hanno alla progettazione, e questo sicuramente richiede uno sforzo maggiore. Nel compito degli insegnanti si possono sottolineare due aspetti. Anzitutto essi possono introdurre l'importante principio dell'accessibilità nell'ambiente web.
Teniamo presente che l'importanza dei siti web non è limitata al settore commerciale. Questo sistema di condivisione dell'informazione coinvolge molte categorie, sia di fornitori sia di utenti, con aspetti che richiedono attenzione anche ai problemi degli utenti marginali. In particolare, per i siti che si rivolgono alla cittadinanza, come quelli della Pubblica Amministrazione, le caratteristiche di accessibilità possono risultare determinanti per la fruizione generalizzata e pertanto questo aspetto assume il connotato di un doveroso rispetto delle minoranze e non soltanto un generico segnale di attenzione.
Se una ditta commerciale può volere un sito web che attiri il più possibile l'attenzione dei navigatori, e quindi ricco di componenti grafiche e sonore d'effetto, e sia quindi indotta a sacrificare a questi aspetti il principio dell'accessibilità, un sito di una Pubblica Amministrazione dovrebbe invece essere improntato con altri criteri. Comunque non è neanche detto che un sito ricco di effetti coreografici, ma che richiede un lungo tempo di caricamento e molti applicativi per la sua visualizzazione dia migliori risultati in termini di pubblicità. Se l'utente, annoiato dall'attesa o dall'incapacità di vedere tutte le componenti del sito, cambia l'oggetto della navigazione, si ottiene l'effetto contrario.
In secondo luogo gli insegnanti possono sottolineare fin dall'inizio, le tecniche di attuazione dei principi di accessibilità. Per esempio, potrebbero far conoscere gli elementi e gli attributi direttamente coinvolti nel problema ed anche evidenziare la loro attivazione nei vari tool autore. Questo permette spesso anche una più approfondita conoscenza del linguaggio HTML, non basata solo sulla conoscenza superficiale del numero di elementi e di applicazioni messi a disposizione dal tool autore.
Anche questa categoria è tenuta a conoscere tali regole. Sono essi infatti che in genere possiedono dei siti web densi di informazioni, spesso con strutture complesse e articolate. Sono siti in generale molto frequentati e da essi prendono spunto gli utenti per creare le proprie pagine. Adottano le tecnologie più avanzate, cercando di rimanere sempre aggiornati coi nuovi sviluppi del settore. Per questo possono rappresentare un esempio da seguire per i clienti. Se i loro documenti presentano caratteristiche di accessibilità queste potranno avere una diffusione tra i loro clienti o comunque far si che si diffonda almeno la problematica.
Inoltre può anche essere utile, per guadagnare ulteriormente clienti, dimostrare attenzione a tutti gli utenti e non solo a particolari categorie.
Per i provider americani si può pensare anche ad una loro influenza riguardo alle case produttrici degli authoring tool. In Italia questo risulta piuttosto improbabile.
In questa sezione riportiamo la descrizione di alcune pagine presenti in rete, affinché possano servire come guida all'applicazione dei principi precedentemente esposti.
Consideriamo come primo esempio il sito del Trace Research and Development Center, University of Wisconsin, Madison, in particolare l'Home Page:
http://www.trace.wisc.edu/index.html.La pagina inizia con un link ad un altro documento che contiene la versione alternativa solo testuale della stessa Home Page. Questa semplice frase "Click here for a modified text version of this page", al di là dell'infelice scelta della parola click per indicare la selezione del link, richiede qualche spiegazione.
Questo link indica che nel sito si mette in atto una doppia forma di accessibilità, perché, sebbene l'Home Page stessa sia realizzata in modo accessibile, viene fornita anche una pagina alternativa solo testuale per chi volesse valersi di questo tipo di navigazione.
La scritta che contiene il link a questa pagina alternativa è realizzata con un font più piccolo di quello del resto della Home Page ( <font size=-2> ), affinché non abbia grossa rilevanza sull'aspetto grafico della pagina e quindi non lo condizioni. E' un chiaro esempio del fatto che accessibilità non significa impoverimento dell'aspetto dei documenti, ma solo ridondanza dell'informazione. La scritta, infatti, è riletta da coloro che, per necessità o per scelta, preferiscono una navigazione testuale rispetto ad una grafica, ma non distrae coloro che invece attuano una navigazione mediante la selezione delle componenti grafiche. Allo stesso tempo, la soluzione di porre questo elemento all'inizio della pagina permette all'utente che preferisce la versione testuale di evitare una lunga, noiosa e complessa ricerca su tutta la pagina.
Comunque, come accennato sopra, l'accessibilità della home page non è affidata solamente alla sua alternativa testuale. Questa rappresenta solo una opzione a disposizione dell'utente, ma anche nella pagina principale sono applicate le regole di accessibilità con soluzioni interessanti.
Oltrepassata infatti la scritta iniziale, il corpo del documento è composto da una serie di immagini, delle quali la prima contiene il nome del sito e una concisa descrizione delle finalità dell'ente, mentre le altre elencano i quattro argomenti principali presenti. Si sottolinea come in questo caso, per ragioni estetiche, sia stato scelto di realizzare dei testi mediante delle immagini, fatto questo che non presenta differenze per l'utente vedente e dotato di un browser grafico, ma che rappresenta una realizzazione tecnicamente diversa della componente e quindi un filtraggio completamente diverso da parte del browser che visualizza il documento. Infatti la componente di tipo testuale è costituita da una serie di caratteri ASCII digitati in sequenza all'interno del documento, mentre la componente grafica è costituita da un file separato, generalmente GIF o JPEG, che viene richiamato dal documento HTML principale tramite, ad esempio, l'e lemento IMG. Questo dettaglio, apparentemente irrilevante, risulta però di fondamentale importanza dal punto di vista dell'accessibilità, perché, come già sottolineato più volte, la forma testuale è accessibile, quella grafica può non esserlo.
Per questo le componenti grafiche sopra citate sono correttamente fornite di testo alternativo (attributo "alt" di elementi come IMG) che in questo caso specifico è esattamente uguale alla dicitura presente nell'immagine. In questo modo si garantisce sia il rilievo grafico di queste informazioni sia la loro lettura anche da chi non è in grado di vedere le immagini.
Da notare che queste immagini sono disposte in colonna senza l'utilizzo di tabelle, ma semplicemente con l'ausilio dell'elemento <br> per il ritorno a capo. Qualora si possa ricorrere a soluzioni equivalenti, è un buon metodo evitare l'adozione di un elemento sempre critico come la tabella.
Proseguendo la descrizione della pagina ci imbattiamo in una toolbar che serve per indice e mappa del sito. In essa sono contenuti tutti gli argomenti principali del sito, tra i quali i 4 soggetti già espressi dalle immagini sovrastanti, e gli altri elementi canonici di una pagina web, quali il riferimento all'ente ospitante, il riferimento ad una pagina o ad un indirizzo di posta elettronica per avere informazioni ulteriori a quelle presenti sul sito ed infine il collegamento ad un motore di ricerca per una ricerca mirata e non guidata da percorsi fissi come quella tramite link.
La realizzazione tecnica di questa barra è tramite una tabella di 4 righe per 5 colonne.
La prima riga è però costituita da una sola cella, che si estende su tutte le colonne, in cui è presente un link alla pagina di benvenuto.
La seconda riga di 5 celle presenta quella dell'argomento selezionato in controcolore rispetto alle altre. Questo crea un effetto visivo di notevole impatto, ancor più evidenziato da una sottolineatura dello stesso colore di sfondo di questa cella, di spessore di pochi pixels ma estesa alle cinque colonne. Per inciso, questo effetto si propaga alle altre pagine del sito, perché in ognuna di esse è in controcolore l'argomento di cui si occupa la pagina stessa.
La terza riga contiene solo 4 celle, poiché una di esse si estende su due colonne. Esse contengono gli elementi canonici della pagina.
Naturalmente, in tutte le immagini sono presenti i tag "alt".
Un particolare della pagina che rimane nascosto a molti utenti è la presenza di due immagini di 30x1 pixel, dello stesso colore del background poste all'inizio e alla fine della toolbar. Tali immagini, praticamente invisibili all'utente normodotato e in possesso di computer con caratteristiche grafiche, trasportano però informazione con l'attributo "alt", che indica rispettivamente nella prima l'inizio (alt="start toolbar") e nella seconda la fine della toolbar (alt="end toolbar"). Con questo accorgimento, gli utenti che navigano in modo testo potranno essere informati in anticipo circa il tipo d'oggetto con cui hanno a che fare e quindi procedere ad una navigazione più veloce al suo interno. Anche questo è un chiaro esempio del principio di riconfigurabilità delle pagine.
La pagina dunque offre molti spunti per l'applicazione dei criteri d'accessibilità, in particolare riguardo alla capacità di trasformazione dei documenti secondo le caratteristiche proprie del browser. Mette in evidenza che molte soluzioni vanno pensate già in fase di progettazione e sottolinea la difficoltà cui va incontro l'autore, qualora volesse aggiungerle solo dopo la completa costruzione della pagina.
Un altro utile esempio è rappresentato dal sito del Center for Applied Special Technology, http://www.cast.org/. Esaminiamo in dettaglio la pagina della mappa del sito che offre un'ampia panoramica di diverse funzioni.
Anzitutto, questa pagina è un'applicazione di mappa del sito in forma testuale e non grafica. Il corpo del documento è infatti costituito da un lungo elenco di argomenti strutturato in una serie di liste fino a 5 livelli di specificazione (es. Cap.1, 1.1, 1.1.1, ecc.).
Ma la particolarità di questa pagina, come di tutto il sito, è anche la presenza di numerose caratteristiche di accessibilità, introdotte dall'HTML 4, la cui applicazione sarà poi descritta in dettaglio.
La struttura della pagina è composta da 4 blocchi principali, definiti mediante l'elemento Div: header, navigation, body e footer, il cui significato è evidente. La presentazione della pagina è realizzata mediante tabelle.
La prima tabella è costituita da una riga con due celle e contiene l'intestazione: in una cella l'identificativo della pagina (site map), nell'altra il link all'home page, realizzato con un'immagine fornita di attributo "alt". Questa è la sezione "header".
Al di sotto, separata da un Horizontal Rule (HR), un'altra tabella di due righe, in cui la prima riga è composta da due celle contenenti rispettivamente la sezione "navigation" e quella "body", che costituisce la vera e propria informazione della pagina, cioè la mappa estesa descritta sopra.
La porzione Navigation è realizzata attraverso una mappa immagine client side che definisce 9 aree sensibili, ciascuna di forma rettangolare, poste una sopra l'altra, a mo' di lista. La mappa è fornita di un tag alternativo complessivo per tutta la lista, ma anche di un tag "alt" per ognuna delle zone calde della mappa stessa.
Si sottolinea come la presenza su ogni pagina del menu di navigazione faciliti l'orientamento nel sito, come auspicato dal secondo principio fondamentale dell'accessibilità.
La seconda cella di questa riga è caratterizzata dalla lunga lista strutturata, che dettaglia sezioni e sottosezioni del sito, la quale risulta accessibile. Ogni elemento della lista è un link ad una pagina del sito.
Questa soluzione, di realizzare una riga di due celle, di cui una sola contiene testo mentre l'altra contiene un elemento grafico, rappresenta un uso non critico dell'elemento tabella, perché, relegando il testo in una sola delle celle, non ci sono problemi di confusione di lettura di celle adiacenti, neppure da parte degli screen reader per ambienti grafici.
La seconda riga, composta da una cella di larghezza pari a due colonne, contiene infine i link di navigazione, già presenti in forma grafica nella mappa client side della riga precedente, ma espressi in forma testuale.
Vediamo le applicazioni dell'accessibilità specifiche dell'HTML 4.0, in particolare l'utilizzo degli attributi ACCESSKEY e TABINDEX.
Con l'attributo ACCESSKEY degli elementi A, AREA, BUTTON, INPUT, LABEL, LEGEND, TEXTAREA vengono definiti degli short cut con i quali andare direttamente a posizionarsi su punti specifici del documento. In particolare in questo momento sono presenti:
A: About CAST
C: Concepts & Issues
T: Teaching Tools
S: Teaching Strategies
I: Initiatives
P: Participate
E: About this Site
R: Resources
M: Site Map
N: What's New
B: Bobby
F: Newsletter (Interfaces)
W: WiggleWorks
L: Learning to Read in the Computer Age
Una modalità di scelta di questo tipo facilita la navigazione, perché permette subito la selezione del link voluto. Appare superfluo sottolineare l'importanza di quelli che in italiano vengono indicati come "tasti di scelta rapida".
Va però sottolineato che all'atto pratico l'attributo ACCESSKEY presenta diversi problemi sia pratici che teorici. Anzitutto, al momento viene interpretato solo dal browser MS IE e non da altri. Questo significa che l'utilizzo di questo attributo ai fini dell'accessibilità rimane confinato all'uso di un'interfaccia grafica in unione con uno screen reader. Non si può utilizzare per esempio con navigatori a carattere testuale. Inoltre questo attributo nasconde altri due problemi. Il primo è quello di come mettere l'utente a conoscenza della presenza di short cut nella pagina. Ad esempio, nella pagina del CAST se ne fa menzione in un documento separato intitolato "about site", ma non sulla pagina stessa. L'altro problema in discussione è l'attivazione di tale attributo su piattaforme diverse, come Windows o Apple. Le specifiche dell'HTML definiscono solo l'attributo, ovvero indicano che con questo attributo si può scegliere u na lettera da associare ad un particolare elemento. Quella che non viene indicata è la sua modalità di applicazione che viene lasciata al browser. In IE uno shortcut è ad esempio attivato tramite il tasto ALT.
Questi problemi limitano al momento l'importanza dell'attributo ACCESSKEY.
L'altro attributo largamente utilizzato è TABINDEX (relativo agli elementi A, AREA, BUTTON, INPUT, OBJECT, SELECT, TEXTAREA), l'attributo per l'ordinamento dei link. La maggior parte delle persone accede ai link mediante il mouse, con la libertà di muovere il puntatore nella pagina senza seguire un percorso stabilito, ma molti browser danno la possibilità di usare il tasto TAB per muoversi da un link all'altro. In particolare, in alcuni sistemi questo è il solo modo per accedere ai link. In questo caso, il tasto TAB permette di saltare da link a link nell'ordine in cui questi appaiono nel file, che può non essere l'ordine più logico e intuitivo. L'attributo TABINDEX permette ad un progettista di specificare per ciascun link la posizione che deve avere nella sequenza di scansione con il tasto TAB. Nelle pagine del CAST è stato scelto di selezionare prima i link del corpo del testo di quelli relativi alla navigazione, anche se graficamente appaiono in ordine opposto. Purtroppo anche per questo elemento esistono delle limitazioni d'utilizzo: non è interpretato da tutti i browser.
Va sottolineato anche l'utilizzo dell'attributo "SUMMARY", che fornisce una piccola introduzione delle tabelle. Non è ben chiaro quali browser al momento lo utilizzino.
In fondo alla pagina, nella lista dei link testuali, sono presenti anche due esempi di d-link,cioè di link ad una pagina alternativa che contiene la descrizione estesa di un particolare elemento grafico, o comunque di un elemento non accessibile, legata a una semplice lettera d posta vicino all'elemento stesso. In questo esempio, ambedue i d-link presenti puntano alla stessa pagina. Il primo d-link riporta una sommaria descrizione della pagina e dei suoi principali elementi grafici, il secondo descrive il simbolo "Bobby approved", che indica l'esito positivo del test di questa pagina tramite il programma Bobby (vedi al riguardo 6.Testing e tool di validazione). I link, pur puntando alla stessa pagina hanno "ancore" in punti diversi di essa, dove è stata posta la specifica spiegazione. Al termine di essa è stato inserito un link di ritorno alla pagina di partenza, in particolare, al punto in cui è posto il d-link specifico.
Nello stesso sito, alla pagina site_about.html, si può comunque trovare una descrizione dettagliata del progetto del sito, con altre più approfondite osservazioni.
Questo sito è un esempio completo di applicazioni delle caratteristiche di accessibilità del linguaggio HTML 4 ed insieme delle difficoltà ancora esistenti di interpretazione di tali elementi ed attributi da parte dei browser.
Un altro esempio significativo di sito accessibile è quello del National Center for Accessible Media, con indirizzo: http://www.wgbh.org/wgbh/pages/ncam). In questo caso, il primo link porta alle "Istruzioni di accesso per gli utenti con disabilità", e rappresenta un esempio di applicazione della norma B2.5.
Nel documento relativo si trovano due argomenti principali: come è organizzato il sito e il dettaglio delle istruzioni per l'accesso di utenti non vedenti, ipovedenti e non udenti. Questo è uno dei molti sistemi con i quali si può facilitare la navigazione a molti utenti, con poche parole di commento alla struttura del sito.
La pagina vera e propria è costituita poi da una serie di immagini disposte a semicerchio, il cui posizionamento è stato realizzato per mezzo di una serie di tabelle nidificate. Vedremo in un esempio successivo come un effetto analogo sia stato ottenuto per mezzo di una mappa immagine. Giocando sulle dimensioni di righe e celle delle tabelle, si possono ottenere effetti visivi buoni, pur mantenendo l'accessibilità della pagina, in particolare l'adattabilità alla rilettura da parte degli screen reader. Legati alle immagini, ciascuna delle quali indica una sezione del sito, ci sono anche dei javascript che fanno si che, all'avvicinarsi del mouse, lo sfondo dell'immagine cambi colore, così da dare maggiore rilevanza all'argomento selezionato. L'utilizzo di questi script, visualizzabili solo con browser grafico, non disturba in caso di navigazione con browser testuali perché questi browser ne ignorano la presenza, né è necessaria alcuna ridondanza di informazione, perché questi script realizzano solo effetti per la presentazione.
Sulla pagina sono presenti poi anche due menu realizzati con l'elemento SELECT insieme all'elemento option, che risultano accessibili da i browser testuali.
Anche in questo esempio possiamo notare l'utilizzo di soluzioni realizzative interessanti, ma non per questo inaccessibili.
Infine consideriamo un altro esempio, specifico dell'utilizzo di una mappa immagine in modo accessibile. E' quello offerto dall'Adaptive Technology Resource Centre (ATR) http://www.utoronto.ca/atrc/. Abbiamo già visto che il linguaggio HTML permette di fornire dei singoli attributi "alt" a ciascuna zona sensibile di una mappa immagine. In questo modo, anche in caso di navigazione testuale è possibile avere l'elenco dei link. In questo sito era stata adottata in un primo tempo un'altra soluzione: l'unico tag "alt" usato era quello per l'intera mappa, ma con la dicitura [Image map of links - text equivalents below]. In questo modo si poteva accedere ai link presenti sulla mappa attraverso il loro corrispondente testuale alla fine della pagina. Certamente non era un uso canonico dell'attributo "alt", ma è una possibile soluzione. Successivamente la pagina è stata modificata introducendo la soluzione canonica dei tag alt delle aree sensibili della mappa. Varie dunque le soluzioni possibili, lasciate anche alla fantasia e alle preferenze dell'autore.
Come esempio dell'utilizzo di style sheet possiamo considerare quelli adottati dagli stessi documenti dell'accessibilità del WAI, in particolare quello denominato
"Techniques for Web Content Accessibility Guidelines",
W3c Working Draft 26-Feb-1999 ,
al momento della redazione di questo documento all'indirizzo
http://www.w3.org/TR/WD-WAI-PAGEAUTH/wai-pageauthor-tech.html.
Per la presentazione del documento sono stati utilizzati due style sheet, indicati nell'head del documento, con i quali si ottengono tutti gli effetti di colori, di cornici, ecc. che distinguono le varie parti del documento.
Esaminiamo ad esempio proprio le sezioni degli esempi presentati nel documento. Ne vengono introdotti di tipo "corretto" o di tipo cosiddetto "disapprovato". Ad ognuno di essi viene associata una diversa classe, denominata proprio example e deprecated-example.
Riportiamo porzioni di testo HTML relativi agli esempi dei frame in cui sono presenti i richiami alle classi sopra citate.
<div class="example">
<p><strong>Example.</strong></p>
<p>In this example, if the user reads "top.html":</p>
<pre>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN">
<HTML>
<HEAD>
<TITLE>This is top.html</TITLE>
</HEAD>
<FRAMESET cols="50%, 50%" title="Our big document">
<FRAME src="main.html" title="Where the content is displayed">
<FRAME src="table_of_contents.html" title="Table of Contents">
<NOFRAMES>
<A href="table_of_contents.html">Table of Contents.</A>
<!-- other navigational links that are available in main.html
are available here also. -->
</NOFRAMES>
</FRAMESET>
</HTML>
</pre>
<p>and the user agent is not displaying frames, the user will have
access (via a link) to a non-frames version of the same
information.</p>
<p class="off">End example.</p>
</div>
e
<div class="deprecated-example">
<p><strong>Deprecated example.</strong></p>
<pre>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN">
<HTML>
<HEAD>
<TITLE>A bad frameset document</TITLE>
</HEAD>
<FRAMESET cols="100%" title="Do not do this">
<FRAME name="badframe"
src="apples.gif" title="Apples">
</FRAMESET>
</HTML>
</pre>
<p>Note that if, for example, a link causes a new image to be
inserted into the frame:</p>
<pre>
<P>Visit a beautiful grove of
<A target="badframe" href="oranges.gif" title="Oranges">oranges</A>
</pre>
<p>the initial title of the frame ("Apples") will no longer match
the current content of the frame ("Oranges").</p>
</div>
Nello style sheet associato a queste classi vengono assegnate caratteristiche grafiche precise, come si rileva dal codice riportato sotto.
.example { border-style: solid;
border-width:1px;
color:#5D0091;
background-color:#F9F5DE;
border-color:#5D0091
}
.deprecated-example { border-style: solid;
border-width:1px;
color:#5D0091;
background-color:#F9F5DE;
border-color:red
}
In particolare viene assegnato lo style del bordo, la sua ampiezza, il colore del testo, il colore del background ed il colore del bordo, che è l'unico elemento che differisce.
In questo modo nel documento web esiste una chiara individuazione strutturale delle componenti esempi e esempi disapprovati, utili per ogni eventuale successiva elaborazione del documento anche automatica. La presentazione grafica viene poi assegnata dal codice degli style sheet associati al documento.
Da questo si intuisce l'estrema utilità degli style sheet per differenziare il contenuto dalla presentazione, anche se questo richiede all'autore un progetto più preciso dal punto di vista della struttura del documento.
Nota: tutti i siti scelti come esempi in questo documento hanno qualche relazione con le problematiche di utilizzo di nuove tecnologie a favore delle persone, disabili e non. Quindi la loro consultazione risulta utile non solo per vedere esempi di codice accessibile, ma anche per ampliare la conoscenza sulle tematiche dell'utilizzo delle nuove tecnologie per tutti, in particolare dei disabili.
Vedi bibliografia per il riferimento del documento completo
Dopo aver fornito in modo descrittivo i criteri di accessibilità viene adesso presentato un riassunto delle regole sotto altra forma: per blocchi di elementi. Inoltre per ciascun criterio viene riportato il valore di priorità fornito dal WAI che può essere utilizzato per chiarire l'importanza del criterio, col seguente significato:
[Priority1]
Indica che questo punto deve essere assolutamente rispettato dall'autore, altrimenti uno o più gruppi di utenti troveranno impossibile accedere all'informazione del documento. Soddisfare questo punto è un requisito base per l'accessibilità al Web di alcuni gruppi di utenti.
[Priority2]
Indica che anche questo punto deve essere rispettato dall'autore, altrimenti, anche se non ne consegue una assoluta inaccessibilità, uno o più gruppi di utenti troveranno difficile accedere all'informazione del documento. Soddisfare questo punto aumenterà notevolmente l'accesso ai documenti Web.
[Priority3]
Indica che questo punto può essere applicato dall'autore per rendere più facile l'accesso all'informazione da parte di uno o più gruppi di utenti. Soddisfare questo punto aumenterà notevolmente l'accesso ai documenti Web.
I criteri sono stati suddivisi in funzione degli elementi cui si riferiscono nel modo seguente:
Generali
Immagini e mappe immagini
Tabelle
Frame
Form
Applet e script
Multimedia
Generali
Priority 1
1. Non usare colori per fornire informazione a meno che questa non sia chiara anche dal markup o dal testo.
2. Usare combinazioni di colore di sfondo e primo piano che forniscano sufficiente contrasto quando vengono visti da persone con disturbi di percezione cromatica o con monitor in bianco e nero.
3.Per le pagine che usano style sheets, assicurarsi che i contenuti di ciascuna pagina siano ordinati e strutturati cosicché possano essere letti nell'ordine voluto anche quando lo style sheet non viene utilizzato.
4.Per pagine che si aggiornano automaticamente o con risposta temporizzata fornire una seconda copia della pagina nella quale il refresh avviene solo dopo la selezione di un link (fintanto che gli user agents non forniranno essi stessi questa caratteristica).
5.Evitare qualsiasi effetto lampeggiante o aggiornamento dello schermo che causa sfarfallio.
Priority 2
1.Nidificare correttamente gli heading ( H1 - H6).
2.Codificare la struttura e gli elementi delle liste (UL, OL, DL, LI).
3.Marcare le citazioni (es., con gli elementi Q e BLOCKQUOTE in HTML). Non usare tali mark up per realizzare effetti speciali di formattazione come rientri.
4.Usare style sheets per creare una impaginazione e la forma di presentazione, quando la maggioranza dei browser li gestirà correttamente. (si veda anche A.9). Fino ad allora usare delle tabelle semplici (per l'impaginazione) e del testo sotto forma di immagini con l'attributo alt (per gli effetti speciali), con pagine alternative usate al bisogno per assicurare che l'informazione sulla pagina sia accessibile.
5.Usare il dimensionamento e posizionamento relativo (valori percentuali) anziché quello assoluto (e.g., pixel o valore in punti).
6.Se si usano le tecnologie del W3C, usare le specifiche più recenti fin dove è possibile.
7.In ogni punto in cui è possibile, rendere le frasi di link più chiare e significative possibili quando vengano lette singolarmente o in successione. Evitare per i link frasi del tipo "Premi qui".
Priority 3
1.Creare una tabulazione logica attraverso i link, i controlli dei form, e gli objects (ad esempio attraverso un progetto logico di pagina o con l'attributo "tabindex").
2.Fornire dei tasti di scelta rapida per i link, compresi quelli nelle mappe immagine e gruppi di controllo dei form. (con l'attributo "accesskey").
3.Quando ci sono dei link a tecnologie non W3C , indicare quale tipo di risorsa viene puntata. Per esempio per linkare un file PDF da un documento HTML, inserire l'attributo "type" a "application/pdf" sull'elemento A .
4.Usare una struttura di navigazione chiara e coerente.
5.Offrire barre di navigazione per un facile accesso alla struttura di navigazione.
6.Offrire una rappresentazione dell'intera struttura del sito.
7.Fornire una descrizione dell'impaginazione del sito, delle caratteristiche d'accesso usate e dei modi per usarle.
8.Offrire tipi differenti di ricerca per differenti livelli di abilità e di preferenze.
9.Porre informazioni per il riconoscimento all'inizio dell'heading, dei paragrafi, delle liste.
10.Facilitare la navigazione off-line creando singoli file da scaricare per i documenti suddivisi in più pagine separate (usando l'elemento LINK , o creando un'archivio "zip").
11. Raggruppare i link correlati, come quelli usati per creare una barra di navigazione e porre un titolo molto esplicativo all'elemento che crea il gruppo (usare "title" per FRAME, DIV, SPAN, etc. Usare class="nav" sugli elementi che creano i gruppi di navigazione).
12. Fornire un link all'inizio di un gruppo di link correlati per oltrepassare l'intero gruppo.
13.Usare icone o grafici (con il testo alternativo) in tutti i punti in cui essi facilitino la comprensione della pagina.
14.Creare uno stile omogeneo di presentazione tra le pagine.
IMMAGINI E MAPPE IMMAGINI
Priority 1
1.Fornire testo alternativo a tutte le immagini (con l'attributo "alt" degli elementi IMG o INPUT, o attraverso l'attributo "title" o all'interno del contenuto dell'OBJECT). Nota. Questo include immagini usate come mappe immagini, spaziatori, evidenziatori degli elementi delle liste (bullets), bottoni grafici e link.
2.Per tutti i link della mappa immagine, fornire testo alternativo per ciascun link (es., con l'attributo "alt" dell'elemento AREA).
3.Sostituire gli ASCII art con un'immagine con testo alternativo
4. Fornire una long description di tutti i grafici, gli script e le applet che contengono informazioni importanti (es., in HTML, con "longdesc" di IMG, con un d-link (o un link invisibile o come contenuto di OBJECT).
Priority 2
1.Per tutti i link delle mappe immagine, creare ridondanza per mezzo di link testuali.
2.Non servirsi di mappe immagini per creare un set di bottoni in un form. Al contrario usare bottoni ed immagini separate accompagnate dal testo alternativo.
Priority 3
Nessuna raccomandazione.
TABELLE
Priority 1
1. Se si usa una tabella per il layout non usare markup strutturali allo scopo della formattazione visiva. Per esempio in HTML non usare l'elemento TH (table header) per far si che il contenuto di una cella sia visualizzato centrato e in grassetto. Altri attributi di una tabella, come una didascalia che descrive lo scopo del layout e il contenuto delle colonne, sono utili, particolarmente se alcune celle diventano barre di navigazione, frame, immagini, mappe immagini, o liste di link.
Priority 2
1.Identificare gli header per righe e colonne (gli elementi TD e TH).
2.Se le tabelle hanno divisioni strutturali che vanno oltre quelle in righe e colonne, usare markup per identificare quelle divisioni ( THEAD, TFOOT, TBODY, COLGROUP, e gli attributi "axis", "scope", e "headers", etc.).
3.Fintanto che gli user agents e gli screen readers non saranno capaci di trattare il testo presentato colonna per colonna, tutte le tabelle che servono a disporre il testo su più colonne richiedono un testo lineare alternativo (sulla pagina corrente o altrove).
Priority 3
1.Fornire riassunti delle tabelle (attraverso l'attributo"summary" sugli elementi html TABLE).
Priority 3
Nessuna raccomandazione.
FRAMES
Priority 1
1. Fornire una pagina alternativa ( usando NOFRAMES in HTML alla fine di ciascun frameset).
2. Assicurarsi che il sorgente di ciascun frame sia un file in un linguaggio di markup, come HTML.
3. Dare un nome a ciascun frame cosicché gli utenti possano ricordarsi dei frame attraverso i nomi (e.g., via the "title" attribute on HTML FRAME elements).
Priority 2
1. Descrivere lo scopo dei frame e come i frame sono in relazione gli uni con gli altri se non risulta ovvio dallo stesso nome del frame. (es., in HTML, usa "longdesc". Fino a quando "longdesc" non sarà gestito dalla maggioranza dei browser, usare anche un d-link o un d-link invisibile).
Priority 3
Nessuna raccomandazione.
FORMS
Priority 1
Nessuna raccomandazione.
Priority 2
1. Per tutti i controlli dei form con etichette implicitamente associate, assicurarsi che le etichette siano posizionate adeguatamente. L'etichetta deve precedere immediatamente il suo controllo sulla stessa linea (permettendo più di un controllo/label per linea) oppure può essere sulla linea prima del controllo.
2. Raggruppare i controlli del form ( usare gli elementi FIELDSET e LEGEND) per radio buttons and checkboxes.
3. Associare le labels esplicitamente ai loro controlli (usare LABEL e il suo attributo "for").
4. Creare una gerarchia di long lists di scelte (con l'elemento HTML OPTGROUP ).
Priority 3
1. Includere valori di default nelle edit boxes and text areas (e.g., TEXTAREA and INPUT in HTML).
2.Includere caratteri non-linkabili e stampabili (circondati da spazi) tra i link adiacenti.
APPLETS AND SCRIPTS
Priority 1
1.Fornire testo alternativo per tutte le applets e altri oggetti di programmazione (es., in HTML, con l'attributo "alt" o all'interno del contenuto della APPLET, o attraverso l'attributo "title" o all'interno del contenuto di OBJECT). (Si veda anche A.11)
2.Per scripts che presentano informazioni o funzioni critiche fornire una presentazione o un meccanismo equivalente (usando NOSCRIPT in HTML, o uno script server side.).
Priority 2
1. Per le applet e gli oggetti di programmazione, quando possibile fornire una funzione alternativa o una presentazione in un formato diverso dall'applet.
2. Le immagini in movimento dovrebbero essere evitate quando possibile, ma se devono essere usate, fornire un meccanismo per permettere all'utente di fermare il movimento o gli aggiornamenti in applet e script o l'uso di style sheet o script per creare movimento.
3.Dove è possibile, rendere accessibili gli elementi di programmazione, come script e applet. Se l'informazione o la funzione è importante, presentarla anche in altro modo.
4.Se possibile, assicurarsi che tutti gli elementi che hanno un'interfaccia propria siano gestibili da tastiera.
5.Non usare finestre di pop-up, nuove finestre o cambiare quelle attive senza che l'utente sia messo a conoscenza di ciò che sta avvenendo.
Priority 3
Nessuna raccomandazione.
MULTIMEDIA
Priority 1
1.Per file audio stand alone, fornire una trascrizione testuale di tutte le parole dette o cantate e di tutti i suoni significativi.
2.Per l'audio associato al video, provvedere una trascrizione testuale (dei dialoghi e suoni necessari alla comprensione del contesto) sincronizzata col video (sottotitoli e didascalie).
3.Per le piccole animazioni come le gif animate fornire il testo alternativo
4.Per i filmati fornire descrizioni audio sincronizzate con il video e armonizzate con l'audio originale.
Priority 2
Nessuna raccomandazione.
Priority 3
Nessuna raccomandazione.
SE COMUNQUE OGNI TENTATIVO DESCRITTO SOPRA NON PRODUCE UN DOCUMENTO ACCESSIBILE (ovvero non si può evitare di usare una tecnologia non W3C o tale tecnologia è usata in modo non accessibile),
occorre fornire un link ad una pagina alternativa che:
usi le tecnologie W3C ,
sia accessibile,
abbia informazioni equivalenti,
venga aggiornata più spesso possibile rispetto alla pagina originale
1. ASCII ART : insieme di caratteri di testo e/o simboli combiati insieme per creare un'immagine. Per esempio ";-)" esprime un sorriso.
2. browser : programma di navigazione in Internet e di lettura di ipertesti.
3. mark up: istruzioni del linguaggio HTML racchiuse tra i caratteri <e >.
4. screen reader : programma di rilettura dello schermo per sintesi vocale e/o display Braille.
5. tecnologia adattiva: tecnologia usata per adattare i dispositivi alle esigenze di utenti diversamente abili.
6. tecnologia W3C: specifiche e tecniche raccomandate e certificate dal consorzio W3C.
7. WAI: Web Accessibility Initiatives.
Autori
Ultimo aggiornamento:3 Maggio 1999
Copyright © 1999 - Laura Burzagli & Paolo Graziani
Riproduzione vietata in qualsiasi forma senza il consenso degli autori