vai al menu vai al contenuto della pagina

Linee Guida WCAG 1.0



citazione riportata dal sito dell'aib : traduzione italiana delle linee guida WCAG 1.0


[torna su]

Linea Guida 1: Fornire alternative equivalenti al contenuto audio e visivo.

Fornire un contenuto che, quando viene presentato all'utente, gli trasmetta essenzialmente la stessa funzione o scopo del contenuto audio o visivo.

Benche' alcune persone non possano usare immagini, film, suoni, applet ecc. direttamente, possono comunque usare pagine che includono un'informazione equivalente al contenuto visivo o audio. L'informazione equivalente deve servire allo stesso scopo del contenuto visivo e audio. Percio' un testo equivalente all' immagine di una freccia verso l'alto che rinvia ad un sommario potrebbe essere "vai al sommario". In alcuni casi un equivalente dovrebbe anche descrivere l'aspetto del contenuto visivo (per esempio per grafici, pannelli o diagrammi complessi) o il suono del contenuto audio (per esempio per i modelli acustici utilizzati nell'istruzione). Questa linea guida rimarca l'importanza di fornire equivalenti testuali al contenuto non testuale (immagini, audio pre-registrati, video). La potenzialita' degli equivalenti testuali sta nella loro capacita' di essere resi secondo modalita' accessibili a persone con differenti disabilita' usando tecnologie diverse. Il testo puo' essere velocemente incanalato verso la sintesi vocale e la display braille , e puo' essere presentato visivamente (in vari formati) sul video del computer o su carta. La sintesi vocale e' fondamentale per le persone non vedenti e per tutti coloro che hanno quelle difficolta' nella lettura che spesso accompagnano le disabilita' cognitive, di apprendimento e la sordita'. Il braille e' essenziale per i sordo-ciechi e per tutte quelle persone la cui unica disabilita' sensitiva e' la cecita'. Il testo mostrato visivamente va a beneficio sia degli utenti sordi, sia della maggioranza degli utenti WEB. Anche fornire equivalenti non testuali (come immagini, video e audio pre-registrati) del testo scritto e' di beneficio per alcuni utenti, specialmente per gli illetterati o per le persone che hanno difficolta' di lettura. Nei film o nelle presentazioni visive l'azione visiva come il linguaggio del corpo o altri espedienti visivi potrebbe non essere accompagnata da una informazione audio sufficiente a trasmettere la stessa informazione. A meno che non venga fornita una descrizione verbale di questo contenuto visivo, le persone che non possono vedere (o guardare) il contenuto visivo non saranno in grado di percepirlo.

[torna su]
Punti di controllo linea guida 1:

1.1 Fornire un equivalente testuale per ogni elemento non di testo (per esempio, mediante "alt", "longdesc" o contenuto nell'elemento stesso). Questo comprende: immagini, rappresentazioni grafiche di testo (compresi i simboli), zone di immagini sensibili, animazioni (ad es. GIF animate), applets e oggetti programmati, arte ASCII, frame, script, immagini usate come richiamo per elenchi, spaziatori, bottoni grafici, suoni (azionati con o senza l'intervento dell'utente), file di solo audio, tracce audio di video e video. [Priorita' 1]. Per esempio, in HTML: usare "alt" per gli elementi IMG, INPUT e APPLET o fornire un equivalente testuale nel contenuto degli elementi OBJECT o APPLET; per contenuti complessi (per esempio un grafico) laddove un testo "alt" non fornisce un equivalente testuale completo, fornire una descrizione aggiuntiva usando, per esempio, "longdesc" con IMG o FRAME, un collegamento all'interno di un elemento OBJECT o a un collegamento descrittivo. Per le immagini sensibili usare l'attributo "alt" con AREA oppure usare l'elemento MAP con gli elementi A (e altro testo) come contenuto.

1.2 Fornire ridondanti collegamenti di testo per ogni zona attiva di una immagine sensibile sul lato server. [Priorita' 1]

1.3 Fino a quando gli interpreti non potranno leggere automaticamente ad alta voce l'equivalente testuale di un filmato, fornire una descrizione audio delle informazioni essenziali del filmato di una presentazione multimediale. [Priorita' 1]. Sincronizzare la descrizione audio con la traccia audio.

1.4 Per ogni presentazione multimediale temporizzata (per es. un film o una animazione), sincronizzare alternative equivalenti (per es. didascalie o descrizioni parlate del filmato) con la presentazione. [Priorita' 1]

1.5 Fino a quando gli interpreti non renderanno disponibili equivalenti testuali per collegamenti di immagini sensibili sul lato client fornire collegamenti di testo ridondanti per ogni zona attiva di una immagine sensibile sul lato client. [Priorita' 3]

[torna su]

Linea Guida 2: Non fare affidamento sul solo colore.

Assicurarsi che il testo e la parte grafica siano comprensibili se consultati senza il colore.

Se viene usato il solo colore per veicolare informazione, le persone che non possono distinguere fra alcuni colori e utenti che hanno monitor in bianco e nero o non visuali non riceveranno l'informazione. Quando i colori dello sfondo e degli oggetti in primo piano sono troppo simili per tonalita', potrebbero dare un contrasto non sufficiente se consultati usando un monitor monocromatico o da persone con varie disabilita' percettive sul colore.

[torna su]
Punti di controllo linea guida 2:

2.1 Assicurarsi che tutta l'informazione veicolata dal colore sia disponibile anche senza, per esempio grazie al contesto o ai marcatori. [Priorita' 1]

2.2 Assicurarsi che le combinazioni fra colori dello sfondo e del primo piano forniscano un sufficiente contrasto se visti da qualcuno con deficit percettivi sul colore o se visti su uno schermo in bianco e nero. [Priorita' 2 per le immagini, Priorita' 3 per il testo].

[torna su]

Linea Guida 3: Usare marcatori e fogli di stile e farlo in modo appropriato.

Marcare i documenti con i corretti elementi strutturali. Controllare la presentazione con fogli di stile piuttosto che con elementi e attributi di presentazione.

Usare i marcatori in modo improprio -- non seguendo le specifiche -- impedisce l'accessibilita'. Il cattivo uso di marcatori per un effetto di presentazione (p.es. usare una tabella per l'impaginazione o una intestazione per cambiare la dimensione dei caratteri) rende difficile, per l'utente con software specialistico, la comprensione dell'organizzazione della pagina o la navigazione attraverso questa. Inoltre, l'uso di marcatori di presentazione invece che di marcatori strutturali per veicolare una struttura (per es. costruire cio' che sembra una tabella di dati con un elemento HTML PRE) rende difficile la comprensione di una pagina per chi ha altri strumenti di lettura (vedi la descrizione delle differenze fra contenuto, struttura e presentazione). Gli sviluppatori possono essere tentati di usare (o usar male) costruzioni che ottengono l'effetto di formato voluto su vecchi browser. Costoro devono sapere che queste abitudini causano problemi di accessibilita' e devono considerare se l'effetto della formattazione sia cosi' importante da giustificare di avere reso il documento inaccessibile per alcuni utenti. All'altro estremo, gli sviluppatori non devono sacrificare dei marcatori appropriati perche' un certo browser o una tecnologia assistiva non li gestiscono correttamente. Per esempio, e' corretto l'uso dell'elemento TABLE in HTML per segnare una informazione tabellare anche se alcuni vecchi lettori di schermo possono non gestire correttamente il testo giustapposto (vedi anche il punto di controllo 10.3). Usare TABLE correttamente e creare tabelle che si trasformino bene (vedi anche la Linea guida 5) permette al software di restituire tabelle in altro modo rispetto alle griglie bidimensionali.

[torna su]
Punti di controllo linea guida 3:

3.1 Quando esiste un linguaggio di marcatori adatto, per veicolare informazione usare un marcatore piuttosto che le immagini. [Priorita' 2]. Per esempio, usare MathML per marcare le equazioni matematiche e i fogli di stile per formattare il testo e controllare l'impaginazione. Inoltre, evitare l'uso di immagini per rappresentare un testo: usare invece testo e fogli di stile.

3.2 Creare documenti che facciano riferimento a grammatiche formali pubblicate. [Priorita' 2]. Per esempio, includere all'inizio di un documento una dichiarazione sul tipo di documento che rimandi a una DTD pubblicata (ad es. il DTD rigoroso di HTML 4.0).

3.3 Usare fogli di stile per controllare l'impaginazione e la presentazione. [Priorita' 2]. Per esempio, usare la proprieta' dei caratteri CSS invece che l'elemento HTML FONT per controllare gli stili di caratteri.

3.4 Usare unita' relative e non assolute nei valori degli attributi del linguaggio dei marcatori e i valori della proprieta' del foglio di stile. [Priorita' 2]. In CSS, per esempio, usare "em" o misure di percentuale invece di "pt" o "cm", che sono misure assolute. Se si usano misure assolute accertarsi che il contenuto espresso sia utilizzabile (vedi la sezione sulla validazione).

3.5 Usare elementi di intestazione per veicolare la struttura del documento e usarli in modo conforme alle specifiche. [Priorita' 2]. Per esempio, in HTML, usare H2 per indicare una sottosezione di H1. Non usare intestazioni per gli effetti di carattere.

3.6 Marcare le liste ed elencare le voci della lista in modo appropriato. [Priorita' 2]. In HTML, per esempio, inserire le liste OL, UL e DL in modo appropriato.

3.7 Marcare le citazioni. Non usare marcatura che definisca citazioni per ottenere effetti di formato come il rientro. [Priorita' 2]. In HTML, per esempio, usare gli elementi Q e BLOCKQUOTE per marcare rispettivamente le citazioni brevi e quelle piu' lunghe.

[torna su]

Linea Guida 4: Chiarire l'uso di linguaggi naturali.

Utilizzare marcatori che facilitino la pronuncia o l'interpretazione di testi stranieri o abbreviati.

Quando lo sviluppatore contrassegna in un documento i cambiamenti di linguaggio naturale, le sintesi vocali e le periferiche braille possono selezionare automaticamente la nuova lingua, rendendo il documento piu' accessibile agli utenti multilingue. Gli sviluppatori dovrebbero identificare il linguaggio naturale principale del contenuto di un documento (mediante marcatori o intestazioni HTTP). Gli sviluppatori dovrebbero anche sciogliere le abbreviazioni e gli acronimi. Oltre a facilitare le tecnologie assistive, contrassegnare il linguaggio naturale permette ai motori di ricerca di trovare parole chiave e di identificare documenti nel linguaggio desiderato. Il contrassegno del linguaggio naturale, inoltre, consente a tutti la leggibilita' del Web, compresi quelli che hanno difficolta' di apprendimento, cognitive e i sordi. Quando i cambiamenti di lingua e le abbreviazioni non vengono identificati, possono risultare indecifrabili per la lettura da parte dei dispositivi di sintesi vocale e di quelli braille.

[torna su]
Punti di controllo linea guida 4:

4.1 Identificare con chiarezza i cambiamenti nel linguaggio naturale del testo di un documento e in ogni equivalente testuale (per es. nelle didascalie). [Priorita' 1]. Per esempio, in HTML usare l'attributo "lang". In XML, usare "xml:lang".

4.2 Specificare lo scioglimento di ogni abbreviazione o acronimo nel documento laddove compare per la prima volta. [Priorita' 3]. Per esempio, in HTML usare l'attributo "title" degli elementi ABBR e ACRONYM. Anche fornire lo scioglimento nel corpo stesso del documento ne aiuta la fruibilita'.

4.3 Identificare il linguaggio naturale principale di un documento. [Priorita' 3]. In HTML, per esempio, assegnare l'attributo "lang" all'elemento HTML. In XML usare "xml:lang". I gestori di server dovrebbero configurare i server per l'utilizzo dei meccanismi di negoziazione del contenuto HTTP cosi' che i client possano automaticamente scaricare i documenti nella lingua preferita.

[torna su]

Linea Guida 5: Creare tabelle che si trasformino in maniera elegante.

Assicurarsi che le tabelle abbiano la marcatura necessaria per essere trasformate dai browser accessibili e da altri interpreti.

Le tabelle dovrebbero essere usate per marcare informazioni realmente tabellari ("tabelle di dati"). Gli sviluppatori dovrebbero evitare di usarle per l'impaginazione ("tabelle di impaginazione"). Le tabelle, in qualsiasi modo siano usate, presentano anche problemi particolari per gli utenti con lettori di schermo. Alcuni interpreti consentono agli utenti di navigare fra le celle delle tabelle e di accedere alle intestazioni e ad altre informazioni nelle celle. A meno che non sia stata realizzata una marcatura corretta, queste tabelle non forniranno agli interpreti le informazioni appropriate. I punti di controllo seguenti andranno a diretto beneficio delle persone che hanno accesso a una tabella con ausili audio (ad es. un lettore di schermo o un PC installato in un'auto) o che vedono soltanto una parte della pagina per volta (ad es. utenti con cecita' o ipovedenti che usano sintesi vocali o display braille, o altri utenti con sistemi con display piccoli, ecc.).

[torna su]
Punti di controllo linea guida 5:

5.1 Per tabelle di dati, identificare le intestazioni di righe e colonne. [Priorita' 1]. Per esempio, in HTML, usare TD per identificare le celle di dati e TH per identificare le intestazioni.

5.2 Per tabelle di dati che hanno due o piu' livelli logici di intestazioni di righe o colonne, usare marcatori per associare le celle di dati e le celle di intestazione. [Priorita' 1]. Per esempio, in HTML, usare THEAD, TFOOT e TBODY per raggruppare righe, COL e COLGROUP per raggruppare colonne e gli attributi "axis", "scope" e "headers" per descrivere relazioni piu' complesse fra i dati.

5.3 Non usare tabelle per impaginazioni a meno che la tabella non sia comprensibile se letta in modo linearizzato. Altrimenti, se la tabella non risulta leggibile, fornire una alternativa equivalente (che puo' essere una versione linearizzata). [Priorita' 2]. Nota. Quando gli interpreti supporteranno l'impaginazione con foglio di stile, non dovrebbero essere usate le tabelle per questo scopo.

5.4 Se per l'impaginazione viene usata una tabella non usare nessun marcatore di struttura per la formattazione della resa visiva. [Priorita' 2]. Per esempio, in HTML non usare l'elemento TH per determinare il contenuto di una cella (intestazione non tabellare) che debba essere mostrata centrata e in grassetto.

5.5 Per le tabelle, fornire sommari. [Priorita' 3]. Per esempio, in HTML usare l'attributo "summary" dell'elemento TABLE.

5.6 Fornire abbreviazioni per le etichette di intestazione. [Priorita' 3]. Per esempio, in HTML, usare l'attributo "abbr" sull'elemento TH.

[torna su]

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

Assicurarsi che le pagine siano accessibili anche quando le tecnologie piu' recenti non sono supportate o sono disabilitate.

Sebbene gli sviluppatori siano incoraggiati a usare nuove tecnologie che risolvano problemi creati da tecnologie esistenti, essi dovrebbero sapere come far si' che le loro pagine funzionino anche con browser piu' vecchi e con persone che scelgono di disabilitare alcune caratteristiche.

[torna su]
Punti di controllo linea guida 6:

6.1 Organizzare i documenti in modo che possano essere letti senza i fogli di stile. Per esempio, quando un documento HTML viene reso senza i fogli di stile associati, deve essere sempre possibile leggere il documento. [Priorita' 1]. Quando il contenuto sara' organizzato logicamente, esso verra' reso secondo un ordine significativo quando i fogli di stile sono disabilitati oppure non supportati.

6.2 Assicurarsi che gli equivalenti del contenuto dinamico vengano aggiornati quando il contenuto dinamico cambia. [Priorita' 1].

6.3 Assicurarsi che le pagine siano utilizzabili quando script, applet, o altri oggetti di programmazione sono disabilitati oppure non supportati. Se questo non e' possibile, fornire informazione equivalente in una pagina accessibile alternativa. [Priorita' 1]. Per esempio, assicurarsi che i collegamenti che attivano script funzionino quando gli script sono disabilitati oppure non supportati (per esempio, non usare "javascript:" come obiettivo del collegamento). Se non e' possibile rendere la pagina utilizzabile senza script, fornire un equivalente testuale con l'elemento NOSCRIPT, oppure usare uno script lato server al posto di uno script lato client, oppure fornire una pagina accessibile alternativa.

6.4 Per quanto riguarda script e applet, assicurarsi che i gestori di eventi siano indipendenti dai dispositivi di input. [Priorita' 2].

6.5 Assicurarsi che il contenuto dinamico sia accessibile oppure fornire una presentazione o pagina alternativa. [Priorita' 2]. Per esempio, in HTML, usare NOFRAMES alla fine di ogni insieme di frame. Per alcune applicazioni, gli script lato server possono essere piu' accessibili degli script lato client.

[torna su]

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

Assicurarsi che gli oggetti in movimento, lampeggianti, scorrevoli o che si autoaggiornano possano essere arrestati temporaneamente o definitivamente.

Alcune persone con disabilita' cognitive o visive non riescono a leggere testo in movimento con velocita' sufficiente, oppure non sono in grado di leggerlo affatto. Il movimento puo' anche causare una distrazione tale da rendere illeggibile il resto della pagina per persone con disabilita'. I lettori di schermo non sono in grado di leggere testo in movimento. Persone con disabilita' fisiche potrebbero non essere in grado di muoversi con velocita' o precisione sufficienti ad interagire con oggetti in movimento. Nota. Tutti i punti di controllo che seguono presuppongono un certo livello di responsabilita' da parte degli sviluppatori fino a quando gli interpreti non forniranno adeguati meccanismi di controllo delle diverse caratteristiche.

[torna su]
Punti di controllo linea guida 7:

7.1 Fino a quando gli interpreti non permetteranno agli utenti di controllare lo sfarfalli'o, evitare di far sfarfallare lo schermo. [Priorita' 1]. Nota. Persone con epilessia fotosensibile possono avere crisi scatenate da sfarfalli'o oppure da lampeggiamenti nell'intervallo che va da 4 a 59 lampi al secondo (Hertz), con un picco di sensibilita' intorno ai 20 lampi al secondo, cosi' come da mutamenti repentini di oscurita' e luce (come nel caso di luci intermittenti).

7.2 Fino a quando gli interpreti non permetteranno agli utenti di controllare il lampeggiamento, evitare di far lampeggiare il contenuto (cioe' di cambiare la presentazione a intervalli regolari, come se si accendesse e spengesse). [Priorita' 2].

7.3 Fino a quando gli interpreti non permetteranno agli utenti di bloccare il contenuto in movimento, evitare il movimento nelle pagine. [Priorita' 2]. Quando una pagina include contenuto in movimento, fornire un meccanismo all'interno di uno script o applet per permettere agli utenti di bloccare il movimento o gli aggiornamenti. Il fatto di usare i fogli di stile insieme con gli script per creare il movimento permette agli utenti di disabilitare oppure tenere sotto controllo gli effetti con maggiore facilita'.

7.4 Fino a quando gli interpreti non forniranno la possibilita' di bloccare l'autoaggiornamento, non creare pagine che si autoaggiornano periodicamente. [Priorita' 2]. Per esempio, in HTML, non fare autoaggiornare le pagine con "HTTP-EQUIV=refresh" fino a quando gli interpreti non permetteranno agli utenti di disabilitare questa caratteristica.

7.5 Fino a quando gli interpreti non forniranno la capacita' di bloccare l'auto-reindirizzamento, non usare marcatura per reindirizzare le pagine automaticamente. Piuttosto, configurare il server in modo che esegua i reindirizzamenti. [Priorita' 2]. Nota. Gli elementi BLINK e MARQUEE non sono definiti in alcuna delle specifiche HTML del W3C e non dovrebbero essere usate.

[torna su]

Linea Guida 8: Assicurare l'accessibilita' diretta delle interfacce utente incorporate.

Assicurarsi che la progettazione delle interfacce utente segua i principi dell'accessibilita': accesso alle diverse funzionalita' indipendente dai dispositivi usati, possibilita' di operare da tastiera, comandi vocali, ecc.

Quando un oggetto incorporato possiede una "sua propria interfaccia", l'interfaccia -- cosi' come l'interfaccia dello stesso browser -- deve essere accessibile. Se l'interfaccia dell'oggetto incorporato non puo' essere resa accessibile, deve essere fornita una soluzione alternativa accessibile.

[torna su]
Punti di controllo linea guida 8:

8.1 Fare in modo che elementi di programmi come script e applet siano direttamente accessibili o compatibili con le tecnologie assistive [Priorita' 1 se la funzionalita' e' importante e non presentata altrove, altrimenti Priorita' 2.]

[torna su]

Linea Guida 9: Progettare per garantire l'indipendenza da dispositivo.

Usare caratteristiche che permettono di attivare gli elementi della pagina attraverso una molteplicita' di dispositivi di input.

Accesso indipendente da dispositivo significa che gli utenti possono interagire con l'interprete o con il documento con il dispositivo di input (output) preferito -- mouse, tastiera, voce, bacchette manovrate con la testa, o altro. Se, per esempio, il controllo di un modulo puo' essere attivato solo con un mouse o un altro dispositivo di puntamento, qualcuno che sta usando la pagina senza usare la vista, con input vocale o con una tastiera, oppure chi sta usando qualche altro dispositivo di input non a puntamento non riuscira' ad usare il modulo. Nota. Fornendo equivalenti testuali per immagini sensibili o per immagini usate come collegamento si da' agli utenti la possibilita' di interagire con esse senza un dispositivo di puntamento. In genere, le pagine che permettono di interagire tramite tastiera sono accessibili anche tramite input vocale o interfaccia a linea di comando.

[torna su]
Punti di controllo linea guida 9:

9.1 Fornire immagini sensibili sul lato client invece di immagini sensibili sul lato server, con l'eccezione dei casi nei quali le zone non possono essere definite con una forma geometrica valida. [Priorita' 1].

9.2 Assicurarsi che ogni elemento che possiede una sua specifica interfaccia possa essere gestito in una modalita' indipendente da dispositivo. [Priorita' 2].

9.3 Negli script, specificare gestori di evento logici piuttosto che gestori di evento dipendenti da dispositivo. [Priorita' 2].

9.4 Creare un ordine logico di tabulazione fra i collegamenti, i controlli dei moduli, e gli oggetti. [Priorita' 3]. Per esempio, in HTML, specificare l'ordine di tabulazione tramite l'attributo "tabindex" oppure garantire una disposizione logica della pagina.

9.5 Fornire scorciatoie da tastiera per i collegamenti importanti (compresi quelli nelle immagini sensibili sul lato client), per i controlli dei moduli, e per i gruppi di controlli dei moduli. [Priorita' 3]. Per esempio, in HTML, specificare scorciatoie tramite l'attributo "accesskey".

[torna su]

Linea Guida 10: Usare soluzioni provvisorie.

Usare soluzioni provvisorie in modo che le tecnologie assistive e i browser piu' vecchi possano operare correttamente.

Per esempio, i browser piu' vecchi non permettono agli utenti di spostarsi su caselle per l'immissione di testo vuote. I lettori di schermo piu' vecchi leggono liste di collegamenti consecutivi come se fossero un unico collegamento. E' quindi difficile se non impossibile accedere a questi elementi attivi. Ugualmente, cambiare la finestra attiva oppure far venir fuori nuove finestre puo' disorientare notevolmente gli utenti che non possono vedere che cio' e' successo. Nota. I punti di controllo che seguono si applicano fino a quando gli interpreti (comprese le tecnologie assistive) non risolveranno questi aspetti. Questi punti di controllo sono classificati come "provvisori", nel senso che il Gruppo di lavoro sulle Web Content Guidelines li ritiene validi e necessari per l'accessibilita' del Web al momento della pubblicazione di questo documento. Tuttavia, il Gruppo di lavoro non pensa che questi punti di controllo saranno necessari nel futuro, quando le tecnologie Web avranno incorporato le capacita' e caratteristiche che sono state anticipate.

[torna su]
Punti di controllo linea guida 10:

10.1 Fino a quando gli interpreti non permetterano agli utenti di bloccare la generazione di nuove finestre, non fare apparire finestre a cascata o di altro tipo e non cambiare la finestra attiva senza informare l'utente. [Priorita' 2]. Per esempio, in HTML, evitare di usare un frame la cui destinazione e' una nuova finestra.

10.2 Fino a quando gli interpreti non supporteranno esplicite associazioni fra etichette e controlli dei moduli, assicurare, per tutti i controlli dei moduli che hanno etichette associate implicitamente, che l'etichetta sia posizionata correttamente. [Priorita' 2]. L'etichetta deve precedere il proprio controllo immediatamente sulla stessa riga (permettendo piu' di un controllo/etichetta per riga) oppure essere nella riga precedente il controllo (con una sola etichetta e un solo controllo per riga.

10.3 Fino a quando gli interpreti (comprese le tecnologie assistive) non renderanno in modo corretto il testo affiancato, fornire un testo lineare alternativo (nella pagina attiva o in qualche altra) per tutte le tabelle che dispongono testo su colonne parallele e andando a capo. [Priorita' 3]. Nota. Si prega di consultare la definizione di tabella linearizzata. Questo punto di controllo favorisce le persone che hanno interpreti (come alcuni lettori di schermo) che non sono in grado di gestire blocchi di testo affiancati; il punto di controllo non dovrebbe scoraggiare gli sviluppatori dall'usare tabelle per rappresentare informazione tabellare.

10.4 Fino a quando gli interpreti non gestiranno in maniera corretta controlli vuoti, inserire caratteri di default come segnaposto nelle caselle per l'immissione di testo a una riga oppure a piu' righe. [Priorita' 3]. Per esempio, in HTML, fare questo per TEXTAREA e INPUT.

10.5 Fino a quando gli interpreti (comprese le tecnologie assistive) non renderanno in modo distinto collegamenti adiacenti, inserire caratteri stampabili (delimitati da spazi), non facenti parte dei collegamenti, per separare i collegamenti adiacenti. [Priorita' 3].

[torna su]

Linea Guida 11: Usare le tecnologie e le raccomandazioni del W3C.

Usare le tecnologie del W3C (in conformita' con le specifiche) e seguire le raccomandazioni sull'accessibilita'. Nei casi in cui non sia possibile usare una tecnologia del W3C, oppure se nell'utilizzarla si ottenesse materiale che non si trasforma in maniera elegante, fornire una versione alternativa del contenuto che sia accessibile.

Questa linea guida raccomanda tecnologie del W3C (per es. HTML, CSS ecc.) per diversi motivi:

  • le tecnologie W3C contengono elementi di accessibilita' "integrati".
  • le specifiche W3C subiscono una revisione preliminare per assicurarsi che gli elementi di accessibilita' siano presi in considerazione fin dalla fase progettuale.
  • le specifiche W3C sono sviluppate all'interno di un processo aperto e con il consenso dell'industria del settore.

Molti formati che non sono del W3C (per es., PDF, Shockwave, etc.) richiedono di essere visti o con plug-in o con applicazioni autonome. Spesso, questi formati non possono essere visualizzati oppure non e' possibile effettuare una navigazione con interpreti standard (comprese le tecnologie assistive). Il fatto di evitare l'uso di caratteristiche non W3C e non standard (elementi, attributi, proprieta' ed estensioni proprietarie) aiutera' a rendere le pagine piu' accessibili a un numero maggiore di persone che usino una piu' ampia varieta' di hardware e software. Quando devono essere usate tecnologie non accessibili (proprietarie oppure no), devono essere fornite pagine equivalenti accessibili. Anche quando si usano le tecnologie W3C, lo si deve fare rispettando linee guida per l'accessibilita'. Nell'usare nuove tecnologie assicurarsi che esse si trasformino in maniera elegante. Nota. La conversione di documenti (da PDF, PostScript, RTF, ecc.) ai linguaggi di marcatura del W3C (HTML, XML) non sempre crea un documento accessibile. Quindi validare ogni pagina per verificare l'accessibilita' e la possibilita' d'uso dopo il processo di conversione. Se una pagina non viene convertita velocemente, correggerla finche' la sua rappresentazione originale non viene convertita appropriatamente oppure fornire una versione in formato HTML o testo semplice.

[torna su]
Punti di controllo linea guida 11:

11.1 Usare le tecnologie W3C quando sono disponibili e sono appropriate per un certo compito e usare le versioni piu' recenti quando sono supportate. [Priorita' 2].

11.2 Evitare le caratteristiche delle tecnologie W3C che sono disapprovate. [Priorita' 2]. Per esempio, in HTML, non usare l'elemento FONT che e' disapprovato; usare al suo posto i fogli di stile (per es., la proprieta' 'font' di CSS).

11.3 Fornire agli utenti l'informazione necessaria perche' possano ricevere i documenti in maniera che si adattino alle loro preferenze (per es., lingua, tipo di contenuto ecc.) [Priorita' 3]. Nota. Usare la negoziazione del contenuto quando e' possibile.

11.4 Se, nonostante ogni sforzo, non si puo' creare una pagina accessibile, fornire un collegamento a una pagina alternativa che usi le tecnologie W3C, sia accessibile, contenga informazioni (o funzionalita') equivalenti, e sia aggiornata con la stessa frequenza della pagina (originale) inaccessibile. [Priorita' 1].

Nota. Gli sviluppatori dovrebbero ricorrere a pagine alternative solo quando le altre soluzioni falliscono perche' le pagine alternative sono in genere meno aggiornate delle pagine "primarie". Una pagina non aggiornata puo' essere frustrante quanto una pagina inaccessibile visto che, in entrambi i casi, l'informazione presentata nella pagina originale non e' disponibile. La generazione automatica di pagine alternative puo' portare a aggiornamenti piu' frequenti, ma gli sviluppatori devono comunque fare attenzione ad assicurare che le pagine generate abbiano sempre senso, e che gli utenti siano in grado di navigare in un sito seguendo i collegamenti delle pagine primarie, di quelle alternative, o di entrambe. Prima di ricorrere a una pagina alternativa, riesaminare il progetto della pagina originale; e' probabile che rendendola accessibile essa risulti migliore per tutti gli utenti.

[torna su]

Linea Guida 12: Fornire informazione per la contestualizzazione e l'orientamento.

Fornire informazione per la contestualizzazione e l'orientamento, per aiutare gli utenti a comprendere pagine od elementi complessi.

Il fatto di raggruppare gli elementi e di fornire informazione contestuale sulle relazioni fra gli elementi puo' essere utile per tutti gli utenti. Relazioni complesse fra parti di una pagina possono essere difficili da interpretare per persone con invalidita' cognitive o visive.

[torna su]
Punti di controllo linea guida 12:

12.1 Dare un titolo a ogni frame per facilitare l'identificazione del frame e la navigazione. [Priorita' 1]. Per esempio, in HTML, usare l'attributo "title" con l'elemento FRAME.

12.2 Descrivere lo scopo dei frame e il modo in cui essi interagiscono se non e' evidente dai titoli dei frame da soli. [Priorita' 2]. Per esempio, in HTML, usare "longdesc," oppure un collegamento descrittivo.

12.3 Dividere grandi blocchi di informazione in gruppi piu' maneggevoli quando e' naturale ed appropriato. [Priorita' 2]. Per esempio, in HTML, usare OPTGROUP per raggruppare gli elementi OPTION all'interno di un SELECT; raggruppare i controlli dei moduli con FIELDSET e LEGEND; usare liste annidate quando e' appropriato; usare intestazioni per strutturare i documenti, ecc.

12.4 Associare esplicitamente le etichette ai loro controlli. [Priorita' 2]. Per esempio, in HTML, usare LABEL e il suo attributo "for".

[torna su]

Linea Guida 13: Fornire chiari meccanismi di navigazione.

Fornire chiari e coerenti meccanismi di navigazione -- informazione per l'orientamento, barre di navigazione, una mappa del sito, ecc. -- per aumentare le probabilita' che una persona trovi quello che sta cercando in un sito.

Chiari e coerenti meccanismi di navigazione sono importanti per persone con invalidita' cognitive o per i non vedenti, e giovano a tutti gli utenti.

[torna su]
Punti di controllo linea guida 13:

13.1 Identificare con chiarezza l'obiettivo di ogni collegamento. [Priorita' 2]. Un collegamento testuale dovrebbe essere abbastanza significativo da mantenere un senso se letto fuori contesto -- sia da solo che come parte di una sequenza di collegamenti. Un collegamento testuale dovrebbe anche essere sintetico. Per esempio, in HTML, scrivere "Informazione sulla versione 4.3" invece che "clicca qui". In aggiunta a un chiaro collegamento testuale, gli sviluppatori possono ulteriormente chiarire l'obiettivo di un collegamento con un titolo del collegamento con funzione informativa (per es., in HTML, l'attributo "title").

13.2 Fornire metadata per aggiungere informazione di tipo semantico alle pagine e ai siti. [Priorita' 2]. Per esempio, usare RDF per indicare l'autore di un documento, il tipo di contenuto, ecc. Nota. Alcuni interpreti HTML possono costruire strumenti di navigazione a partire dalle relazioni del documento descritte dall'elemento HTML LINK e dagli attributi "rel" o "rev" (per es., rel="prossimo", rel="precedente", rel="indice", ecc.).

13.3 Fornire informazione sulla configurazione generale di un sito (per es., una mappa oppure un indice del sito). [Priorita' 2]. Nel descrivere la configurazione di un sito, evidenziare e spiegare le caratteristiche di accessibilita' che sono disponibili.

13.4 Usare meccanismi di navigazione in modo coerente. [Priorita' 2].

13.5 Fornire barre di navigazione per evidenziare e dare accesso ai meccanismi di navigazione. [Priorita' 3].

13.6 Raggruppare i collegamenti correlati, identificare i gruppi (per gli interpreti) e, fino a quando gli interpreti non lo fanno, fornire un modo per saltare il gruppo. [Priorita' 3].

13.7 Se sono fornite funzionalita' di ricerca, rendere possibili diversi tipi di ricerca per differenti livelli di abilita' e per preferenze diverse. [Priorita' 3].

13.8 Posizionare l'informazione piu' significativa all'inizio delle intestazioni, dei paragrafi, delle liste, ecc. [Priorita' 3]. Nota. Questo e' comunemente chiamato "front-loading" ed e' di particolare aiuto per persone che accedono all'informazione con dispositivi seriali come i sintetizzatori della voce.

13.9 Fornire informazione sulle raccolte di documenti (cioe' documenti composti da piu' pagine). [Priorita' 3]. Per esempio, in HTML, specificare le raccolte di documenti con l'elemento LINK e con gli attributi "rel" e "rev". Un altro modo di creare una raccolta e' quello di costruire un archivio (per es. con le utility zip, tar e gzip, stuffit ecc.) delle diverse pagine. Nota. La crescita di prestazioni ottenuta con l'elaborazione offline puo' rendere la visualizzazione molto meno faticosa per persone disabili che abbiano una visualizzazione lenta.

13.10 Fornire un mezzo per saltare arte ASCII multilinea. [Priorita' 3]

[torna su]

Linea Guida 14: Assicurarsi che i documenti siano chiari e semplici.

Assicurarsi che i documenti siano chiari e semplici in modo che possano essere compresi piu' facilmente.

Una disposizione coerente della pagina, una grafica riconoscibile e un linguaggio facile da capire giovano a tutti gli utenti. In particolare essi aiutano persone con disabilita' cognitive o con difficolta' di lettura. (Tuttavia assicurarsi che le immagini abbiano equivalenti testuali per i non vedenti, gli ipovedenti, o per qualsiasi utente che non possa o abbia scelto di non visualizzare la grafica.) L'uso di un linguaggio chiaro e semplice promuove una comunicazione efficace. L'accesso all'informazione scritta puo' essere difficile per persone con disabilita' cognitive o dell'apprendimento. L'uso di un linguaggio chiaro e semplice giova anche alle persone la cui madrelingua e' diversa dalla vostra, comprese le persone che comunicano essenzialmente con il linguaggio dei segni.

[torna su]
Punti di controllo liean guida 14:

14.1 Usare il linguaggio piu' chiaro e semplice possibile che sia adatto al contenuto di un sito. [Priorita' 1].

14.2 Integrare il testo con presentazioni grafiche o uditive nei casi in cui esse possano facilitare la comprensione della pagina. [Priorita' 3].

14.3 Creare uno stile di presentazione coerente fra le pagine. [Priorita' 3].