Linee Guida per l'Accessibilità ai Contenuti Web 2.0

Working Draft del W3C dell’ 11 Marzo 2004

Questo documento è una traduzione della Working Draft relativa alle Linee Guida per l'Accessibilità ai Contenuti Web 2.0.
Questo documento potrebbe contenere errori di traduzione.

La versione normativa, in lingua inglese, si trova a:   

http://www.w3.org/TR/2004/WD-WCAG20-20040311/

 

Questa versione italiana tradotta è disponibile all’indirizzo:

http://www.del.univpm.it/ , sezione knowledge - Accessibilità

 

Traduttrici:

Elvira D’Orsi, Maria Valenti

 

Questa versione:

http://www.w3.org/TR/2004/WD-WCAG20-20040311/

Ultima versione:

http://www.w3.org/TR/WCAG20/

Versione precedente:

http://www.w3.org/TR/2003/WD-WCAG20-20030624/

Redazione:

Ben Caldwell, Trace R&D Center

Wendy Chisholm, W3C

Gregg Vanderheiden, Trace R&D Center

Jason White, University of Melbourne

Copyright © 2004  W3C ® ( MIT , ERCIM , Keio), Tutti i diritti riservati. Si applicano le regole del W3C riguardanti la responsabilità, il marchio depositato, l'uso dei documenti e le licenze software.

Abstract

Il World Wide Web Consortium (W3C) ha pubblicato nel maggio 1999 le Web Content Accessibility Guidelines 1.0 (WCAG 1.0) sotto forma di Reccommendation. L’attuale Working Draft per la versione 2.0 si basa sulle WCAG 1.0. Ha lo stesso scopo: spiegare come costruire materiali Web accessibili ad utenti disabili e stabilire come obiettivo dei livelli di accessibilità. Avendo tenuto in debito conto il feedback relativo alle WCAG 1.0, la Working Draft 2.0 si concentra sulle linee guida che tenta di applicare ad un’ampia gamma di tecnologie e si sforza di  usare una terminologia comprensibile ad un più vasto uditorio.

 

Stato del Documento

In questa sezione viene descritto lo stato del documento all’atto della sua pubblicazione. Altri documenti possono prenderne il posto. Un elenco delle correnti pubblicazioni del W3C e l’ultima revisione di questo rapporto tecnico sono reperibili nel W3C technical reports index all’indirizzo http://www.w3.org/TR/.

Questo documento è stato redatto dal Web Content Accessibility Guidelines Working Group (WCAG WG) per mostrare come leggere linee guida WCAG più generiche (meno specifiche per l’HTML). Questa draft non si basa ancora sul consenso del WCAG Working Group né ha superato il cammino di un documento tecnico del W3C, né soppianta le WCAG 1.0.

Far riferimento a "Issue Tracking for WCAG 2.0 Working Draft" per un elenco di questioni aperte relative a questa Working Draft. E’ anche disponibile la "History of Changes to WCAG 2.0 Working Drafts".

Pubblicazioni tipo una Working Draft non implica l’approvazione dei membri del W3C. Questo documento è in stato di bozza e può essere aggiornato, sostituito o reso obsoleto da altri documenti in qualunque momento. Va citato unicamente come work in progress. E’ disponibile un elenco dei current W3C Recommendations and other technical documents.

The Working Group attende commenti a questo documento all’indirizzo public-comments-wcag20@w3.org. Gli  archives for this list sono di dominio pubblico, così come gli archivi relativi alle WCAG WG mailing list discussions.

L’informativa relativa ai diritti di brevetto inerenti questa specifica si può reperire nella WCAG Working Group’s patent disclosure page, in conformità alla politica del W3C.

Questo documento è stato prodotto come parte del W3C Web Accessibility Initiative (WAI). Gli obiettivi del WCAG WG sono dibattuti nella Working Group charter. Il WCAG WG fa parte di WAI Technical Activity.

Indice dei Contenuti

·         Principio 1: Rendere i contenuti percepibili.

o        Linea guida 1.1 Per ogni  contenuto non testuale, fornire testo equivalente che svolga  la stessa funzione o sia in grado di veicolare le stesse informazioni, fatta eccezione per quei casi in cui il contenuto non testuale abbia il solo scopo di generare una specifica esperienza sensoriale (ad esempio, musica ed arte visiva). In tal caso è sufficiente un’etichetta di testo o una descrizione.

o        Linea guida 1.2 Fornire media equivalenti sincronizzati per le presentazioni multimediali dipendenti dal tempo.

o        Linea guida 1.3 Assicurare che informazioni, funzionalità e strutture siano separabili dalla presentazione.

o        Linea guida 1.4 Nelle presentazioni visive, parole e immagini devono essere chiaramente  distinguibili dallo sfondo.

o        Linea guida 1.5 Nelle presentazioni audio, il parlato e i suoni devono essere chiaramente distinguibili  dai suoni di sottofondo. [linea guida di livello 2] 

o        Linea guida 2.2 Permettere agli utenti di controllare i propri tempi di lettura o di interazione a meno che tale controllo non sia possibile  a causa di eventi in tempo reale o di regole di gara.

o        Linea guida 2.3 Consentire agli utenti di evitare il contenuto che potrebbe causare attacchi dovuti ad epilessia fotosensibile.  

o        Linea guida 2.4 Aggiungere funzionalità che aiutino l’utente ad orientarsi e a spostarsi tra i contenuti. [linea guida di livello 2]

o        Linea guida 2.5 Aiutare gli utenti ad evitare gli errori e consentire loro di  rimediare con facilità. [linea guida di livello 2]

·         Principio 3: Rendere comprensibili contenuti e comandi.

o        Linea guida 3.1 Assicurare che possa essere determinato il significato del contenuto.

o        Linea guida 3.2 Organizzare il contenuto in maniera coerente da "pagina a pagina" e fare in modo che le  componenti interattive si comportino in modo prevedibile.  

·         Principio 4: Progettare  contenuti sufficientemente robusti al fine di garantirne la compatibilità con le tecnologie presenti e future.

o        Linea guida 4.1 Utilizzare tecnologie che rispettino le specifiche.

o        Linea guida 4.2 Assicurare che le interfacce utente siano accessibili o fornite di alternative accessibili.

Appendici

Introduzione

Scopo

Questo documento delinea i principi di progettazione per creare materiali Web accessibili. Laddove tali principi vengano ignorati, gli utenti disabili non saranno in grado di accedere ai contenuti o vi accederanno con grande difficoltà. Se i principi di accessibilità saranno implementati, i contenuti Web diventeranno accessibili tramite molteplici dispositivi, quali telefoni, palmari, cabine telefoniche, apparecchiature di rete e pertanto accessibili agli utenti nelle situazioni più disparate.

I principi di progettazione espressi in questo documento rappresentano concetti generali che si applicano a tutti i contenuti Web, non essendo specifici per l’HTML, XML o qualsiasi altra tecnologia. Si è scelto questo tipo di approccio per consentire l’applicazione dei principi di progettazione a molteplici situazioni e tecnologie, incluse quelle future.

Come leggere il documento

Allo scopo di facilitare la comprensione delle linee guida e aiutare i lettori a focalizzare esattamente le parti di interesse, si è deciso di presentare le linee guida sotto forma di più documenti intercorrelati.

Le WCAG 2.0 sono articolate su tre livelli di informazione:

1 - Top layer - Panoramica dei Principi di Progettazione, delle Linee Guida, dei  Success Criteria

Tale livello ha per titolo "Web Content Accessibility Guidelines 2.0". E’ costituito dal presente documento. Contiene:

1.    Un’ introduzione.

2.    I 4 principi fondamentali per l’accessibilità (Percepibile, Fruibile, Comprensibile e Robusto).

3.     Le linee guida (non riferite a tecnologie specifiche) (14 in tutto).

4.     I success criteria , test di verifica del successo, (normativi), e le definizioni, i benefici e gli esempi (tutti non normativi) relativi a ciascuna linea guida.

5.     Un’appendice contenente definizioni, riferimenti ed altre informazioni di supporto.

2 - Liste di controllo inerenti tecnologie specifiche

Andranno ad integrare le linee guida tutta una serie di documenti costituiti da liste di controllo inerenti tecnologie specifiche. Questi documenti forniranno informazioni su quanto richiesto nell’uso delle varie tecnologie per conformarsi alla Working Draft delle WCAG 2.0.

Nota dell’ Editore: Tali checklist non sono state ancora organizzate. Al momento, non è chiaro se saranno normative o non-normative. Se le checklist saranno non-normative, sarà più facile aggiornarle. In caso contrario, i cambiamenti ad esse apportate andranno ad alterare la definizione di conformità. Comunque, potrebbe essere indispensabile organizzare checklist normative al fine di rendere  le linee guida testabili.

3 - Bottom layer – Informazioni sulle applicazioni inerenti tecnologie specifiche

I Techniques Documents includeranno esempi di codice, screen shot e informazioni specifiche relative alle diverse tecnologie. Saranno documenti non normativi. Illustreranno varie strategie, che consentiranno di conformarsi ai requisiti delle linee guida, e gli approcci correnti più utilizzati, laddove esistano. Gli esempi comprenderanno:

 

·         Hypertext Markup Language (HTML) and Extensible Hypertext Markup Language (XHTML) Techniques

·         Cascading Style Sheets (CSS) Techniques

·         Server-side scripting Techniques

·         Client-side scripting Techniques

·         Scalable Vector Graphics (SVG) Techniques

·         Synchronized Multimedia Integration Language (SMIL) Techniques

·         Extensible Markup Language (XML) Techniques

(I sopracitati diventeranno link attivi non appena le corrispondenti Working Draft saranno pubblicate)

Destinatari

Le linee guida sono dirette ad un pubblico vasto, politici, manager, creatori di contenuti Web, programmatori. Ci si è sforzati di rendere il documento leggibile ed usabile per quanto possibile senza trascurare l’accuratezza e la chiarezza necessarie in una specifica di carattere tecnico. Per utenti alle prime armi, è vivamente raccomandato il lavoro Education and Outreach Working Group del WAI.

Ambito

Le linee guida coprono un’ampia gamma di questioni e raccomandazioni per creare contenuti Web maggiormente accessibili. Includono raccomandazioni per rendere i materiali accessibili ed usabili da utenti con le più disparate disabilità. In genere, non includono raccomandazioni inerenti l’usabilità, eccetto dove esistono specifiche conseguenze per l’accessibilità che vanno al di là dell’effetto degli standard di usabilità.

Priorità e Tecniche

La Working Draft WCAG 2.0 si basa sulle WCAG 1.0 e sul feedback ricevuto a partire dalla loro pubblicazione, avvenuta nel maggio del 1999. Anche se i due documenti si approcciano in modo identico alle problematiche dell’accessibilità, hanno organizzazione e struttura diverse. Mentre le WCAG 1.0 sono organizzate in linee guida in cui sono inseriti i vari checkpoint, le WCAG 2.0 utilizzano le linee guida per raggruppare i success criteria. Nelle WCAG 1.0, ad ogni checkpoint è assegnato un diverso livello di priorità; nella presente draft i success criteria sono articolati in tre diverse categorie.

I principi di progettazione sono stati riscritti per essere applicati ad un’ampia gamma di tecnologie esistenti e future. La Working Draft  WCAG 2.0 non contiene requisiti o tecniche di implementazione relative a tecnologie specifiche, ma farà riferimento a requisiti, esempi e tecniche inerenti tecnologie specifiche (non appena saranno organizzati i relativi documenti).

Il Working Group si sta preoccupando di facilitare la transizione alle WCAG 2.0 per le organizzazioni e per coloro che fanno riferimento alle WCAG 1.0 (che al momento rimangono l’unico documento ufficiale). Per maggiori informazioni riguardanti analogie e differenze fra i checkpoint delle WCAG 1.0 e le linee guida con i relativi success criteria delle WCAG 2.0, si può far riferimento al documento Mapping Between WCAG 1.0 and the WCAG 2.0 Working Draft.

Conformità

Nota dell’Editore: Esistono varie questioni aperte relative allo schema di conformità proposto. Questa sezione delinea lo schema di conformità usato in questo documento. Si auspicano feedback, commenti e proposte.

Le linee guida sono articolate in tre categorie di success criteria:

 

·         Success criteria di livello 1:

1.      non specifica come è presentata l’informazione

2.      sono ragionevolmente applicabili a tutti i siti Web

3.      alcuni sono testabili automaticamente, altri necessitano del controllo eseguito dall’utente. I success criteria da testare  mediante utenti forniscono risultati coerenti fra i tester.

·         Success criteria di livello 2:

1.      possono richiedere all’autore di presentare i contenuti in modo particolare

2.      sono ragionevolmente applicabili a tutti i siti Web

3.      alcuni sono testabili automaticamente, altri necessitano del controllo eseguito dall’utente. I success criteria da testare mediante utenti forniscono risultati coerenti fra i tester.

·         Success criteria di livello 3:

1.       sono criteri supplementari ai Livelli 1 e 2 che possono essere applicati al fine di rendere i siti accessibili a un maggior  numero di utenti disabili o con particolar tipi di disabilità.

Nota dell’Editore: Per facilitare la discussione relativa ai livelli assegnati a ciascun criterio, al termine di ciascuno di essi è stata posta una notazione racchiusa in parentesi quadre. “[V]” (visibile) indica che un criterio non specifica come è presentata l’informazione e “[I]” (invisibile) indica che conformarsi al criterio può richiedere all’autore di presentare il contenuto in modo specifico.

Nota:

   Alcune linee guida non contengono success criteria di livello 1.

Dichiarazioni di Conformità

1.     Al fine di render valida una dichiarazione di conformità per una risorsa Web, questa deve soddisfare tutti i success criteria di livello 1 di tutte le linee guida.

2.     La conformità di tipo “WCAG 2.0 Level A” può essere dichiarata se sono verificati tutti i success criteria di livello 1 relativi a tutte le linee guida.

3.     La conformità di tipo “WCAG 2.0 Level A+” può essere dichiarata se sono verificati tutti i success criteria di livello 1 e alcuni success criteria di livello 2.

4.     La conformità di tipo “WCAG 2.0 Level AA” può essere dichiarata se sono verificati tutti i success criteria di livello 1 e 2 relativi a tutte le linee guida.

5.     La conformità di tipo “WCAG 2.0 Level AAA” può essere dichiarata se sono verificati tutti i success criteria di livello 1, 2 e 3 relativi a tutte le linee guida.

Nota dell’Editore: Il feedback ricevuto dalle WCAG 1.0 segnala che gli sviluppatori Web spesso non tentano di conformarsi ad alcuni dei Checkpoint di Priorità 2 perché non esiste la possibilità di indicare nella dichiarazione di conformità che essi hanno "fatto più del Livello A ma non abbastanza per dichiarare il livello AA". "A+" rappresenta una proposta per permettere agli sviluppatori di affermare "Ho fatto più di A ma non tutto di AA". Quindi, alcuni membri del WCAG WG hanno lanciato l’idea di dichiarazioni di conformità tipo A+ o AA+.

Tutte le dichiarazioni di conformità devono includere come minimo:

1.    La versione delle linee guida in base alla quale è sta dichiarata la conformità e l’URI corrente in cui ritrovare il documento.

2.    L’ambito della dichiarazione di conformità che specifica quali sezioni del sito o di un’applicazione sono incluse nella dichiarazione.

Nota dell’Editore: Sarebbero consentite esclusioni per certi tipi di contenuto, come materiali di terze parti o protetti dal copyright in fase di ristampa? Come definire l’estensione di queste esclusioni? E’ un processo da utente a utente che questi dovrebbe essere in grado di completare? E’ un percorso attraverso il contenuto accessibile?

3.    Il set di criteri rispettati

4.    La data della dichiarazione di conformità.

Siti conformi alle WCAG 1.0

I siti attualmente conformi alle WCAG 1.0, che desiderano passare alle WCAG 2.0, vorranno capitalizzare gli sforzi fatti in passato per raggiungere l’accessibilità. Ciò potrebbe realizzarsi mediante una dichiarazione di conformità con riserva. Una dichiarazione di conformità ad hoc potrebbe essere del tipo: “I materiali creati o modificati prima del 24 aprile 2003 sono conformi alle WCAG 1.0. Quelli creati o modificati in data o dopo il 24 aprile 2003 sono conformi alle WCAG 2.0 ”.

Nota dell’Editore: A seconda dei success criteria, potrebbe risultare più semplice o più complicato conformarsi alla WCAG 2.0 Working Draft che alla WCAG 1.0 Recommendation. Il WCAG WG prenderà in considerazione le differenze fra la conformità secondo le WCAG 1.0 e quella secondo le WCAG 2.0 e fornirà comunicazione agli sviluppatori che attualmente si conformano alle WCAG 1.0. Tale comunicazione, che non è stata ancora organizzata, potrebbe assumere la forma di un profilo di conformità tra WCAG 1.0 e WCAG 2.0 e informare su come passare dalle WCAG 1.0 alle WCAG 2.0.

 

Panoramica dei principi di progettazione

L’obiettivo principale è creare materiale Web che sia percepibile, fruibile e comprensibile da una molteplicità di utenti  e compatibile con un’ampia gamma di tecnologie assistive, attuali e future. I principi fondamentali sono:

 

1.    Rendere i contenuti percepibili.

2.    Rendere fruibili gli elementi dell’interfaccia nel contenuto.

3.    Rendere comprensibili contenuti e comandi.

4.    Progettare contenuti sufficientemente robusti al fine di garantirne la compatibilità con le tecnologie presenti e future.

Rendere accessibile i contenuti Web va a vantaggio di moltissimi utenti, non solo di quelli con disabilità. Nel mondo fisico, le rampe sono usate dalle biciclette, dalle persone con passeggini e da quelle in carrozzella. Parimenti, dei contenuti Web accessibili beneficerà una grande varietà di  utenti, con o senza disabilità. Ad esempio, chi si trova temporaneamente ad operare in condizioni poco consone (es. ambienti rumorosi che impediscono di ascoltare bene o sguardo rivolto alla strada mentre si è alla guida della propria auto), può trarre benefici da un sito accessibile. Allo stesso modo, un motore di ricerca può trovare una citazione famosa in un film se esso è sottotitolato.

Nota:

I principi di progettazione si applicano solo ai  contenuti Web rivolti ad un lettore umano. Un database o un insieme di metadata destinati all’uso di altre macchine, e che non richiedono interfaccia, non rientrano nel campo d’azione di queste linee guida.

Bisogni dell’utente

Di seguito sono rappresentati alcuni scenari senza alcuna pretesa di esaustività nei riguardi dei vari tipi di disabilità e bisogni:

·         Chi non può sentire desidera una rappresentazione visiva delle informazioni veicolate col sonoro.

·         Chi non può vedere desidera ascoltare o sentire (mediante braille o grafici tattili) l’equivalente dell’informazione visiva.

·         Chi ha difficoltà nei movimenti desidera utilizzare piccolissimi spostamenti ed avere più tempo a disposizione per operare con le interfacce Web.

·         Chi non legge bene può desiderare che le informazioni siano lette ad alta voce.

Se i contenuti Web si avvalgono dei principi di progettazione descritti in questo documento, gli utenti dovrebbero essere in grado  di accedere ai materiali usando strategie adattive e tecnologie assistive. Esistono molti strumenti utilizzati da utenti disabili per navigare all’interno del Web. Per scenari più approfonditi inerenti le disabilità rapportate a contenuti Web accessibili o meno, far riferimento al documento "How People with Disabilities Use the Web".

Progettare Contenuti Web Accessibili

Le presenti linee guida forniscono i requisiti base per progettare contenuti Web accessibili. Scopo di questo documento non è fornire il background necessario per far apprendere come progettare un Web accessibile in maniera effettiva od esauriente. A questo proposito, si può far riferimento al documento Education and Outreach Working Group del Web Accessibility Initiative.

Principio 1: Rendere i contenuti percepibili.

Linea Guida 1.1 Per ogni  contenuto non testuale, fornire testo equivalente che svolga  la stessa  funzione o sia in grado di veicolare le stesse informazioni, fatta eccezione per quei casi in cui il contenuto non testuale abbia il solo scopo di generare una specifica esperienza sensoriale (ad esempio, musica ed arte visiva). In tal caso è sufficiente un’etichetta di testo o una descrizione.

Success Criteria per la Linea Guida 1.1 – Livello 1

  1. Testi equivalenti sono esplicitamente associati a contenuto non testuale, eccetto quando questi ultimi hanno la funzione di generare specifiche esperienze sensoriali (musica o arte visiva). [I]

o        Il testo equivalente adempie allo stesso scopo che l’autore si è prefisso con l’utilizzo del contenuto non testuale (cioè, esso veicola tutte le informazioni e svolge la stessa funzione del contenuto non testuale).

Eccezione:

Non è necessario fornire testo equivalente se il fine è far sì che gli utenti organizzino equivalenti testuali (ad esempio, un testo da compitare).

  1. Il contenuto non testuale destinato a generare una specifica esperienza sensoriale (ad esempio, musica priva di parole ed arte visiva) ha un’etichetta di testo o una descrizione testuale associata ad esso in modo esplicito [I].

Success Criteria per la Linea Guida 1.1 – Livello 2

1.     Nessun success criteria di livello 2 per questa linea guida.

Success Criteria per la Linea Guida 1.1 – Livello 3

  1. Un documento di testo (ad esempio un movie script) è strutturato in modo da includere tutte le informazioni visive importanti, i dialoghi e altri suoni fondamentali [I].

Chi beneficia della Linea guida 1.1 (Informativa)

·         Utenti non vedenti, ipovedenti, disabili cognitivi o che hanno difficoltà per un qualsiasi motivo a leggere un testo possono usufruire del contenuto letto a voce alta dalle tecnologie assistive.

·         Utenti non udenti, con menomazioni dell’udito o che hanno difficoltà per un qualsiasi motivo a comprendere informazioni audio possono leggere il contenuto in forma testuale o averlo tradotto e rappresentato nel linguaggio dei segni dalle tecnologie assistive.

·         Utenti non vedenti-non udenti possono leggere il testo in braille.

Esempi relativi alla Linea Guida 1.1 (Informativi)

·         Esempio 1: un’immagine usata come un pulsante. (breve equivalente testuale per la funzione)

Un’icona a forma di freccia rivolta verso destra è usata in una presentazione per collegare una slide alla successiva. L’equivalente testuale all’icona è  “Slide successiva” e uno screen reader, leggendolo, lo identifica automaticamente come link, aggiungendo la parola link o modificando la voce del sintetizzatore.

·         Esempio 2: un diagramma di dati. (etichetta breve + descrizione lunga)

Un diagramma a barre confronta quanti articoli sono stati venduti in Giugno, Luglio ed Agosto. L’etichetta breve dice “ Figura 1 – Vendite in Giugno, Luglio ed Agosto”. La descrizione lunga identifica il tipo di diagramma o grafico, fornisce un sommario dei dati confrontabile con quello che risulta dal diagramma o grafico, e organizza i dati in una tabella o in un altro formato accessibile.

·         Esempio 3: un’animazione. (etichetta breve + descrizione lunga)

Un’animazione mostra come allacciare un nodo. L’etichetta breve dice, “Un’animazione mostra come intrecciare un nodo”. La spiegazione più lunga descrive i movimenti delle mani necessari.

·         Esempio 4: un file audio di un discorso. (etichetta breve + trascrizione)

In una pagina Web è inserito un file audio. L’etichetta breve dice, “Discorso di Chairman all’assemblea”. Dopo l’audio clip viene fornito immediatamente un link alla trascrizione testuale.

·         Esempio 5: un file audio di una sinfonia. (etichetta breve)

In una pagina Web è inserito un file audio. L’etichetta breve dice, “Quinta sinfonia di Beethoven eseguita dall’ Orchestra filarmonica di Vienna”.

Linea guida 1.2 Fornire media equivalenti sincronizzati per le presentazioni multimediali dipendenti dal tempo.

Nota dell’Editore: Per rispettare la data di scadenza della nostra pubblicazione, la risoluzione dei problemi inerenti questa linea guida è rimandata alla prossima Working Draft. La questione fondamentale è "Come applicare questi success criteria ad  una qualunque Webcam, notiziario e home broadcast?" Le possibilità che stiamo considerando includono di spostare i success criteria esistenti dal Livello 1 al Livello 2 o di permettere dichiarazioni di conformità che escludono sezioni del sito come "Tutte le pagine e le applicazioni presenti in questo sito sono conformi al livello 1 delle linee guida delle WCAG 2.0 eccetto la Webcam all’indirizzo http://example.org/webcam/."

Success Criteria per la Linea Guida 1.2 – Livello 1

  1. E’ fornita una  descrizione audio per gli eventi visivi delle presentazioni audio-visive[I].
  2. Tutti i dialoghi e i suoni significativi dei contenuti dipendenti dal tempo sono forniti di sottotitoli [I].
  3. Descrizioni e sottotitoli sono sincronizzati con gli eventi che rappresentano [I]

Eccezione:

Non è necessario sincronizzare con la presentazione multimediale trascrizioni  testuali o altri equivalenti non sonori se si verificano tutte insieme le quattro condizioni sottostanti:

a.      il contenuto è erogato in tempo reale,

b.      il contenuto è solo audio,

c.      il contenuto non dipende dal tempo,

d.      il contenuto non è interattivo.

Nota:

Questa eccezione si applica ad entrambi i success criteria 2 e 3 succitati.

  1. Sono forniti sottotitoli sincronizzati ai contenuti audio/video erogati in tempo reale. [I]

Eccezione:

I sottotitoli non sono da fornire nel caso di un programma musicale essenzialmente non vocale.

  1. Se il contenuto Web real-time è un video non interattivo (ad esempio le immagini di una Webcam che fornisce informazioni meteorologiche), è disponibile una delle seguenti opportunità: [I]

o        un contenuto alternativo conforme alla linea guida 1.1 (ad esempio, un testo scorrevole che relazioni sulle condizioni del tempo)

o        un link ad un contenuto alternativo conforme alla linea guida 1.1 (ad esempio, un link ad un sito meteorologico conforme alla linea guida 1.1)

  1. E’ fornita una presentazione equivalente sincronizzata (audio, visiva o testuale) per ogni presentazione contenente solo audio o solo video che richieda agli utenti di interagire in momenti specifici [I].

Eccezione:

Se il contenuto diffuso da altro medium o risorsa soddisfa i requisiti di accessibilità per quel medium, la trasmissione rispetta questo checkpoint, se si conforma ad altre sezioni applicabili delle WCAG 2.0.

Success Criteria per la Linea Guida 1.2 – Livello 2

  1. Sono forniti sottotitoli sincronizzati per ogni trasmissione in tempo reale [I].

Nota dell’Editore: Si discute su cosa è possibile e cosa dovrebbe essere necessario per le descrizioni audio in tempo reale, poiché non c’è modo di sapere se ci saranno intervalli di tempo tali da permettere di leggere le descrizioni e quali altri problemi potrebbero verificarsi in concomitanza con gli eventi descritti in tempo reale.

Success Criteria per la Linea Guida 1.2 – Livello 3

1.     Nessun success criteria di livello 3 per questa linea guida.

Chi beneficia della Linea guida 1.2 (Informativa)

·         Utenti non udenti o con menomazioni dell’udito possono accedere alle informazioni audio mediante i sottotitoli.

·         Utenti non vedenti o ipovedenti o con disabilità cognitive, che hanno difficoltà ad interpretare informazioni visive, traggono vantaggio dalle corrispondenti descrizioni audio.

Anche persone non disabili beneficiano dei media equivalenti :

·         Utenti in ambienti rumorosi  o senza sonoro spesso fanno affidamento sui sottotitoli.

·         I sottotitoli aiutano molti utenti a sviluppare il linguaggio e l’abilità di lettura.

·         Le descrizioni audio forniscono l’informazione visiva a chi distoglie temporaneamente lo sguardo dallo schermo, ad esempio quando si stanno eseguendo le istruzioni di un video e l’attenzione è rivolta si alle mani.

·         Sottotitoli e descrizioni testuali rendono possibile l’indicizzazione e la ricerca dei file mediali.

Nota:

Presentazioni dipendenti dal tempo che richiedono all’utente di usare un solo senso per seguire due o più eventi contemporaneamente possono costituire per alcune categorie di persone barriere significative. A seconda della natura della presentazione, può essere possibile evitare scenari dove, ad esempio, ad un utente non udente è richiesto di osservare un’azione sullo schermo e leggere allo stesso tempo i sottotitoli. Comunque, ciò potrebbe non esser possibile per trasmissioni dal vivo (ad esempio, una partita di football). Dove possibile (specialmente per materiali educativi e di addestramento),  occorre fornire i contenuti in modo da non richiedere di attivare lo stesso senso per seguire più eventi simultaneamente o dare all’utente la possibilità di congelare lo schermo cosicché i sottotitoli possano essere letti senza perdere la schermata.

Esempi relativi alla Linea Guida 1.2 (Informativi)

·         Esempio 1: un movie clip con descrizione audio e sottotitoli.

Un movie clip è pubblicato su un sito Web. Nel clip un bambino sparge delle briciole per attrarre un cucciolo nella sua stanza.  Poiché il sonoro include esclusivamente il borbottio del bambino, la descrizione audio che si sente quando il bambino smette di borbottare dice “Charlie mette una briciola  su ogni gradino che conduce alla sua stanza”. Il sottotitolo che appare mentre lui borbotta riporta “borbottio impercettibile”.

·         Esempio 2: un video clip di una notizia di attualità.

Un video clip è collegato alla notizia di un allagamento in una grande città. Il giornalista descrive la scena. Non è necessaria alcuna descrizione audio. I sottotitoli spiegano quello che il giornalista sta dicendo.

·         Esempio 3: un’animazione silenziosa.  

Un’animazione mostra un mimo con la faccia bianca e il costume nero che sale su una scala invisibile. Non c’è traccia audio per questa animazione. Non sono richiesti sottotitoli o descrizioni audio. Viene invece fornita un’etichetta di testo e una descrizione, come richiesto dalla linea guida 1.1.

Linea guida 1.3 Assicurare che informazioni, funzionalità e strutture siano separabili dalla presentazione.

Success Criteria per la Linea Guida 1.3 – Livello 1

  1. Quanto sotto elencato è derivato in modo programmatico dal contenuto (per esempio, attraverso markup o data model) e non richiede interpretazione della presentazione da parte dell’utente [I]:

a.      Gli elementi gerarchici e le correlazioni, come ad esempio:

·         paragrafi

·         elenchi

·         intestazioni

·         associazioni tra celle di tabelle e relative intestazioni

b.      Le relazioni non gerarchiche fra elementi, come:

·         riferimenti incrociati  e altre associazioni

·         associazioni fra etichette e comandi,

c.      L’enfasi o altra formattazione di parole specifiche, frasi, e citazioni.

Nota dell’Editore: A questo elenco potrebbero essere aggiunte altre strutture nelle future draft.

  1. Qualsiasi informazione presentata attraverso il colore deve essere disponibile anche senza l’utilizzo di esso (per esempio attraverso il contesto o il markup o con una codifica non dipendente dal colore) [I].

Success Criteria per la Linea Guida 1.3 – Livello 2

  1. Le informazioni presentate attraverso l’uso del colore sono anche disponibili senza colore e senza  interpretazione del markup (ad esempio dal contesto o dalla codifica del  testo) [V].

Success Criteria per la Linea Guida 1.3 – Livello 3

1.      Nessun success criteria di livello 3 per questa linea guida.

Chi beneficia della Linea Guida 1.3 (Informativa)

·         Separare contenuto e struttura dalla presentazione permette di veicolare i contenuti Web essere in maniera differenziata per venire incontro alle esigenze e alle difficoltà degli utenti, senza perdita d’informazione o di struttura. Ad esempio, un contenuto concepito originariamente per essere rappresentato visivamente, può esser reso col sonoro o in testo braille.

·         Può essere facilitata l’enfasi automatica della struttura o una navigazione più efficiente.

·         Di tutto ciò possono beneficiare utenti con disabilità cognitive, fisiche, uditive e visive.

Esempi relativi alla Linea Guida 1.3 (Informativi)

Nota dell’Editore: Questi esempi sono stati migliorati rispetto alle draft precedenti, ma sono specifici per l’HTML. Saranno generalizzati nelle future draft.

·         Esempio 1: Un form che specifica in forma testuale quali campi non sono stati compilati.

Quando un utente compila un form senza riempire tutti i campi richiesti, appare un messaggio che lo informa dei campi ancora vuoti. Questi sono anche evidenziati con colore diverso per attrarre su di essi l’attenzione dei disabili cognitivi. Poiché il messaggio è anche disponibile in forma testuale, gli utenti che non possono distinguere i colori saranno in grado di individuare i campi da correggere.

·         Esempio 2: Un orario di autobus dove le intestazioni sono state associate alle celle.

L’orario di un autobus è organizzato in una tabella dove verticalmente sono indicate le fermate e orizzontalmente le diverse corse. Ogni cella contiene l’ora relativa alla fermata del bus. Nel markup ogni cella è stata associata sia alla corrispondente fermata dell’autobus, che alla relativa corsa.

·         Esempio 3: Un form dove ad ogni casella di controllo è stata associata la relativa etichetta.

In un form dove gli utenti possono selezionare differenti opzioni usando caselle di controllo, ad ognuna è stata associata la relativa etichetta. Ciò avvantaggia varie categorie di utenti. Permette ai non vedenti di determinare qual è la funzione della casella. I disabili motori possono controllare la casella più agevolmente in quanto possono selezionare un qualunque punto dell’etichetta invece di cliccare esattamente nella casella di controllo.

Linea Guida 1.4 Nelle presentazioni visive, parole e immagini devono essere chiaramente  distinguibili dallo sfondo.

Success Criteria per la Linea Guida 1.4 – Livello 1

  1.  Per ogni testo implementato su uno sfondo, è possibile una nuova presentazione in modo che esso risulti chiaramente distinguibile dallo sfondo [I].

Note:

Questo criterio dovrebbe essere soddisfatto dal testo conforme alla linea guida 1.1.

Success Criteria per la Linea Guida 1.4 – Livello 2

  1. Il testo implementato su uno sfondo ha un contrasto maggiore di quello presente___ fra il testo e lo sfondo come misurato da___ oppure esiste la possibilità di personalizzare il testo e soddisfare questo criterio. [V]

Nota dell’ Editore: Il Working Group sta cercando di sviluppare  un algoritmo che misuri il contrasto in modo sufficientemente accurato e testabile, al fine di poterlo includere nelle linee guida. Attualmente è preso in considerazione, per l’inclusione nelle tecniche, un algoritmo presente nel documento Techniques For Accessibility Evaluation And Repair Tools, ma il gruppo non ha ancora trovato qualcosa di più specifico per l’inserimento nelle linee guida.

Success Criteria per la Linea Guida 1.4 – Livello 3

  1. Questa voce elenco dovrebbe esser letta in maniera identica a quella del livello 2 voce #1, eccetto per l’affermazione  "nella rappresentazione di default." [V]
  2. Il testo non è implementato su un'immagine di sfondo o su un pattern, oppure se è presente un'immagine di background o un pattern, il testo è facilmente leggibile con visualizzazione in scala di grigi e lo sfondo non rende difficile l’identificazione dei caratteri [V].

Chi beneficia della Linea Guida 1.4 (Informativa)

·         Utenti ipovedenti possono facilmente leggere i caratteri di un testo perfino se non hanno un ampio campo visivo o la piena percezione del colore, cose che consentono agli utenti normodotati di distinguere il testo dalle immagini di background.

Esempi relativi alla Linea Guida 1.4 (Informativi)

·         Esempio 1: una pagina con immagine di background.

Un’immagine di background e un testo sono implementati in modo tale che essa non si trovi dietro il testo o che sia appena percettibile in modo che il contrasto tra la parte più scura dell’immagine e il testo (che è scuro) incontri i requisiti standard per il contrasto tra foreground e background. Inoltre l’immagine dietro il testo non contiene linee che hanno lo stesso spessore dei caratteri, in modo da non interferire con il loro riconoscimento.

Linea Guida 1.5 Nelle presentazioni audio, il parlato e i suoni devono essere chiaramente distinguibili dai suoni di sottofondo. [linea guida di livello 2]

Success Criteria per la Linea Guida 1.5 – Livello 1

1.      Nessun success criteria di livello 1 per questa linea guida.

Success Criteria per la Linea Guida 1.5 – Livello 2

1.      Nessun success criteria di livello 2 per questa linea guida.

Success Criteria per la Linea Guida 1.5 – Livello 3

  1. Il contenuto audio non ha sottofondo oppure i suoni di sottofondo sono almeno di 20 decibel più bassi rispetto al contenuto audio, eccetto che per suoni brevi e occasionali [V].

Nota:

Una differenza di 20 decibel nel livello di un suono lo rende circa 4 volte più basso (o più alto). Il background sonoro che ha questi requisiti risulterà approssimativamente quattro volte (4x) più basso del contenuto audio di foreground.

Chi beneficia della Linea Guida 1.5 (Informativa)

·         Utenti con menomazioni uditive, che limitano la loro capacità di percepire le frequenze sonore, possono estrapolare le parole dai suoni perché non mixate col sottofondo musicale.

Esempi relativi alla Linea Guida 1.5 (Informativi)

·         Esempio 1: parlato su background sonoro.

Il parlato è spesso naturalmente mixato con suoni di background (movie, notizie dal vivo ecc.) e non può essere facilmente rimosso o separato, perciò (secondo le indicazioni della linea guida 1.2) sono forniti sottotitoli al fine di rendere il dialogo comprensibile. Non tutte le persone, però, sono in grado di leggerli o vederli. Se il parlato è mixato o registrato con suoni di background, ma ha un’intensità superiore ad essi di almeno 20 decibel, per molti utenti non sono più necessari i sottotitoli per comprendere il dialogo.

Principio 2: Rendere fruibili gli elementi dell’interfaccia nel contenuto.

Linea Guida 2.1 Rendere  tutte le funzionalità fruibili attraverso tastiera o interfaccia di tastiera. 

Success Criteria per la Linea Guida 2.1 – Livello 1

  1. Tutte le funzionalità del contenuto, laddove le funzionalità o il loro  risultato possono essere descritte in una frase, sono fruibili tramite tastiera o interfaccia di tastiera [I].

Nota:

Sono incluse caratteristiche di accessibilità fornite dagli autori.

Nota:

Possono essere fornite interfacce aggiuntive alla tastiera, come ad esempio il mouse.

Nota:

Far riferimento alla linea guida 4.2 per informazioni inerenti il supporto degli user agent.

Success Criteria per la Linea Guida 2.1 – Livello 2

  1. Laddove è disponibile e supportata una scelta fra event handler attivati da dispositivi di input, è utilizzato l’evento più astratto [I].

Success Criteria per la Linea Guida 2.1 – Livello 3

1.      Tutte le funzionalità del contenuto sono fruibili tramite tastiera o interfaccia di tastiera.

Chi beneficia della Linea Guida 2.1 (Informativa)

·         I non vedenti (che non possono usare dispositivi di puntamento) possono accedere alle funzionalità del contenuto Web o del sito.

·         Coloro che hanno serie disabilità fisiche possono utilizzare input vocali (che simulano i tasti) sia per immettere i dati che per operare con gli elementi dell’interfaccia della pagina.

Esempi relativi alla Linea Guida 2.1 (Informativi)

·         Esempio 1: operare con più dispositivi di input

Il contenuto fa affidamento soltanto su focus-in, focus-out e eventi di attivazione; questi sono definiti nelle API dell’ambiente per il quale il contenuto è stato realizzato e sono fruibili mediante più dispositivi di input, inclusi dispositivi di puntamento, tastiere e sistemi di input vocale.

·         Esempio 2: esempi di contenuto Web fruibile o meno da tastiera o interfaccia di tastiera

o        Se è scritto per essere fruibile da tastiera, allora è conforme (in quanto è fruibile da tastiera). 

o        Se è scritto per essere per essere utilizzato da un dispositivo che solitamente non è provvisto di tastiera, come un telefono cellulare, ma può essere controllato mediante una tastiera aggiuntiva, allora è conforme. (Un utente che necessita di tastiera – o di tastiera alternativa – può utilizzarla per controllare l’applicazione).

o        Se è scritto per essere fruibile da un dispositivo che non ha tastiera, ma potrebbe anche essere utilizzabile mediante tastiera da dispositivi simili che ne sono provvisti, allora è conforme. (Un utente che necessita di tastiera non comprerebbe un dispositivo che ne è privo, che potrebbe essere considerato non accessibile. Ma il contenuto può essere controllato da un dispositivo con tastiera e quindi è conforme a questa linea guida).

o        Se è scritto per essere fruibile da dispositivi sprovvisti di tastiera ma non può essere utilizzato da quelli con tastiera, allora non è conforme (non si può accedere al contenuto tramite tastiera).

Linea Guida 2.2 Permettere agli utenti di controllare i propri tempi di lettura o di interazione a meno che tale controllo non sia possibile  a causa di eventi in tempo reale o di regole di gara.

Success Criteria per la Linea Guida 2.2 – Livello 1

  1.  Il contenuto è progettato in modo che il tempo non sia elemento essenziale dell’interazione, oppure si verifica almeno una delle seguenti situazioni [I]:

o        L’utente può disattivare il tempo o

o        L’utente può regolare il tempo entro un ampio intervallo, almeno 10 volte più lungo rispetto alle impostazioni di default o

o        L’utente è avvertito che il tempo a disposizione sta per terminare, può prolungarlo con una semplice azione (ad esempio premendo un qualunque tasto) e gli vengono forniti almeno 10 secondi per rispondere o

o        Il tempo è una componente importante di un evento real-time (ad esempio una vendita all’incanto) e non ci sono alternative possibili al limite temporale o

o        Il tempo è parte di un’attività in cui la temporizzazione è essenziale (ad esempio gare o test da risolvere entro un certo limite di tempo) e quindi non può essere ulteriormente prolungato per non invalidare l’attività.

Success Criteria per la Linea Guida 2.2 – Livello 2

  1. L’utente può disattivare il contenuto che lampeggia per più di 3 secondi [I]
  2. L’utente può mettere in pausa e/o disattivare in modo permanente contenuti in movimento o basati sul tempo [I]

Success Criteria per la Linea Guida 2.2 – Livello 3

  1. Il contenuto è stato progettato in maniera tale che ogni limite di tempo soddisfi il success criterion di livello 1 di questa linea guida, senza eccezioni [V].

Nota dell’ Editore: Con questa affermazione, non sarebbero permessi eventi in tempo reale. Vogliamo accettarli?

  1. Ogni interruzione non indispensabile, come ad esempio la possibilità di aggiornare il contenuto, può essere posposta e/o eliminata dall’utente [V].

Chi beneficia della Linea Guida 2.2 (Informativa)

·         Utenti dislessici, con disabilità cognitive e di apprendimento hanno spesso bisogno di più tempo per leggere e comprendere un testo scritto.

·         Utenti con disabilità fisiche possono esaminare e leggere i materiali frequentemente aggiornati prima che avvenga il refresh o nel caso in cui i contenuti siano letti con una tecnologia assistiva o un browser vocale guasti.

Esempi relativi alla Linea Guida 2.2 (Informativi)

·         Esempi di contenuti che devono soddisfare i success criteria di questo checkpoint:

o        refresh automatico,

o        reindirizzamento,

o        testo che lampeggia o in scorrimento,

o        dialogo che scompare dopo un breve periodo,

o        chiusura o disattivazione di risorse se l’attività non è espletata entro un certo tempo.

·         Esempio 1: testo che lampeggia

Lo scripting dal lato client è utilizzato per creare testo che lampeggia. Il contenuto fornisce all’utente un’opzione che gli consente di disattivare l’intermittenza.

 

·         Esempio 2: un sito di news che si aggiorna regolarmente.

La prima pagina di un sito di news viene aggiornata ogni mezz’ora. Contiene testi molto stringati e consiste principalmente di link al contenuto. Un utente che non desidera l’aggiornamento della pagina seleziona una casella di controllo, che si trova nella sezione del sito relativa alle “user preferences” e che costituisce uno dei primi link di ogni pagina.

Linea Guida 2.3 Consentire agli utenti di evitare il contenuto che potrebbe causare attacchi dovuti ad epilessia fotosensibile. 

Success Criteria per la Linea Guida 2.3 – Livello 1

  1. Il contenuto che viola la Soglia d’Intermittenza Generale (General Flash Threshold)  o la Soglia d’Intermittenza Rossa (Red Flash Threshold) è marcato in modo che l’utente possa accedervi  prima del suo apparire [V].

Success Criteria per la Linea Guida 2.3 – Livello 2

  1. Il contenuto non viola la General Flash Threshold o la Red Flash Threshold [V].

Success Criteria per la Linea Guida 2.3 – Livello 3

  1. Il contenuto non viola alcuna delle Soglie di Distribuzione Spaziale (Spatial Pattern Thresholds) [V].

General Flash Threshold

·         Non sono permesse sequenze intermittenti o rapidi cambiamenti di immagini quando si verificano entrambe le seguenti situazioni:

 

1.      L’area sede delle intermittenze che avvengono simultaneamente (ma non necessariamente contiguamente) occupa più di un quarto di un qualsiasi rettangolo di dimensioni 355x268 pixel entro l’area schermo, laddove il contenuto sia visualizzato con risoluzione 1024x768 e

2.      Avvengono più di tre intermittenze al secondo.

Nota:

Nel General Flash Threshold, un’intermittenza è definita come coppia di opposti cambiamenti nella luminanza (ad esempio, un aumento della luminanza seguito da una sua diminuzione o una diminuzione seguito da un aumento) di 20 cdŸm-2 o più, e se la luminanza dello schermo relativa alle immagini più scure è inferiore a 160 cdŸm-2.

Red Flash Threshold

·         Non è permesso il passaggio a (o da) un rosso saturo ad un qualsiasi livello luminescente quando si verificano entrambe le seguenti situazioni:

1.      L’area sede delle intermittenze che avvengono simultaneamente occupa più di un quarto di un qualsiasi rettangolo di dimensioni 355x268 pixel  entro l’area schermo, laddove il contenuto è visualizzato con risoluzione 1024x768 e

2.      avvengono più di tre intermittenze al secondo.

Nota:

Nel Red Flash Threshold, un flash è definito come qualunque coppia di transizioni opposte a (o da) un rosso saturo ad un qualsiasi livello luminescente. (Vedi note 1 e 2 sottostanti)

Spatial Pattern Thresholds

·         Bande chiaramente distinguibili consistenti in più di 5 coppie chiaro-scure, comunque orientate, non sono da usare anche se le bande sono stazionarie, quando la distribuzione occupa più del 40% di una qualsiasi area rettangolare dello schermo di dimensioni 355x268 pixel e il contenuto è visualizzato con risoluzione 1024x768 pixel.

·         Bande chiaramente distinguibili consistenti in più di 5 coppie chiaro-scure, comunque orientate, che cambiano direzione, oscillano, producono intermittenza, o invertono il contrasto non sono da usare quando la distribuzione occupa più del 25% di una  qualsiasi area rettangolare dello schermo di dimensioni 355x268 pixel e il contenuto è visualizzato con risoluzione 1024x768 pixel.

1.      Bande chiaramente distinguibili sono strisce di colore dove la luminanza dello schermo delle zone più scure della distribuzione è al di sotto di 160 cdŸm-2 e differisce dalle zone più chiare di 20 cd·m-2 o più (fai riferimento alle note 1 e 2 sottostanti).  

Note:

1.      La luminanza di un video non è una misura diretta della luminosità dello schermo. Non tutti i dispositivi schermo presentano le stesse caratteristiche di gamma, ma si può scegliere un display con una gamma di 2.2 allo scopo di determinare misure elettriche per controllare la conformità alle linee guida.

2.      Allo scopo di determinare misure elettriche per controllare la conformità alle linee guida, si assume che le immagini siano visualizzate in accordo con 'home viewing environment' descritto nella Recommendation ITU-R BT.500 in cui il massimo di bianco corrisponde ad un’illuminazione dello schermo di 200 cdŸm-2.

3.      I livelli minimi si basano sul documento ITC Guidance Note for Licensees on Flashing Images and Regular Patterns in Television (Riveduto e ripubblicato nel luglio 2001) come modificato dal Wisconsin Computer Equivalence Algorithm.

Nota dell’Editore: Nel secondo trimestre del 2004, verrà reso disponibile dall’University of Wisconsin's Trace Center un free tool in grado di analizzare il contenuto Web.

Chi beneficia della Linea Guida 2.3 (Informativa)

·         Persone con epilessia fotosensibile che possono evitare attacchi dovuti alle intermittenze o alle distribuzioni spaziali.

Linea Guida 2.4 Aggiungere funzionalità che aiutino l’utente ad orientarsi e a spostarsi tra i contenuti. [linea guida di livello 2]

Success Criteria per la Linea Guida 2.4 – Livello 1

  1. Nessun success criteria di livello 1 per questa linea guida.

Success Criteria per la Linea Guida 2.4 – Livello 2

  1. Sono presenti elementi strutturali che si differenziano dagli altri e dal corpo del testo nell’aspetto o nel suono [V].
  2. Nei documenti che contengono più di 50.000 parole o nei siti con più di 50 pagine percepite, è presente almeno una delle seguenti risorse: [V]

Nota dell’Editore: Cos’è una pagina percepite? E se si tratta di un’ applicazione VoiceXML? Come utilizzarla nelle applicazioni Web? Perché 50 e 50.000?

a.      struttura gerarchica

b.      tabella dei contenuti (per le pagine) o mappa del sito (per i siti)

c.      ordine alternativo di visualizzazione (per le pagine) o meccanismi di navigazione di un sito alternativi (per i siti)

  1. Grossi blocchi di contenuto ripetuti in più pagine, quali ad esempio menù di navigazione con più di 8 link, possono essere bypassati da chi usa screen reader o tastiera o interfacce di tastiera [V].

Success Criteria per la Linea Guida 2.4 – Livello 3

  1. Sono fornite informazioni che indicano almeno una sequenza logica in cui leggere il documento [I].
  2. I diagrammi sono costruiti con una struttura che permette agli utenti di accedervi [I].
  3. E’ presente un ordine logico di tabulazione [I].

Nota dell’Editore: "L’ordine logico di tabulazione " può non essere testabile.

  1. Esiste una dichiarazione associata al contenuto in cui si afferma che sono state considerate le voci del seguente elenco: [V]

a.      Frammentare il testo in paragrafi logici,

b.      Suddividere i documenti, in particolare di quelli molto lunghi, in sezioni gerarchiche e sottosezioni con titoli chiari e significativi,

c.      Assegnare un titolo esplicativo ad ogni pagina o risorsa a cui si può accedere in modo indipendente (ad esempio, da una pagina dinamica elaborata da un motore di ricerca)

Nota dell’Editore: Se il requisito per titoli esplicativi è testabile (Linea Guida 3.1) e rimane un success criteria di Livello 2, allora si consideri declinato questo criterio.

d.      Assegnare un unico titolo ad ogni pagina o risorsa a cui si può accedere in modo indipendente (ad esempio, da una pagina dinamica elaborata da un motore di ricerca),

e.      Evidenziare le relazioni non gerarchiche, come i riferimenti incrociati, in modo che le relazioni siano rappresentate in maniera non ambigua nel markup o nel data model.

Nota dell’Editore: Ne esistono altre?

  1. Le enfasi strutturali sono evidenti almeno sui seguenti video [V]:

a.      monitor bianco e nero,

b.      schermi a bassa risoluzione (160x160 pixel),

c.      dispositivi "mono" audio playback.

[V]

Chi Beneficia della Linea Guida 2.4 (Informativa)

·         Se nel markup o nel data model è fornita la struttura logica,

o        Utenti con disabilità fisiche possono usare la  struttura per muoversi più agevolmente fra paragrafi, capitoli, sezioni ecc.

o        Utenti con disabilità cognitive possono usare la  struttura (titoli dei capitoli, intestazioni, ecc.) per contestualizzare meglio il testo di loro interesse. Fra l’altro gli elementi strutturali richiamano l’attenzione sui cambiamenti di contesto ed orientano l’utente verso il nuovo focus.

o        Utenti non vedenti o ipovedenti possono passare da intestazione ad intestazione per avere una panoramica degli argomenti o per "saltare" più rapidamente alla sezione d’interesse.

o        Lettori ipovedenti possono talvolta (a seconda della tecnologia video) modificare la visualizzazione dei titoli dei capitoli e delle intestazioni per renderli più visibili e più facili da usare quando navigano nel documento.

o        Il contenuto può essere visualizzato tramite molteplici dispositivi il cui software non solo è in grado di scegliere quali elementi visualizzare, ma di farlo anche nel modo più efficace.

·         Fornire differenti meccanismi di navigazione può aiutare utenti con diverse abilità, background culturale, orientamento visuale verso il testo, e tipo di informazioni che essi stanno ricercando in quel momento.

·         Per utenti con disabilità cognitive può risultare più facile cercare quello che desiderano piuttosto che dedurne la posizione da scelte categoriche.

·         Utenti ipovedenti o non vedenti possono reputare più efficaci tecniche di ricerca che prelevano i dati inerenti l’argomento d’interesse, rispetto a tecniche che richiedono loro di esaminare liste o elenchi di contenuti.

·         Una presentazione che enfatizza la struttura:

o        Mette in grado gli utenti con disabilità cognitive e visive di orientarsi all’interno dei contenuti,

o        Mette in grado tutti gli utenti di spostarsi più velocemente fra i contenuti e di rilevarne le ripartizioni più importanti,

o        Mette in grado tutti gli utenti, ma particolarmente gli utenti con disabilità cognitive e visive  a focalizzare contenuti chiave,

o        Mette in grado tutti gli utenti, ma particolarmente gli utenti con disabilità cognitive e visive  di distinguere i vari tipi di contenuto.

Esempi relativi alla Linea Guida 2.4 (Informativi)

·         Esempio 1: documentazione per un prodotto

E’ consuetudine identificare i capitoli ed etichettare la struttura di un libro. Nei capitoli, i titoli (etichette) identificano i cambiamenti di contesto e i concetti chiave contenuti nel testo. Le sottili differenze fra l’aspetto del titolo di un capitolo e delle intestazioni dei paragrafi aiutano l’utente a comprendere la gerarchia e le relazioni fra titoli ed intestazioni. Nel caso di informazioni visive, la differenza potrebbe consistere nella dimensione del carattere e nei margini di indentazione; nel caso di informazioni uditive in una voce diversa o in un suono da anteporre.

·         Esempio 2: un’immagine scalabile di una bicicletta

Linee e un circonferenza (raggi e cerchio) sono raggruppati in una “ruota”. Linee in un triangolo che si fissa ad ogni ruota sono raggruppati in un “telaio”.

·         Esempio 3: interfaccia utente

I controlli dell’interfaccia utente sono suddivisi in gruppi organizzati.

·         Esempio 4: una tabella di dati

I gruppi di righe o colonne sono etichettati con le intestazioni.

·         Esempio 5: una presentazione audio

La versione audio di un documento, generata secondo un foglio di stile, utilizza una voce diversa, più formale, per leggere i titoli e le intestazioni in modo che l’ascoltatore possa identificare facilmente le parole componenti i titoli e distinguerle dal restante testo.

Linea Guida 2.5 Aiutare gli utenti ad evitare gli errori e consentire loro di  rimediare con facilità. [linea guida di livello 2]

Success Criteria per la Linea Guida 2.5 – Livello 1

  1. Nessun success criteria di livello 1 per questa linea guida.

Success Criteria per la Linea Guida 2.5 – Livello 2

1.      E’ rilevato un errore dell’utente. L’errore è identificato e segnalato  sotto forma di testo.

2.      E’ rilevato un errore dell’utente e sono noti i suggerimenti per la correzione da poter fornire senza compromettere la sicurezza o gli obiettivi (ad esempio, validità di un test). Tali suggerimenti sono resi disponibili (in forma accessibile come richiesto dai success criteria - Livello 1).  

3.      Se sono importanti le conseguenze ma non il  tempo di risposta, si verifica una delle seguenti possibilità:

a.      Le azioni sono reversibili

b.      Se le azioni sono non reversibili, viene eseguito il controllo degli errori prima di procedere al passo successivo.

c.      Se le azioni sono non reversibili e non controllabili, l’utente è messo in grado di riesaminare e confermare o correggere l’informazione prima che venga trasmessa.

Success Criteria per la Linea Guida 2.5 – Livello 3

1.      Se sono note le opzioni di input, sono meno di 75 e possono essere fornite senza compromettere la sicurezza, la validità di un test, ecc., l’utente può selezionarle da una lista di opzioni così come accedere direttamente al testo

2.      Esiste il controllo ortografico e vengono suggeriti i termini corretti quando è richiesta l’immissione testo.

Chi beneficia della Linea Guida 2.5 (Informativa)

·           Identificare gli errori di battitura aiuta gli utenti disgrafici e dislessici che spesso incontrano difficoltà nell’inserire il testo nei form o dove è richiesto un input testuale.

·           Permettere di selezionare una voce da un elenco, piuttosto che immettere testo direttamente, aiuta gli utenti con disabilità del linguaggio che potrebbero non essere compresi correttamente da un’applicazione con input vocale.

Esempi relativi alla Linea Guida 2.5 (Informativa) 

·           Esempio 1: un motore di ricerca

Un motore di ricerca è provvisto di una varietà di opzioni di ricerca relative a differenti livelli di abilità e diverse preferenze. Include una ricerca vocale e offre alternative di “best guess”, ricerche basate su query-by-example e ricerche analoghe.

Principio 3: Rendere comprensibili contenuti e comandi.

Linea Guida 3.1 Assicurare che possa essere determinato il significato del contenuto.

Success Criteria per la Linea Guida 3.1 – Livello 1

  1.  Il linguaggio naturale utilizzato dal documento nella sua globalità può essere identificato da strumenti automatici [I].
  2. Il significato delle abbreviazioni e degli acronimi può essere individuato programmaticamente [I].

Success Criteria per la Linea Guida 3.1 – Livello 2

  1. I titoli delle pagine sono esplicativi [V].
  2. Il significato e la pronuncia di ogni parola possono essere individuati programmaticamente [I].
  3. Il significato di tutti gli idiomi nel contenuto può essere determinato programmaticamente  [I].
  4. Ogni passo o frase in lingua straniera presente nel contenuto è identificato attraverso markup o in altri modi. Si fa riferimento a passi o frasi che non utilizzano la lingua base del documento. [I]

Nota:

Quanto detto sopra non si applica ai termini stranieri presenti nel testo, diventati di uso comune.

Success Criteria per la Linea Guida 3.1 – Livello 3

  1. Può essere determinato programmaticamente il significato delle abbreviazioni [I].
  2. Quando una parola ha più significati e non è da attribuirle quello che il dizionario associato contempla come principale, è fornito markup aggiuntivo o altra tecnica per poter determinare il significato corretto [I].
  3. Intestazioni di sezione e link testuali sono comprensibili quando letti come un gruppo a sé (ad esempio in una lista di link o in una tabella di contenuti di uno screen reader) [V].
  4. E’ presente una dichiarazione associata al contenuto che afferma l’esistenza di Strategie per Ridurre la Complessità del Contenuto (lista seguente). [V]

Nota dell’Editore: Stiamo tuttora esaminando metodi per rendere testabili alcuni o tutti i success criteria succitati. (che potrebbero diventare success criteria di per sé).

o        In generale

§         Organizzare il materiale in modo che sia semplice da leggere ed usare.

§         Usare un manuale di stile, dizionario, e gli altri materiali di riferimento.

§         Testare i documenti con potenziali utenti per verificare la comprensibilità  del materiale, includendo nel test group soggetti con disabilità cognitive, di apprendimento e di lettura.

§         Sviluppare un solo argomento o sotto argomento per paragrafo.

o        Lessico

§         Usare un lessico che sia familiare ai potenziali lettori.

§         Se la risorsa è diretta a chi lavora in un particolare campo tecnico, usare un linguaggio controllato. Per esempio, una risorsa progettata per ingegneri aeronautici potrebbe servirsi di un linguaggio controllato come quello utilizzato dalla Boeing Aircraft Company.

§         Se una risorsa tecnica è designata ad essere tradotta in altre lingue, usare un linguaggio controllato

§         Evitare gergo professionale, dialetto, e altri termini con significato specialistico che può essere sconosciuto a persone non del ramo, se il materiale è diretto ad una vasta platea o è destinato alla traduzione in altre lingue. Può essere anche utile rivedere il materiale per semplificarne il linguaggio, usando una checklist come quella prodotta dagli Stati Uniti e da agenzie governative canadesi.  

Nota dell’Editore: Bisogna aggiungere altri esempi relativi ad altri paesi ed altre lingue.

§         Formulare frasi di lunghezza e complessità conformi a quanto raccomandato nelle best practices relative al pubblico a cui ci si rivolge. Ciò è quanto avviene nei correnti libri di testo che trattano argomenti della disciplina o del campo d’interesse dei lettori.

o        Frasi

§         Rendere la lunghezza della frase coerente con le comuni pratiche del linguaggio del documento o dello specifico pubblico a cui il documento è diretto. Possono essere utili i libri di testo che trattano della disciplina o del campo d’interesse dei lettori, se disponibili.

o        Sintassi

§         Usare per le frasi  la sintassi più semplice, adatta allo scopo del contenuto. 

§         Per esempio, la sintassi più semplice per una frase inglese è soggetto-verbo-complemento: John hit the ball o Il sito Web è conforme alle WCAG 2.0.  

§         Usare elenchi numerati o puntati al posto di paragrafi che contengono una lunga serie di parole o frasi separate da punteggiatura.

o        Nomi, locuzioni nominali, e pronomi

§         Usare nomi singoli o brevi locuzioni nominali.

§         Rendere chiaro a chi o cosa rimanda un certo pronome e collocarlo il più vicino possibile al termine a cui fa riferimento nel documento. 

Esempio di potenziale ambiguità:

La frase sottostante contiene vari pronomi e non è chiaro a chi o a cosa essi si riferiscano:

Web developers can't understand those guidelines because they don't speak their language.

§         Non è chiaro a quali linee guida si fa riferimento con “those guidelines” (le linee guida che stai leggendo ora, sono these guidelines )

§         Non è chiaro se il pronome “they” è riferito ai Web developers o alle guidelines (la sintassi inglese afferma che dovrebbe riferirsi alle guidelines ma questa regola non sempre è rispettata nell’uso comune)

§         Non è chiaro se il pronome “their” è riferito al linguaggio utilizzato dai Web developers o al linguaggio in cui sono scritte le guidelines

Per evitare ambiguità, la frase può essere riscritta nel seguente modo:

 Web developers can't understand these guidelines because the guidelines are not written in the developers' language.

o        Verbi

o        Voci verbali

§         Usare la voce attiva per documenti scritti in inglese e nelle altre lingue occidentali, a meno che non ci sia una specifica ragione per usare la costruzione passiva. Infatti le frasi attive sono spesso più corte e più facili da capire di quelle in forma passiva.

§         Attivo: Many people believe that readers understand sentences in the active voice more easily than sentences in the passive voice.

§         Passivo: It is believed by many that sentences in the active voice are more easily understood by readers than sentences in the passive voice.

o        Tempi.

§         Usare i tempi verbali in modo coerente.

Ad esempio, non cambiare a caso tra presente e passato. Nella frase, John left the room. He takes the elevator down to the lobby, il passaggio dal tempo passato (nella prima frase left the room) al tempo presente nella seconda frase (takes the elevator) potrebbe creare ambiguità circa l’uso dell’ascensore da parte di John: l’ha usato nel passato o lo sta usando adesso?

o        Logica e relazioni.

§         Indicare le relazioni logiche tra frasi, proposizioni, paragrafi o sezioni del testo.

§         In alcuni casi, semplici parole come “e”, “comunque”, “inoltre”, “perciò” possono essere sufficienti per chiarire la relazione logica tra una proposizione e la successiva. In altri casi può essere utile ricorrere a frasi più lunghe o proposizioni aggiuntive che siano maggiormente esplicative del contenuto. 

o        Istruzioni e contenuti fruibili.

§         Spiegare in modo esauriente istruzioni o azioni richieste.

§         Usare in maniera coerente nomi ed etichette. 

§         Esser chiari nei punti in cui il documento:

§         spiega le scelte e le opzioni, 

§         etichetta le opzioni per ottenere ulteriori informazioni,

§         istruisce gli utenti su come modificare selezioni in funzioni critiche (ad esempio, come cancellare un articolo da un carrello di acquisto).

§         Utilizzare una struttura obiettivo-azione per il prompt di menu. 

§         Utilizzare le impostazioni di default (e renderne facile il ripristino)

§         Utilizzare two-step, “seleziona e conferma” per ridurre selezioni accidentali per funzioni critiche.

§         Fornire assistenza di calcolo (per esempio, usare uno script per calcolare il prezzo totale per un acquisto on-line). 

o        Rappresentazioni alternative: sommari, parafrasi, esempi, illustrazioni, e linguaggi simbolici.

§         Fornire sommari per aiutare la comprensione. 

§         Aggiungere contenuto non-testuale al sito per pagine o sezioni chiave in modo da renderlo più comprensibile agli utenti che non possono capire la sola versione testuale.  

Nota dell’Editore: Le WCAG 1.0 e la Section 508 permettono varianti di solo testo unicamente nei casi in cui "l’originale" non possa esser reso accessibile in alcun modo, e richiedono che la versione solo-testo sia aggiornata ogni volta che si modifica l’originale. Tale richiesta non è presente nelle WCAG 2.0, ma riteniamo necessario reinserirla.

§         Usare design, grafica, colori, font, animazioni, video o audio per chiarire testi complessi.

§         Includere contenuto non-testuale in aggiunta a quello testuale nelle pagine o nelle sezioni chiave del sito. 

Chi beneficia della Linea Guida 3.1 (Informativa)

·         Spesso in un documento sono utilizzate  frasi di lingua diversa dal resto del documento. Se queste sono opportunamente identificate, un sintetizzatore vocale può leggerle con accento e pronuncia appropriati; in caso contrario esso legge la frase in modo incomprensibile poiché continua ad utilizzare la lingua base del documento. Identificare i cambiamenti di lingua permette inoltre di chiedere traduzioni automatiche del contenuto. Nell’editare il testo, gli authoring tools possono scegliere fra dizionari appropriati.

·         Fornire la spiegazione delle abbreviazioni e degli acronimi non solo aiuta gli utenti che hanno poca familiarità con essi, ma chiarisce quale sia il significato più appropriato da usare. Ad esempio, l'acronimo "ADA" sta sia per “American with Disabilities Act” che per “American Dental Association”.

·         Definire termini chiave e linguaggio specifico aiuta le persone che non hanno familiarità con quell’argomento. 

·         La decodifica non ambigua di caratteri e parole di un contenuto è inoltre utile per coloro che stanno imparando a leggere o stanno studiando una seconda lingua. 

·         Tutti gli utenti, specialmente quelli con deficit cognitivo, di apprendimento o difficoltà di lettura si avvantaggiano dell’utilizzo di un linguaggio chiaro e semplice. Ciò non dovrebbe però scoraggiare dall’esprimere idee complesse o concetti tecnici. 

·         Usare un linguaggio chiaro e semplice aiuta chi non padroneggia la lingua, inclusi coloro che comunicano soprattutto col linguaggio dei segni. 

·         Suoni, grafica, video e animazioni possono aiutare a presentare meglio i concetti, specialmente a persone con deficit cognitivo, di lettura, di apprendimento e a chi ha poca familiarità con la lingua del sito. 

·         Riassumere le informazioni difficili da comprendere aiuta le persone con difficoltà di lettura. 

·         Fornire sommari degli schemi visivi che mostrano relazioni e collegamenti fra informazioni complesse aiuta le persone che non utilizzano schemi visivi o che hanno difficoltà ad interpretarli. Ad esempio, i non vedenti non possono servirsi di alcuno schema visivo, mentre i dislessici o gli ipovedenti potrebbero avere difficoltà nell’interpretarli.

Nota:

I designer devono essere cauti nell’utilizzo delle illustrazioni. Leggere una figura è probabilmente un modo di apprendere più facile per alcuni che per altri. Alcuni utenti ignorano le figure, mentre altri leggono solo quelle. I designer devono inoltre tener presente che le convenzioni visive non sono universali e che ognuno sviluppa propri schemi mentali e aspettative nell'interpretare le informazioni visive.  

Esempi relativi alla Linea Guida 3.1 (Informativi)

·          Esempio 1: un acronimo nel titolo di una pagina.

Nel titolo seguente, “People of the W3C”, "W3C" è identificato come un acronimo. Poichè il markup è stato fatto in modo appropriato, gli user agent saranno in grado di leggere le lettere dell’acronimo una alla volta piuttosto che tentare di pronunciarlo come se fosse un’unica parola.

·         Esempio 2: una frase in lingua francese in un periodo in lingua inglese.

Nel seguente periodo, “And with a certain je ne sais quoi, she entered both the room, and his life, forever." la frase "je ne sais quoi" è identificata come lingua francese. A seconda del linguaggio di markup, l’inglese può essere marcato come la lingua usata per l’intero documento, eccetto dove specificato o marcato a livello di paragrafo.

·         Esempio 3: una descrizione di un processo.

Una pagina descrive come imparare a giocare a calcio. Ciascun passo nell’apprendimento delle regole del gioco è illustrato con la foto di un giocatore mentre esegue ciò che viene descritto nel testo.

·          Esempio 4: un concetto concreto.

Il concetto principale espresso in una pagina è un concetto concreto. Si sta trattando del  Monte Pinatubo. Viene descritta l’eruzione del 1991, sono inserite le relative foto, e si discute delle conseguenze. Si effettua un collegamento ad un sito che contiene un video e ad un altro sito che presenta una simulazione in 3D di cosa accade sotto la crosta terrestre e all’interno del vulcano durante l’eruzione.

·         Esempio 5: relazione di una bambina su una gita scolastica.

Una bambina è andata in visita scolastica presso una fabbrica che costruisce biciclette. Scrive una relazione da inserire nel Web per la sua famiglia e per gli amici. In essa, include il logo della compagnia e l’immagine di una bicicletta sulla catena di montaggio. Effettua il collegamento al sito Web della compagnia per ulteriori informazioni e inserisce le foto della fabbrica.

·         Esempio 6: dati sull’andamento della borsa.

Un sito di news confronta l’andamento dell’economia nel terzo trimestre di questo anno con il terzo trimestre degli ultimi tre anni. Si confrontano i prezzi delle azioni più comuni. I dati vengono rappresentati in un grafico a barre collegato ai dati grezzi utilizzati per la creazione del diagramma.

·         Esempio 7: storia della musica.

Un nonno ha l’hobby di ascoltare e suonare musica, tanto che ha creato un sito Web che contiene esempi di vari tipi di musica e di strumenti musicali. Quando descrive specifici tipi di musica, effettua un collegamento ad un breve clip sonoro.

Linea Guida 3.2 Organizzare il contenuto in maniera coerente da "pagina a pagina" e fare in modo che le  componenti interattive si comportino in modo prevedibile.

Nota dell’Editore: Stiamo cercando un termine per rimpiazzare la parola “pagina”  che sia valido per le tecnologie. Per applicazioni visive, si potrebbe utilizzare "schermata", ma tale termine non sarebbe fruibile per tecnologie sonore, come VoiceXML.

Success Criteria per la Linea Guida 3.2 – Livello 1

  1. Qualsiasi cambiamento imprevisto nel contesto è implementato in maniera da poter essere identificato in modo programmatico. [I]  

Success Criteria per la Linea Guida 3.2 – Livello 2

  1. Le componenti  ripetute in più "pagine" all'interno di un documento o  sezione di un documento si succedono sempre nella stessa sequenza, o almeno in un unico formato di presentazione. [V]  
  2. Tutti i componenti dell’interfaccia dovrebbero essere focalizzati, senza provocarne l'attivazione automatica. [I]  
  3. Cambiare il settaggio di qualche campo di input non dovrebbe provocare automaticamente un cambiamento imprevisto nel contesto, come ad esempio l’abbandono della "pagina". [V] 
  4. Elementi interattivi che appaiono in più "pagine", inclusi elementi grafici, sono associati alle stesse funzionalità, ovunque essi appaiano. [I]  
  5. Ogni cambiamento imprevisto nel contesto è segnalato in modo esplicito. [V] 

Nota dell’Editore: Questo criterio è specifico per l’HTML.

Success Criteria per la Linea Guida 3.2 – Livello 3

  1. La destinazione finale di ogni link è chiaramente identificata [V].
  2. Le componenti grafiche che appaiono su più pagine, inclusi i link grafici, sono associati allo stesso equivalente testuale, ovunque essi appaiano [V].
  3. Le componenti che appaiono su più pagine, come barre di navigazione, form di ricerca e sezioni all'interno del contenuto principale, sono visualizzati sempre nella stessa posizione [V]. 
  4. Gli utenti possono scegliere di visualizzare componenti, come menu di navigazione e form di ricerca che appaiono su più pagine, in una differente posizione o con un diverso ordine di lettura  [V].
  5. Non si verificano cambiamenti imprevisti del contesto [V].

Nota dell’Editore: C’è preoccupazione per il fatto che questi success criteria siano troppo specifici per l’HTML.

Chi beneficia della Linea Guida 3.2 (Informativa)

·         Fornire risposte coerenti e prevedibili alle azioni dell’utente costituisce per questi un importante feedback. Consente loro di capire che il sito funziona in maniera appropriata e ne incoraggia le interazioni con i contenuti. Risposte inaspettate potrebbero scoraggiare gli utenti nell’utilizzo del sito o far ritenere che ci siano problemi di funzionamento. Alcuni potrebbero confondersi tanto da non ritenersi in grado di navigare il sito.

·         Gli utenti che non sono capaci d’individuare cambiamenti imprevisti nel contesto o che non possono realizzare che il contesto è cambiato saranno probabilmente meno disorientati nel corso della navigazione. Ci si riferisce alle seguenti situazioni:

o        Non vedenti o ipovedenti che possono avere difficoltà ad individuare cambiamenti nel contesto visivo, come l’apertura automatica di una finestra di pop up. In tal caso, avvertire l’utente che il contesto sta cambiando, minimizza la confusione quando egli scopre che il pulsante per tornare alla pagina precedente non funziona più al solito modo.

o        Nelle presentazioni solo audio, gli utenti sordi o con deficit dell’udito o quelli che non sono in grado di individuare cambiamenti dello speaker: è opportuno, quindi, evidenziarli mediante sottotitoli.

·         Gli ipovedenti, i dislessici o coloro che hanno difficoltà ad interpretare schemi visivi possono beneficiare di indicazioni supplementari per rilevare cambiamenti imprevisti del contesto.

Esempi relativi alla Linea Guida 3.2 (Informativi)

·         Esempio 1: un form per disattivare finestre di pop-up.

In una pagina di link viene fornita una casella di controllo per permettere agli utenti di scegliere se far apparire le pagine attivate nella stessa finestra o meno.

·         Esempio 2: un avvertimento fornito prima dell’apertura di una finestra di pop-up.

Al termine di una notizia  di attualità, vengono forniti parecchi link per ottenere ulteriori informazioni. All’inizio di ogni link viene posta un'icona a forma di freccia, con testo equivalente "Il collegamento attiverà una nuova finestra ".

·         Esempio 3: frame che non permettono di tracciare lo sviluppo della storia perché il pulsante per tornare alla pagina precedente si comporta in maniera inaspettata.

·         Esempio 4: form.

Nota dell’Editore: E’ necessario completare questi esempi o sostituirli con altri migliori.

Principio 4: Progettare  contenuti sufficientemente robusti al fine di garantirne la compatibilità con le tecnologie presenti e future.

Linea Guida 4.1  Utilizzare tecnologie che rispettino le specifiche.

Success Criteria per la Linea Guida 4.1 – Livello 1

  1. Eccetto il caso in cui il sito abbia documentato che una specifica è stata violata per compatibilità con le versioni precedenti o per compatibilità con una tecnologia assistiva, la tecnologia ha: [I]

a.      superato i test di validazione per la versione in uso (se essa è conforme o meno ad uno schema, Document Type Definition (DTD), o soddisfa altri test descritti nelle specifiche),

b.      gli elementi strutturali e gli attributi sono utilizzati come suggerito nelle specifiche.

Success Criteria per la Linea Guida 4.1 – Livello 2

1.      Nessun success criteria di livello 2 per questa linea guida.

Success Criteria per la Linea Guida 4.1 – Livello 3

  1. Le tecnologie sono utilizzate nel rispetto delle specifiche senza eccezioni. [V]

Chi beneficia della Linea Guida 4.1 (Informativa)

·         Questa linea guida enfatizza inoltre che le future specifiche accrescono la probabilità di contenuto accessibile. Mentre altre linee guida fanno riferimento a parti specifiche del contenuto, la 4.1 fa un passo indietro per guardare al quadro generale. Esiste anche per aiutare a coprire le tecnologie future o i problemi che non possiamo prevedere nel momento in cui tale linea viene redatta. Così, i vantaggi delle future specifiche consistono principalmente nel fatto che le tecnologie assistive e gli user agent possono rappresentare il contenuto in modo conforme.

·         Conformarsi alle future specifiche per markup e altri formati di file rende più semplice riformattare, riproporre e riutilizzare il contenuto, cosa importante per gli utenti che possono utilizzarlo a pieno solo se è presentato in un particolare formato.

Esempi relativi alla Linea Guida 4.1 (Informativi)

·         Esempio 1: elementi strutturali

In tutto un sito Web storico, gli elementi strutturali sono usati in maniera appropriata per indicare la presenza di citazioni, definizioni e riferimenti bibliografici. Poiché questi elementi sono stati utilizzati secondo le specifiche, gli user agent possono essere configurati in maniera tale che gli elementi siano differenziati dal resto del contesto, permettendo all’utente di ottimizzare l’uso del sito per scopi di ricerca.

·         Esempio 2: elementi di  presentazione

Un autore Web desidera attirare l’attenzione su una serie di parole di una pagina per ragioni puramente estetiche. Usa elementi progettati per applicare caratteristiche di stile e di presentazione, piuttosto che elementi progettati per trasmettere informazioni circa la struttura o l’organizzazione della pagina e per esaltare la presentazione visiva ed evita elementi poco comprensibili a utenti che non usano l’informazione visuale o che fanno riferimento solo al testo.

·         Esempio 3: API accessibili

Un’applet Java utilizza l’accessibilità API definita dal linguaggio. Far riferimento a IBM Guidelines for Writing Accessible Applications Using 100% Pure Java.

Linea Guida 4.2 Assicurare che le interfacce utente siano accessibili o fornite di alternative accessibili.

Success Criteria per la Linea Guida 4.2 – Livello 1

  1. Almeno un plug-in necessario per accedere al contenuto soddisfa sia i requisiti di conformità nelle User Agent Accessibility Guidelines (UAAG) 1.0 (che devono essere soddisfatte al livello A) sia i sottostanti (a) through (j). Se il plug-in necessario non è accessibile, è disponibile una soluzione alternativa conforme alle WCAG 2.0. Se sono disponibili plug-in inaccessibili, il contenuto spiega come ottenere un plug-in accessibile. [V]
  2. Ogni componente programmatica dell’interfaccia utente del contenuto è conforme sia a quanto richiesto nelle UAAG 1.0 (che devono essere soddisfatte al livello A) sia ai requisiti sottostanti. Se le interfacce utente personalizzate non possono essere rese accessibili, è presente una soluzione alternativa conforme alle WCAG 2.0 al livello richiesto. [V]

Requisiti (a) through (j)

a.      Le applicazioni che presentano testo sotto forma di immagine dovrebbero conformarsi ai VisualText checkpoints.

b.      Le applicazioni che presentano immagini dovrebbero conformarsi agli Image checkpoints.

c.      Le applicazioni che presentano animazioni dovrebbero conformarsi agli Animation checkpoints.

d.      Le applicazioni che utilizzano video dovrebbero conformarsi ai Video checkpoints.

e.      Le applicazioni che utilizzano audio dovrebbero conformarsi agli Audio checkpoints.

f.        Le applicazioni che eseguono un proprio event handling dovrebbero conformarsi agli Events checkpoints.

g.      Le applicazioni che implementano meccanismi di selezione dovrebbero  conformarsi ai Selection checkpoints.

h.      Le applicazioni dovrebbero supportare l’accesso tramite tastiera per i checkpoint 1.1 e 6.7.

i.        Le applicazioni che implementano input vocali o di puntamento dovrebbero conformarsi agli Input Modality checkpoints.

Success Criteria per la Linea Guida 4.2 – Livello 2

  1. Sono utilizzate le regole di accessibilità del markup o dei linguaggi di programmazione (markup API o specifico). [I]

Success Criteria per la Linea Guida 4.2 – Livello 3

  1. La risorsa Web include una lista delle tecnologie che gli user agent devono supportare allo scopo di rendere operativo il contenuto come prefisso. La lista è documentata nei metadata se essi sono supportati dal formato, altrimenti nei suggerimenti per l’uso associati al contenuto. [V]
  2. Gli utenti che non possiedono una o più di tali tecnologie possono ancora accedere ed utilizzare la risorsa, anche se in modo limitato. [V]

Nota:

Quando selezioni la tecnologia occorrente, considera che l’hardware e il software assistivi si adattano con ritardo ai progressi tecnologici e che la disponibilità di tecnologie assistive varia a seconda dei linguaggi naturali. Verifica che la tecnologia assistiva compatibile con le tecnologie che hai scelto sia disponibile nel linguaggio naturale del tuo contenuto.

  1. Le tecnologie e le caratteristiche utilizzate sono open standard o hanno specifiche pubbliche. [V]

Chi beneficia della Linea Guida 4.2 (Informativa)

·         Gli autori che assicurano l’accessibilità delle interfacce utente in tutto il loro contenuto:

o        andranno incontro a minori difficoltà implementando queste linee guida,

o        non avranno bisogno di creare soluzioni personalizzate e procedere per approssimazioni successive per fronteggiare i problemi di accessibilità,

o        non avranno bisogno di fornire versioni alternative del contenuto presentato mediante una tecnologia  che non si adegua totalmente a queste linee guida.

Vantaggi nel determinare e documentare i requisiti delle tecnologie:

o       Gli utenti possono capire (attraverso la documentazione del sito o automaticamente attraverso i metadata) se sono o non sono in grado di utilizzare il sito. In combinazione con un motore di ricerca o un server proxy, ciò potrebbe servire a filtrare ed escludere i siti a cui l’utente non può accedere oppure servire a filtrare i migliori siti usabili.

o        Documentare i requisiti tecnologici costringerà gli autori a valutare le assunzioni degli user agent e minimizzerà il numero di siti loro malgrado inaccessibili perché non sono consapevoli dei problemi di compatibilità sottostanti.

Vantaggi nell’assicurare l’accessibilità dell’interfaccia utente e nel fornire alternative accessibili:

o        Utenti che devono usare browser e dispositivi alternativi saranno in grado di accedere al contenuto.

o        Anche gli utenti che non possono permettersi o non possono avere accesso alle più recenti tecnologie traggono vantaggio dalla compatibilità con le versioni precedenti poiché non avranno bisogno di acquistare spesso aggiornamenti o attrezzature.

Esempi relativi alla Linea Guida 4.2 (Informativi)

·         Esempio 1: un magazzino online che elenca le tecnologie richieste

Documentando i requisiti minimi degli user agent, lo store rende possibile l’uso di particolari tecnologie per determinare se le persone potranno o meno trovarsi in difficoltà utilizzando lo stesso store o il suo meccanismo di checkout prima che comincino ad acquistare. Ciò evita che gli utenti, dopo aver selezionato i prodotti e iniziato il processo di checkout, scoprano di non essere in grado di completare la transazione. Essi possono, comunque, scegliere alternative per riuscire nell’intento.

·         Esempio 2: un sito intranet che si trasforma in modo gradevole

Una grande compagnia si interessa di indirizzare gli utenti alle varie diverse office locations che hanno differenti basi tecnologiche. Per risolvere il problema, essa ha creato due versioni dei propri contenuti e documentato i requisiti per ciascuno, rendendo facile per gli utenti determinare con quale versione lavorare al meglio nel rispetto delle loro tecnologie.

·         Esempio 3: un sito di informazione che assicura la compatibilità con le versioni precedenti.

Un sito di informazione tratta di una gran varietà di argomenti e vuole mettere in grado i propri visitatori di reperire velocemente gli argomenti oggetto della ricerca. A questo scopo, è stato implementato nel sito un sistema di menù interattivo supportato dalla più recente versione di due diffusi user agent. Per assicurare ai visitatori sprovvisti di questi user agent di utilizzare in maniera efficiente il sito, viene fornito un meccanismo di navigazione che non dipende dal sistema di menù interattivo e che non supporta le tecnologie più recenti.

Appendice A Glossario

Nota dell’editore: Il WCAG WG non ha ancora affrontato le definizioni dei termini, utilizzati a volte in modo non coerente. È necessario coordinare i  termini e le definizioni col Glossario del WAI e lavorare sulle proposte per organizzare le definizioni. L’attenzione è rivolta al glossario dell'UAAG 1.0 e agli altri glossari del W3C.

Attività in cui la temporizzazione è essenziale

Un’attività in cui la temporizzazione è essenziale è stata progettata in modo che il tempo rivesta in essa un’importanza fondamentale.  La rimozione del fattore tempo può modificare la performance dei partecipanti. Potrebbero essere preferite e necessarie in alcune circostanze attività (es. test) non basate sul tempo o con limiti di tempo. Questo comporterebbe riprogettare l’attività (es. test) e potrebbe modificarne il carattere e i metodi di validazione e quindi non rientrerebbe nel campo di azione di queste linee guida.

Arte ASCII

Rappresentazioni grafiche create per mezzo di una sistemazione spaziale di caratteri di testo. Sebbene si possa  visualizzare in forma testuale, non si tratta di testo.

Descrizione audio

Una descrizione audio è una descrizione verbale di significative informazioni visive relative a scene, azioni, eventi che non possono essere percepiti soltanto dalla traccia sonora.  L’estensione è resa possibile dai vincoli esistenti sulla traccia audio e dalle limitazioni relative al congelamento del programma audiovisivo, per l’inserimento di descrizioni audio supplementari.

Nota:

Quando viene aggiunta una descrizione audio a materiali esistenti, tutte le informazioni veicolate attraverso tale descrizione sono vincolate dallo spazio disponibile nell’esistente traccia audio, a meno che il suo inserimento sia consentito dalla possibilità di congelare periodicamente il programma audiovisivo. Comunque è spesso impossibile o inappropriato effettuare tale congelamento per inserire descrizioni audio supplementari.

Sottotitoli

I sottotitoli sono equivalenti testuali di informazioni uditive relative al parlato, a effetti sonori, a suoni di ambiente sincronizzati con la presentazione multimediale.

Contenuto complesso

Il contenuto è considerato complesso quando non è facile dedurre le relazioni esistenti tra le varie informazioni. Se la presentazione delle informazioni mira ad evidenziare trend o relazioni tra i concetti, questi dovrebbero essere esplicitati nel sommario.

Esempi d’informazioni complesse:

·         Tabelle di dati,

·         Concetti esoterici o difficili da capire,

·         Contenuto sviluppato su più livelli.

 

Contenuto

Contenuto

Nota dell’editore: È necessario includere in questo punto una definizione di contenuto.

Contenuto che lampeggia

Il contenuto che lampeggia è un contenuto che si accende e si spegne tra 0.5  e 4 volte al secondo.

Linguaggi controllati

I linguaggi controllati usano un vocabolario ristretto che costituisce un sottoinsieme del linguaggio naturale. Lo scopo è di rendere i testi più semplici da capire e da tradurre. Gli standard in genere attribuiscono alle parole un solo significato e prestabilita parte del discorso. È evitata la sintassi complessa. Informazioni sulle applicazioni di linguaggio controllato sono disponibili sul Web.

Event handler

Sezione di codice che corrisponde ad un'azione effettuata dall'utente (o dallo user agent). Sulle pagine Web, gli eventi di solito sono azioni eseguite dall’utente come il movimento del mouse, la pressione di un tasto, ecc. Un event handler determina la risposta a quell'azione. Un event handler specifico per una tecnologia risponde solo ad un'azione effettuata tramite un certo dispositivo di input. Un abstract event handler corrisponde ad un’azione che può essere attivata da più dispositivi di input.

Esplicitamente associato

Nota dell’editore: È necessario includere in questo punto una definizione di associazione esplicita.

Cambiamento imprevisto nel contesto

Un cambiamento imprevisto nel contesto include:

·         apertura inaspettata di una nuova finestra del browser e senza alcuna indicazione non visiva (il pulsante per tornare alla pagina precedente improvvisamente non funziona)

·         in una presentazione auditiva, lo speaker cambia senza che venga dato un avvertimento visivo o un’indicazione nei sottotitoli

·         sottotitoli che non segnalano il cambiamento dello speaker 

Azioni tipiche dell’utente sono:

·         movimenti del mouse

·         attivazione di un tasto

·         selezione di un link

·         uso di un pulsante di navigazione del browser (es. pulsanti per tornare indietro o andare avanti)

·         apertura di nuove finestre del browser

Risposte tipiche alle azioni dell’utente sono:

·         caricamenti di nuove pagine

·         visibilità o meno del contenuto a seconda della posizione del mouse o del focus della tastiera

·         visualizzazione dei contenuti di un menù (in modo auditivo o visivo)

·         visualizzazione di menù o finestre di pop-up

·         sottoscrizione di un form

È importante che le risposte alle azioni dell’utente siano prevedibili e percepibili e che le modalità  d’interazioni siano coerenti in tutto il sito, e analoghe alle metafore d’interazione comunemente usate nel Web. 

Caratteristica

Una caratteristica è una specifica componente di una tecnologia, per esempio un elemento in un linguaggio di markup o l’attivazione di una funzione in una Application Programming Interface. Solitamente, una certa caratteristica può essere disponibile solo in determinate versioni della tecnologia, e quindi può essere necessario segnalare la cosa nell'elenco dei requisiti.

Funzionalità

Le funzionalità rappresentano lo scopo o effetto previsto del contenuto. Ciò può includere presentare di un’informazione, raccogliere dati, assicurare una risposta da parte dell’utente, fornire esperienza all’utente, stabilire collegamenti ad altro contenuto, testare, confermare, l’acquistare, ecc. 

Interfaccia di tastiera

Su dispositivi che non hanno una tastiera incorporata o annessa, esiste spesso un metodo alternativo per connettere la tastiera al dispositivo o un metodo interno per inserire un testo. Attraverso “l' interfaccia di tastiera”, il contenuto può essere controllato attraverso comandi da tastiera o metodi alternativi che ne sostituiscono l’utilizzo.

Marcato in modo che l’utente possa accedervi prima del suo apparire

Il contenuto è marcato in modo da permettere all’utente di individuare il materiale indesiderato e di evitarlo. Alcuni metodi che potrebbero essere usati a tale scopo includono:

·         metadata relativi alla pagina

·         informazioni nel titolo (così i motori di ricerca sono in grado di mostrarle)

·         notifica sulla pagina prima che le informazioni indesiderate siano visualizzate

Nota dell’editore:Questa definizione necessita di rielaborazione.

Media equivalenti

I media equivalenti presentano visivamente informazioni audio essenziali (sottotitoli) ed uditivamente informazioni video essenziali (descrizioni audio).

Linguaggi naturali

I linguaggi naturali sono quelli usati dall’uomo per comunicare, inclusa le lingue parlate, scritte e il linguaggio dei segni.

Contenuto non testuale

Il contenuto non testuale include, ma non si limita, a immagini, testo in immagini raster, mappe immagini, animazioni (es. GIF animate), arte ASCII, immagini usate come list bullet,  barre spaziatrici, pulsanti grafici, suoni (che si attivano con o senza interazione dell’utente), file audio stand-alone, tracce audio o video, video. Inoltre includono qualunque testo che non può essere tradotto nel linguaggio Unicode.

Nota:

Script, applet, e oggetti programmatici non sono inclusi in questa definizione e sono analizzati nella linea guida 4.2.

Normativo

Richiesto per la conformità.

Presentazione

La presentazione è la resa del contenuto e della struttura in una forma che può essere percepita dall’utente.

Componente programmatica dell’interfaccia utente

Componente d’interfaccia creata dall’autore, aggiuntiva rispetto a quelle fornite dallo user agent. Per esempio, una casella di controllo HTML non può essere una componente programmatica dell’interfaccia utente perché l’autore usa una componente dell’interfaccia supportata dallo user agent. Una casella di controllo implementata con script potrebbe essere una componente programmatica dell’interfaccia utente perché fornisce funzionalità che sono note o supportate dagli user agent e non possono essere rese accessibili dagli user agent anche se questi si conformano alle UAAG.

Determinato programmaticamente

Programmaticamente determinato indica che può essere determinato il significato specifico.

Individuato programmaticamente

Individuato programmaticamente vuole dire che il significato può essere trovato, sebbene possano esistere più significati per una stessa parola.

Nota dell’editore: Questa disposizione dipende dalla definizione di un modo standard di associare i dizionari e dalla disponibilità di dizionari on-line. 

Eventi in tempo reale

Eventi in tempo reale sono accadimenti che non sono sotto il diretto controllo dell’autore.

Meccanismo di navigazione di un sito

Un meccanismo di navigazione di un sito è un meccanismo per orientarsi e muoversi facilmente all’interno del sito. I meccanismi di navigazione di un sito includono ma non sono limitati a:

·         una homepage con hyperlink e pagine successive che collegano ad altre parti del sito

·         mappa(e) del sito

·         motore(i) di ricerca

·         schema(i) che si espandono

·         visioni dinamiche a vasto raggio che mostrano tutte le pagine linkate o gli argomenti collegati a ciascuna pagina

·         rappresentazioni virtuali in 3-D del contenuto del sito

 

Struttura

La struttura include sia la struttura gerarchica del contenuto, sia le relazioni non gerarchiche come i riferimenti incrociati o le corrispondenze tra le intestazioni e i dati contenuti nelle celle di una tabella. La struttura gerarchica del contenuto rappresenta le variazioni nel contesto. Per esempio,

1.      un libro è diviso in capitoli, paragrafi, liste. I titoli dei capitoli aiutano il lettore ad anticipare il senso dei paragrafi successivi. Le liste indicano concetti separati, ma collegati tra loro. Tutte queste suddivisioni aiutano il lettore ad anticipare le variazioni nel contesto.

2.      una bicicletta è costituita da ruote e telaio. Inoltre una ruota è divisa in pneumatico e cerchio. In un’immagine di bicicletta, un gruppo di cerchi e linee si trasformano in una “ruota” mentre un altro gruppo si trasforma nel “telaio”.

Tecnologia

Una tecnologia è

·         un linguaggio di markup o di programmazione

·         un’applicazione Programming Interface (API)

·         o un protocollo di comunicazione

Testo

Editorial Note: Stiamo attualmente lavorando con Internationalization (I18N) per includere riferimenti ed esprimere meglio le definizioni  WCAG 2.0 relative a  “testo” e “codifica dei caratteri”.

Descrizione testuale

Editorial Note: È necessario inserire in questo punto una definizione di descrizione testuale.

Etichetta di testo

Editorial Note: È necessario inserire in questo punto una definizione di etichetta di testo.

Testo equivalente (equivalente testuale)

Un testo equivalente

·         ha la stessa funzione del contenuto non testuale

·         comunica la stessa informazione veicolata dal contenuto non testuale

·         può comprendere contenuto strutturato o metadata

Nota:

Gli equivalenti testuali dovrebbero essere facilmente convertibili in Braille o parlato, visualizzati con un font più grande o colori diversi, inseriti nei traduttori o in software per riassumere, etc

Presentazioni dipendenti dal tempo

Una presentazione dipendente dal tempo è una presentazione che:

·         è formata da tracce audio e video sincronizzate (es. un film), o

·         richiede all'utente di interagire in uno specifico momento della presentazione.

 

Contenuto poco familiare

È probabile che il contenuto sia poco familiare se si usano termini specifici per un particolare uditorio. Per esempio, molti dei termini usati in questo documento sono specifici per la comunità dei disabili. 

Wisconsin Computer Equivalence Algorithm

Il Wisconsin Computer Equivalence Algorithm è un metodo per applicare i principi espressi dalla ITC del Regno Unito nel documento "ITC Guidance Note for Licensees on Flashing Images and Regular Patterns in Television (Revisionato e pubblicato nel Luglio 2001)" al contenuto visualizzato sullo schermo di un computer, come le pagine Web o altri contenuti digitali. ITC Guidance si basa sull’assunzione che lo schermo televisivo occupa i dieci gradi centrali del campo visivo.  Questo non è esatto per uno schermo che è collocato di fronte ad una persona. Il Wisconsin Algorithm fondamentalmente esegue la stessa analisi delle linee guida dell’ITC, ma lo fa per ogni possibile finestra di dieci gradi di un prototipo di display di calcolatore.

Nota dell’editore: I collegamenti ai riferimenti saranno forniti non appena essi saranno disponibili.

 

Appendice B Collaboratori

Partecipanti al WCAG Working Group

 

Appendice C  Differenze tra le WCAG 1.0 e le WCAG 2.0

Sin dalla pubblicazione delle WCAG 1.0 nel Maggio 1999, il WCAG Working Group ha ricevuto feedback sulle priorità dei checkpoint, sull’usabilità  dei vari documenti, e richieste di chiarimenti sul significato di specifici checkpoint e di come operare per soddisfarli. Pertanto quando le WCAG 2.0 diventeranno una W3C Recommendation:

·         saranno organizzate in modo più efficiente,

·         potranno rettificare la priorità di alcuni checkpoint,

·         potranno modificare, eliminare o aggiungere requisiti a seguito dei cambiamenti nelle Tecnologie Web, riscontrati dopo la pubblicazione delle WCAG 1.0,

·         incorporeranno gli Errata delle WCAG 1.0,

·         faranno tesoro dell’esperienza acquisita nell’implementare le WCAG 1.0.

Per un confronto dettagliato, fare riferimento al documento  Mapping Between WCAG 1.0 and the WCAG 2.0 Working Draft.

Miglioramenti nelle WCAG 2.0

Ci auguriamo che le WCAG 2.0 presentino parecchi miglioramenti rispetto alle WCAG 1.0. L’obiettivo principale delle  WCAG 2.0 è lo stesso delle WCAG 1.0 (promuovere l’accessibilità dei contenuti Web). Obiettivi supplementari per le WCAG 2.0 sono:

1.      assicurare che i requisiti possano essere applicati trasversalmente dalle tecnologie

2.      assicurare che i requisiti per la conformità siano chiari

3.      assicurare che i documenti siano facili da  usare

4.      scrivere per un pubblico variegato

5.      identificare chiaramente chi beneficia dei contenuti accessibili

6.      assicurare che la revisione sia compatibile con le WCAG 1.0

Per maggiori informazioni circa i miglioramenti proposti nella Working Draft WCAG 2.0 fare riferimento ai Requisiti per WCAG 2.0.

 

Appendice D Riferimenti

Nota dell’editore: I collegamenti che si trovano nel documento saranno elencati in questa sezione. Per il momento essi sono interni al documento stesso.