I possibili errori presenti in questo documento, dovuti alla traduzione, sono di responsabilit� del traduttore e non sono in alcun modo imputabili al W3C. Per qualsiasi commento riguardo la traduzione rivolgersi a Roberto Scano. Nella traduzione italiana di queste specifiche ci potrebbero essere degli errori. L'unica versione ufficiale di questo documento � la versione originale in inglese: http://www.w3.org/TR/2000/REC-ATAG10-20000203 [contenuti] [Tabella Punti di Controllo] [Elenco Punti di Controllo] ------------------------------------------------------------------------ Linee Guida per l'Accessibilit� degli Strumenti di Sviluppo per il Web 1.0 Raccomandazione W3C del 3 Febbraio 2000 Questa versione del documento: http://www.robertoscano.info/files/atag10/ (versione solo testo, HTML in archivio compresso (gzip tar), HTML in archivio compresso (zip), PostScript, PDF) Questa versione del documento (versione originiale in lingua inglese): http://www.w3.org/TR/2000/REC-ATAG10-20000203 (versione solo testo, HTML in archivio compresso (gzip tar), HTML in archivio compresso (zip), PostScript, PDF) Ultima versione delle Linee Guida per l'Accessibilit� degli Strumenti di Sviluppo per il Web 1.0 (lingua inglese): http://www.w3.org/TR/ATAG10 Versione Precedente (in lingua inglese): http://www.w3.org/TR/1999/PR-WAI-AUTOOLS-19991026 Redazione: Jutta Treviranus - ATRC, Universit� di Toronto Charles McCathieNevile - W3C Ian Jacobs - W3C Jan Richards - Universit� di Toronto Redazione italiana: Roberto Scano, International Webmasters Association / HTML Writers Guild, Sezione italiana -- Venezia Copyright � 2000 W3C (MIT, INRIA, Keio), Tutti i diritti riservati. Si applicano le regole del W3C riguardanti la responsabilit�, i marchi depositati, l'utilizzo dei documenti e le licenze software. ------------------------------------------------------------------------ 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: w3c-wai-au@w3.org (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 wai-atag-editor@w3.org. 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. Indice Sommario Stato del Documento 1. Introduzione 1.1 Come sono organizzate le Linee Guida 1.2 Priorit� dei Punti di Controllo 1.3 Conformit� a queste Linee Guida 2. Linee Guida 1. Sostenere attivit� che rendano accessibili i sistemi di sviluppo. 2. Generare marcature standard. 3. Sostenere la creazione di contenuti accessibili. 4. Provvedere modalit� di controllo e correzione di contenuti non accessibili. 5. Integrare soluzioni per l'accessibilit� nell'aspetto generale degli strumenti di sviluppo. 6. Promuovere l'accessibilit� nei sistemi di supporto e nella documentazione. 7. Garantire l'accessibilit� dei sistemi di sviluppo agli autori con disabilit�. 3. Glossario dei termini e delle definizioni 4. Ringraziamenti 5. Riferimenti 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.2 Priorit� dei Punti di Controllo Ogni punto di controllo ha un livello di priorit�. Il livello di priorit� rispecchia l'impatto del punto di controllo per i raggiungimento dell'obiettivo di queste specifiche. Gli obiettivi sono: * Che i sistemi di sviluppo siano accessibili; * Che i sistemi di sviluppo producano in modalit� predefinita contenuti accessibili; * Che i sistemi di sviluppo incoraggino la creazione di contenuti accessibili. I livelli di priorit� sono assegnati nella seguente modalit�: [Priorit� 1] Se il punto di controllo � essenziale per raggiungere l'obiettivo. [Priorit� 2] Se il punto di controllo � importante per raggiungere l'obiettivo. [Priorit� 3] Se il punto di controllo favorisce il raggiungimento degli obiettivi. [Priorit� Relativa] Alcuni punti di controllo che si riferiscono alla generazione, alla creazione, o al controllo dei contenuti per il web hanno diverse priorit�. La priorit� dipende dalla corrispondente priorit� delle Linee Guida per l'Accessibilit� dei Contenuti per il Web (WCAG) 1.0 [WCAG10]. E' Priorit� 1 soddisfare i punti di controllo per le caratteristiche dei contenuti che abbiano il requisito di Priorit� 1 nelle WCAG 1.0. E' Priorit� 2 soddisfare i punti di controllo per le caratteristiche dei contenuti che abbiano il requisito di Priorit� 2 nelle WCAG 1.0. E' Priorit� 3 soddisfare i punti di controllo per le caratteristiche dei contenuti che abbiano il requisito di Priorit� 3 nelle WCAG 1.0. Ad esempio: Fornire un equivalente testuale per immagini e suoni � un requisito della Priorit� 1 delle WCAG 1.0 poich� senza esso uno o pi� gruppi troveranno impossibile accedere alle informazioni. Di conseguenza, per i sistemi di sviluppo per il web � necessario controllare un requisito di Priorit� 1 (4.1) oppure � necessario richiederlo all'autore (3.1) delle alternative equivalenti per queste tipologie di contenuti. Raggruppare i collegamenti un barre di navigazione � una Priorit� 3 nelle WCAG 1.0. Di conseguenza, per i sistemi di sviluppo per il web � da controllare soltanto un requisito di Priorit� 3 (4.1) o da richiedere all'autore (3.2) se sono gruppi di collegamenti che non sono raggruppati a livello di codice come sistema di navigazione. Quando un punto di controllo di questo documento fa riferimento alle WCAG 1.0 [WCAG10], si applicano solamente i punti di controllo delle WCAG 1.0 che si riferiscono al contenuto sostenuto o generato automaticamente dai sistemi di sviluppo. Alcuni punti di controllo delle WCAG 1.0 sono applicabili in modo da soddisfare automaticamente (senza l'intervento dell'autore) mentre altri richiedono il giudizio umano e il supporto dei sistemi di sviluppo sotto forma di richiami e documentazione. Diversi sistemi di sviluppo possono soddisfare diversamente lo stesso punto di controllo. Il livello di Priorit� per ogni punto di controllo � stato scelto basandosi sul presupposto che l'autore sia competente, ma non necessariamente esperto, utente di sistemi di sviluppo con poca o nessuna conoscenza di accessibilit�. Per esempio, non � pensabile che l'autore legga tutta la documentazione, ma si pensa che sappia utilizzare la documentazione nel caso necessiti assistenza. 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 dettagliati 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: * Il titolo/la versione delle Linee Guida: "Linee Guida per l'Accessibilit� degli Strumenti di Sviluppo per il Web 1.0"; * L'indirizzo web delle Linee Guida: http://www.w3.org/TR/2000/REC-ATAG10-20000203; * Il livello di conformit� soddisfatto: "A", "Doppia-A", o "Tripla-A"; * 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; * La data della dichiarazione; * 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:

MioSistemadiSviluppo versione 2.3 sul MioSistemaOperativo � conforme alle "Linee Guida per l'Accessibilit� degli Strumenti di Sviluppo per il Web 1.0" del W3C, 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 http://unsitoweb.com/dettagli.

Validit� di una Dichiarazione Una dichiarazione di conformit� ha validit� per un determinato livello di conformit� se: * La dichiarazione � ben definita, e * 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� pedefinita 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 natuale 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. Web authors may not be familiar with accessibility issues that arise when creating Web content. 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 modialit� 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: 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. 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. 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. ------------------------------------------------------------------------ -------- [contenuti] [Tabella Punti di Controllo] [Elenco Punti di Controllo]