W3C

Tecniche centrali per l'accessibilità dei contenuti Web 1.0

W3C - 6 Novembre 2000

Questo documento è una traduzione delle Tecniche centrali per l'accessibilità dei contenuti Web 1.0.
Questo documento potrebbe contenere errori di traduzione.
La versione normativa, in lingua inglese, si trova a:

http://www.w3.org/TR/WCAG10-CORE-TECHS/
Questa versione italiana tradotta è:
http://accessibility.comune.prato.it/tradotte/TR/WCAG10-CORE-TECHS/
Traduttori:
Gruppo di lavoro U.O. Rete Civica del Comune di Prato (in particolare Denti Linda, Munastra Nadia, Nelli Enrico, Postiferi Vanessa)
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

Estratto

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.

Stato del documento

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).

Indice


1 Struttura e presentazione

Punti di controllo in questa sezione:

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.

2 Equivalenti testuali

Punti di controllo in questa sezione:

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?

2.1 Visione globale delle tecnologie

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.

2.2 Compatibilità con le versioni passate

Gli sviluppatori devono considerare la compatibilità all'indietro quando progettano nuovi siti o pagine web in quanto::

Quindi, quando si progetta per tecnologie più vecchie, dobbiamo considerare queste tecniche:

3 Pagine alternative

Punti di controllo in questa sezione:

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:

  1. Permettere agli utenti di navigare in pagine accessibili separate, contenenti le stesse informazioni di quelle inaccessibili e aggiornate con la stessa frequenza.
  2. Anzichè usare pagine alternative statiche, prevedere dal lato server script che generano versioni accessibili della pagina richiesta.
  3. Esempi di Frames e Scripts.
  4. 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:

  1. 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.
  2. 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:

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.

3.1 Controlli indipendenti dal dispositivo per interfacce

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.

4 Navigazione

Punti di controllo in questa sezione:

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:

  1. barre di navigazione
  2. contenuto principale della pagina
  3. 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.

5 Comprensione

Punti di controllo in questa sezione:

Le seguenti sezioni discutono le tecniche che aiutano la comprensione di una pagina o di un sito.

5.1 Stile di scrittura

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.

  1. 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.
  2. 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.
  3. Limitare ogni paragrafo ad una sola idea principale.
  4. Evitare parole in dialetto, gerghi e termini troppo specialistici in favore di parole semplici di uso comune.
  5. Preferire sempre parole di uso comune.
  6. Usare verbi attivi piuttosto che passivi.
  7. 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.

5.2 Equivalenti multimediali

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:

  1. Una tabella di dati complessi, come un grafico delle vendite di un'impresa per il precedente anno fiscale.
  2. Una traduzione di un testo in un filmato che riproduce un testo a segni. Sign Language è molto diverso da quello parlato.
  3. 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.

6 Trattativa dei contenuti

Punti di controllo in questa sezione:

Ci sono diverse strategie che permettono agli utenti di selezionare i contenuti appropriati:

  1. 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.
  2. Indicare il tipo di contenuto o il linguaggio attraverso i marcatori (ad esempio, in HTML si usano "type" e "hreflang").
  3. 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).

7 Aggiornamento automatico della pagina

Punti di controllo in questa sezione:

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:

  1. 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.
  2. 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].

8 Lampeggiamento dello schermo

Punti di controllo in questa sezione:

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).

9 Documenti compressi

Punti di controllo in questa sezione:

I documenti collegati possono essere letti facilmente in modalità non in linea. Per creare un "pacchetto" coerente:

10 Validazione

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".

10.1 Validatori automatici

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:

  1. Un validatore dell'accessibilità come Bobby (refer to [BOBBY]).
  2. Un validatore HTML come W3C HTML Validation Service (refer to [HTMLVAL]).
  3. Un validatore CSS come W3C CSS Validation Service (refer to [CSSVAL]).

10.2 Strumenti di riparazione

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.

10.3 Scenari degli utenti

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ò:

  1. Testare le pagine con un browser testuale come Lynx ([LYNX]) o un emulatore di Lynx come Lynx Viewer ([LYNXVIEW]) o Lynx-me ([LYNXME]).
  2. Usare browsers grafici con:
  3. 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.
  4. 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] .

10.4 Controllo ortografico e grammaticale

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.

11 Supporto browser

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.

12 Rivisitazione delle tecnologie per l'accessibilità

Punti di controllo in questa sezione:

"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:

13 Audio e video

14 Informazioni audio

Punti di controllo in questa sezione:

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].

15 Informazioni visuali e filmati

Punti di controllo in questa sezione:

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.

16 Trascrizioni testuali collegate

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.


17 Referenze

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/.

18 Risorse

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.

18.1 Altre linee guida

[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.

18.2 Browser e altri strumenti

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.
[HOMEPAGEREADER]
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.

18.3 Risorse per l'accessibilità

[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

19 Ringraziamenti

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