Tecniche centrali per l'accessibilità dei contenuti
Web 1.0
W3C - 6 Novembre 2000
- Questa versione:
- http://www.w3.org/TR/2000/NOTE-WCAG10-CORE-TECHS-20001106/
- (plain text, PostScript, PDF,
gzip tar file of HTML, zip archive of HTML)
- Ultima versione:
- http://www.w3.org/TR/WCAG10-CORE-TECHS/
- Versione precedente:
- http://www.w3.org/TR/2000/NOTE-WCAG10-CORE-TECHS-20000920/
- Redazione:
- Wendy Chisholm, W3C;
Gregg Vanderheiden, Trace R &
D Center University of Wisconsin - Madison;
Ian Jacobs, W3C
Copyright ©1999
- 2000 W3C® (MIT, INRIA,
Keio), All Rights Reserved. W3C liability,
trademark,
document
use and software
licensing rules apply.
Questo documento descrive le tecniche per creare contenuti accessibili applicabili
alle nuove tecnologie. Si propone di aiutare gli autori di pagine web che vorrebbero
adottare le tecniche delle Linee
guida per l'accessibilità ai contenuti del Web 1.0. Mentre le tecniche
contenute in questo documento dovrebbero aiutare i "webmaster" che vogliono adeguarsi
agli standard delle linee guida per l'accessibilità 1.0, le linee guida
per l'accessibilità non solo non ne garantiscono la conformità
ma non sono neanche l'unico modo con cui un autore può produrre contenuti
conformi.
Questo documento fa parte di una serie di documenti sulle tecniche per la redazione
di contenuti web accessibili. Per informazioni sugli altri documenti della serie,
si deve fare riferimento alle Linee guida per l'accessibilità
ai contenuti del Web 1.0.
Questa versione è stata pubblicata per correggere alcuni collegamenti
sbagliati presenti nella versione precedente.
La versione del 6 novembre 2000 di questo documento è una nota in una
serie di note prodotte e firmate dal Gruppo di lavoro per le linee guida dell'accessibilità
Web Content Accessibility Guidelines Working
Group (WCAG WG).
Questa nota non è stata rivista nè firmata dai membri del W3C.
La serie di documenti sostituisce il singolo documento del 5 maggio 1999 del
W3C Note sulle tecniche per l'accessibilità dei contenuti web (5 May 1999 W3C Note Techniques
for Web Content Accessibility Guidelines 1.0)
L'argomento dell'ultimo documento è stato diviso in "specifiche
- tecnologiche" che possono svilupparsi in maniera indipendente. Le più piccole
specifiche tecnologiche permettono agli autori di concentrarsi su particolari
tecnologie.
Mentre le "Linee guida per l'accessibilità ai contenuti del Web
1.0." costituiscono un documento stabile, questa serie di manuali sono
in attesa dell'evoluzione delle tecnologie e dei contenuti.
È disponibile la storia dei cambiamenti della serie di documenti intesa
come una lista di problemi aperti e chiusi. I lettori sono incoraggiati a commentare
il documento e a proporre una soluzione ai problemi ricorrenti.
L'iniziativa per l'accessibilità del web del W3C rende disponibile una
grande varietà di risorse per l'accessibilità. Le linee guida
del WAI sono prodotte come parte dell'Attività Tecnica del WAI. Le reti
del Gruppo di Lavoro per le Linee Guida sull'Accessibilità sono descritte
nella carta costituzionale (charter).
Punti di controllo in questa sezione:
- 2.1 Assicurarsi che tutta l'informazione veicolata dal colore
sia disponibile anche senza, per esempio grazie al contesto o ai marcatori
<em> e <strong>. [Priorità 1]
- 3.1 Preferire sempre il testo alle immagini per trasmettere
l’informazione. [Priorità 2]
- 3.3 Usare i fogli di stile per controllare la struttura e la
presentazione. [Priorità 2]
- 3.5 Usare gli header (h1, h2, h3, h4, h5, h6) per strutturare
il documento. [Priorità 2]
- 3.6 Utilizzare in modo appropriato i punti delle liste. [Priorità 2]
- 5.3 Non usare le tabelle per il layout della pagina, altrimenti
provvedere la pagina di un testo lineare equivalente. [Priorità 2]
- 5.4 Se si usa una tabella per il layout della pagina, non usare
nessun tag per la formattazione della pagina. [Priorità 2]
- 6.4 Assicurarsi che i gestori di eventi di script e applets
siano indipendenti dai dispositivi di input. [Priorità 2]
Quando si progetta un documento o una serie di documenti, gli sviluppatori
di contenuti devono lottare prima per identificare la struttura desiderata per
i loro documenti, poi devono pensare a come deve essere presentato agli utenti.
Distinguere la struttura del documento dalla sua presentazione offre molti vantaggi,
inclusi i miglioramenti ad accessibilità, amministrazione e navigabilità.
L'identificazione di struttura e presentazione puo' cambiare a volte. Per esempio,
molti webmaster pensano che una riga orizzontale possa comunicare una divisione
strutturale. Questo puo' essere vero per gli utenti vedenti, ma per i non vedenti
e per tutti coloro che utilizzano un browser non visuale, una riga orizzontale
non ha nessun significato. Per esempio, in HTML, chi fa una pagina puo' usare
i tag H1, H2...H6 per identificare nuove sezioni di testo. Questi tag possono
essere completate da elementi grafici (come le linee), ma non essere
sostituiti da essi.
Chi fa una pagina web non dovrebbe usare elementi strutturali per ottenere
effetti di presentazione. Per esempio, in HTML, se l'elemento BLOCKQUOTE viene
interpretato da alcuni browser come il rientro del testo, da altri viene interpretato
come un a citazione, che non è un effetto di presentazione bensì
una strutturazione del testo.
La separazione della presentazione dalla struttura di un documento XML è
uguale, come si puo' leggere nella Guida XML [WALSH].
I browser HTML sono molto codificati. Un primo livello appare con la codifica
degli headers, per come il browser interpreta il tag H1. Ancora, dato che
documenti XML non hanno tag fissi, questo approccio non funziona. La presentazione
di un documento XML dipende dai fogli di stile.
Test veloce! Per determinare se i contenuti
sono strutturali o di presentazione, create una bozza del vostro documento.
Ogni punto della gerarchia denota un cambio strutturale. Usare un tag di struttura
per segnare questi cambiamenti e i tag di presentazione per la visualizzazione.
Notificare che le regole orizzontali non appariranno in questa bozza e perciò
non sono strutturali ma di presentazione.
Nota. Questo test indirizza la struttura di capitoli, sezioni
e paragrafi, per determinare la struttura senza l'uso di frasi, abbreviazioni,
cambi di lingue, definizioni e liste.
Punti di controllo in questa sezione:
- 1.1 Fornire un equivalente testuale per ogni elemento non di
testo (per esempio, mediante "alt", "longdesc"). Questo comprende: immagini, rappresentazioni grafiche
di testo (compresi i simboli), zone di immagini sensibili, animazioni (ad
es. GIF animate), applet e oggetti programmati, arte ASCII, frame, script,
immagini usate come richiamo per elenchi, spaziatori, bottoni grafici, suoni
(azionati con o senza l'intervento dell'utente), file di solo audio, tracce
audio-video e video. [Priorità 1]
- 1.2 Fornire collegamenti di testo ridondanti per ogni zona
attiva di una immagine sensibile sul lato server. [Priorità 1]
- 1.5 Fino a che gli user agents non forniscono la possibilità di avere testi equivalenti per le mappe immagine lato client, fornire link di testo ridondanti per ogni regione attiva della mappa immagine lato client.
[Priorità 3]
- 12.2 Descrivere lo scopo dei frame e il modo in cui essi interagiscono
se non è evidente dai titoli dei frame da soli. [Priorità 2]
Il testo è considerato accessibile da quasi tutti gli utenti dato che
viene tradotto da screen readers, browser non visuali, lettori braille. Il testo
può essere visualizzato, ingrandito, sincronizzato con un video per creare
un caption, etc. Nel caso in cui si progetti un documento contenente informazioni
non testuali (immagini, applet, suoni, presentazioni multimediali, etc.) occorre
fornire la pagina, dove possibile, di equivalenti testuali.
Quando un equivalente testuale viene presentato agli utenti, esso compie essenzialmente
la stessa funzione del contenuto originale. Per contenuti semplici, un equivalente
testuale dovrebbe necessitare solo di una descrizione della funzione o dello
scopo del contenuto. Per contenuti complessi (cartine, grafici, etc.), l'equivalente
testuale dovrebbe essere più lungo e descrittivo.
Gli equivalenti testuali devono essere provvisti per loghi, fotografie, tasti
di submit, applets, punti elenco, ASCII art,
e tutti i links senza una mappa immagine come le immagini invisibili usate per
il l'impaginazione della pagina.
Test veloce! Una buona prova per capire se un
equivalente testuale è utile è di immaginare di leggere il documento
ad alta voce al telefono. Cosa potresti dire sul contenuto dell'immagine per
rendere la pagina comprensibile all'ascoltatore?
Come specificare l'equivalente testuale dipende dalla lingua in cui il documento
è redatto.
Per esempio, a seconda dell'elemento, l'HTML permette agli sviluppatori di
pagine web di specificare equivalenti testuali attraverso gli attributi ("alt"
o "longdesc" ) o gli elementi (ad esempio, l'elemento OBJECT).
I formati video, come QuickTime, permetterà agli sviluppatori di includere
diverse alternative audio e video. SMIL ([SMIL]) permette di sincronizzare audio
e video clips, con file testuali.
Nella creazione di file XML DTDs,
occorre assicurare che gli elementi che potrebbero necessitare di una descrizione
abbiano alcuni modi di associarsi con le loro descrizioni.
Gli sviluppatori devono considerare la compatibilità all'indietro quando progettano
nuovi siti o pagine web in quanto::
- alcuni browser non supportano alcuni caratteri dell'HTML,
- gli utenti possono usare vecchi browser o video players,
- problemi di compatibilità possono sorgere tra i software.
Quindi, quando si progetta per tecnologie più vecchie, dobbiamo considerare
queste tecniche:
- Fornire equivalenti testuali in linea. Per esempio, includere una descrizione
dell'immagine immediatamente dopo l'immagine.
- Fornire collegamenti ad equivalenti testuali lunghi, in un file diverso
o nella stessa pagina. Questi sono chiamati description
links o "d-links". Il testo del link dovrebbe spiegare
che il collegamento indica una descrizione. Dove è possibile,
dovrebbe anche spiegare la natura della descrizione. Comunque, gli sviluppatori
di contenuti web
However,
content
developers interessati a come il link di descrizione interesserà la
visualizzazione della pagina potranno usare link di testro più discreti
(ad esempio "[D]"), come viene raccomandato da NCAM [NCAM]. In questo
caso, dovranno anche offrire più informazioni sui target dei
link così
che gli utenti possano distinguere links che hanno come contenuto "[D]" (ad
esempio, con l'attributo "title" in HTML).
Punti di controllo in questa sezione:
- 11.4 Se, nonostante
ogni sforzo, non si può creare una pagina accessibile, fornire un collegamento
a una pagina alternativa che usi le tecnologie W3C, sia accessibile, contenga
informazioni (o funzionalità) equivalenti, e sia aggiornata con la
stessa frequenza della pagina (originale) inaccessibile. [Priorità 1]
- 6.5 Assicurarsi che il contenuto dinamico sia accessibile oppure
fornire una presentazione o pagina alternativa. [Priorità 2]
Sebbene sia possibile rendere i contenuti più accessibili, può
accadere che tutta la pagina o parte di essa resti inaccessibile. Ulteriori
tecniche per creare alternative accessibili includono:
- Permettere agli utenti di
navigare in pagine accessibili separate, contenenti le stesse informazioni
di quelle inaccessibili e aggiornate con la stessa frequenza.
- Anzichè usare pagine alternative statiche, prevedere dal lato server
script che generano versioni accessibili della pagina richiesta.
- Esempi di Frames e Scripts.
- Fornire numero di telefono, numero di fax, indirizzo e-mail o indirizzo
postale dove le informazioni sono disponibili ed accessibili, preferibilmente
24 ore su 24.
Qui ci sono due tecniche di collegamenti a pagine alternative accessibili:
- Fornire links sia all'inizio della pagina principale che di quella alternativa,
per permettere agli utenti di navigare tra di esse. Per esempio, all'inizio
di
una pagina grafica conviene inserire un link alla pagina solo testuale e,
allo stesso modo, inserire all'inizio della pagina di solo testo il link
alla pagina grafica. Assicurarsi che questi link siano i primi che gli utenti
raggiungano
con il "tab", prima di tutti gli altri link.
- Usare i meta per scegliere documenti alternativi. I browsers dovrebbero
caricare automaticamente le pagine alternative , basandosi sulle impostazioni
e le preferenze dell'utente.
Punti di controllo in questa sezione:
- 9.2 Assicurarsi che ogni elemento che possiede una sua specifica
interfaccia possa essere gestito in una modalità indipendente da dispositivo.
[Priorità 2]
- 9.3 Negli script, specificare gestori di evento logici piuttosto
che gestori di evento dipendenti da dispositivo. [Priorità 2]
- 9.4 Creare
un ordine logico attraverso link, form control ed oggetti. [Priorità 3]
- 9.5 Fornire scorciatoie da tastiera per i collegamenti importanti
(compresi quelli nelle immagini sensibili sul lato client), per i controlli
dei moduli, e per i gruppi di controlli dei moduli. [Priorità 3]
Non tutti gli utenti hanno una piattaforma grafica con un mouse o un altro
dispositivo di puntamento. Alcuni utenti utilizzano la tastiera, tastiere
alternative
o dispositivi di input vocali per navigare, scegliere le voci di un modulo,
etc. Gli sviluppatori devono assicurare che gli utenti possano interagire
con
una pagina anche senza usare un dispositivo di puntamento. Una pagina progettata
per la navigazione con la tastiera (oltre che con il mouse) dovrà essere
accessibile in generale per gli utenti che utilizzano altri dispositivi input.
Progettare una pagina per l'accesso tramite la tastiera, solitamente comporta
un miglioramento generale.
L'accesso tramite tastiera ai links e ai form controls può essere specificato
in diversi modi:
- Link delle mappe di immagini
- Provvedere un equivalente testuale per le mappe di immagini dal lato client,
o provvedere numerosi link testuali per le mappe di immagini dal lato server.
Sezione sulle mappe di immagini.
- Scorciatoie da tastiera
- Fornire di scorciatoie da tastiera così che gli utenti possano combinare
i tasti per navigare
tra i links o i form controls della pagina. Nota. Le scorciatoie
da tastiera possono essere digitate in modo diverso a seconda dei diversi
sistemi operativi. Sulle macchine Windows, i tasti "alt" e "ctrl" sono
le chiavi più frequenti mentre su quelle Macintosh, è la mela
o il tasto "clover leaf". Per esempi, consultare le sezioni
Keyboard access for links e Keyboard Access to Forms.
- Ordine di tabulazione
- L'ordine di tabulazione descrive un ordine logico per la navigazione da
un link all'altro o da un form all'altro (di solito usando il tasto "tab").
Per esempi, consultare la sezione Keyboard Access to Forms.
Alcuni elementi importano oggetti (ad esempio applets o elementi multimediali)
le cui interfacce non possono essere controllate attraverso l'uso dei tag. In
alcuni casi, gli sviluppatori, dovrebbero fornire alternative equivalenti con
le interfacce se gli oggetti importati stessi non prevedono interfacce accessibili.
Punti di controllo in questa sezione:
- 14.3 Creare uno stile di presentazione che sia consistente
su più pagine. [Priorità 3]
- 13.4 Usare meccanismi di navigazione in modo coerente. [Priorità 2]
- 13.5 Fornire
barre di navigazione per evidenziare e dare accesso ai meccanismi di navigazione.
[Priorità 3]
- 13.3 Fornire informazioni sul layout generale del sito (es.
mappa del sito). [Priorità 2]
- 13.7 Se sono
fornite funzionalità di ricerca, rendere possibili diversi tipi di
ricerca per differenti livelli di abilità e per preferenze diverse.
[Priorità 3]
- 13.2 Utilizzare i metadati per aggiungere informazioni semantiche
alle pagine e ai siti. [Priorità 2]
Lo stile di presentazione di ogni pagina permette agli utenti di localizzare
meccanismi di navigazione più facilmente ma anche per trovare meccanismi
di navigazione validi a trovare importanti contenuti. Tutto ciò aiuta
le persone con letture disabilitate ma rende anche la navigazione più
semplice per gli utenti. Prevedibilmente, aumenterà la probabilità
che gli utenti trovino le informazioni nel nostro sito, o che queste siano disponibili
quando gli utenti le desiderano.
Esempi di strutture che possono apparire nello stesso posto della pagina:
- barre di navigazione
- contenuto principale della pagina
- pubblicità
Un meccanismo di navigazione crea una serie di percorsi che un utente può
intraprendere nel nostro sito. Fornendo il sito di una barra di navigazione,
di una mappa del sito, di strumenti di ricerca, possiamo aumentare la probabilità
di far trovare le informazioni all'utente. Se il vostro sito è di natura
visuale, la struttura potrebbe essere più difficile da navigare se gli
utenti non hanno una "mappa mentale" del sito per capire
dove stanno andando o dove sono stati. Per aiutarli, gli sviluppatori dovrebbero
descrivere ogni meccanismo di navigazione. È cruciale il fatto che le
descrizioni e le guide del sito siano accessibili, in modo che gli utenti possano
contare su di essi per orientarsi nel sito.
In presenza di dispositivi di ricerca, gli sviluppatori dovrebbero fornire
meccanismi che soddisfino diversi livelli di ricerca e diverse preferenze.
Alcuni
motori permettono agli utenti di cercare le parole tramite le parole chiave.
Gli utenti con difficoltà di linguaggio ed ortografia, potranno avere
dei problemi a trovare cosa gli serve se il motore richiede una ortografia
precisa.
I motori di ricerca possono includere uno spell checker, offrendo
le migliori alternative maggiormente simili a quanto scritto.
Punti di controllo in questa sezione:
- 14.1 Usare il linguaggio più chiaro e semplice possibile
che sia adatto al contenuto di un sito. [Priorità 1]
- 13.8 Posizionare l'informazione più significativa all'inizio
delle intestazioni, dei paragrafi, delle liste, ecc. [Priorità 3]
- 14.2 Integrare
il testo con presentazioni grafiche o uditive nei casi in cui esse possano
facilitare la comprensione della pagina. [Priorità 3]
Le seguenti sezioni discutono le tecniche che aiutano la comprensione di una
pagina o di un sito.
I seguenti stili di scrittura suggeriscono gli aiuti per rendere il contenuto
del sito più leggibili da tutti, specialmente dalle persone con difficoltà
di lettura e / o di ortografia. Diverse guide (inclusa [HACKER]) discutono questi e altri
stili di scrittura più dettagliatamente.
- Sforzi per una accurata intestazione e descrizione dei link. Questo include
l'uso di link testuali chiari anche se letti fuori dal contesto della serie
di link (alcuni utenti navigano saltando da un link all'altro, ascoltando
solo il testo del link testuale). Usare intestazioni informative così
che gli utenti possano scorrere velocemente la pagina e capire le informazioni
trattate, senza dover leggere tutta la pagina.
- Definire lo scopo della frase o del paragrafo iniziale (chiamato "front-loading"
= "frontespizio"). Questo potrà aiutare le persone
con dispositivi visuali (skimming visually) ma anche coloro che fanno uso
di sintetizzatori vocali. "Skimming" with speech currently significa che
gli utenti possono saltare da un titolo all'altro, da un paragrafo all'altro,
e ascoltare solo alcune parole per determinare un blocco di informazioni
(heading, paragrafi, link, etc.) che gli interessa. Se l'idea principale
del paragrafo
si trova nel mezzo o verso la fine, gli speech users dovranno ascoltare gran
parte del documento prima di trovare quello che vogliono. A seconda di cosa
gli utenti stanno cercando e quanto conoscono sull'argomento, vengono cercate
caratteristiche che possono aiutare gli utenti a localizzare le informazioni
più velocemente.
- Limitare ogni paragrafo ad una sola idea principale.
- Evitare parole in dialetto, gerghi e termini troppo specialistici in favore
di parole semplici di uso comune.
- Preferire sempre parole di uso comune.
- Usare verbi attivi piuttosto che passivi.
- Evitare frasi complesse.
Per aiutare a capire se un documento è facile da leggere, occorre considerare
le misure di lettura Gunning-Fog (descritte in [SPOOL] con esempi e algoritmi online
a [TECHHEAD]). Questo algoritmo solitamente
produce un punteggio basso se il documento da leggere è facile. Ad esempio,
la Bibbia, Shakespeare, Mark Twain e la Guida TV hanno tutti un indice Fog
intorno al 6. Time, Newsweek, e il Wall St. Journal hanno un indice Fog medio
intorno a 11.
Per le persone che leggono male o per nulla, equivalenti multimediali (non-testuali)
possono facilitare la comprensione. Dobbiamo stare attenti perchè le
presentazioni multimediali non sempre rendono il testo più comprensibile.
A volte, le presentazioni multimediali possono creare confusione.
Esempi di elementi multimediali che integrano il testo:
- Una tabella di dati complessi, come un grafico delle vendite di un'impresa
per il precedente anno fiscale.
- Una traduzione di un testo in un filmato che riproduce un testo a segni.
Sign Language è molto diverso da quello parlato.
- Registrazioni audio di musica, linguaggio parlato, effetti sonori possono
aiutare coloro che non possono leggere ma che possono percepire presentazioni
audio. Sebbene il testo possa essere generato attraverso i sentetizzatori
vocali, i cambiamenti in una voce registrata possono trasmettere informazioni
perse attraverso la sintesi.
Punti di controllo in questa sezione:
- 11.3 Fornire agli utenti l'informazione necessaria perché
possano ricevere i documenti in maniera che si adattino alle loro preferenze
(per es. lingua, tipo di contenuto ecc.) [Priorità 3]
Ci sono diverse strategie che permettono agli utenti di selezionare i contenuti
appropriati:
- Includere link ad altre versioni del contenuto, come una traduzione. Per
esempiom il link "vai alla versione francese di questo documento" va alla
versione francese.
- Indicare il tipo di contenuto o il linguaggio attraverso i marcatori (ad
esempio, in HTML si usano "type" e "hreflang").
- Usare trattative per servire le richieste del client. Per esempio, servire
la versione francese di un documento ai client francesi (o alle richieste
francesi al client).
Punti di controllo in questa sezione:
- 7.4 Fino a quando gli interpreti non forniranno la possibilità
di bloccare l'autoaggiornamento, non creare pagine che si autoaggiornano periodicamente.
[Priorità 2]
- 7.5 Fino a quando gli interpreti non forniranno la capacità
di bloccare l'auto-reindirizzamento, non usare marcatura per reindirizzare
le pagine automaticamente. Piuttosto, configurare il server in modo che esegua
i reindirizzamenti. [Priorità 2]
Gli sviluppatori, a volte, creano pagine che si aggiornano o che cambiano senza
che gli utenti facciano il refresh. Il refresh automatico può disorientare
molti utenti. Invece, a seconda delle preferenze, gli autori possono:
- Configurare il server per usare il codice di stato HTTP più appropriato
(301). Usare gli headers HTTP è preferibile perchè riduce
il traffico internet e i tempi del download, può essere applicato
ai documenti non-HTML e può essere usato dai browser che richiedono
solo una richiesta HEAD (ad esempio, i link checkers). Inoltre,
il codice di stato del 30x tipo fornisce informazioni come "rimossi permanentemente" o "rimossi
temporaneamente"
che non possono essere date dai META.
- Sostituire le pagine che potrebbero essere redirette con una pagina statica
contenente un normale link alla nuova pagina.
Nota. Entrambi checkpoint 7.4 e checkpoint 7.5
indirizzano i problemi posti dai browser. I browser più recenti dovrebbero
disabilitare il refresh e sostituirlo con un link alle nuove informazioni all'inizio
della pagina.
Esempi deprecati sono dati nelle "Linee guide sulle tecniche per l'accessibilità
dei contenuti web 1.0" [WCAG10-TECHS].
Punti di controllo in questa sezione:
- 7.1 Fino a quando gli interpreti non permetteranno agli utenti
di controllare lo sfarfallìo, evitare di far sfarfallare lo schermo.
[Priorità 1]
Il lampeggiare dello schermo può causare problemi agli utenti con epilessia
fotosensibile e gli sviluppatori dovrebbero evitare che questo avvenga. I fastidi
possono essere
innescati dal lampeggiare dello schermo in un campo che va dai
4 ai 59 flash al secondo (Hertz) con un picco di sensibilità intorno
ai 20 flash al secondo, come un veloce cambiamento dallo scuro al chiaro (ad
esempio, le luci stroboscopiche).
Punti di controllo in questa sezione:
- 13.9 Fornire informazione sulle raccolte di documenti (cioè
documenti composti da più pagine). [Priorità 3]
I documenti collegati possono essere letti facilmente in modalità non
in linea. Per creare un "pacchetto" coerente:
- Usare metadata per descrivere le relazioni tra i componenti del pacchetto
(link metadata in HTML).
- Usare strumenti di archiviazione come zip, tar and gzip, e StuffIt per creare
i pacchetti compressi
Questa sezione discute le strategie e le tecniche per testare i documenti web
per determinearne l'accessibilità. Questi test dovrebbero portare il
documento ad un livello massimo di accessibilità, e si valutano con la
riduzione del numero delle barriere. Comunque, alcune di questi test replicano
solo le condizioni che nascono da una disabilità; non simulano l'intera
esperienza che un utente disabile può avere. Nella realtà, le
pagine possono essere meno usabili di quello che pensiamo. Quindi, una delle
strategie raccomanda che gli sviluppatori osservino come le persone con diversi
tipi di disabilità fruiscano delle loro pagine.
Se, dopo aver completato i seguenti tests e aver fatto i vari accorgimenti
alle pagine, trovate che la pagina non sia ancora accessibile, è consigliabile
creare una pagina alternativa accessibile.
Nota. Passare questi test non garantisce la conformità
alle "Linee guida per l'accessibilità dei contenuti web 1.0".
Un validatore può verificare la sintassi delle pagine (ad esempio, HTML,
CSS, XML). Una corretta sintassi può aiutare a eliminare un numerosi
problemi di accessibilità visto che il software può interpretare
più facilmente i documenti ben formati. Inoltre, alcuni validatori possono
avvertire riguardo alcuni problemi di accessibilità basati solo sulla
sintassi (ad esempio, in un documento manca un attributo o una proprietà
importante per l'accessibilità). Da notare, comunque, che la corretta
sintassi non garantisce che il documento sia accessibile. Per esempio, possiamo
provvedere di un equivalente testuale un'immagine, secondo le specifiche del
linguaggio, ma il testo può essere inaccurato o insufficiente. Alcuni
validatori guideranno l'analisi attraverso parti più soggettive dell'analisi.
Alcuni esempi di validazione automatica includono:
- Un validatore dell'accessibilità
come Bobby (refer to [BOBBY]).
- Un validatore HTML come
W3C HTML Validation Service (refer to [HTMLVAL]).
- Un validatore CSS come W3C
CSS Validation Service (refer to [CSSVAL]).
I validatori solitamente riferiscono cosa serve a rimediare agli errori e
spesso dà esempi pratici di come risolverli. Di solito non aiutano
un autore nel percorso attraverso ogni problema ma lo aiutano a modificare
il documento
in modo interattivo.
Il WAI Evaluation and Repair Working Group ([WAI-ER]) sta lavorando allo sviluppo
di una serie di strumenti che aiuteranno gli autori non solo identificando gli
errori ma anche trovandone la soluzione in automatico.
Teniamo in mente che molti browser e sistemi operativi permettono agli utenti
di configurare le impostazioni che cambiano la visualizzazione, i comportamenti
e la riproduzione dei suoni. Con diversi browser, diversi utenti avranno
diverse
esperienze con il Web. Perciò:
- Testare le pagine con un browser
testuale come Lynx ([LYNX]) o un emulatore di Lynx come
Lynx Viewer ([LYNXVIEW]) o Lynx-me ([LYNXME]).
- Usare browsers
grafici con:
- caricamento di suoni ed immagini,
- immagini disabilitate,
- suoni disabilitati,
- mouse disabilitato,
- frames, scripts, fogli di stile e applets disabilitati
- Usare diversi browsers, vecchi e nuovi.
Nota. Alcuni sistemi operativi o alcuni browser non permottono
installazioni multiple di browser sulla stessa macchina. Può essere
difficile anche localizzare software meno recenti.
- Usare altri strumenti come
self-voicing browser (e.g., [PWWEBSPEAK] and [HOMEPAGEREADER]),
screen reader (e.g., [JAWS] and [WINVISION]),
software per ipovedenti, uno schermo piccolo, una tastiera onscreen,
una tastiera alternativa, etc.
Nota. Se un sito web è utilizzabile con uno di questi
prodotti, non è detto che il sito sarà utilizzabile con altri
prodotti. Per maggiori dettagli sulle tecnologie assistive usate per l'accessibilità
del Web rconsultare la sezione [ALTBROWSERS] .
Una persona, leggendo una pagina con un sintetizzatore vocale, potrebbe non
essere in grado di decifrare la combinazione usata per una parola con un errore
di ortografia. I controlli grammaticali aiutano ad assicurare che il contenuto
testuale della pagina sia corretto. Questo aiuterà i lettori alle prese
con documenti scritti in una lingua diversa dalla loro, o le persone che
stanno
imparando la lingua del documento. Tutto questo aumenta la comprensibilità
della pagina.
Nota. Ai tempi di questo elaborato, non tutti i browsers
supportano alcuni attributi ed elementi dell'HTML 4.01 [HTML4] che possono migliorare l'accessibilità
delle pagine Web.
Per informazioni sui browser e sugli altri agenti che supportano le caratteristiche
dell'accesibilità, consultare il sito del W3C ([WAI-UA-SUPPORT]).
In generale, va notato che i browser HTML ignorano gli attributi che non supportano
e restituiscono il contenuto degli elementi non supportati.
Punti di controllo in questa sezione:
- 11.1 Usare le tecnologie W3C quando sono disponibili e sono
appropriate per un certo compito e usare le versioni più recenti quando
sono supportate. [Priorità 2]
"Linee guida 1.0 per l'accessibilità del Web" suggeriscono di usare
le tecnologie del W3C per l'accessibilità. Le ultime tecnologie del W3C
sono disponibili alla pagina delle Relazioni
tecniche e pubblicazioni del W3C.
Le principali tecnologie del W3C:
- MathML per equazioni matematiche
- HTML, XHTML, XML per documenti strutturati
- SMIL per creare presentazioni multimediali
- CSS and XSL per definire i fogli di stile
- XSLT per creare trasformazioni di stile
- PNG per i grafici
Punti di controllo in questa sezione:
- 1.4 Per ogni presentazione multimediale temporizzata (per es.
un film o una animazione), sincronizzare alternative equivalenti (per es.
didascalie o descrizioni parlate del filmato) con la presentazione. [Priorità 1]
- 6.5 Assicurarsi che il contenuto dinamico sia accessibile oppure
fornire una presentazione o pagina alternativa. [Priorità 2]
Le presentazioni sonore devono essere accompagnate da trascrizioni testuali
ed equivalenti testuali. Quando queste trascrizioni sono presentate simultaneamente
con le presentazioni video, vengono chiamate "captions" e sono utilizzate
dalle persone che non possono ascoltare le tracce audio dei materiali visivi.
Alcuni formati multimediali (es. QuickTime 3.0 e SMIL) permettono di aggiungere
al clip multimendiale captions e trascrizioni.
Il seguente esempio dimostra che il caption può includere la voce così
come altri suoni dell'ambiente che aiutano a capire cosa sta succedendo.
Example
Captions da una scena dal film "E.T." Il telefono squilla tre volte, poi
c'è la risposta.
[Il telefono suona]
[ring]
[ring]
Pronto?"
Fine dell'esempio
Finchè il formato usato supporta tracce alternative, devono essere
resi disponibili 2 versioni del filmato, una con il caption e la descrizione
video, l'altra senza. Alcune tecnologie, come SMIL e SAMI, permettono di separare
file audio e video per combinare con i file testuali per la sincronizzazione
dei captions creati con i file audio e video.
Alcune tecnologie permettono anche agli utenti di scegliere tra diversi caption,
a seconda di come lo vogliono leggere. Per altre informazioni vedi le specifiche
SMIL 1.0 ([SMIL]).
Equivalenti per i suoni possono essere forniti in forma di testo sulla pagina
che collega a una trascrizione testuale o descrizione del file sonoro. Il link
alla trascrizione potrebbe apparire in una sezione visibile della pagina, come
la parte superiore. Comunque, se uno script carica automaticamente un suono,
potrebbe essere in grado di caricare automaticamente indicazioni visuali del
suono che c'è in quel momento e fornire una trascrizione testuale o una
descrizione del suono.
Per altre informazioni, vedi [NCAM].
Punti di controllo in questa sezione:
- 1.3 Fino a quando gli interpreti non potranno leggere automaticamente
ad alta voce l'equivalente testuale di un filmato, fornire una descrizione
audio delle informazioni essenziali del filmato di una presentazione multimediale.
[Priorità 1]
- 7.1 Fino a quando gli interpreti non permetteranno agli utenti
di controllare lo sfarfallìo, evitare di far sfarfallare lo schermo.
[Priorità 1]
- 7.3 Fino a quando gli interpreti non permetteranno agli utenti
di bloccare il contenuto in movimento, evitare il movimento nelle pagine.
[Priorità 2]
Le descrizioni sonore dei filmati provvedono descrizioni degli elementi visivi
principali, senza interferire con l'audio o i dialoghi del filmato. Gli elementi-chiave
del filmato includono azioni, linguaggio del corpo, gesti, grafica e testo visualizzato.
Le descrizioni sonore sono usate in via primaria dai non vedenti per seguire
le azioni e altre informazioni non-sonore di un materiale video.
Example.
Questo è un esempio di trascrizioni
testuali collegate di un clip dal film "Il re leone" (disponibile
a [DVS]). Notare che chi
descrive provvede una descrizione sonora di una scena e che la descrizione
è integrata della trascrizione.
Simba: Yeah!
Descrittore: Simba esce fuori, seguito dai suoi genitori.
Sarabi sorride e spinge gentilmente Simba verso suo padre. I due si siedono
fianco a fianco, guardando lo splendore del sole.
Mufasa: Guarda Simba, tutto quello che la luce tocca è il nostro
regno.
Simba: Wow.
Fine esempio
Nota. Se non ci sono importanti informazioni, per esempio, un'animazione
che descrive attraverso una voce registrata come usare il sito, allora la descrizione
sonora non è necessaria.
Per i filmati, fornire descrizioni sonore che siano sincronizzate con l'audio
originale. Vedi sezioni sulle informazioni audio
per maggiori dettagli sui formati multimediali.
Consentono alle persone con disabilità visisive o uditive di accedere
a tutte le informazioni. Permettono inoltre di indicizzare e cercare le informazioni
contenute nei materiali audio-visivi.
Includono dialoghi parlati così come altri suoni significativi includendo
suoni di sistema, musica, risate, applausi, ecc.
Per l'ultima versione delle specifiche del W3c consultare la lista del
W3C Technical Reports su http://www.w3.org/TR.
- [HTML4]
- "HTML 4.01
Recommendation", D. Raggett, A. Le Hors, and I. Jacobs, eds., 24 December
1999. This HTML 4.01 Recommendation is
http://www.w3.org/TR/1999/REC-html401-19991224/.
- [PNG]
- "PNG (Portable Network Graphics) Specification", T. Boutell, ed., T. Lane,
contributing ed., 1 October 1996. The latest version of PNG 1.0 is available
at http://www.w3.org/TR/REC-png.
- [SMIL]
- "Synchronized Multimedia Integration Language (SMIL) 1.0 Specification",
P. Hoschka, ed., 15 June 1998. This SMIL 1.0 Recommendation is http://www.w3.org/TR/1998/REC-smil-19980615/.
The latest version of SMIL 1.0 is available at http://www.w3.org/TR/REC-smil.
- [WCAG10]
- "Web Content Accessibility
Guidelines 1.0", W. Chisholm, G. Vanderheiden, and I. Jacobs, eds., 5
May 1999. This WCAG 1.0 Recommendation is http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/.
-
[WCAG10-TECHS]
- "Techniques for Web Content Accessibility
Guidelines 1.0", W. Chisholm, G. Vanderheiden, I. Jacobs, eds. This document
explains how to implement the checkpoints defined in "Web Content Accessibility
Guidelines 1.0". The latest draft of the techniques is available at http://www.w3.org/TR/WCAG10-TECHS/.
Nota: il W3C non garantisce la stabilità
di nessuna delle seguenti referenze fuori dal suo controllo. Tali referenze
sono incluse per convenienza. Le referenze dei prodotti non costituiscono approvazioni
di essi.
- [HACKER]
- Hacker, Diana. (1993). A Pocket Style Manual. St. Martin's Press, Inc. 175
Fifth Avenue, New York, NY 10010.
- [SPOOL]
- Spool, J.M., Sconlong, T., Schroeder, W., Snyder, C., DeAngelo, T. (1997).
Web Site Usability: A Designer's Guide User Interface Engineering, 800 Turnpike
St, Suite 101, North Andover, MA 01845.
- [UWSAG]
- "The
Unified Web Site Accessibility Guidelines", G. Vanderheiden, W. Chisholm,
eds. The Unified Web Site Guidelines were compiled by the Trace R & D Center at the University
of Wisconsin under funding from the National Institute on Disability and
Rehabilitation Research (NIDRR), U.S. Dept. of Education.
- [WALSH]
- Walsh, Norman. (1997). "A Guide to XML." In "XML: Principles, Tools, and
Techniques." Dan Connolly, Ed. O'Reilly & Associates, 101 Morris St,
Sebastopol, CA 95472. pp 97-107.
Una lista di browser alternativi
(tecnologie assistive ed altri browser studiati per l'accessibilità)
si trova sul sito web del WAI.
- [ALTBROWSERS]
- "Metodi di browsing
alternativi". Questa pagina elenca i diversi metodi per leggere le pagine
web (incluse le tecnologie assistive) secondo le caratteristiche dell'accessibilità
elencate in questo documento. La pagina è consultabile all'indirizzo
http://www.w3.org/WAI/References/Browsing.
- [BOBBY]
- Bobby validatore automatico di
accessibilità sviluppato da Cast.
- [CSSVAL]
- Il W3C CSS Validation Service.
- IBM's Home Page Reader.
- [HTMLVAL]
- Il W3C HTML Validation Service.
- [JAWS]
- Henter-Joyce's Jaws screen reader.
- [LYNX]
- Lynx browser solo testuale.
- [LYNXME]
- Lynx-me emulatore
di Lynx.
- [LYNXVIEW]
- Lynx Viewer emulatore
di Lynx.
- [PWWEBSPEAK]
- The Productivity Works' pwWebSpeak.
- [WAI-UA-SUPPORT]
- User Agent Support
for Accessibility
- [WINVISION]
- Artic's WinVision.
- [DVS]
- DVS Descriptive Video
Services.
- [NCAM]
- The National Center for Accessible
Media include informazioni su titoli
e descrizioni audio sul Web
- [TECHHEAD]
- Tech Head provvede informazioni su Fog
index descritto in [SPOOL].
- [WAI-ER]
- Il WAI Evaluation and Repair Working
Group
- Gruppo di lavoro per le Linee Guida per i contenuti Web:
- Jason White, Università
di Melbourne
- Gregg Vanderheiden, Ricerca e Sviluppo
- W3C Team contact:
- Wendy Chisholm
- Vorremmo ringraziare coloro che hanno contribuito con il loro tempo e i
loro consigli per realizzare queste linee guida:
- Harvey Bingham, Kevin Carey, Chetz Colwell, Neal Ewers, Geoff Freed, Al
Gilman, Larry Goldberg, Jon Gunderson, Eric Hansen, Phill Jenkins, Leonard
Kasday, George Kerscher, Marja-Riitta Koivunen, Josh Krieger, Chuck Letourneau,
Scott Luebking, William Loughborough, Murray Maloney, Charles McCathieNevile,
MegaZone (Livingston Enterprises), Masafumi Nakane, Mark Novak, Charles
Oppermann, Mike Paciello, David Pawson, Michael Pieper, Greg Rosmaita, Liam
Quinn, Dave Raggett, T.V. Raman, Robert Savellis, Jutta Treviranus, Steve
Tyler, and Jaap van Lelieveld