Linee guida per l'accessibilità ai contenuti del web

1. Introduzione

Coloro che non hanno familiarità con i problemi di accessibilità che riguardano le pagine Web, considerino che molti utenti possono operare in contesti molto differenti dal nostro:

Possono non essere in grado di vedere, ascoltare o muoversi o possono non essere in grado di trattare alcuni tipi di informazioni facilmente o del tutto.
Possono avere difficoltà nella lettura o nella comprensione del testo.
Possono non avere o non essere in grado di usare una tastiera o un mouse.
Possono avere uno schermo solo testuale, un piccolo schermo o una connessione Internet molto lenta.
Possono non parlare e capire fluentemente la lingua in cui il documento è scritto.
Possono trovarsi in una situazione in cui i loro occhi, orecchie o mani sono occupati o impediti (ad es., stanno guidando, lavorano in un ambiente rumoroso, ecc.).
Possono avere la versione precedente di un browser, un browser completamente diverso, un browser vocale o un diverso sistema operativo.

Gli sviluppatori devono considerare queste diverse situazioni durante la progettazione. Mentre ci cono diverse situazioni da considerare, ogni scelta di design accessibile porta dei benefici in un colpo solo a molto gruppi di disabili e all'intera comunità del Web. Per esempio, usando i fogli di stile per controllare le font ed eliminando l'elemento FONT. Gli scrittori di HTML avranno un maggiore controllo sulle loro pagine, rendendo le pagine stesse maggiormente accessibili a persone con difficoltà di visione e mediante la condivisione di fogli di stile abbrevieranno i tempi di dowloading delle pagine per tutti gli utenti.

Le Linee guida discutono i problemi di accessibilità e forniscono soluzioni di design accessibile. Esse riguardano scenari tipici (simili all'esempio dei fogli di stile) che possono rappresentare una difficoltà per utenti con certe disabilità. Per esempio la prima linea guida spiega come gli sviluppatori possono rendere accessibili le immagini. Alcuni utenti possono non essere in grado di vedere le immagini, altri possono usare browser testuali che non supportano le immagini, mentre altri possono avere disattivate le funzioni per le immagini (a causa di una connessione Internet lenta, per esempio). Le Linee guida non suggeriscono di evitare le immagini come via per migliorare l'accessibilità. Al contrario, esse spiegano che fornire un equivalente testuale dell'immagine, la renderà accessibile.

Come fa un equivalente testuale a rendere un'immagine accessibile? Nell'espressione "equivalente testuale" entrambi termini sono importanti:

Il contenuto testuale può essere presentato all'utente come sintesi vocale, braille e testo visualizzato sullo schermo. Ognuno di questi tre meccanismi usa uno dei cinque sensi - udito per la sintesi vocale, tatto per il braille e vista per il testo visualizzato sullo schermo - rendendo l'informazione accessibile a gruppi che rappresentativi di una varietà di difficoltà sensoriali e altre disabilità.
Allo scopo di essere utile, il testo deve svolgere la stessa funzione o scopo dell'immagine. Per esempio, si consideri un equivalente testuale per un'immagine fotografica del pianeta Terra visto dallo spazio. Se lo scopo dell'immagine è principalmente quello decorativo, allora il testo "Foto della Terra vista dallo spazio" può svolgere la funzione necessaria. Se lo scopo della foto è quello di illustrare un'informazione specifica sulla geografia terrestre, allora l'equivalente testuale deve fornire quell'informazione. Se la foto è stata designata per dire all'utente di selezionare l'immagine (per esempio, cliccando su di essa) per avere delle informazioni riguardanti la Terra, l'equivalente testuale dovrà essere "Informazioni sul pianeta Terra". Perciò se il testo svolge la stessa fuzione o scopo, per l'utente con una disabilità, dell'immagine per gli altri utenti comuni, allora essa può essere considerata un equivalente testuale.

Si noti che in aggiunta al beneficio che possono trarne utenti con disabilità, gli equivalenti testuali possono aiutare tutti gli utenti a trovare le pagine molto più rapidamente, dal momento che i robot per la ricerca possono usare il testo nell'indicizzazione delle pagine.

Mentre spetta agli sviluppatori fornire degli equivalenti testuali per le immagini e altri contenuti multimediali, è responsabilità degli interpreti (ad. es. browser e tecnologie assistive come lettori di schermo, dispositivi braille, ecc.) presentare le informazioni all'utente.

Gli equivalenti non-testuali del testo (per esempio le icone, discorsi pre-registrati o il filmato di una persona che traduce il testo nel linguaggio dei segni) possono rendere i documenti accessibili a persone che possono avere delle difficoltà ad accedere al testo scritto, inclusi molti individui con disabilità cognitive e difficoltà di apprendimento e sordità. Gli equivalenti non-testuali del testo possono anche essere utili a coloro che non leggono. Una descrizione sonora è un esempio di equivalente non-testuale di informazione visuale. Una descrizione sonora di una traccia visiva di presentazione multimediale, favorisce le persone che non riescono a vedere l'informazione visuale.

Appendice A. -- Validazione

Validare l'accessibilità con strumenti automatici e revisione umana. I metodi automatizzati sono di solito rapidi e convenienti ma non riescono ad identificare tutti i problemi dell'accessibilità. La revisione umana può aiutare ad assicurare la chiarezza di linguaggio e la facilità di navigazione.

Cominciare usando metodi di validazione al più primitivo stadio di sviluppo. I problemi legati all'accesso identificati subito sono più facili da correggere e da evitare.

Di seguito elenchiamo alcuni importanti metodi di validazione, discussi in dettaglio nella sezione sulla validazione nel Documento sulle Tecniche.

Usare uno strumento di accessibilità automatico e uno strumento di validazione browser. Si noti che i software non risolvono tutti i problemi di accessibilità, come il significato pieno del testo linkato; l'applicabilità di un equivalente testuale, ecc.
Validare la sintassi (ad es., HTML, XML, etc.).
Validare i fogli di stile (per es., CSS).
Usare un browser o un emulatore solo-testo.
Usare browser multi-grafici, con:

suoni e grafici caricati,
grafici non caricati,
suoni non caricati,
niente mouse,
frame, script, fogli di stile e applet non caricati

Usare molteplici browser, vecchi e nuovi.
Usare un browser con la voce incorporata, uno screen reader, un software ingrandente, un piccolo display, ecc.
Usare controlli automatici di spelling e grammatica. Una persona che legge una pagina con un sintetizzatore vocale può non essere in grado di decifrare il miglior tentativo del sintetizzatore per una parola con un errore di spelling. Eliminare problemi di grammatica migliora la comprensione.
Revisionare il documento per chiarezza e semplicità. Statistiche di leggibilità, come quelle generate da alcuni word processor possono essere degli utili indicatori di chiarezza e semplicità. Ancora meglio, chiedere ad un esperto editor (umano) di revisionare il testo per verificarne la chiarezza. Gli editor possono anche migliorare l'utilizzabilità dei documenti identificando problemi culturali potenzialmente rilevanti che possono sorgere a causa dell'uso del linguaggio o delle icone.
Invitare persone con una disabilità a revisionare i documenti. Utenti disabili esperti e principianti forniscono un valido feedback sui problemi dell'accessibilità e dell'utilizzabilità e delle difficoltà.

Appendice B. -- Glossario

Accessibile: Il contenuto è accessibile quando può essere usato da qualcuno che ha una disabilità.
Applet: Un programma inserito in una pagina web.
ASCII: L'ASCII si riferisce alle lettere del testo e ai simboli che sono combinati per creare un immagine. Per esempio ";-)" è l'emoticon smile. Ciò che segue è una cifra ascii che mostra la relazione fra la frequenza del flash e la risposta fotoconvulsiva in pazienti con occhi aperti e chiusi [skip over ascii figure or consult a description of chart]:
Assistente digitale personale (PDA): Un PDA è un piccolo dispositivo portatile di conteggio.La maggior parte dei PDA sono usati per tracciare dati personali come ad esempio calendari, contatti e posta elettronica. Un PDA è di solito un apparecchio maneggevole con un piccolo schermo che consente input da diverse sorgenti.
Braille: Il braille usa sei punti in rilievo in diversa sequenza per rappresentare lettere e numeri per essere lette da persone non vedenti mediante i polpastrelli. La parola "accessibile" in braille:; Un display braille, comunemente indicato come un "display braille dinamico", solleva o abbassa sequenze di punti a comando da un dispositivo elettronico, di solito un computer. Il risultato è una linea braille che cambia di momento in momento. Un braille dinamico corrente (Current dynamic braille) mostra una gamma di punti in una cella (sei o otto) per una linea formata da otto celle, la maggior parte ha tra le dodici e le venti celle per linea.
Compatibile all'indietro: Design che continua a funzionare con versioni precedenti di un linguaggio, programma, ecc.
Contenuto del documento, struttura e presentazione: Il contenuto di un documento si riferisce a ciò che dice all'utente mediante il linuaggio naturale, immagini, suoni, filmati, animazioni, ecc. La struttura di un documento equivale a come è organizzato da un punto di vista logico (per esempio per capitoli, con un introduzione e delle tavole di contenuto, ecc.). Un elemento (per es., P, STRONG, BLOCKQUOTE nell'HTML) che specifichi la struttura del documento, viene chiamato elemento strutturale. La presentazione di un documento è come viene reso il documento stesso (per esempio, a stampa, come presentazione grafica bi-dimensionale, come presentazione solo-testo, come sintesi vocale, come braille, ecc.). Un elemento che specifichi la presentazione di un documento (per esempio, B, FONT, CENTER) viene denominato elemento di presentazione.; Consideriamo l'intestazione di un documento, per esempio. Il contenuto dell'intestazione è ciò che dice l'intestazione (es. "Barche a vela"). Nell'HTML, l'intestazione è un elemento strutturale contrassegnato per esempio da un elemento H2. Infine la presentazione dell'intestazione deve essere un testo in grassetto allineato al margine, una linea di testo centrata, un titolo detto con un certo stile di voce (come fonte sonora), ecc.
Disapprovato: Un elemento o attributo disapprovato è qualcosa che è stato superato da nuovi costrutti. Elementi disapprovati possono diventare obsoleti nelle versioni future dell'HTML. L'indice degli elementi e attributi HTML nel Documento sulle Tecniche indica quali elementi e attributi sono disapprovati dall'HTML 4.0.; Gli autori dovrebbero evitare di utilizzare elementi e attributi disapprovati. Gli interpreti dovrebbero continuare il loro supporto per ragioni di compatibilità.
Elemento: Il presente documento utilizza il termine "elemento" nel senso ristretto di SGML (un elemento è un costrutto sintattico) e più generalmente per definire un tipo di contenuto (come il video o il suono) o un costrutto logico (come un'intestazione o una lista). Il secondo senso è usato per enfatizzare che una linea-guida ispirata dall'HTML si possa facilmente applicare ad un altro linguaggio di marcatura.Si noti che alcuni elementi (SGML)_ hanno un contenuto che è reso (es., gli elementi P, LI, o TABLE in HTML), alcuni sono rimpiazzati da contenuti esterni (es., IMG) e alcuni hanno a che fare con procedimenti (es., STYLE e SCRIPT fanno in modo che l'informazione sia trattata da un foglio di stile o da un motore script). Un elemento che fa sì che i caratteri di testo siano parte di un documento viene chiamato un elemento di testo.
Equivalente: Un contenuto è "equivalente" ad un altro contenuto quando entrambi svolgono essenzialmente la stessa funzione o scopo nei confronti dell'utente. Nel contesto di questo documento, per una persona con una disabilità, l'equivalente deve svolgere essenzialmente la stessa funzione (almeno fino a quanto è possibile data la natura della disabilità e lo stadio della tecnologia) che il contenuto principale svolge verso una persona con nessuna disabilità. Per esempio, il testo "La luna piena" può veicolare la stessa informazione di un'immagine di luna piena quando presentato ad un utente. Si noti che l'informazione equivalente si basa sullo svolgimento della stessa funzione. Se l'immagine è parte di un link e la sua comprensione è cruciale per indovinare la destinazione del link, anche un equivalente deve dare all'utente un'idea della destinazione del link. Fornire informazione equivalente per un contenuto inaccessibile è uno dei modi primari attraverso i quali gli autori possono rendere i loro documenti accessibili a persone con disabilità.; Come aspetto dello svolgere la stessa funzione per quel che riguarda il contenuto, un equivalente può comportare la descrizione di quel contenuto (cioé, come appare alla vista o all'udito). Per esempio, allo scopo che gli utenti comprendano l'informazione veicolata da un grafico complesso, gli autori dovrebbero descrivere l'informazione visuale del grafico.; Dal momento che il contenuto testuale puo essere presentato all'utente sotto forma di sintesi vocale, braille e testo visibile a video, queste linee guida richiedono equivalenti testuali per le informazioni grafiche e sonore. Gli equivalenti testuali devono essere scritti in modo da veicolare l'intero contenuto essenziale.Gli equivalenti non-testuali (per esempio, una descrizione sonora o una presentazione visuale, un video di una persona che racconti una storia usando il linguaggio dei segni come equivalente di una storia scritta, ecc..) migliorano anche l'accessibilità per persone che non possono accedere all'informazione visuale o al testo scritto, inclusi molti individui colpiti da cecità, disabilità cognitive, disabilità nell'apprendimento, e sordità.; L'informazione equivalente può essere fornita in un certo numero di modi che includano gli attributi (per esempio, un valore testuale per l'attributo "alt' in HTML e SMIL), come parte dell'elemento contenuto (per esempio, l'OBJECT in HTML), come parte della prosa del documento, o attraverso un documento linkato (per esempio designato dall'attributo "londesc" dell'HTML o un link descrittivo). In base alla complessità dell'equivalente può essere necessario combinare tecniche (per esempio, usare alt per un equivalente abbreviato, utile ai lettori che hanno familiarità in unione con "londesc" per un link ad un'informazione più complessa, utile ai lettori principianti). I dettagli su come e quando fornire un'informazione equivalente fanno parte del Documento sulle Tecniche ([TECHNIQUES]).; Una trascrizione testuale è un equivalente testuale di informazioni audio che includa parole pronunciate e suoni come ad esempio effetti sonori. Un allegato è un testo trascritto per la traccia audio di una presentazione video che sia sincronizzato con le tracce audio e video. Le didascalie vengono generalmente rese da un punto di vista visivo, venendo sovrappostie alla schermata, cosa che favorisce le persone sorde o con difficoltà di udito e qualsiasi altra persona non possa ascoltare l'audio (per esempio, quando si è in una stanza affollata). Una trascrizione testuale collazionata combina (collaziona) gli allegati con le descrizioni testuali di informazioni video (descrizione delle azioni, linguaggio corporeo, grafici, e cambiamenti di scena nella traccia video). Questi equivalenti testuali rendono la presentazione accessibile a persone che sono sordo-cieche e a persone che non possono ascoltare film, animazioni, ecc; Rende anche l'informazione reperibile ai motori di ricerca.Un esempio di un equivalente non-testuale è una descrizione uditiva degli elementi visuali chiave di una presentazione. La descrizione consiste sia in una voce umana preregistrata o una voce sintetizzata (registrata o generata sul momento). La descrizione audio è sincronizzata con la traccia audio della presentazione, di solito durante le pause naturali nella traccia audio. Le descrizioni audio includono informazioni su azioni, linguaggio corporeo, grafici e cambi di scena.
Fino a quando gli interpreti ...: Nella maggior parte dei checkpoint si chiede agli sviluppatori di assicurare l'accessibilità delle pagine e dei siti. Tuttavia vi sono esigenze di accessibilità che verrebbero incontro ai bisogni degli interpreti (incluse le tecnologie assistive). Alla data di pubblicazione di questo documento, non tutti gli interpreti o le tecnologie assistive forniscono il controllo di vaccessibilità che gli utenti richiedono (per esempio, alcuni traduttori possono non consentire all'utente di spegnere il vcontenuto che lampeggia, o alcuni screen readers allo stesso modo possono non trattare bene le tavole). I checkpoint che contengono la frase "fino a quando gli interpreti..." richiedono agli sviluppatori di fornire un aiuto aggiuntivo per vl'accessibilità fino a quando la maggior parte degli interpreti prontamente disponibili per il pubblico, non avranno incluso le caratteristiche necessarie di accessibilità.; Nota. Il sito WAI del W3C (fare riferimento a [WAI-UA-SUPPORT]) fornisce informazioni riguardo ai supporti per vgli interpreti per le caratteristiche di accessibilità. Si incoraggiano gli sviluppatori a consultare di frequente queste pagine per un'informazione regolarmente aggiornata.
Fogli di stile: Un foglio di stile è una serie di specifiche che riguardano la presentazione di un documento. I fogli di stile possono avere vtre diverse origini: possono essere scritti dagli sviluppatori, creati dagli utenti, o incorporati in interpreti. Nei CSS ([CSS2]), l'interazione dei fogli di stile del content provider, dell'utente e dell'interprete è denominata la cascata.; La marcatura di presentazione è una marcatura che raggiunge (piuttosto che strutturare) un effetto stilistico come gli elementi B o I nell'HTML. Si noti che gli elementi STRONG e EM non sono considerate marcature di presentazione dal momento che contengono un'informazione che è indipendente da un particolare stile del font.
HTML dinamico (DHTML): DHTML è il termine di marketing applicato a un misto di standard che includono HTML, i fogli di stile, il Document Object Model [DOM1] e gli script. Tuttavia non esiste una specifica W3C che definisca formalmente il DHTML. La maggior parte delle linee guida si possono applicare ad applicazioni che usano il DHTML, tuttavia le linee guida che seguono focalizzano l'attenzione su problemi collegati con l'inserimento di scripts e con i fogli di stile: linea guida 1, linea guida 3, linea guida 6, lineaguida 7, e lineaguida 9.
Immagine: Una presentazione grafica.
Immagine sensibile: Un'immagine che è stata divisa in zone con azioni associate. Cliccando su una zona attiva si fa in modo che avvenga un'azione.; Quando un utente clicca su una zona attiva di un'immagine sensibile dalla parte client, l'interprete calcola in quale zona si è verificato il click e segue il link associato a quella zona. Cliccando su una zona attiva di un'immagine sensibile dalla parte server si fa in modo che le coordinate del click vengano inviate al server che di conseguenza svolge una qualche azione.; Gli sviluppatori possono rendere accessibili le immagini sensibili dal lato-client fornendo accesso indipendente dai dispositivi agli stessi link associati con le regioni dell'immagine. Le immagini sensibili client-side consentono all'interprete di fornire un feedback immediato sia che il puntatore dell'utente sia o non sia su una determinata zona.
Importante: L'informazione in un documento è importante se la comprensione dell'informazione stessa è cruciale per la comprensione del documento.
Indipendente da dispositivo: L'utente dovrebbe essere in grado di interagire con un traduttore (e il documento che rende) usando i dispositivi di input e output di propria scelta e secondo i propri bisogni. I dispositivi di input possono includere dispositivi di puntammento, tastiere, dispositivi braille, bacchette manovrate con la testa, microfoni ed altro. I dispositivi di output possono includere monitors, sintetizzatori vocali e dispositivi braille.; Si noti che "supporto indipendente da dispositivo" non significa che i traduttori devono supportare ogni dispositivo di input o output. I traduttori dovrebbero offrire meccanismi di input e output ridondanti per i dispositivi supportati. Ad esempio, se un traduttore supporta la tastiera ed il mouse, l'utente dovrebbe essere in grado di interagire con tutte le configurazioni usando sia la tastiera che il mouse.
Informazione tabulare: Quando le tavole sono usate per rappresentare relazioni logiche fra i dati -- testi, numeri, immagini, ecc., vquell'informazioneè chiamata "informazione tabulare" e le tavole sono chiamate "tavole di dati". Le relazioni espresse da una tavola possono essere rese da un punto di vista visivo (di solito su una griglia bi-dimensionale), uditivo (spesso precedendo celle con informazione nel titolo), o in altri formati.
Ingranditore di schermo: Un programma di software che ingrandisce una porzione di schermo in modo che possa essere vista più facilmente. Gli ingranditori di schermo vengono usati principalmente da individui ipovedenti.
Interprete: Software per l'accesso al contenuto web, inclusi browser di desktop grafico, browser testuali, browser vocali, cellulari, lettori multimediali, plugin, e alcuni software di tecnologia assitiva usati congiuntamente a browser come screen reader, ingranditori, e software di ricognizione vocale.
Lettore di schermo: Un programma di software che legge il contenuto dello schermo a voce alta a un utente. I lettori di schermo vengono usati principalmente da persone non-vedenti. I lettori di schermo di solito sono in grado di leggere solo il testo stampato (scritto) e non disegnato sullo schermo.
Linguaggio naturale: Linguaggi umani parlati, scritti o dei segni come il linguaggio dei segni francese, giapponese, americano e il braille. Il vlinguaggio naturale di un contenuto puo' essere indicato con l'attributo "lang" in HTML ([HTML40], sezione 8.1) e l'attributo "xml:lang" in XML ([XML], sezione 2.12).
Meccanismo di navigazione: Un meccanismo di navigazione è rappresentato da qualsiasi mezzo col quale un utente possa navigare in un sito o pagina vweb. Alcuni meccanismi tipici includono:
Strumento di authoring: Editor HTML, strumenti di conversione dei documenti, strumenti che producono contenuto web da dei database sono tutti strumenti di authoring. Riferirsi alle "Linee guida sull'accessibilità degli strumenti di authoring" ([WAI-AUTOOLS]) per informazioni sullo sviluppo di strumenti accessibili.
Sviluppatore: Qualcuno che fa l'authoring di pagine web o progetta siti.
Tavola linearizzata: Una tavola che rende un processo dove i contenuti delle celle diventano una serie di paragrafi (per esempio, in fondo alla pagina) uno dopo l'altro. I paragrafi seguiranno lo stesso ordine delle celle del documento d'origine. Le celle dovrebbero rendere il senso lette nell'ordine e dovrebbero includere elementi strutturali (che creino paragrafi, titoli, liste, ecc.) in modo che la pagina conservi il senso dopo la linearizzazione.
Tecnologia assistiva: Software o hardware progettato specificamente per supportare persone con un'invalidità a compiere le attività quotidiane. La tecnologia assistiva include sedie a rotelle, macchine per la lettura, aggeggi per afferrare, ecc. Nell'area dell'accessibilità del web, le technologie assistive basate su software comune, includono screen reader, ingranditori di schermo, sintetizzatori vocali e software di importazione della voce che operano congiuntamente a browser con desktop grafico (tra gli altri interpreti). Le tecnologie assistive, dal punto di vista dell'hardware, includono tastiere alternative e dispositivi di puntamento.
Testo del link: Il contenuto di un link reso in maniera testuale.

Riconoscimenti

Web Content Guidelines Working Group Co-Chairs:: Chuck Letourneau, Starling Access Services; Gregg Vanderheiden, Trace Research and Development
Contatti del W3C Team:: Judy Brewer e Daniel Dardailler
Desideriamo ringraziare le persone seguenti che, con il loro tempo e i loro validi commenti hanno contribuito a da rforma queste linee guida:: Harvey Bingham, Kevin Carey, Chetz Colwell, Neal Ewers, Geoff Freed, Al Gilman, Larry Goldberg, Jon Gunderson, Eric Hansen, Phill Jenkins, Leonard Kasday, George Kerscher, Marja-Riitta Koivunen, Josh Krieger, Scott Luebking, William Loughborough, Murray Maloney, Charles McCathieNevile, MegaZone (Livingston Enterprises), Masafumi Nakane, Mark Novak, Charles Oppermann, Mike Paciello, David Pawson, Michael Pieper, Greg Rosmaita, Liam Quinn, Dave Raggett, T.V. Raman, Robert Savellis, Jutta Treviranus, Steve Tyler, Jaap van Lelieveld, e Jason White

La bozza originale di questo documento è basata su "The Unified Web Site Accessibility Guidelines" ([UWSAG]) compilate dal Trace R & D Center all'Università del Wisconsin. Quel documento include una lista di ulteriori partecipanti.

Riferimenti

Per l'ultima versione di qualsiasi specifica W3C si prega di consultare la lista W3C Technical Reports.

[CSS1]: "CSS, level 1 Recommendation", B. Bos, H. Wium Lie, eds., 17 December 1996, revised 11 January 1999. La CSS1 Recommendation è: http://www.w3.org/TR/1999/REC-CSS1-19990111.
[CSS2]: "CSS, level 2 Recommendation", B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs, eds., 12 May 1998. La CSS2 Recommendation è: http://www.w3.org/TR/1998/REC-CSS2-19980512.
[DOM1]: "Document Object Model (DOM) Level 1 Specification", V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, and L. Wood, eds., 1 October 1998. La DOM Level 1 Recommendation è: http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001.
[HTML40]: "HTML 4.0 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs, eds., 17 December 1997, revised 24 April 1998. L' HTML 4.0 Recommendation è: http://www.w3.org/TR/1998/REC-html40-19980424.
[HTML32]: "HTML 3.2 Recommendation", D. Raggett, ed., 14 January 1997. L'ultima versione dell'HTML 3.2 è disponibile a: http://www.w3.org/TR/REC-html32.
[MATHML]: "Mathematical Markup Language", P. Ion and R. Miner, eds., 7 April 1998. La MathML 1.0 Recommendation è: http://www.w3.org/TR/1998/REC-MathML-19980407.
[PNG]: "PNG (Portable Network Graphics) Specification", T. Boutell, ed., T. Lane, contributing ed., 1 October 1996. L'ultima versione di PNG 1.0 è: http://www.w3.org/TR/REC-png.
[RDF]: "Resource Description Framework (RDF) Model and Syntax Specification", O. Lassila, R. Swick, eds., 22 February 1999. La RDF Recommendation è: http://www.w3.org/TR/1999/REC-rdf-syntax-19990222.
[RFC2068]: "HTTP Version 1.1", R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen, and T. Berners-Lee, January 1997.
[SMIL]: "Synchronized Multimedia Integration Language (SMIL) 1.0 Specification", P. Hoschka, ed., 15 June 1998. La SMIL 1.0 Recommendation è: http://www.w3.org/TR/1998/REC-smil-19980615
[TECHNIQUES]: "Techniques for Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, I. Jacobs, eds. Questo documento spiega come migliorare i checkpoints definiti nelle "Web Content Accessibility Guidelines 1.0". L'ultima versione delle tecniche è disponibile a: http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/
[WAI-AUTOOLS]: "Authoring Tool Accessibility Guidelines", J. Treviranus, J. Richards, I. Jacobs, C. McCathieNevile, eds. L'ultima versione di queste lineeguida per la progettazione di strumenti di authoring accessibili è disponibile a: http://www.w3.org/TR/WAI-AUTOOLS/
[WAI-UA-SUPPORT]: Questa pagina documenta i supporti conosciuti dagli interpreti (incluse le tecnologie assistive) di alcune caratteristiche di accessibilità elencate in questo documento. La pagina è disponibile a: http://www.w3.org/WAI/Resources/WAI-UA-Support
[WAI-USERAGENT]: "User Agent Accessibility Guidelines", J. Gunderson and I. Jacobs, eds. L'ultima versione di queste lineeguida per la progettazione di interpreti accessibili è disponibile a: http://www.w3.org/TR/WAI-USERAGENT/
[WCAG-ICONS]: Informazioni sulle icone di conformità per questo documento e su come usarle è disponibile a: http://www.w3.org/WAI/WCAG1-Conformance.html
[UWSAG]: "The Unified Web Site Accessibility Guidelines", G. Vanderheiden, W. Chisholm, eds. Le Unified Web Site Guidelines sono state compilate dal Trace R & D Center all'Università del Wisconsin grazie ai fondi del National Institute on Disability and Rehabilitation Research (NIDRR), U.S. Dept. of Education. Questo documento è disponibile a: http://www.tracecenter.org/docs/html_guidelines/version8.htm
[XML]: "Extensible Markup Language (XML) 1.0.", T. Bray, J. Paoli, C.M. Sperberg-McQueen, eds., 10 February 1998. L'XML 1.0 Recommendation è: http://www.w3.org/TR/1998/REC-xml-19980210.