[Indice dei contenuti]   [Core Techniques]   [HTML Techniques]   [Css Techniques]  

W3C

Tecniche per le linee guida 1.0 dell'accessibilità web

W3C nota, 6 Novembre 2000

Questo documento è una traduzione delle Tecniche per le linee guida 1.0 dell'accessibilità Web.
Questo documento potrebbe contenere errori di traduzione.
La versione normativa, in lingua inglese, si trova a:

http://www.w3.org/TR/WCAG10-TECHS/
Questa versione italiana tradotta è:
http://accessibility.comune.prato.it/tradotte/TR/WCAG10-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-TECHS-20001106/
( plain, PostScript, PDF, gzip tar file of HTML, zip archive of HTML)
Ultima versione:
http://www.w3.org/TR/WCAG10-TECHS/
Versione precedente:
http://www.w3.org/TR/2000/NOTE-WCAG10-TECHS-20000920/
Editori:
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.

Sommario

Questo documento è il principale di una una serie di documenti correlati che provvedono tecniche per soddisfare le esigenze definite nel "Contenuto accessibile delle linee-guida 1.0" [WCAG10]. Questa serie include:

  1. "Techniques for Web Content Accessibility Guidelines 1.0", il documento corrente, che è l'entrata agli altri documenti.
  2. "Core Techniques for Web Content Accessibility Guidelines 1.0" ([WCAG10-CORE-TECHNIQUES]), che discute i temi dell'accessiblità e le generali tecniche che applicano attraverso tecnologie (ad es., validazioni, test, etc.).
  3. "HTML Techniques for Web Content Accessibility Guidelines 1.0" ([WCAG10-HTML-TECHNIQUES]), che provvede esempi e strategie per creare documenti HTML accessibili.
  4. "CSS Techniques for Web Content Accessibility Guidelines 1.0" ([WCAG10-CSS-TECHNIQUES]), che provvede esempi e strategie per aiutare a creare fogli di stile a cascata come parte di un progetto accessibile .

Versione di questo documento

Questa versione è stata pubblicata per correggere dei link rotti nella versione precedente.

La versione del 6 novembre di questo documento è una nota in una serie di Nota prodotte e firmate dal Web Content Accessibility Guidelines Working Group. Questa nota è stata rivista e firmata dai membri del W3C. La serie di documenti sostituiscono la 5 May 1999 W3C Nota "Techniques for Web Content Accessibility Guidelines 1.0". Quel singolo documento è stato diviso in specifici-tecnologici documenti che dovrebbero svilupparsi indipendentemente. Questi documenti specifici-tecnologici più piccoli permettono anche agli autori di focalizzare su una particolare tecnologia.

Mentre la raccomandazione delle "linee guida 1.0 per l'accessibilità" [WCAG10] è un documento stabile, questa serie di documenti ci si aspetta che si evolva appena le tecnologie cambiano e gli sviluppatori scoprono maggiori tecniche per progettare pagine e siti accessibili. Nel vicino futuro il gruppo di lavoro intende incorporare tecniche per il Synchronized Multimedia Integration Language (SMIL) [SMIL] descritto nel "Futuro dell'accessibilità dello "SMIL" ([SMIL-ACCESS]) e tecniche per Scalable Vector Graphics (SVG) [SVG] descritte in "Futuro accessibile di SVG" ([SVG-ACCESS]). Il gruppo di lavoro intende anche incorporare tecniche per tecnologie che non sono del W3C come ECMAScript, PDF and Flash.

Sono disponibili la storia dei cambiamenti alla serie di documenti così come la lista di apertura e chiusura delle pubblicazioni. I lettori sono incoraggiati a commentare il documento e a proporre risoluzioni ai correnti fatti. Prego inviate commenti dettagliati su questo documento al gruppo di lavoro a w3c-wai-gl@w3.org; gli archivi pubblici sono disponibili.

La versione inglese di questo documento è l'unica versione normativa. Però, per traduzioni in altre lingue vedi "http://www.w3.org/WAI/GL/WAI-WEBCONTENT-TRANSLATIONS".

La lista di errori conosciuti in questo documento è disponibile a "Errata in Web Content Accessibility Guidelines". Prego, riferisci gli errori di questo documento a wai-wcag-editor@w3.org.

La Web Accessibility Initiative (WAI) del World Wide Web Consortium (W3C) rende disponibili una varietà di risorse nell'accessibilità per il Web. WAI Accessibility Guidelines sono prodotte come parte del WAI Technical Activity. Gli scopi del WCAG WG sono descritti nella licenza.

È disponibile una lista di correnti raccomandazioni del W3C e altri documenti tecnici.

Tabella dei contenuti

1 Com' è organizzato questo documento

La SEZIONE 2 di questo documento riproduce le linee-guida e i punti di controllo del "Web Content Accessibility Guidelines 1.0" [WCAG10]. Ogni linea-guida contiene:

Ogni definizione di punto di controllo include:

Ogni punto di controllo è seguito da uno o più link alle tecniche nel seguente documento:

1.1 Priorità

A ciascun punto di controllo è stato assegnato dal Gruppo di Lavoro un livello di priorità, basato sull'impatto che tale punto può avere sull'accessibilità.

[Priorità 1]
Lo sviluppatore di contenuti Web deve conformarsi al presente punto di controllo. In caso contrario, a una o più categorie di utenti viene precluso l'accesso alle informazioni presenti nel documento. La conformità a questo punto di controllo costituisce un requisito base affinché alcune categorie di utenti siano in grado di utilizzare documenti Web.
[Priorità 2]
Lo sviluppatore di contenuti Web dovrebbe conformarsi a questo punto di controllo. In caso contrario per una o più categorie di utenti risulterà difficile accedere alle informazioni nel documento. La conformità a questo punto consente di rimuovere barriere significative per l'accesso a documenti Web .
[Priorità 3]
Lo sviluppatore di contenuti Web può tenere in considerazione questo punto di controllo. In caso contrario, una o più categorie di utenti sarà in qualche modo ostacolata nell'accedere alle informazioni presenti nel documento. La conformità a questo punto migliora l'accesso ai documenti Web.

Alcuni punti di controllo specificano un livello di priorità che potrebbe cambiare in determinate (indicate) condizioni.

2 Linee guida

Linea-guida 1. Fornire alternative equivalenti al contenuto audio e visivo.

Punti di controllo:

1.1 Fornire un equivalente testuale per ogni elemento non di testo (per esempio, mediante "alt", "longdesc" o contenuto nell'elemento stesso). 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 di video e video. [Priorità 1] (Punto di controllo 1.1)
1.2 Fornire ridondanti collegamenti di testo per ogni zona attiva di una immagine sensibile sul lato server. [Priorità 1] (Punto di controllo: 1.2)
Riferimenti: punto di controllo 1.5 e 9.1.
1.3 Fino a quando gli user agent 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] (Punto di controllo: 1.3)
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] (Punto di controllo: 1.4)
1.5 Fino a quando gli user agent non renderanno disponibili equivalenti testuali per collegamenti di immagini sensibili sul lato client fornire collegamenti di testo ridondanti per ogni zona attiva di una immagine sensibile sul lato client. [Priorità 3] (Punto di controllo: 1.5)
Riferimenti anche a: Punto di controllo: 1.2 and Punto di controllo: 9.1.

Linea-guida 2. Non fare affidamento sul solo colore.

Punti di controllo:

2.1 Assicurarsi che tutta l'informazione veicolata dal colore sia disponibile anche senza, per esempio grazie al contesto o ai marcatori. [Priorità 1] (Punto di controllo: 2.1)
2.2 Assicurarsi che le combinazioni fra colori dello sfondo e del primo piano forniscano un sufficiente contrasto se visti da qualcuno con deficit percettivi sul colore o se visti su uno schermo in B&N. [Priorità 2 per le immagini, Priorità 3 per il testo]. (Punto di controllo: 2.2)

Linea-guida 3. Usare marcatori e fogli di stile e farlo in modo appropriato.

Punti di controllo:

3.1 Quando esiste un linguaggio di marcatori adatto, per veicolare informazione usare un marcatore piuttosto che le immagini.[Priorità 2] (Punto di controllo: 3.1)
3.2 Creare documenti che facciano riferimento a grammatiche formali pubblicate. [Priorità 2] (Punto di controllo: 3.2)
3.3 Usare fogli di stile per controllare l'impaginazione e la presentazione. [Priorità 2] (Punto di controllo: 3.3)
3.4 Usare unità relative e non assolute nei valori degli attributi del linguaggio dei marcatori e i valori della proprietà del foglio di stile. [Priorità 2] (Punto di controllo: 3.4)
3.5 Usare elementi di intestazione per veicolare la struttura del documento e usarli in modo conforme alle specifiche. [Priorità 2] (Punto di controllo: 3.5)
3.6 Marcare le liste ed elencare le voci della lista in modo appropriato. [Priorità 2] (Punto di controllo: 3.6)
3.7 Marcare le citazioni. Non usare marcatura che definisca citazioni per ottenere effetti di formato come il rientro. [Priorità 2] (Punto di controllo: 3.7)

Linea-guida 4. Chiarire l'uso di linguaggi naturali.

Punti di controllo:

4.1 Identificare con chiarezza i cambiamenti nel linguaggio naturale del testo di un documento e in ogni equivalente testuale (per es. nelle didascalie). [Priorità 1] (Punto di controllo: 4.1)
4.2 Specificare lo scioglimento di ogni abbreviazione o acronimo nel documento laddove compare per la prima volta.[Priorità 3] (Punto di controllo: 4.2)
4.3 Identificare il linguaggio naturale principale di un documento. [Priorità 3] (Punto di controllo: 4.3)

Linea-guida 5. Creare tabelle che si trasformino in maniera elegante

Punti di controllo:

5.1 Per tabelle di dati, identificare le intestazioni di righe e colonne. [Priorità 1] (Punto di controllo: 5.1)
5.2 Per tabelle di dati che hanno due o più livelli logici di intestazioni di righe o colonne, usare marcatori per associare le celle di dati e le celle di intestazione. [Priorità 1] (Punto di controllo: 5.2)
5.3 Non usare tabelle per impaginazioni a meno che la tabella non sia comprensibile se letta in modo linearizzato. Altrimenti, se la tabella non risulta leggibile, fornire un'alternativa equivalente (che può essere una versione linearizzata). [Priorità 2] (Punto di controllo: 5.3)
5.4 Se per l'impaginazione viene usata una tabella non usare nessun marcatore di struttura per la formattazione della resa visiva. [Priorità 2] (Punto di controllo: 5.4)
5.5 Per le tabelle, fornire sommari.[Priorità 3] (Punto di controllo: 5.5)
5.6 Fornire abbreviazioni per le etichette di intestazione. [Priorità 3] (Punto di controllo: 5.6)

Riferimenti anche a Punto di controllo: 10.3.

Linea-guida 6. Assicurarsi che le pagine che danno spazio a nuove tecnologie si trasformino in maniera elegante.

Punti di controllo:

6.1 Organizzare i documenti in modo che possano essere letti senza i fogli di stile. Per esempio, quando un documento HTML viene reso senza i fogli di stile associati, deve essere sempre possibile leggere il documento. [Priorità 1] (Punto di controllo: 6.1)
6.2 Assicurarsi che gli equivalenti del contenuto dinamico vengano aggiornati quando il contenuto dinamico cambia. [Priorità 1] (Punto di controllo: 6.2)
6.3 Assicurarsi che le pagine siano utilizzabili quando script, applet, o altri oggetti di programmazione sono disabilitati oppure non supportati. Se questo non è possibile, fornire informazione equivalente in una pagina accessibile alternativa. [Priorità 1] (Punto di controllo: 6.3)
6.4 Per quanto riguarda script e applet, assicurarsi che i gestori di eventi siano indipendenti dai dispositivi di input. [Priorità 2] (Punto di controllo: 6.4)
6.5 Assicurarsi che il contenuto dinamico sia accessibile oppure fornire una presentazione o pagina alternativa. [Priorità 2] (Punto di controllo: 6.5)

Riferimenti anche al Punto di controllo: 11.4.

Linea-guida 7. Assicurarsi che l'utente possa tenere sotto controllo i cambiamenti di contenuto nel corso del tempo.

Punti di controllo:

7.1 Fino a quando gli interpreti non permetteranno agli utenti di controllare lo sfarfallìo, evitare di far sfarfallare lo schermo. [Priorità 1] (Punto di controllo: 7.1)
7.2 Fino a quando gli interpreti non permetteranno agli utenti di controllare il lampeggiamento, evitare di far lampeggiare il contenuto (cioè di cambiare la presentazione a intervalli regolari, come se si accendesse e spengesse). [Priorità 2] (Punto di controllo: 7.2)
7.3 Fino a quando gli interpreti non permetteranno agli utenti di bloccare il contenuto in movimento, evitare il movimento nelle pagine.
. [Priorità 2] (Punto di controllo: 7.3)
7.4 Fino a quando gli interpreti non forniranno la possibilità di bloccare l'autoaggiornamento, non creare pagine che si autoaggiornano periodicamente. [Priorità 2] (Punto di controllo: 7.4)
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] (Punto di controllo: 7.5)

Nota. Lo SFARFALLIO e l'elemento MARQUEE non sono definiti in nessuna specificazione HTML del W3C e non dovrebbero essere usati. Riferimenti anche alla linea guida 11.

Linea-guida 8. Assicurare l'accessibilità diretta delle interfacce utente incorporate.

Punto di controllo:

8.1 Fare in modo che elementi di programmi come script e applet siano direttamente accessibili o compatibili con le tecnologie assistive [Priorità 1 se la funzionalità è importante e non presentata altrove, altrimenti Priorità 2.] (Punto di controllo: 8.1)
Riferimenti anche alla linea guida 6.

Linea-guida 9. Progettare per garantire l'indipendenza da dispositivo.

Punti di controllo:

9.1 Fornire immagini sensibili sul lato client invece di immagini sensibili sul lato server, con l'eccezione dei casi nei quali le zone non possono essere definite con una forma geometrica valida. [Priorità 1] (Punto di controllo: 9.1)
Riferimenti anche alla Punto di controllo: 1.1, Punto di controllo: 1.2, and Punto di controllo: 1.5.
9.2 Assicurarsi che ogni elemento che possiede una sua specifica interfaccia possa essere gestito in una modalità indipendente da dispositivo. [Priorità 2] (Punto di controllo: 9.2)
Riferimento alla definizione di portabilità.
Riferimenti anche alla linea guida 8.
9.3 Negli script, specificare gestori di evento logici piuttosto che gestori di evento dipendenti da dispositivo. [Priorità 2] (Punto di controllo: 9.3)
9.4 Creare un ordine logico di tabulazione fra i collegamenti, i controlli dei moduli, e gli oggetti. [Priorità 3] (Punto di controllo: 9.4)
9.5 Fornite 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] (Punto di controllo: 9.5)

Linea-guida 10. Usare soluzioni provvisorie

Punti di controllo:

10.1 Fino a quando gli interpreti non permetterano agli utenti di bloccare la generazione di nuove finestre, non fare apparire finestre a cascata o di altro tipo e non cambiare la finestra attiva senza informare l'utente. [Priorità 2] (Punto di controllo: 10.1)
10.2 Fino a quando gli interpreti non supporteranno esplicite associazioni fra etichette e controlli dei moduli, assicurare, per tutti i controlli dei moduli che hanno etichette associate implicitamente, che l'etichetta sia posizionata correttamente. [Priorità 2] (Punto di controllo: 10.2)
10.3 Fino a quando gli interpreti (comprese le tecnologie assistive) non renderanno in modo corretto il testo affiancato, fornire un testo lineare alternativo (nella pagina attiva o in qualche altra) per tutte le tabelle che dispongono testo su colonne parallele e andando a capo. [Priorità 3] (Punto di controllo: 10.3)
10.4 Fino a quando gli interpreti non gestiranno in maniera corretta controlli vuoti, inserire caratteri di default come segnaposto nelle caselle per l'immissione di testo a una riga oppure a più righe.[Priorità 3] (Punto di controllo: 10.4)
10.5 Fino a quando gli interpreti (comprese le tecnologie assistive) non renderanno in modo distinto collegamenti adiacenti, inserire caratteri stampabili (delimitati da spazi), non facenti parte dei collegamenti, per separare i collegamenti adiacenti.[Priorità 3] (Punto di controllo: 10.5)

Linea-guida 11. Usare le tecnologie e le raccomandazioni del W3C

Punti di controllo:

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] (Punto di controllo: 11.1)
11.2 Evitare le caratteristiche delle tecnologie W3C che sono disapprovate. [Priorità 2] (Punto di controllo: 11.2)
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] (Punto di controllo: 11.3)
Nota. Usa la content negotiation dove è possibile.
11.4 Se, nonostante ogni sforzo, non si può creare una pagina accessible, 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] (Punto di controllo: 11.4)

Nota. Gli sviluppatori non dovrebbero ricorrere solamente a pagine alternative quando altre soluzioni falliscono perchè le pagine alternative sono generalmente aggiornate meno frequentemente delle pagine "primarie". Una pagina scaduta è tanto inutile come una non accessibile visto che, in entrambi i casi, l'informazione presentata sulla pagina originale non è disponibile. La generazione automatica di pagine alternative dovrebbe implicare aggiornamenti più frequenti, ma gli sviluppatori dovrebbero essere accurati per assicurare che le pagine generate abbiano sempre un senso, e che gli utenti siano in grado di navigare un sito seguendo i link sulla pagina primaria, sulle pagine alternative, o entrambi. Prima di far ricorso a pagine alternative , riconsidera il design della pagina originale; rendendola accessibie è probabile che venga migliorata per tutti gli utenti.

Linea-guida 12. Fornire informazione per la contestualizzazione e l'orientamento

Punti di controllo:

12.1 Dare un titolo a ogni frame per facilitare l'identificazione del frame e la navigazione. [Priorità 1] (Punto di controllo: 12.1)
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] (Punto di controllo: 12.2)
12.3 Dividere grandi blocchi di informazione in gruppi più maneggevoli quando è naturale ed appropriato. [Priorità 2] (Punto di controllo: 12.3)
12.4 Associare etichette esplicitamente con i loro controlli. [Priorità 2] (Punto di controllo: 12.4)

Linea-guida 13. Fornire chiari meccanismi di navigazione.

Punti di controllo:

13.1 Identificare con chiarezza l'obiettivo di ogni collegamento. [Priorità 2] (Punto di controllo: 13.1)
13.2 Fornire metadata per aggiungere informazione di tipo semantico alle pagine e ai siti. [Priorità 2] (Punto di controllo: 13.2)
13.3 Fornire informazione sulla configurazione generale di un sito (per es., una mappa oppure un indice del sito). [Priorità 2] (Punto di controllo: 13.3)
13.4 Usare meccanismi di navigazione in modo coerente.[Priorità 2] (Punto di controllo: 13.4)
13.5 Fornire barre di navigazione per evidenziare e dare accesso ai meccanismi di navigazione. [Priorità 3] (Punto di controllo: 13.5)
13.6 Raggruppare i collegamenti correlati, identificare i gruppi (per gli interpreti) e, fino a quando gli interpreti non lo fanno, fornire un modo per saltare il gruppo.[Priorità 3] (Punto di controllo: 13.6)
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] (Punto di controllo: 13.7)
13.8 Posizionare l'informazione più significativa all'inizio delle intestazioni, dei paragrafi, delle liste, ecc. [Priorità 3] (Punto di controllo: 13.8)
13.9 Fornire informazione sulle raccolte di documenti (cioè documenti composti da più pagine). [Priorità 3] (Punto di controllo: 13.9)
Per esempio, in HTML specificare gruppi di documenti con l'elemento LINK e gli attributi "rel" e "rev". Un altro modo per creare un raggruppamento è costruendo un archivio (per esempio, con zip, tar e gzip, stuffit, ecc.) delle pagine multiple.
13.10 Fornire un mezzo per saltare arte ASCII multilinea. [Priorità 3] (Punto di controllo: 13.10)

Linea-guida 14. Assicurarsi che i documenti siano chiari e semplici

Punti di controllo:

14.1 Usare il linguaggio più chiaro e semplice possibile che sia adatto al contenuto di un sito. [Priorità 1] (Punto di controllo: 14.1)
14.2 Testo supplementare con presentazioni grafiche o uditive dove faciliteranno la comprensione della pagina. [Priorità 3] (Punto di controllo: 14.2)
14.3 Crea uno stile di presentazione che sia consistente attraverso le pagine. [Priorità 3] (Punto di controllo: 14.3)

3 Glossario

Accessibile
Il contenuto è accessibile quando dovrebbe essere usato da qualcuno con disabilità.
Applet
Un programma inserito in una pagina Web.
Tecnologie assistive
Software o hardware che è stato designato specificatamente per assistere persone con disabilità per portare a termine attività gioranliere. Includono sedie a rotelle, macchine lettrici, dispositivi per comprensioni, ecc. Nell'area dell'accessibilità Web, le tecnologie assistive delle basi-software comuni includono screen readers, screen magnifiers, sintetizzatori vocali, e voice input software che operano in congiunzione con graphical desktop browsers (tra altri user agents). Le tecnologie assistive dell'Hardware includono tastiere alternative e dispositivi di puntamento.
ASCII art
Con Arte ascii ci si riferisce ai caratteri e simboli che sono combinati per creare un'immagine. Per esempio ";-)" è l'emoticon che sorride. La seguente è una figura ASCII che mostra le relazioni tra frequenti flash e fotoconvulsive risposte in pazienti con occhi aperti e chiusi [Salta la figura o consulta la descrizione del grafico]: 
 
  %   __ __ __ __ __ __ __ __ __ __ __ __ __ __   
100 |             *                             |
 90 |                *  *                       |
 80 |          *           *                    |
 70 |             @           *                 |
 60 |          @                 *              |
 50 |       *        @              *           |
 40 |                   @              *        |
 30 |    *  @              @  @           *     |
 20 |                                           |
 10 |    @                       @  @  @  @     |
      0  5 10 15 20 25 30 35 40 45 50 55 60 65 70
      Frequenza di flash (Hertz)
Authoring tool
Editori HTML, strumenti per convertire documenti, strumenti che generano contenuto Web dai database sono tutti authoring tools. Riferimento a "Authoring Tool Accessibility Guidelines 1.0" ([ATAG10]) per informazioni sullo sviluppo accessibile degli strumenti.
Backward compatible
Design che continua a lavorare con versioni più semplici di linguaggi, programmi ecc.
Braille
Braille usa 6 punti rialzati in modi differenti per rappresentare lettere e numeri per essere letti da persone che sono ciechi con le loro punte delle dita. La parola "Accessible" in braille viene:
Accessible
Un braille display, comunemente riferito come a un "dinamico display braille ," solleva o abbassa punti su comando da un dispositivo elettronico, di solito un computer. Il risultato è una linea di braille che può cambiare da un momento all'altro.
Correnti display braille dinamici raggruppano da una cella (sei o otto punti) a ottanta celle per linea, most having tra dodici e venti celle per linea.
Content developer
Qualcuno che crea pagine Web o progetta siti Web.
Deprecato
Un elemento o attributo deprecato è uno che è stato superato da uno nuovo. Elementi deprecati dovrebbero diventare obsoleti nelle versioni future dell'HTML. L'indice degli elementi e attributi HTML nei Techniques Document indica quali elementi e attributi sono deprecati nell' HTML 4.01.
Gli autori dovrebbero evitare di usare elementi e attributi deprecati. Gli utenti dovrebbero continuare a supportarli per ragioni di retrocompatibilità.
Device independent
Gli utenti devono essere in grado di interagire con un utente (and the document it renders) usando i dispositivi supportati di input e output della loro scelta e accordati ai loro bisogni. I dispositivi di input dovrebbero includere dispositivi di puntatori, tastiere, dispositivi Braille, bacchette di testa, microfoni e altri..and others. Dispositivi output dovrebbero includere monitor, sintetizzatori vocali, e dispositivi Braille.
Nota che "supporti di dispositivi indipendenti" non significa che gli utenti devono supportare ogni dispositiviìo di input e output. Gli utenti dovrebbero offrire ridondanti meccanismi di input e output o quei dispositivi che sono supportati. Per esempio, se un utente supporta tastiere e mouse, gli utenti dovrebbero essere in grado di interagire con tutti i futuri usi per ogni tastiera o mouse.
Document Content, Structure, and Presentation
Con contenuto di un documento ci si riferisce a ciò che esso dice agli utenti attraverso un linguaggio naturale, immagini, suoni, filmati, animazioni, ecc. La struttura di un documento è com' è organizzato logicamente (es. dai capitoli, con un'introduzione e tabella di contenuti, ecc.). Un elemento (e.g., P, STRONG, BLOCKQUOTE in HTML) che specifica la struttura di documenti è chiamato un elemento strutturale. La presentazione di un documento è com'è reso il documento (es. come stampa, come una presentazione grafica bi-dimensionale, come una presentazione di solo-testo, come un sintetizatore vocale, braille, ecc.) Un elemento che specifica la rappresentazine di un documento (e.g., B, FONT, CENTER) è chiamato un elemento di presentazione.
Considera il titolo di un documento, per esempio. il contenuto del titolo è ciò che dice (es. "Barche a vela"). In HTML, l'intestazione è un elemento strutturale marcato con, per esempio, un elemento H2. Alla fine, la presentazione del titolo dovrebbe essere un blocco in grassetto, testo nel margine, una linea di testo centrata, un titolo detto con un acerta voce di stile (come un font aural), ecc.
Dynamic HTML (DHTML)
DHTML è il termine applicato a una miscuglio di standard che includono HTML, fogli di stile, il Document Object Model [DOM1] e scripting. Però, non ci sono specificazioni dal W3C che formalmente definiscono DHTML. Più linee guida dovrebbero essere applicate a applicazioni che usano DHTML, però la seguente linea guida mette afuoco su questioni relazionate a scripting e fogli di stile: linea guida 1, linea guida 3, linea guida 6, linea guida 7, and linea guida 9.
Elemento
Questo documento usa il termine "elemento" per entrambi i significati dell'SGML strict (un elemento è una costruzione sintattica) e più generalmente per intendere un tipo di contenuto (come video o suono) o una costruzione logica (come un'intestazione o lista).
Il secondo significato dà risalto al fatto che una linea guida ispirata dall'HTML può facilmente essere applicata ad un altro linguaggio di Markup.
Nota che alcuni (SGML) elementi hanno un contenuto che è interpretato (es.gli elementi P, LI, o TABLE nell'HTML), alcuni sono sostituiti da contenuto esterno (es IMG), e alcuni effettuano unl'elaborazione (es STYLE e SCRIPT causano informazioni per essere processati da un foglio di stile o script engine). Un elemento che induce i caratteri del testo a fare parte del documento è denominato un elemento di testo.
Equivalent
Il contenuto è "equivalente" ad altri contenuti quando entrambi adempiono essenzialmente la stessa funzione o scopo sopra presentazione agli utenti. Nel contesto di questo documento, l'equivalente deve adempiere essenzialmente la stessa funzione per le persone con una disabilità (almeno nella misura in cui è fattibile, dato natura dell'inabilità e della condizione di tecnologia), e per le persone senza disabilità. Per esempio, il testo "La luna piena" dovrebbe portare la stessa informazione come un'immagine di una luna piena quando è presentata agli utenti. Nota che equivalenti informazioni focalizzano sul compiere la stessa funzione. Se l'immagine è parte di un link e tale immagine è essenziale per comprendere l'obiettivo del link, un equivalente deve anche dare agli utenti un'idea del bersaglio del link. Provvedere informazioni equivalenti per contenuti inaccessibili è uno dei principali modi con cui gli autori possono fare i loro documenti accessibili a persone con disabilità.
Come parte di un'adempimento del contenuto della stessa funzione, un equivalente dovrebbe coinvolgere una descrizione di quel contenuto (es. ciò che il contenuto mostrano o i suoni sembrano). Per esempio, in ordine di utenti per capire le informazioni comunicanoattraverso un grafico complesso, gli autori dovrebbero descrivere le informazioni visuali nel grafico.
Da quando il testo può essere presentato agli utenti con sintetizzatori vocali, braille, e visually-displayed text, queste linee guida richiedono testo equivalente per informazioni grafiche e audio. Il testo equivalente deve essere scritto così che essi comunichino tutti i contenuti essenziali. Non-testo equivalente (es. una descrizione uditiva di una presentazione visuale, un video di una persona che sta dicendo una storia usando il linguaggio dei segni come un equivalente per una storia scritta, etc.) migliora anche l'accessibilità per persone che non possono accedere a informazioni visuali o testo scritto, inclusi molti con cecità, inabilità conoscitive, inabilità di apprendimento e sordità.
Informazioni equivalenti potrebbero essere provvedute in tanti modi, includendo attributi (es. un valore per l'attributo "alt" in HTML and SMIL), come parte del contenuto degli elementi(es. OBJECT in HTML), come parte della prosa del documento, o tramite un documento linkato (es. indicato dall'attributo "longdesc" in HTML o una descrizione di link). Secondo la complessità dell'equivalente, potrebbe essere necessario combinare le tecniche (es. usa "alt" per un equivalente abbreviato, utile ai lettori esperti, in più un "longdesc" per un link con maggiori informazioni, utile per i lettori meno esperti).
Una trascrizione del testo è un testo equivalente di informazioni audio che include parole parlate e suoni non parlati come gli effetti sonori. Un caption è un testo trascritto per la traccia audio di una presentazione video che è sincronizzata col video e la traccia audio. I caption sono generalmente resi visibili essendo sovrapposti sopra il video, che dà benefici a persone che sono sordi, duri di udito e quando non possono sentire l'audio (es. quando si è in una stanza affollata). A trascrizione fascicolata del testo unisce (fascicola) i caption con le descrizioni delle informazioni dei video (descrizioni delle azioni, della lingua del body, grafici, e dei cambiamenti di scena delle tracce video). Questi testi equivalenti fanno presentazioni accessibili a persone che sono sorde-cieche e che non possono vedere filmati, animazioni, ecc. Mette anche a disposizione le informazioni per i motori di ricerca.
Un esempio di un testo non equivalente è una descrizione uditiva degli elementi chiave visivi di una presentazione. La descrizione è una voce umana registrata in anticipo o una voce sintetizzata (registrata o generata in moto). La descrizione uditiva è sincronizzata con la pista audio della presentazione, solitamente durante le pause naturali nella pista audio. Le descrizioni uditive includono le informazioni sulle azioni, sulla lingua di corpo, sui grafici e sui cambiamenti di scena
Immagine
Una rappresentazione grafica.
Mappa immagine
Un'immagine che è stata divisa in regioni con azioni associate. Cliccando su una regione attiva si causa una di quelle azioni.
Quando un utente clicca su una regione attiva di una mappa immagine client-side, l'user-agent calcola in quale regione il click avviene e segue il link associato con quella regione. Il cliccare su una regione attiva di una mappa imamgine server-side causa le coordinate del click per essere spedite al server, che allora realizza una certa azione.
Gli sviluppatori possono fare mappe-immagini cient-side accessibili fornendo l'accesso device-independent agli stessi collegamenti connessi con le regioni dell'immagine. Le mappe client-side permettono all' user agent di fornire immediatamente le risposte appena il puntatore dell'utente è sopra una regione attiva
Importante
Un'informazione, in un documento, è importante se spiega che l'informazione è cruciale per capire il documento.
Tabella lineare
Un processo di interpretazione dove i contenuti delle celle diventano una serie di paragrafi (es. in fondo alla pagina) uno dopo l'altro. I paragrafi si succederanno nello stesso ordine come sono definite le celle nel sorgente del documento. Le celle dovrebbero avere un senso quando lette in ordine e dovrebbero includere elementi strutturali (che crea paragrafi, titoli, liste, ecc.) così la pagina ha un senso dopo la linearizzazione.
Link text
Il contenuto del testo di un link.
Lingua naturale
Lingue umane parlate, scritte o in segni come per esempio Francese, Giapponese, Americano, linguaggio dei segni, e braille. La lingua naturale di un contenuto dovrebbe essere indicato con l'atributo "lang" in HTML ([HTML4], sezione 8.1) e l'attributo "xml:lang" in XML ([XML], sezione 2.12).
Meccanismo di navigazione
Un meccanismo di navigazione è tutto il modo da cui un utente può navigare una pagina o un sito. Dei tipici meccanismi includono:
Barre di navigazione
Una barra di navigazione è una collezione di link alla più importante parte di un documento o sito.
Mappe di siti
Una mappa provvede una vista globale dell'organizzazione di una pagina o sito.
Tabella di contenuti
Una tabella di contenuti generalmente elenca (e linka verso) la più importante sezione di un documento.
Personal Digital Assistant (PDA)
Un PDA è un piccolo, dispositivo portabile. Più PDAs sono usati per inseguire dati personali come per esempio calendari, contatti, e posta elettronica. Un PDA è generalmente un dispositivo a mano con un piccolo video che permette l'input da varie risorse.
Screen magnifier
Programma software che ingrandiscono un parte dello schermo, così che esso può essere visto più facilmente. Screen magnifiers sono usati principalmente da utenti con vista bassa.
Screen reader
Programma software che legge il contenuto del video ad alta voce ad un'utente. Screen readers sono usati principalmente da utenti che sono ciechi. Screen readers possono di solito leggere solo testo che è stampato, non disegnato.
Foglio di stile
Un foglio di stile è un insieme di dichiarazioni che specificano la dichiarazione di un documento. I fogli di stile potrebbero avere tre diverse origini: potrebbero essere scritti da content providers, creati da utenti, o costruiti nei user agents. Nei CSS ([CSS2]), l'interazione del content provider, utente, e user agent style sheets è chiamata "cascade".
Presentazione markup è un macatore che raggiunge uno stilistico (piuttosto che strutturale) effetto come per esempio gli elementi B o I in HTML. Nota che gli elementi STRONG e EM non sono considerati marcatori di rappresentazione dato che comunicano informazioni indipendentemente da un particolare stile di font.
Informazioni tabulari
Quando tabelle sono usate per rappresentare relazioni logiche tra dati -- testo, numeri, immagini, ecc., quell'informazione è chiamata "informazione tabulare" e le tabelle sono chiamate "data tables". Le relazioni espresse da un atabella dovrebbe essere resa visualizzabile (di solito su una grata bi-dimensionale), aurally (spesso precedendo celle con informazioni intestative), o in altri formati.
Finchè gli user agents ...
Nella maggior parte dei Punti di controllo, agli sviluppatori è richiesto di garantire l'accessibilità delle loro pagine e siti. Però ci sono dei bisogni che dovrebbero essere più appropriatamente conosciuti da user agents (inclusi tecnologie assistive). Come la pubblicazione di questo documento, non tutti gli user agents o tecnologie assistive provvedono i controlli di accessibilità agli utenti richiesti (per esempio, alcuni user agents potrebbero non permettere di spengere contenuto lampeggiante, o alcuni screen readers potrebbero non maneggiare bene le tabelle). I punti di controllo che contengono la frase "until user agents ..." richiedono che gli sviluppatori provvedano supporti addizionali per l'accessibilità fino a quando la maggior parte degli user agents non includa prontamente disponibile alla loro utenza il necessario per caratteristiche accessibili.
Nota. Il sito WAI Web (referito a WAI-UA-SUPPORT]) provvede informazioni su supporti user agent per caratteristiche di accessibilità. Gli sviluppatori sono incoraggiati a consultare questa pagina regolarmente per informazioni aggiornate.
User agent
Software per accedere ai contenuti Web, inclusi desktop graphical browsers, text browsers, browser vocali, telefoni cellulari, multimedia players, plug-ins, e dei software con tecnologie assistive usati in congiunzione con browsers come screen readers, screen magnifiers, and voice recognition software. Riferimento a "User Agent Accessibility Guidelines 1.0" ([UAAG10]) per informazioni sullo sviluppo degli strumenti accessibili.

4 Riferimenti

Per l'ultima versione di ogni specifica W3C, prego consultate la lista di W3C Technical Reports.

[ATAG10]
"Authoring Tool Accessibility Guidelines 1.0", J. Treviranus, C. McCathieNevile, I. Jacobs, and J. Richards, eds., 3 February 2000. This ATAG 1.0 Recommendation is http://www.w3.org/TR/2000/REC-ATAG10-20000203/.
[CSS2]
"CSS, level 2 Recommendation", B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs, eds., 12 May 1998. This CSS2 Recommendation is http://www.w3.org/TR/1998/REC-CSS2-19980512/. The latest version of CSS2 is available at http://www.w3.org/TR/REC-CSS2.
[DOM1]
"Document Object Model (DOM) Level 1 Specification", V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, and L. Wood, eds., 1 October 1998. This DOM Level 1 Recommendation is http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001. The latest version of DOM Level 1 is available at http://www.w3.org/TR/REC-DOM-Level-1.
[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/.
[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.
[SMIL-ACCESS]
"Accessibility Features of SMIL", M. Koivunen and I. Jacobs, eds., 21 September 1999. This W3C Nota is http://www.w3.org/TR/1999/Nota-SMIL-access-19990921/.
[SVG]
"Scalable Vector Graphics (SVG) 1.0 Specification", J. Ferraiolo, ed., 2 August 2000. This W3C Candidate Recommendation is http://www.w3.org/TR/2000/CR-SVG-20000802/.
[SVG-ACCESS]
"Accessibility Features of SVG", C. McCathieNevile and M. Koivunen, eds., 7 August 2000. This W3C Nota is http://www.w3.org/TR/2000/Nota-SVG-access-20000807.
[UAAG10]
"User Agent Accessibility Guidelines", J. Gunderson and I. Jacobs, eds. The latest version of the User Agent Accessibility Guidelines is available at http://www.w3.org/TR/UAAG10/.
[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-CORE-TECHNIQUES]
"Core Techniques for Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, and I. Jacobs, eds. The latest version of this document is available at http://www.w3.org/TR/WCAG10-CORE-TECHS/.
[WCAG10-CSS-TECHNIQUES]
"CSS Techniques for Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, and I. Jacobs, eds. The latest version of this document is available at http://www.w3.org/TR/WCAG10-CSS-TECHS/.
[WCAG10-HTML-TECHNIQUES]
"HTML Techniques for Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, and I. Jacobs, eds. The latest version of this document is available at http://www.w3.org/TR/WCAG10-HTML-TECHS/.
[XML]
"Extensible Markup Language (XML) 1.0.", T. Bray, J. Paoli, C.M. Sperberg-McQueen, eds., 10 February 1998. This XML 1.0 Recommendation is: http://www.w3.org/TR/1998/REC-xml-19980210. The latest version of XML 1.0 is available at http://www.w3.org/TR/REC-xml.

5 Risorse

Nota: Il W3C non garantisce la stabilità di ognuno dei seguenti riferimenti fuori dal suo controllo. Queste referenze sono incluse per convenienza. Riferimenti ai risultati non sono approvati da quei risultati.

5.1 Altre linee guida

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

5.2 User agents e altri strumenti

Una lista di alternativi Web browsers (tecnologie assistive e altri user agents designati per l'accessibilità) è mantenuta al sito Web del WAI.

[WAI-UA-SUPPORT]
User Agent Support for Accessibility

6 Ringraziamenti

Web Content Guidelines Working Group Co-Chairs:
Jason White, University of Melbourne
Gregg Vanderheiden, Trace Research and Development
Contatta il Team del W3C:
Wendy Chisholm
Speriamo di ringraziare le seguenti persone che hanno contribuito con il loro tempo e con le loro osservazioni a formare 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

Level Triple-A conformance icon, W3C-WAI Web Content Accessibility Guidelines 1.0

[Indice dei contenuti]   [Core Techniques]   [HTML Techniques]   [CSS Techniques]