*Linux Guide

Fare Web - Accessibilità Parte 3

*

Il 5 maggio 1999 è stata emanata la versione 1.0 delle linee guida per l'Accessibilità dei Contenuti Web (Web Content Accessibility Guidelines 1.0) che annuncia, nella sezione iniziale, quanto segue:

These guidelines explain how to make Web Content accessible to people with disabilities.
The guidelines are intended for all Web content developers (page authors and site designers) and for developers of authoring tools.
The primary goal of these guidelines is to promote accessibility.
However, following them will also make Web content more available to all users, whatever user agent they are using (e.g. desktop browser, voice browser, mobile phone, automobile-based personal computer, etc.) or constraints they may be operating under (e.g. noisy surrounding, under or over illuminated rooms, in a hands-free environment, etc). Following these guidelines will also help people find information on the Web more quickly. These guidelines do not discourage content developers from using images, video, etc., but rather explain how to make multimedia content more accessible to a wide audience.

La traduzione, se ce ne fosse il bisogno, dice:

Queste linee guida descrivono come ottenere il contenuto del web accessibile a persone con disabilità.
Le linee guida sono dedicate a tutti gli sviluppatori di contenuti web (autori di pagine e designers di siti) e a tutti gli sviluppatori di software per il web.
L'obiettivo principale di queste linee guida è promuovere l'accessibilità
Comunque, seguendo queste si potranno anche ottenere contenuti web più disponibili a tutti gli utenti, qualunque programma utente stiano usando (cioè browser per desktop, browser vocali, pc per auto, ecc.) o condizione nelle quali si trovino ad operare (cioè ambienti rumorosi, ambienti sotto o sovra illuminati, situazioni che richiedano le mani libere, ecc.). Seguendo queste linee guida, si aiuteranno anche le persone ad ottenere le informazioni in modo più rapido. Queste linee guida non scoraggiano gli sviluppatori all'uso di immagini, video, ecc., ma anzi espongono come realizzare contenuti multimediali più accessibili per una larga utenza.

Con la sola esposizione di queste poche righe, qualunque sviluppatore del web dovrebbe convincersi a realizzare pagine accessibili e modificare quelle già realizzate al fine di renderle accessibili.
Se così fosse passiamo quindi a esporre le linee guida rispettando i tre concetti principali detti Priorità.
Queste priorità alludono a tre condizioni in conseguenza delle quali il contenuto deve, dovrebbe o potrebbe essere accessibile.
Le linee guida sono divise per punti e ogni punto delle linee guida ha un livello di priorità assegnato dal Gruppo di Lavoro del WAI e basato sull'importanza del singolo punto rispetto all'accessibilità.

[ Priorità 1 ]
Lo sviluppatore web deve attenersi a questo punto. Diversamente per uno o più gruppi di persone sarà impossibile accedere alle informazioni contenute nel documento. Soddisfare questa direttiva è un requisito base per alcuni gruppi di persone per accedere ai documenti web.
[ Priorità 2 ]
Lo sviluppatore web dovrebbe attenersi a questo punto. Diversamente, uno o più gruppi di persone avrà difficoltà ad accedere alle informazioni contenute nel documento.
Soddisfare questo punto rimuoverà ostacoli significativi per l'accesso ai documenti.
[ Priorità 3 ]
Lo sviluppatore web potrebbe rivolgersi a questo punto. Diversamente, uno o più gruppi di persone potranno essere in qualche modo ostacolati all'accesso alle informazioni contenute nel documento. Soddisfare questo punto migliorerà l'accesso ai documenti web.

Alcuni punti che hanno una priorità specifica, potrebbero cambiare in alcune (segnalate) condizioni.
Nella descrizione dei vari punti, saranno inseriti dei box con esempi pratici).

Punti a Priorità 1 (tra parentesi l'indicizzazione del WAI)

Nei box di esempio, le stringhe di testo importanti e collegate al punto in discussione, sono evidenziate con un colore rosso e la sottolineatura.

# (1.1) Provvedere a inserire un testo equivalente per tutti gli elementi non testuali
Questi includono immagini, rappresentazioni grafiche del testo (simboli), regioni delle immagini mappate, animazioni (gif animate), applets, ASCII art, frames, scripts, bottoni, spaziatori, bottoni grafici, suoni, video.


<img src="immagine.jpg" alt="Descrizione dell'immagine" />


<img src="immagine.jpg" longdesc="Longdesc.htm" />


<applet code="applet.class" width="xxx" height="xxx" alt="Descrivi la Applet">
<param name="image" value="immagine.jpg">
<param name="ZoomLevel" value="x">
<param name="speed" value="xx">
</applet>

# (2.1) Assicurarsi che tutte le informazioni veicolate dal colore, lo siano veicolate anche senza, per esempio nel contesto o con marcatori.
Evitare di scrivere :
"... le frasi significative sono quelle evidenziate in verde..." in quanto i daltonici non potrebbero distinguere il colore verde. E' accessibile scrivere :
"... le frasi significative sono sottolineate..." per cui anche i daltonici possono capire la differenza.
Quando si vuole enfatizzare un frammento di testo e/o riprodurlo in grassetto, è bene usare i tags <em>enfatizzato</em> e <strong>grassetto</grassetto> al posto dei tags <i> e <b> perchè i lettori di schermo pronunceranno simili parole con toni diversi ed il non-vedente ne capirà la differenza, mentre la differenza grafica sarà nulla.
# (4.1) Identificare chiaramente i cambi di linguaggio nel testo del documento e in ogni testo equivalente.


<p>Ieri sono stata dal <span lang="fr">coiffeur</span></p>
<p><span lang="en">Windows</span> &egrave; un prodotto <acronym title="Microsoft"lang="en">MS</acronym></p>

Senza questa specificazione i lettori di schermo ed i browsers braille pronuncerebbero la parola straniera con la lingua di default rendendo il vocabolo incomprensibile.
# (6.1) Organizzare i documenti in modo che siano leggibili anche senza i CSS.
Per esempio, quando un documento HTML sia visualizzato senza i CSS associati, deve essere possibile leggere ugualmente il documento.
Questo perchè i browser desktop più datati, i lettori di schermo e i browser braille, nonché i supporti palmari, non sono adibiti alla inclusione dei fogli di stile od hanno un supporto non completo, il che rende la fruibilità delle pagine non ideale. Perciò una pagina male impostata diverrebbe totalmente inaccessibile ad utenti con queste tecnologie.
# (6.2) Assicurare che gli equivalenti dei contenuti dinamici siano aggiornati, quando il contenuto dinamico cambia.
Quando si inseriscono dati in una pagina potenzialmente inaccessibile (perché basata su scripts supportati non totalmente), si dovrebbe creare una corrispettiva pagina accessibile e con gli stessi contenuti. Questa seconda pagina deve essere aggiornata di pari passo a quella inaccessibile.
# (7.1)
Fino a quando i programmi utente permetteranno agli utenti di controllare lo sfarfallamento delle immagini e dello schermo, evitate di causare lo sfarfallamento dello schermo e nello schermo.
Molte immagini e script provocano lo sfarfallamento ed il lampeggiamento di elementi nello schermo o dello schermo intero. Questo può arrecare danni e fastidi molto seri in persone affette da problemi neurologici, fino a giungere a vere crisi epilettiche. Evitate queste situazioni di pericolo.
# (14.1) Usate un linguaggio chiaro e semplice, appropriato ai contenuti del sito.
Non esistono solo disabilità fisiche o neurologiche, ma anche disabilità di tipo culturale e cognitivo per cui molte persone non riescono a comprendere il significato di parole, modi di dire, sottintesi e citazioni. Per questi motivi è bene scrivere in un linguaggio semplice e rapidamente comprensibile al popolo della rete.
# (1.2) Prevedere un link testuale per ogni regione attiva di una mappa immagine lato server
Questo per permettere ai lettori di schermo di identificare precisamente l'area e consentire all'utente di utilizzare il collegamento.
# (9.1)
Prevedere una mappa immagine lato client, al posto di una lato server, eccetto quando le regioni non possano essere definite con una area geometrica adeguata
# (5.1) Per le tabelle di dati, identificare le righe e le colonne capitolo


<table border="1">
<caption>Tabella di esempio</caption>
<tr>
<td></td>
<th>Colonna 1 header</th>
<th>Colonna 2 header</th>
</tr>
<tr>
<th>Riga 1 header</th>
<td>Dati</td>
<td>Dati2</td>
</tr>
<tr>
<th>Riga 2 header</th>
<td>Dati 3</td>
<td>Dati 4</td>
<tr>
</table>

Questo accorgimento serve ai lettori di schermo per modificare il tono della pronuncia o il volume o la voce delle caselle capitolo e conferire quindi senso alla tabella di dati.
# (5.1)
Per le tabelle di dati che hanno due o più livelli logici di righe e colonne capitolo, usare un marcatore da associare alle celle dati e celle capitolo
# (12.1) Titolate ogni frame per facilitare la identificazione e la navigazione


<frameset rows="100,*">
<frame src="Framealto.htm" title="Frame alto" />
<frameset cols="100,*">
<frame src="Framesinistro.htm" title="Frame sinistro" />
<frame src="Framedestro.htm" title="Frame destro" />
</frameset>
<noframes>
<body>
<p>E' necessario un browser che supporti i frames</p>
</body>
</noframes>
</frameset>

Ogni singola area della pagina dovrà avere il titolo per l'identificazione :


<html>
<head>
<title>Frame alto</title>
</head>
<body></body>
</html>

ecc., ecc.
# (6.3) Assicurarsi che le pagine siano usabili quando gli scripts, le applets o altri oggetti programmatici siano disattivati, o non supportati.
Se questo non è possibile, prevedere le stesse informazioni contenute in questi oggetti, in una pagina accessibile alternativa.
Alcuni scripts contengono informazioni utili alla navigazione ed alla lettura di altre informazioni (Scroller testuali automatici, file swf , applet, slideshow DHTML). Se questi scripts non sono supportati o non sono abilitati, le informazioni vengono perdute e non sono sfruttabili. E' necessario produrre una pagina dove le stesse informazioni siano comunque sfruttabili e questa pagina deve essere accuratamente segnalata e aggiornata al pari degli scripts
# (1.3)
Fino a quando i programmi utente potranno leggere automaticamente il testo equivalente di un filmato, prevedere una descrizione audio delle informazioni video più importanti della presentazione multimediale.
Se nel filmato sono presenti immagini importanti alla compressione globale del messaggio video, e se queste immagini non sono commentate vocalmente, è necessario prevedere un commento vocale a queste parti non audio, ma determinanti per la comprensione dell'intero messaggio.
Tutto ciò per evitare il colmo di portare un non vedente a vedere un film muto!!! :-)
# (1.4)
Per ogni presentazione multimediale temporizzata (ad esempio un filmato od una animazione), sincronizzare le alternative equivalenti (testo esplicativo delle animazioni e/o delle didascalie) con la presentazione stessa.
# (11.4)
Se, malgrado il massimo impegno, non avete potuto creare una pagina accessibile, inserite un collegamento ad una pagina alternativa che sia accessibile e con le stesse informazioni ( o funzionalità ), e che sia aggiornata tanto spesso quanto quella inaccessibile.
Prosegui con le Priorità 2

<< Precedente | Indice | Successiva >>

Linux Guide | Torna in alto