�

Sommario

Queste specifiche forniscono delle linee guida per gli sviluppatori di tool di sviluppo per il web. Lo scopo è in due direzioni: assistere gli sviluppatori nella creazione dei sistemi di sviluppo per il web per produrre contenuti che siano accessibili nonché assistere gli sviluppatori nella creazione di interfacce accessibili dei propri sistemi di sviluppo.

I sistemi di sviluppo possono consentire, incoraggiare e assistere gli utenti ("autori") nella creazione di contenuti accessibili per il web attraverso richiami, avvisi, funzionalità di controllo e riparazione, documenti di supporto e sistemi automatizzati. E' importante che tutte le persone siano capaci di creare contenuti che allo stesso tempo siano accessibili a tutti. Gli strumenti di sviluppo utilizzati per generare queste informazioni devono quindi essere anch'essi accessibili. L'utilizzo di queste linee guida contribuirà alla proliferazione di contenuti per il web che possono essere fruiti da una più vasta gamma di utenti nonché di sistemi di sviluppo che possono essere usati da una più vasta gamma di autori.

Questo documento è parte di una serie di documentazione sull'accessibilità pubblicata dal the W3C Web Accessibility Initiative (WAI).

Stato del Documento

Questa sezione descrive lo stato del documento al momento della sua pubblicazione. Altri documenti possono sostituire questo documento. L'ultima condizione di questa serie del documento è effettuata dal W3C.

Questo documento fa da appendice alle "Linee Guida per l'Accessibilità degli Strumenti di Sviluppo per il Web 1.0", documento che è stato riveduto dai membri del W3C e da altre parti interessate ed è stato approvato dal Direttore come Raccomandazione W3C. La presente versione è stabile e può essere utilizzata come materiale di riferimento o citata come normativa di riferimento da parte di altri documenti. Questo incrementa la funzionalità e l'interoperabilità del Web.

E' disponibile riepilogo delle implementazioni dei successivi documenti in fase di lavorazione.

Per ulteriori informazioni sulle decisioni del Gruppo di Lavoro, è possibile consultare i verbali degli incontri dell'- AUWG.

Questo documento è stato prodotto dal Authoring Tool Accessibility Guidelines Working Group (AUWG) come parte del progetto Web Accessibility Initiative (WAI). Gli obiettivi del gruppo di lavoro sono presentati nel Manifesto AUWG .

E' possibile inviare commenti sull'argomento alla lista di discussione pubblica: [email protected] (archivi pubblici).

Solamente la versione in lingua inglese di questa specifica ha valore normativo. Maggiori informazioni sulle traduzioni di questo documento sono disponibili all'indirizzo web http://www.w3.org/WAI/AU/ATAG-TRANSLATIONS.

L'elenco di errori conosciuti riscontrati in questo documento sono disponibili all'indirizzo web http://www.w3.org/WAI/AU/ATAG-ERRATA. Ulteriori errori di questo documento possono essere segnalati a [email protected].

Un elenco delle attuali Raccomandazioni e di altri documenti tecnici del W3C, inclusi documenti in fase di sviluppo e annotazioni possono essere consultati all'indirizzo web http://www.w3.org/TR.

Una appendice di questo documento [ATAG10-CHECKLIST] elenca un riferimento conveniente di tutti i punti di controllo.

1. Introduzione

In queste linee guida il termine "sistema di sviluppo" fa riferimento ad una vasta gamma di applicazioni software per la creazione di contenuti per il web, includendo:

• Sistemi di sviluppo generati per produrre contenuti per il web (ad esempio, sistemi di sviluppo WYSIWYG per HTML e XML);
• Sistemi che offrono l'opzione di salvare contenuti in un formato utilizzabile nel web (ad esempio, word processor e sistemi di desktop publishing);
• Sistemi che trasformano documenti in un formato utilizzabile nel web (ad esempio, filtri che trasformano documenti di applicazioni desktop in documenti HTML);
• Sistemi che producono elementi multimediali, specialmente se intesi per la pubblicazione nel web (ad esempio, produzioni video e sistemi di pubblicazione multimediale, sistemi di produzione SMIL);
• Sistemi per la gestione di siti o per la pubblicazione di siti web, inclusi i sistemi che generano dinamicamente siti web da un database, sistemi di conversione in tempo reale e sistemi di pubblicazione sul web;
• Sistemi per la gestione della presentazione (ad esempio, sistemi di formattazione tramite fogli di stile CSS).

Gli obiettivi di questo documento possono essere dichiati come segue: che i sistemi di sviluppo siano accessibili agli autori senza discriminarne la disabilità, che per impostazione predefinita si producano contenuti accessibili e che questo supporti e incoraggi gli sviluppatori a creare contenuti accessibili. Poiché molti dei contenuti del web sono generati utilizzando dei sistemi di sviluppo, questi giocano un ruolo critico nel garantire l'accessibilità del Web. Poiché il web è uno strumento sia di ricezione che di invio di informazioni, è importante che sia i sistemi di sviluppo che i contenuti per il web prodotti siano entrambi accessibili.

Per realizzare questi obiettivi, gli sviluppatori degli strumenti di sviluppo devono prendere le misure come accertare la conformità agli standard di accessibilità (ad esempio, HTML 4), controllando e correggendo i problemi di accessibilità, segnalandoli e provvedendo dell'adeguata documentazione e supporto. Per informazioni dettagliate su cosa costituisca l'accessibilità dei contenuti per il web, è possibile analizzare le Linee Guida per l'Accessibilità dei Contenuti per il Web 1.0 [WCAG10]. Per la stessa motivazione, piuttosto che riprodurre delle specifiche attuali per l'accessibilità nello sviluppo dei software, queste linee guida si appoggiano direttamente su altre fonti. Le presenti linee guida forniscono indirizzi e considerazioni specifiche ai sistemi di sviluppo per il web, provvedendo ad esempio per gli autori delle modalità flessibili di visualizzazione in fase di modifica, supporti durante la navigazione e accesso alla visualizzazione di proprietà.

I principii disposti in queste linee guida avvantaggeranno anche molti utenti senza disabilità ma con necessità similari. Questi utenti possono essere persone che lavorano in ambienti rumorosi o silenziosi in qui l'uso del suono non è pratico, persone che devono usare gli occhi per altre operazioni e non possono osservare uno schermo, e le persone che utilizzano piccoli dispositivi portatili dotati di schermi ridotti, senza tastiera o mouse.

In un altro documento, intitolato "Tecniche per Linee Guida per l'Accessibilità degli Strumenti di Sviluppo per il Web 1.0" [ATAG10-TECHS], sono forniti suggerimenti ed esempi su come soddisfare ogni punto di controllo. Include inoltre riferimenti ad altre risorse sull'accessibilità (come ad esempio linee guida per l'accessibilità di applicazioni per una specifica piattaforma) che forniscono informazioni aggiuntive su come un sistema di sviluppo possa soddisfare i singoli punti di controllo. I lettori sono fortemente incoraggiati a familiarizzare con i documenti tecnici, così come per le "Tecniche per l'Accessibilità dei contenuti per il Web 1.0" [WCAG10-TECHS] e le "Tecniche per l'accessibilità dei sistemi di navigazione 1.0" [UAAG10-TECHS].

Annotazione: Le tecniche contenute in [ATAG10-TECHS] sono solamente esempi informativi. Altre strategie possono essere usate per soddisfare i punti di controllo oltre, o al posto, di quelle discusse nelle [ATAG10-TECHS].

Annotazione: I sistemi di sviluppo conformi a questo documento diffonderanno contenuti accessibili e saranno utili a chiunque indipendentemente dalla disabilità. Ci saranno inoltre sistemi di sviluppo che produrranno contenuti accessibili in circostanze favorevoli (ad esempio, un editor di testo utilizzato da un autore motivato), ma non saranno conformi a queste linee guida.

1.1 Come sono organizzate le Linee Guida

Le sette linee guida contenute in questo documento sono dei principi generali per lo sviluppo accessibile. Ogni linea guida include:

• Il numero della linea guida;
• La dichiarazione della linea guida;
• La spiegazione della linea guida;
• Una lista delle definizioni dei punto di controllo.

Le definizioni dei punti di controllo in ogni linea guida specificano i requisiti per i sistemi di sviluppo per la conformità alle linee guida. Ogni definizione dei punti di controllo include:

• Il numero del punto di controllo;
• La dichiarazione del punto di controllo;
• La priorità del punto di controllo;
• In alcuni casi delle note informative, degli esempi chiarificatori, o dei riferimenti incrociati con relazione a linee guida o punti di controllo;
• Un collegamento ad una sezione delle "Tecniche per le Linee Guida per l'Accessibilità degli Strumenti di Sviluppo per il Web 1.0" [ATAG10-TECHS] dove vengono discusse implementazioni ed esempi per il punto di controllo.

Ogni punto di controllo è inteso per essere sufficientemente specifico in modo che possa essere verificato, ed allo stesso tempo sufficientemente generale da permettere agli sviluppatori la libertà di utilizzare le strategie più adatte per soddisfarlo.

Una appendice di questo documento [ATAG10-CHECKLIST] elenca un riferimento conveniente di tutti i punti di controllo.

1.3 Conformità a queste Linee Guida

Questa sezione spiega come creare una dichiarazione di validità attestante la conformità di un sistema di sviluppo a questo documento. Chiunque può creare una dichiarazione di validità (ad esempio, produttori di sistemi di sviluppo, terze parti per quei prodotti, giornalisti circa quei prodotti, ecc.). La dichiarazione può essere pubblicata ovunque (ad esempio, nel Web o nella documentazione del prodotto).

Gli autori della dichiarazione sono i soli responsabili di quanto dichiarano e per l'utilizzo delle icone di conformità. Se l'oggetto della dichiarazione (ad esempio, una applicazione) viene modificato successivamente alla data di dichiarazione, il dichiarante ha la responsabilità di aggiornare la dichiarazione. Chi si occupa dello sviluppo delle dichiarazioni è incoraggiato alla conformità alle linee guida più recenti.

Informazioni dettagliate sulle icone di conformità sono disponibili nel web (riferimento [CONFORMANCE]).

Livelli di Conformità

Una dichiarazione di conformità deve indicare il livello di conformità raggiunto:

• Livello di Conformità "A": sono soddisfatti tutti i punti di controllo di Priorità 1 (inclusi i punti di controllo per la Priorità Relativa).
• Livello di Conformità "Doppia-A": sono soddisfatti tutti i punti di controllo di Priorità 1 e 2 (inclusi i punti di controllo per la Priorità Relativa)
• Livello di Conformità "Tripla-A": sono soddisfatti tutti i punti di controllo di Priorità 1, 2 e 3 (inclusi i punti di controllo per la Priorità Relativa)

Annotazione: I livelli di conformità sono indicati in testo esteso (ad esempio, "Doppia-A" piuttosto che "AA") in modo che possano essere compresi nel caso vengano letti da un sintetizzatore vocale.

Dichiarazione di conformità ben definita

Una dichiarazione di conformità per essere considerata positiva deve includere le seguenti informazioni:

1. Il titolo/la versione delle Linee Guida: "Linee Guida per l'Accessibilità degli Strumenti di Sviluppo per il Web 1.0";
2. L'indirizzo web delle Linee Guida: http://www.w3.org/TR/2000/REC-ATAG10-20000203;
3. Il livello di conformità soddisfatto: "A", "Doppia-A", o "Tripla-A";
4. Il numero della versione del software e il sistema operativo supportato indicato nella dichiarazione di validità. E' necessario inoltre indicare quando siano richiesti dei plug-in o degli aggiornamenti;
5. La data della dichiarazione;
6. I punti di controllo del livello di conformità selezionato che non sono applicabili. Per questa finalità i dichiaranti dovrebbero utilizzare l'elenco di controllo [ATAG10-CHECKLIST].

Queste informazioni dovrebbero essere rese disponibili sotto forma di testo o tramite marcature di metadata (ad esempio, utilizzando il Resource Description Framework (RDF) [RDF10] ed uno schema RDF designato per la dichiarazione di conformità WAI). Tutti i contenuti della dichiarazione devono essere accessibili secondo le Linee Guida per l'Accessibilità dei Contenuti per il Web 1.0 [WCAG10].

Qui di seguito si riporta un esempio di una dichiarazione in linguaggio HTML:

<p>MioSistemadiSviluppo versione 2.3 sul MioSistemaOperativo è conforme alle "Linee Guida per l'Accessibilità degli Strumenti di Sviluppo per il Web 1.0" del <abbr lang="en" title="the World Wide Web Consortium">W3C</abbr>, disponibili all'indirizzo web http://www.w3.org/TR/2000/REC-ATAG10-20000203, per il livello di conformità Doppia-A. Ulteriori dettagli su questa dichiarazione sono disponibili all'indirizzo web <a href="http://unsitoweb.com/dettagli"> http://unsitoweb.com/dettagli</a>.</p>

Validità di una Dichiarazione

Una dichiarazione di conformità ha validità per un determinato livello di conformità se:

1. La dichiarazione è ben definita, e
2. Il sistema di sviluppo soddisfa tutti i punti di controllo per quel livello.

I dichiaranti (o terze parti per loro conto) sono responsabili per la validità della dichiarazione. A partire dalla pubblicazione di questo documento, il W3C non ha la funzionalità di controllore, ma potrebbe farlo nel futuro, o stabilire delle raccomandazioni per garantire le parti.

Si auspica che i dichiaranti modifichino o ritirino una dichiarazione nel caso sia possibile dimostrare che tale dichiarazione non è valida. E' importante far notare che attualmente non è possibile validare le dichiarazioni di conformità in modalità completamente automatizzata.

Icone di Conformità

Come parte integrante della dichiarazione di conformità, si dovrebbero utilizzare le icone di conformità all'interno di un sito web, nella scatola di un prodotto, nella documentazione, ecc. Ogni icona di conformità (selezionata con il rispetto del Livello di Conformità appropriato) deve riportare un collegamento alla propria spiegazione fornita dal W3C. La presenza di una icona di conformità non implica che il W3C ha revisionato e validato la dichiarazione. Una icona di conformità deve essere accompagnata da una dichiarazione ben definita.

2. Linee Guida

Linea Guida 1. Sostenere attività che rendano accessibili i sistemi di sviluppo.

Se il sistema di sviluppo genera automaticamente marcature, molti autori saranno ignari della condizione di accessibilità del contenuto finale a meno che non impieghino ulteriore attenzione revisionandolo e apportando manualmente le correzioni. Siccome molti autori non hanno familiarità con l'accessibilità, i sistemi di sviluppo hanno la responsabilità di generare automaticamente marcature accessibili, e dove sia appropriato, guidando l'autore nella produzione di contenuti accessibili.

Molte applicazioni hanno come caratteristica la possibilità di convertire documenti da altri formati (ad esempio, Rich Text Format) in un formato di marcature specificatamente sviluppato per il Web come HTML. La modifica della marcatura può consentire di modificare e manipolare facilmente i contenuti. E' essenziale che questi processi non introducano marcature non accessibili oppure che rimuovano i contenuti accessibili, in particolar modo quando un sistema di sviluppo nasconde le modifiche alle marcature dalla finestra di modifica presentata all'autore.

Punti di Controllo:

1.1 Assicurarsi che l'autore possa produrre contenuti accessibili secondo la grammatica formale/grammatiche formali supportate dallo strumento di sviluppo. [Priorità�1]

Tecniche per il Punto di Controllo 1.1

1.2 Assicurarsi che lo strumento di sviluppo preservi tutte le informazioni accessibili durante le fasi di sviluppo, trasformazione e conversione. [Priorità�1]

Tecniche per il Punto di Controllo 1.2

1.3 Accertarsi che quando un sistema di sviluppo genera automaticamente marcatura questo sia conforme alle "Linee Guida per l'Accessibilità dei Contenuti per il Web 1.0" [WCAG10] del W3C. [Priorità�Relativa]

Tecniche per il Punto di Controllo 1.3

1.4 Accertarsi che i modelli predefiniti forniti dal sistema di sviluppo siano conformi alle "Linee Guida per l'Accessibilità dei Contenuti per il Web 1.0" [WCAG10]. [Priorità�Relativa]

Tecniche per il Punto di Controllo 1.4

Linea Guida 2. Generare marcature standard.

La conformità con gli standard promuove l'interoperabilità e l'accessibilità consentendo di creare con maggior semplicità degli specifici programmi utenti che rispondano ai requisiti degli utenti con disabilità. In particolare, molte tecnologie assistive utilizzate con i navigatori per il web e con i lettori multimediali garantiscono solo l'accesso a documenti web che utilizzano una marcatura valida. Di conseguenza, l'utilizzo di marcature valide è un aspetto essenziale per l'accessibilità dei sistemi di sviluppo per il web.

Dove sono applicabili, utilizzare le Raccomandazioni del W3C che sono stare analizzate per garantire l'accessibilità e l'interoperabilità. Se le Raccomandazioni del W3C non sono applicabili, utilizzare uno standard pubblicato che consenta l'accessibilità.

Punti di Controllo:

2.1 Utilizzare le ultime versioni delle raccomandazioni del W3C quando sono disponibili ed adatte per un'operazione. [Priorità�2]

Le specifiche del W3C hanno subito la revisione specificamente per accertarsi che non compromettessero l'accessibilità e, dove possibile, la aumentino.

Tecniche per il Punto di Controllo 2.1

2.2 Assicurarsi che lo strumento di sviluppo generi automaticamente codice rispettoso delle grammatiche formali. [Priorità�1]

Questo è necessario ai programmi utenti per poter presentare i contenuti del Web in modo appropriato alle particolari necessità degli utenti.

Tecniche per il Punto di Controllo 2.2

2.3 Informare l'autore se il codice generato dal sistema di sviluppo non è conforme alle specifiche del W3C. [Priorità�3]

Tecniche per il Punto di Controllo 2.3

Linea Guida 3. Sostenere la creazione di contenuti accessibili.

Informazioni ben strutturate e informazioni alternative equivalenti sono i punti vitali dello sviluppo accessibile, consentendo di presentare le informazioni nel modo più appropriato alle esigenze dell'utente senza limitare la creatività dell'autore. Tuttavia produrre informazioni equivalenti, quali alternative testuali per le immagini e le descrizioni uditive del video, può essere una bella sfida nello sviluppo dei contenuti per il web, e i produttori si sistemi di sviluppo per il web dovrebbero cercare di facilitare e automatizzare i meccanismi di questo processo. Ad esempio, richiamando gli autori nei momenti adatti ad includere informazioni alternative equivalenti come equivalenti testuali, Sottotitoli, e descrizioni uditive per rendergli minima tale difficoltà. Nel caso tali informazioni possono essere determinate ed presentate in modalità automatizzata come scelta per l'autore (per esempio, la funzionalità delle icone in una barra di navigazione generata automaticamente, o nell'espansione degli acronimi da un dizionario), il sistema di sviluppo deve poter aiutare l'autore. Allo stesso tempo, lo strumento di sviluppo può rinforzare il fabbisogno di tali informazioni ed il ruolo dell'autore nell'accertarsi che siano in ogni caso utilizzati in modo corretto.

Punti di Controllo:

3.1 Richiedere all'autore di fornire le informazioni alternative equivalenti (per esempio, sottotitoli, descrizioni uditive e trascrizioni del testo per i video). [Priorità�Relativa]

Annotazione: Alcuni punti di controllo delle Linee Guida per l'Accessibilità dei Contenuti 1.0 [WCAG10] potrebbero non essere applicabili.

Tecniche per il Punto di Controllo 3.1

3.2 Aiutare l'autore a generare contenuti strutturati ed a separare le informazioni dalla relativa presentazione. [Priorità�Relativa]

Annotazione: Alcuni punti di controllo delle Linee Guida per l'Accessibilità dei Contenuti 1.0 [WCAG10] potrebbero non essere applicabili.

Tecniche per il Punto di Controllo 3.2

3.3 Accertarsi che i contenuti preconfezionati siano conformi alle "Linee Guida per l'Accessibilità dei Contenuti per il Web 1.0" [WCAG10]. [Priorità�Relativa]

Ad esempio, in contenuti preconfezionati come ad esempio un filmato è necessario includere sottotitoli, una descrizione uditiva, e una trascrizione del testo. Riferirsi anche al Punto di Controllo 3.4.

Tecniche per il Punto di Controllo 3.3

3.4 Non generare automaticamente informazioni alternative equivalenti. Non riutilizzare alternative precedentemente utilizzate senza la conferma dell'autore, tranne quando la funzionalità è riconoscibile con certezza. [Priorità�1]

Ad esempio, richiedere all'autore di inserire per una immagine il relativo equivalente testuale. Se l'autore ha già provveduto a fornire un equivalente testuale per la stessa immagine all'interno di un altro documento, il sistema di sviluppo dovrebbe offrire all'autore la possibilità di riutilizzare il testo chiedendone preventivamente conferma. Se il sistema crea automaticamente un'immagine per "Ricerca", dovrebbe automaticamente riutilizzare lo stesso equivalente testuale già utilizzato per tale icona. Riferirsi anche al Punto di Controllo 3.3 e al Punto di Controllo 3.5.

Annotazione: Gli equivalenti alternativi creati dall'autore potrebbero essere disponibili per un oggetto (ad esempio, attraverso il Punto di Controllo 3.5 e/o il Punto di Controllo 3.3). E' appropriato che in modalità predefinita il sistema di sviluppo offra all'autore queste opzioni.

Tecniche per il Punto di Controllo 3.4

3.5 Fornire le funzionalità per il controllo, la pubblicazione e la riutilizzazione degli equivalenti alternativi per gli oggetti multimediali. [Priorità�3]

Annotazione: Questi equivalenti alternativi possono essere disponibili direttamente nel sistema di sviluppo, prodotti dall'autore, richiamati dal Web, ecc.

Tecniche per il Punto di Controllo 3.5

Linea Guida 4. Provvedere modalità di controllo e correzione di contenuti non accessibili.

Molti sistemi di sviluppo consentono la creazione di documenti anche ad autori con poca o nessuna conoscenza del linguaggio di marcatura. Al fine di garantire l'accessibilità, i sistemi di sviluppo devono essere sviluppati in modo che possano (dove possibile, in modalità automatica) identificare le marcature non accessibili, e devono abilitarne la relativa correzione anche quando la marcatura è nascosta all'autore, come nel caso degli editor visuali.

I sistemi di sviluppo che supportano la creazione di contenuti accessibili per il web dovrebbero fornire differenti modalità di sviluppo. Gli autori che possono configurare le caratteristiche di accessibilità al fine di sostenere la propria attività lavorativa accettano volentieri le pratiche di accessibilità dei sistemi di sviluppo (riferirsi alla Linea Guida 5). Ad esempio, alcuni autori preferiscono esser avvisati quando si riscontrano dei problemi di accessibilità, considerando che altri invece preferiscono effettuare un controllo alla conclusione di una sessione di pubblicazione. Ciò è analogo negli ambienti di programmazione che permettono che gli utenti decidano di controllare se il codice è corretto durante la pubblicazione o alla compilazione.

Annotazione: La validazione della marcatura è un aspetto essenziale per il controllo dell'accessibilità dei contenuti.

Punti di Controllo:

4.1 Controllare ed informare l'autore dei problemi di accessibilità. [Priorità�Relativa]

Annotazione: I problemi di accessibilità dovrebbero essere identificati automaticamente, ove possibile. Dove non sia possibile, il sistema di sviluppo deve segnalarlo all'autore che dovrà effettuare delle scelte oppure correggere manualmente alcuni tipi di problemi.

Tecniche per il Punto di Controllo 4.1

4.2 Assistere l'autore nella correzione dei problemi di accessibilità. [Priorità�Relativa]

Come minimo, provvedere un aiuto contestuale con i controlli di accessibilità richiesti dal Punto di Controllo 4.1

Tecniche per il Punto di Controllo 4.2

4.3 Consentire all'autore di mantenere il codice non riconosciuto dal sistema di sviluppo. [Priorità�2]

Annotazione: L'autore potrebbe aver incluso o importato delle marcature per incrementare l'accessibilità ma queste non sono state riconosciute dal sistema di sviluppo.

Tecniche per il Punto di Controllo 4.3

4.4 Fornire all'autore un sommario del livello di accessibilità del documento. [Priorità�3]

Tecniche per il Punto di Controllo 4.4

4.5 Consentire all'autore di trasformare il codice della presentazione in marcatura strutturale, utilizzato in modo errato per contenere nella struttura anche la presentazione, al fine di trasformare in fogli di stile il codice utilizzato per la presentazione. [Priorità�3]

Tecniche per il Punto di Controllo 4.5

Linea Guida 5. Integrare soluzioni per l'accessibilità nell'aspetto generale degli strumenti di sviluppo.

Quando viene inserita una nuova caratteristica all'interno di un programma esistente senza che ne venga curata la corretta integrazione il risultato è spesso una discontinuità evidente. L'utilizzo di differenti colori, schemi, caratteri, modalità di interazione, e perfino la stabilità del software possono essere fattori che influenzano l'accettazione di nuova caratteristica da parte dell'autore. Inoltre, l'utilizzo di diverse modalità di interazione per compiere la stessa operazione può influenzare la scelta del sistema di sviluppo da parte dell'autore. Di conseguenza, è importante che sia del tutto naturale generare contenuti accessibili quando si utilizzano dei sistemi di sviluppo.

Punti di Controllo:

5.1 Accertarsi che la funzionalità relativa alle pratiche di accessibilità sia integrata in modo naturale nella visione globale dello strumento di sviluppo. [Priorità�2]

Tecniche per il Punto di Controllo 5.1

5.2 Assicurarsi che le pratiche di accessibilità supportino i punti di controllo per la Priorità 1 delle "Linee Guida per l'Accessibilità dei Contenuti per il Web 1.0" [WCAG10] e che l'autore possa identificarli ed interagirci facilmente ed in modo evidente. [Priorità�2]

Tecniche per il Punto di Controllo 5.2

Linea Guida 6. Promuovere l'accessibilità nei sistemi di supporto e nella documentazione.

Gli autori potrebbero non avere familiarità con i problemi dell'accessibilità che si presentano durante la creazione di contenuti per il web. Di conseguenza, i sistemi di aiuto e la documentazione devono includere le spiegazioni delle problematiche dell'accessibilità, e dovrebbero fornire delle soluzioni tramite esempi.

Punti di Controllo:

6.1 Documentare tutte le caratteristiche che promuovono la produzione di contenuti accessibili. [Priorità�1]

Tecniche per il Punto di Controllo 6.1

6.2 Accertarsi che la generazione di contenuti accessibili sia integrata in modo naturale nella documentazione, compresi gli esempi. [Priorità�2]

Tecniche per il Punto di Controllo 6.2

6.3 In una sezione dedicata, documentare tutte le caratteristiche degli strumenti di sviluppo che promuovono la produzione di contenuti accessibili. [Priorità�3]

Tecniche per il Punto di Controllo 6.3

Linea Guida 7. Garantire l'accessibilità dei sistemi di sviluppo agli autori con disabilità.

I sistemi di sviluppo sono delle applicazioni con elementi predefiniti nelle interfacce utente predefinite e devono essere sviluppati nel rispetto delle linee guida per l'accessibilità delle interfacce. Nel caso in cui siano sviluppati dei componenti con interfacce personalizzate, è essenziale che queste siano accessibili attraverso le modalità predefinite di accesso per una piattaforma di riferimento, in modo che le tecnolgie assistive possano interagirvi.

Alcune considerazioni supplementari sullo sviluppo dell'interfaccia utente si applicano specificamente agli strumenti di sviluppo per il Web. Per esempio, i sistemi di sviluppo devono garantire che l'autore possa pubblicare (in modalità visuale) utilizzando un insieme di preferenze stilistiche e pubblicando utilizzando stili differenti. Gli autori ipovedenti possono aver bisogno di testo di grandi dimensioni in fase di creazione ma in fase di pubblicazione desiderano pubblicare con un carattere di dimensioni inferiori. La preferenza di stile della modalità visuale non deve interessare la marcatura del documento in fase di pubblicazione.

Gli strumenti di sviluppo devono anche garantire all'autore la possibilità di muoversi in modo efficiente all'interno del documento durante la produzione, indipendentemente dalle disabilità. Gli autori che utilizzano lettori di schermo, sistemi Braille o ingranditori di schermo possono ricorrere all'uso limitato (all'occorrenza) di impostazioni grafiche che comunicano la struttura del documento e che agiscono come segnaposto durante la navigazione. Gli autori che non possono usare il mouse (ad esempio, persone con disabilità fisiche o non vedenti) devono usare un sistema lento e noioso di navigazione all'interno del documento per arrivare al contenuto desiderato, a meno che non siano disponibili delle modalità più efficienti di navigazione. I sistemi di sviluppo dovrebbero quindi fornire una modalità visuale che dia un senso della struttura generale e che ne consenta la navigazione strutturale.

Annotazione: Documentazione, file di supporto e installazione sono una parte integrante del software e necessitano della disponibilità di un formato accessibile.

Punti di Controllo:

7.1 Utilizzare tutti gli standard e convenzioni per i sistemi operativi e l'accessibilità (Priorità 1 per gli standard e le convenzioni che sono essenziali per l'accessibilità; Priorità 2 per quelli importanti per l'accessibilità; Priorità 3 per quelli che portano un beneficio all'accessibilità).

Le tecniche di questo punto di controllo includono dei riferimenti ai punti di controllo e alle linee guida per un certo numero di piattaforme e a linee guida generali per le applicazioni accessibili.

Tecniche per il Punto di Controllo 7.1

7.2 Consentire all'autore di modificare la presentazione durante la pubblicazione mantenendo la formalità della grammatica del documento. [Priorità�1]

Questo consente all'autore di modificare il documento secondo i requisiti personali, senza modificare il significato e il risultato del documento una volta pubblicato.

Tecniche per il Punto di Controllo 7.2

7.3 Consentire all'autore di modificare tutte le proprietà di ogni elemento ed oggetto in modo accessibile. [Priorità�1]

Tecniche per il Punto di Controllo 7.3

7.4 Accertarsi che la modalità di pubblicazione consenta la navigazione accessibile della struttura del documento. [Priorità�1]

Tecniche per il Punto di Controllo 7.4

7.5 Consentire la pubblicazione della struttura del documento in modo accessibile. [Priorità�2]

Tecniche per il Punto di Controllo 7.5

7.6 Consentire all'autore di ricercare in modalità visuale. [Priorità�2]

Tecniche per il Punto di Controllo 7.6

3. Glossario dei termini e delle definizioni

Accessibilità (o anche: Accessibile)

All'interno di questa guida di riferimento, "accessibilità dei contenuti per il web" e "accessibilità degli strumenti di sviluppo" significa che i contenuti ed i sistemi di sviluppo possono essere utilizzati da utenti indipendentemente dalla presenza di disabilità.

Per comprendere la rilevanza dell'accessibilità nei sistemi di sviluppo, è necessario considerare che molti autori potrebbero creare dei contenuti in un contesto che si differenzia molto dal contesto in cui ti trovi:

• Potrebbero non vedere, sentire, muoversi o potrebbero non esser capaci di comprendere parzialmente o totalmente alcuni tipi di informazioni;
• Potrebbero avere difficoltà nella lettura o comprensione dei testi;
• Potrebbero non avere o avere difficoltà nell'utilizzo di tastiera o mouse;
• Potrebbero avere degli schermi con visualizzazione solamente testuale, oppure schermi di piccole dimensioni.

Lo sviluppo accessibile porterà beneficio a questi diversi scenari di sviluppo ed anche a molte persone che non hanno disabilità di tipo fisico ma che possono avere esigenze similari. Ad esempio, chi lavora in ambienti rumorosi necessita di una rappresentazione alternativa di contenuti audio. Per la stessa motivazione, chi per lavoro necessita di impiegare la vista esclusivamente per una attività di controllo per poter fruire delle informazioni richiede un equivalente uditivo. Gli utenti che utilizzano piccole periferiche mobili (con piccoli schermi, senza tastiera e senza mouse) hanno alcune necessità funzionali di taluni utenti con disabilità.

Informazioni Accessibili

Le "Informazioni Accessibili" rappresentano il contenuto, incluse le informazioni e la marcatura, che viene utilizzato per migliorare l'accessibilità di un documento. Le informazioni accessibili includono le informazioni equivalenti alternative, ma non si limitano a queste ultime.

Problemi di Accessibilità (o anche: Marcature non accessibili)

Contenuti web non accessibili o strumenti di sviluppo non possono essere utilizzati da alcune persone con disabilità. Le Linee Guida per l'Accessibilità dei Contenuti per il Web 1.0 [WCAG10] forniscono informazioni su come creare contenuti accessibili per il web.

Pratiche di Accessibilità dei sistemi di sviluppo

Le "Pratiche di accessibilità dei sistemi di sviluppo" migliorano l'accessibilità dei contenuti per il web. Sia gli autori che i sistemi di sviluppo sono coinvolti nelle pratiche di accessibilità. Ad esempio, gli autori devono scrivere in modo chiaro, strutturare i contenuti e provvedere degli aiuti nella navigazione. I sistemi di sviluppo devono generare automaticamente marcature valide e assistere gli autori nella fornitura e gestione appropriata delle alternative equivalenti.

Avviso

Un avviso porta l'attenzione dell'attenzione dell'autore su un particolare evento o situazione. Richiede un intervento di risposta da parte dell'autore.

Informazione Alternativa (o anche: Alternativa Equivalente)

Un contenuto è "equivalente" ad un altro contenuto quando entrambi compiono essenzialmente la stessa funzione o scopo sulla presentazione all'utente. Le alternative equivalenti svolgono un ruolo importante nelle pratiche di accessibilità dei sistemi di sviluppo (ad esempio, filmati, immagini, audio, ecc.). Agli autori è consigliato di fornire gli equivalenti testuali per contenuti non testuali poiché il testo può essere reso come sintesi vocale per i soggetti con disabilità visive o cognitive, in braiile per i soggetti non vedenti, o come testo grafico per gli individui non udenti o che non abbiano alcuna disabilità. Per maggiori informazioni sulle alternative equivalenti, riferirsi alle Linee Guida per l'Accessibilità dei Contenuti per il Web WCAG 1.0 [WCAG10].

Attributo

Questo documento utilizza il termine "attributo" nello stesso modo utilizzato in SGML e XML ([XML]): Per gli Elementi è possibile definire un certo numero di attributi. Alcuni attributi sono parte integrante dell'accessibilità del contenuto (ad esempio, gli attributi "alt", "title", e "longdesc" definiti nella raccomandazione HTML).

Descrizione Uditiva

Una "descrizione uditiva" fornisce informazioni sulle azioni, sul linguaggio, sulla grafica e sui cambiamenti di scena in un video. Le descrizioni uditive sono comunemente utilizzate dagli utenti non vedenti o ipovedenti, anche se possono essere utilizzate come un equivalente a basso consumo di banda di connettività nel web. Una descrizione uditiva è sia una voce umana registrata in anticipo che una voce sintetizzata (registrata o generata automaticamente in tempo reale). La descrizione uditiva deve essere sincronizzata con la traccia audio della presentazione video, solitamente durante le pause naturali nella traccia audio.

Sistema di sviluppo

Un "sistema di sviluppo" è qualsiasi applicazione utilizzabile per produrre contenuti da pubblicare nel web. I sistemi di sviluppo includono:

• Sistemi di sviluppo generati per produrre contenuti per il web (ad esempio, sistemi di sviluppo WYSIWYG per HTML e XML);
• Sistemi che offrono l'opzione di salvare contenuti in un formato utilizzabile nel web (ad esempio, word processor e sistemi di desktop publishing);
• Sistemi che trasformano documenti in un formato utilizzabile nel web (ad esempio, filtri che trasformano documenti di applicazioni desktop in documenti HTML);
• Sistemi che producono elementi multimediali, specialmente se intesi per la pubblicazione nel web (ad esempio, produzioni video e sistemi di pubblicazione multimediale, sistemi di produzione SMIL);
• Sistemi per la gestione di siti o per la pubblicazione di siti web, inclusi i sistemi che generano dinamicamente siti web da un database, sistemi di conversione in tempo reale e sistemi di pubblicazione sul web;
• Sistemi per la gestione della presentazione (ad esempio, sistemi di formattazione tramite fogli di stile CSS).

Sottotitoli

I "Sottotitoli" sono equivalenti testuali essenziali per l'audio dei filmati. I sottotitoli consistono in una trascrizione testuale della traccia audio del filmato (o di altra presentazione video) che è sincronizzata con il video e con la traccia audio. I sottotitoli sono solitamente presentati in formato grafico e portano beneficio agli utenti non udenti, con problemi d'udito o che non possono sentire l'audio.

Strumenti di Conversione

Uno "strumento di conversione" è un'applicazione o una caratteristica di una applicazione (ad esempio, "Salva come HTML") che trasforma il contenuto da un formato ad un altro formato (ad esempio in un linguaggio di marcatura).

Controllare

Così come utilizzato nel Punto di Controllo 4.1, "controllare" fa riferimento a tre tipi di controllo:

1. In alcuni casi, un sistema di sviluppo potrà controllare automaticamente per vedere se ci sono problemi di accessibilità. Ad esempio, controllando la per la validità della marcatura (Punto di Controllo 2.2) oppure controllando se un'immagine è l'unico contenuto all'interno di un collegamento.
2. In alcuni casi, il sistema potrà "ritenere sospetto" o "ipotizzare" che vi sia un problema, ma avrà bisogno della conferma dall'autore. Ad esempio, per assicurarsi che sia conservato un ordine ragionevole nella lettura, dovrà essere predisposto un sistema che presenti all'autore una versione linearizzata della pagina.
3. In alcuni casi, il sistema deve contare principalmente sull'autore e può chiedere soltanto all'autore di controllare. Ad esempio, il sistema dovrebbe avvisare l'autore al fine di verificare che le alternative equivalenti per elementi multimediali siano effettivamente appropriate. Questo è il requisito base minimo da soddisfare. In breve, è necessario richiamare l'attenzione dell'utente consigliandolo di verificare l'accessibilità dove tale controllo non sia possibile effettuarlo automaticamente.

Documento

Un "documento" è formato da una serie di elementi che sono definiti da un linguaggio di marcatura (ad esempio, HTML 4 o una applicazione XML).

Modalità Visuale

Una "modalità visuale" è una modalità di visualizzazione fornita da un sistema di sviluppo che consente la modifica dei contenuti.

Elemento

Un "elemento" è qualsiasi oggetto identificabile all'interno di un documento, come ad esempio un carattere, una parola, una immagine, un paragrafo o una cella di un foglio di calcolo. In [HTML4] e [XML], un elemento si riferisce ad una coppia di elementi e al loro contenuto, o a un an elemento "vuoto" - ossia un elemento che non richiede la chiusura o del contenuto.

Informare

"Informare" significa attirare l'attenzione dell'autore per una particolare situazione od evento attraverso avvisi, richiami, suoni, flash, o altre modalità.

Linguaggio di Marcatura

Gli autori inseriscono delle informazioni in codice utilizzando "linguaggi di marcatura" come HTML [HTML4], SVG [SVG], oppure MathML [MATHML].

Marcatura di Presentazione

La "Marcatura di Presentazione" è un linguaggio di marcatura che codifica le informazioni relative alla presentazione o alla disposizione del contenuto. Ad esempio i Fogli di stile a cascata ([CSS1], [CSS2]) possono essere utilizzati per controllare i caratteri, i colori, l'audio e la rappresentazione grafica. La marcatura di presentazione non dovrebbe essere utilizzata per definire la struttura di una pagina in sostituzione della marcatura strutturale. Ad esempio, gli autori doverebbero definire delle liste tramite marcatura in HTML e vestirle tramite CSS (ad esempio, per controllare la spaziatura, i puntatori, la numerazione, ecc.) Gli autori non dovrebbero utilizzare in modo errato i CSS o HTML per presentare graficamente il contenuto in modo che assomigli ad una lista.

Richiamo

Un "richiamo" è una richiesta per un intervento da parte dell'autore, sia di tipo informativo che decisionale. Un richiamo richiede che l'autore risponda. Ad esempio nel caso di una finestra di dialogo di inserimento di un'immagine, la casella di immissione di un equivalente testuale dovrebbe richiamare l'attenzione dell'autore. I richiami dovrebbero essere utilizzati per incoraggiare l'autore a fornire informazioni necessarie per rendere accessibili i contenuti (come ad esempio i testi alternativi equivalenti).

Proprietà

Una "proprietà" è una parte di informazione su un elemento, ad esempio informazioni strutturali (ad esempio, l'elemento numero 7 all'interno di una lista, oppure del semplice testo) oppure informazioni di presentazione (ad esempio, che questo testo è in grassetto e la dimensione del carattere è 14). In XML e HTML, le proprietà di un elemento includono il tipo dell'elemento (ad esempio, IMG o DL), i valori dei suoi attributi, e le informazioni associate per mezzo di un foglio di stile. In un database, le proprietà di un particolare elemento possono includere sia i valori che i tipi di dati che possono essere inseriti.

Marcatura strutturale

La "Marcatura Strutturale" è un linguaggio di marcatura che codifica le informazioni relativamente al ruolo degli elementi strutturali all'interno del contenuto. Per esempio, le intestazioni, le sezioni, gli elementi di una lista ed i componenti di uno schema complesso possono essere identificati usando la marcatura strutturale. La marcatura strutturale non deve essere utilizzata in modo scorretto per controllare la presentazione o la grafica. Ad esempio, gli autori non devono utilizzare l'elemento BLOCKQUOTE in HTML [HTML4] per realizzare un effetto visivo di rientro. La marcatura strutturale dovrebbe essere utilizzata correttamente per comunicare il ruoli degli elementi all'interno del contenuto mentre dovrebbe essere separata dalla marcatura di presentazione che ha lo scopo di controllare l'impaginazione.

Trascrizione

Una "trascrizione" è una rappresentazione testuale dei suoni in un clip audio o in una traccia audio di una presentazione multimediale. Una "trascrizione testuale collegata" per un video combina (collega) i sottotitoli con le informazioni della descrizione testuale del video (descrizioni delle azioni, dei movimenti del corpo, delle immagini, dei cambiamenti di scena). Le trascrizioni testuali collegate sono essenziali per gli individui che sono sordo-ciechi e contano sul braille per l'accesso ai film e ad altri contenuti.

Trasformazione

La "trasformazione" è un processo che cambia un documento o un oggetto in un altro, equivalente, secondo un discreto insieme di regole. Questo include strumenti di confersione, software che permette all'autore di modificare il DTD definito originariamente nel documento con un altro DTD, e la capacità di cambiare la marcatura delle liste e di convertirle in tabelle.

Programma Utente

Un "user agent" (programma utente) è una applicazione che richiama e rende utilizzabile un contenuto per il web. I programmi utenti includono i navigatori (browsers), i plug-in per alcuni particolari tipi di media e alcune tecnologie assistive.

Modalità di Visualizzazione

Gli strumenti di sviluppo possono rendere disponibile lo stesso contenuto in diverse modalità; ogni modalità è definita "modalità di visualizzazione". Alcuni strumenti di sviluppo possono rendere disponibili diversi tipi di visualizzazione ed altri ancora renderanno possibile l'immediata visualizzazione di diversi documenti. Alcuni attrezzi creanti avranno vari tipi di viste ed alcuni permettono le viste di parecchi documenti immediatamente. Per esempio, una modalità di visualizzazione può mostrare la marcatura grezza, una seconda versione può mostrare una struttura ad albero, una terza può mostrare la marcatura organizzata per oggetti mentre una visualizzazione finale rende disponibile un esempio di come il documento apparirà se visualizzato in un particolare browser. Una modalità tipica per distinguere le diverse modalità di visualizzazione in un ambiente grafico è quella di disporre ogni modalità di visualizzazione in una finestra separata.

4. Ringraziamenti

Si ringraziano vivamente le seguenti persone che hanno contribuito attraverso la revisione e l'invio di commenti: Jim Allan, Denis Anson, Kitch Barnicle, Kynn Bartlett, Harvey Bingham, Judy Brewer, Carl Brown, Dick Brown, Wendy Chisholm, Aaron Cohen, Rob Cumming, Daniel Dardailler, Mark Day, BK Delong, Martin D�rst, Kelly Ford, Jamie Fox, Edna French, Sylvain Galineau, Al Gilman, Jon Gunderson, Eric Hansen, Phill Jenkins, Len Kasday, Brian Kelly, Marja-Riitta Koivunen, Sho Kuwamoto, Jaap van Lelieveld, Susan Lesch, William Loughborough, Greg Lowney, Karen McCall, Thierry Michel, Charles Oppermann, Dave Pawson, Dave Poehlman, Loretta Reid, Bruce Roberts, Chris Ridpath, Gregory Rosmaita, Bridie Saccocio, Janina Sajka, John Slatin, Jim Thatcher, Ir�ne Vatton, Gregg Vanderheiden, Pawan Vora, Jason White, e Lauren Wood.

5. Riferimenti

Per le ultime versioni delle qualsiasi specifica del W3C è possibile consultarne l'elenco alla pagina web W3C Technical Reports disponibile all'indirizzo http://www.w3.org/TR

[ATAG10-CHECKLIST]

Una appendice di questo docomento elenca tutti i punti di controllo, ordinati per priorità. L'elenco dei punti di controllo è disponibile sia in forma tabellare (in lingua inglese all'indirizzo http://www.w3.org/TR/2000/REC-ATAG10-20000203/atag10-chktable) oppure in elenco (in lingua inglese all'indirizzo http://www.w3.org/TR/2000/REC-ATAG10-20000203/atag10-chklist).

[ATAG10-TECHS]

"Tecniche per le Linee Guida per l'Accessibilità degli Strumenti di Sviluppo per il Web 1.0", J. Treviranus, J. Richards, I. Jacobs, e C. McCathieNevile eds. L'ultima versione è disponibile all'indirizzo web http://www.w3.org/TR/ATAG10-TECHS.

[CONFORMANCE]

"Icone di conformità per ATAG 1.0". Informazioni sulle icone di conformità per le ATAG 1.0 sono disponibili all'indirizzo web http://www.w3.org/WAI/ATAG10-Conformance.

[CSS1]

"Raccomandazione CSS, Livello 1", B. Bos e H. Wium Lie, eds., 17 Dicembre 1996, revisionata l'11 Gennaio 1999. Questa raccomandazione CSS1 è disponibile all'indirizzo web http://www.w3.org/TR/1999/REC-CSS1-19990111. L'ultima versione di CSS1 è disponibile all'indirizzo web http://www.w3.org/TR/REC-CSS1. Annotazione: CSS1 è stato sostituito da CSS2. I sistemi di sviluppo dovrebbero applicare i CSS2.

[CSS2]

"Raccomandazione CSS, Livello 2", B. Bos, H. Wium Lie, C. Lilley, e I. Jacobs, eds., 12 Maggio 1998. Questa raccomandazione CSS2 è disponibile all'indirizzo web http://www.w3.org/TR/1998/REC-CSS2-19980512. L'ultima versione di CSS2 è disponibile all'indirizzo web http://www.w3.org/TR/REC-CSS2.

[HTML4]

"Raccomandazione HTML 4.01", D. Raggett, A. Le Hors, e I. Jacobs, eds., 24 Dicembre 1999. Questa Raccomandazione HTML 4.01 è disponibile all'indirizzo web http://www.w3.org/TR/1999/REC-html401-19991224. L'ultima versione di HTML 4 è disponibile all'indirizzo web http://www.w3.org/TR/html4.

[MATHML]

"Mathematical Markup Language", P. Ion e R. Miner, eds., 7 Aprile 1998, revisionata il 7 Luglio 1999. Questa raccomandazione MathML 1.0 Recommendation è disponibile all'indirizzo web http://www.w3.org/TR/1998/REC-MathML-19990707. L'ultima versione di MathML 1.0 è disponibile all'indirizzo web http://www.w3.org/TR/REC-MathML.

[RDF10]

"Resource Description Framework (RDF) Model and Syntax Specification", O. Lassila, R. Swick, eds. La raccomandazione del 22 febbraio 1999 è disponibile all'indirizzo web http://www.w3.org/TR/1999/REC-rdf-syntax-19990222. L'ultima versione di RDF 1.0 è disponibile all'indirizzo web http://www.w3.org/TR/REC-rdf-syntax.

[SVG]

"Specifica Scalable Vector Graphics (SVG) 1.0 (Documento Provvisorio)", J. Ferraiolo, ed. L'ultima versione disponibile delle specifiche SVG è disponibile all'indirizzo web http://www.w3.org/TR/SVG.

[UAAG10-TECHS]

"Tecniche per le Linee Guida dell'Accessibilità per gli User Agent Accessibility Guidelines 1.0", J. Gunderson, e I. Jacobs, eds. L'ultima versione delle Tecniche per le Linee Guida dell'Accessibilità per gli User Agent 1.0 è disponibile all'indirizzo web http://www.w3.org/TR/UAAG10-TECHS/.

[WCAG10]

"Linee Guida per l'Accessibilità dei Contenuti per il Web 1.0", W. Chisholm, G. Vanderheiden, e I. Jacobs, eds., 5 Maggio 1999. Questa raccomandazione è disponibile all'indirizzo web http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505. L'ultima versione delle Linee Guida per l'Accessibilità dei Contenuti per il Web 1.0" è disponibile all'indirizzo web http://www.w3.org/TR/WCAG10/.

[WCAG10-TECHS]

"Tecniche per le Linee Guida dell'Accessibilità dei Contenuti per il Web 1.0", W. Chisholm, G. Vanderheiden, e I. Jacobs, eds. L'ultima versione delle Tecniche per le Linee Guida dell'Accessibilità dei Contenuti per il Web 1.0 è disponibile all'indirizzo web http://www.w3.org/TR/WCAG10-TECHS/.

[XML]

"The Extensible Markup Language (XML) 1.0", T. Bray, J. Paoli, C. M. Sperberg-McQueen, eds., 10 Febbraio 1998. Questa raccomandazione XML 1.0 è disponibile alla pagina web http://www.w3.org/TR/1998/REC-xml-19980210. L'ultima versione della specifica XML è disponibile all'indirizzo web http://www.w3.org/TR/REC-xml.