Requisiti 2 e 3

Requisito 2

Enunciato: Non è consentito l’uso dei frame nella realizzazione di nuovi siti. In sede di prima applicazione, per i siti Web esistenti già realizzati con frame è consentito l’uso di HTML 4.01 o XHTML 1.0 con DTD frameset, ma con le seguenti avvertenze:

  • evitare di utilizzare, all’interno del linguaggio a marcatori con il quale la pagina è realizzata, elementi ed attributi per definirne le caratteristiche di presentazione della pagina (per esempio, caratteristiche dei caratteri del testo, colori del testo stesso e dello sfondo, ecc.), ricorrendo invece ai Fogli di Stile CSS (Cascading Style Sheets) per ottenere lo stesso effetto grafico;
  • fare in modo che ogni frame abbia un titolo significativo per facilitarne l’identificazione e la navigazione; se necessario, descrivere anche lo scopo dei frame e la loro relazione;
  • pianificare la transizione a XHTML almeno nella versione 1.0 con DTD Strict dell’intero sito dandone comunicazione alla Presidenza del Consiglio dei Ministri – Presidenza del Consiglio dei Ministri – Dipartimento per l’innovazione e le tecnologie e al Centro nazionale per l’informatica nella pubblica amministrazione.

Riferimenti WCAG 1.0: 12.1, 12.2

Riferimenti Section 508: 1194.22 (i)

Motivazione

L’impaginazione tramite frame ha la sua origine con le prime versioni di HTML ed è dovuta alla necessità, in alcuni casi, di dover organizzare i contenuti in modo da poter garantire la permanenza di visualizzazione di alcuni contenuti (ad esempio una serie di menu). I problemi che si incorrono con l’uso di tale tecnologia sono legati ai seguenti fattori:

  • problemi di accessibilità tramite tecnologie assistive. L’utente con lettore di schermo, se i frame non vengono identificati con chiarezza, incorrono in problemi di navigazione e devono “saltare” tra i vari frame rischiando di perdere l’orientamento nella navigazione;
  • problemi di accesso ai contenuti. Con l’uso di frame è possibile che un utente acceda direttamente ai contenuti di una pagina interna al frame (es: se proviene da un motore di ricerca) e pertanto non avrà possibilità di navigare il sito web, mancando di fatto i punti di riferimento contenuti in altri frame.

La normativa quindi richiede ai siti di nuova realizzazione di non utilizzare i frame in modo categorico: non è indicato, come in altri casi, di evitare ma non sono consentiti. I riferimenti alle WCAG 1.0 e le tecniche di verifica che andremo ad analizzare riguardano quindi esclusivamente la prima applicazione del requisito.

Implementazione

Come vedremo dall’analisi dei riferimenti delle WCAG 1.0, un frame è parte di un frameset, ossia un insieme di frame che per essere accessibili agli utenti con tecnologie assistive necessitano di:

  • chiare titolazioni;
  • descrizioni relative allo scopo dei frame;
  • possibilità di passare da un frame all’altro.

Non mi soffermo sull’implementazione di una struttura a frame in quanto la normativa non ne consente l’uso, ma riporto un esempio di codice relativo ad un frameset che sarà la nostra base di implementazione degli esempi di adeguamento dei frame in sede di prima applicazione.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="it" xml:lang="it">
<head>
<title>Esempio di frameset</html>
<meta http-equiv="Content-Type"
content="text/html; charset=ISO-8859-1" />
</head>
<frameset cols="20%, 80%">
<frame src="menu.html" />
<frame src="main.html" />
</frameset>
</html>

Riferimenti WCAG 1.0

Di seguito sono riportati i riferimenti ai punti di controllo delle WCAG 1.0 al fine di fornire allo sviluppatore le informazioni per implementare contenuti conformi al requisito.

Punto di controllo 12.1 (Priorità 1). Assegnare un titolo a ogni frame per facilitarne l’identificazione e la navigazione

Alcuni programmi utente non possono accedere a più frame contemporaneamente o possono essere configurati esclusivamente per visualizzare un solo frame: un esempio sono le applicazioni software di supporto per gli utenti non vedenti. Utilizzando l’attributo “title” per i frame è possibile fornire informazioni al visitatore sul contenuto di quella particolare pagina web, consentendo all’utente di selezionare il frame desiderato.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" lang="it" xml:lang="it">

<head>
<title>Esempio di frameset</html>
<meta http-equiv="Content-Type"
content="text/html; charset=ISO-8859-1" />
</head>

<frameset cols="20%, 80%" title="Esempio di frameset" >
<frame src="menu.html" title="Navigazione" />
<frame src="main.html" title="Pagina iniziale" />
</frameset>

<noframes>
<body>
<ul>
<li><a href="menu.html">Navigazione</a></li>
<li><a href="main.html">Pagina iniziale</a></li>
</ul>
</body>
</noframes>

</html>

Nell’esempio abbiamo riportato anche l’elemento <noframes> al fine di garantire l’accessibilità della pagina anche ai programmi utente che non supportano i frame, per rispettare il requisito 3.

Punto di controllo 12.2 (Priorità 2). Descrivere lo scopo dei frame e il modo in cui questi interagiscono se non è evidente solo tramite i titoli dei frame

Nel punto di controllo 12.1 abbiamo visto che utilizzando l’attributo title possiamo dare alcune informazioni sul contenuto dei frame. In alcuni casi però l’attributo title può non essere sufficiente per spiegare la struttura o lo scopo dell’elemento <frame> o dell’elemento di contenimento <frameset>. Poniamo il caso di una pagina con cinque frame: uno per la testata, uno a sinistra per la navigazione dei menu, uno centrale per i contenuti, uno a destra per le ultime notizie ed uno alla fine per la chiusura di pagina: come è possibile spiegarne la struttura tramite l’attributo title? Già in questo paragrafo per spiegare in modo rapido una struttura teorica ho utilizzato diverse righe di testo, che non avrei potuto utilizzare con l’attributo title. In questi casi è consigliabile utilizzare l’attributo longdesc per l’elemento frame al fine di rendere disponibile un collegamento ad un documento (pagina senza frame) che contiene una descrizione completa per una pagina con una struttura complessa di frame. Il nostro codice di pagina quindi cambierà nel modo seguente:

<frameset cols="20%, 80%" title="Esempio di frameset"
longdesc="descr-frameset.html" >
<frame src="menu.html" title="Navigazione" />
<frame src="main.html" title="Pagina iniziale"
longdesc="descr-main.html" />
</frameset>

Prima applicazione

È bene ribadire che i frame sono supportati dalle raccomandazioni W3C che comunque ne sconsiglia l’utilizzo ma la normativa consente l’uso in fase di prima applicazione con alcuni accorgimenti.

Innanzitutto il requisito richiede di non utilizzare all’interno dei frame delle pagine web contenenti elementi ed attributi presentazionali. Questo significa che utilizzando la DTD Frameset è possibile utilizzare pagine con DTD Transitional (in quanto la DTD Strict non prevede l’attributo “target” per i link) ma evitando elementi ed attributi di formattazione, come già abbiamo visto nel primo requisito. Si richiede sempre in sede di prima applicazione di rendere i frame chiaramente identificabili seguendo le indicazioni del paragrafo relativo ai punti di controllo 11.1 e 11.2 delle WCAG 1.0.

Verifica del requisito

Il valutatore, al fine di verificare l’applicazione del requisito dovrà utilizzare strumenti di supporto come la Barra dell’accessibilità per:

  • verificare che la DTD dichiarata sia conforme al requisito, ovvero per i siti esistenti utilizzo di DTD Frameset e DTD Transitional per i singoli frame;
  • verificare l’utilizzo di elementi ed attributi del linguaggio di marcatura utilizzati a scopo presentazionale;
  • verificare la presenza di titoli ed eventuali descrizioni per i frame.

L’esperto dovrà quindi controllare i testi degli attributi “title” e valutare se siano comprensibili e significativi per garantire informazioni. Per effettuare questa verifica, dovrà immaginare di trovarsi al telefono e di dover operare delle scelte (premi 1 per xxx, premi 2 per yyy): se i testi risulteranno comprensibili, allora il sito internet avrà superato il requisito 2.

Tramite la Barra dell’accessibilità è possibile utilizzare:

Validazione – W3C HTML Validator – Valida HTML (nuova finestra). Consente di inviare direttamente il documento alla validazione per verificare la correttezza delle grammatiche formali del frameset.

Struttura – Bordi dei frame. Evidenzia i bordi di ciascun elemento frame sulla pagina corrente (Punto di controllo 12.1).

Name / Title dei frame. Mostra (in una nuova finestra) una lista delle pagine contenute nel frameset insieme ai rispettivi attributi “name” ed al contenuto dell’attributo “title” (Punto di controllo 12.1 e 12.2).

In caso di presenza di frameset, l’esperto dovrà quindi identificare i singoli frame verificandone la conformità rispetto alla DTD dichiarata (solitamente DTD Transitional). Al termine della verifica dei suddetti punti l’esperto potrà quindi dichiarare la conformità al requisito.

Requisito 3

Enunciato: Fornire una alternativa testuale equivalente per ogni oggetto non di testo presente in una pagina e garantire che quando il contenuto non testuale di un oggetto cambia dinamicamente vengano aggiornati anche i relativi contenuti equivalenti predisposti; l’alternativa testuale equivalente di un oggetto non testuale deve essere commisurata alla funzione esercitata dall’oggetto originale nello specifico contesto.

Riferimenti WCAG 1.0: 1.1, 6.2

Riferimenti Section 508: 1194.22 (a)

Motivazione

Questo requisito dovrà assolutamente essere soddisfatto se desideriamo che il nostro sito possa essere considerato accessibile ai livelli minimi. Molti utenti utilizzano strumenti di navigazione che si basano sui soli contenuti testuali (esempio: i lettori di schermo per i non vedenti) è quindi necessario fornire equivalenti testuali per immagini, rappresentazioni grafiche di testo (compresi i simboli), zone sensibili delle immagini (mappe immagine), animazioni (per esempio, GIF animate), applet e oggetti, ASCII Art, frame, script, immagini usate come richiamo per elenchi, spaziatori, pulsanti grafici, suoni (azionati con o senza l’intervento dell’utente), file di solo audio, tracce audio di video e video. Allo stesso modo le informazioni che vengono rese disponibili in tempo reale, come le ultime notizie all’interno dei siti di informazione, sono chiamate “contenuto dinamico”, ossia una tipologia di contenuto che può essere modificata.

In un sito di informazione, le ultime notizie solitamente scorrono in forma sintetica all’interno di applet Java e al clic del mouse viene aperta una nuova finestra contenente la notizia completa: i visitatori con problemi di mobilità, oppure gli utenti che non dispongono di Java non potranno accedere, o accederanno con difficoltà, ai contenuti, così come gli utenti con disabilità visive. È quindi necessario fornire una versione alternativa, in HTML, che consenta l’accesso ai contenuti a queste categorie di utenti, nascondendo questa versione a chi invece dispone delle tecnologie necessarie per la normale visualizzazione della pagina.

Implementazione

Il requisito chiede di garantire a chiunque di poter accedere a informazioni relative ad immagini ed oggetti in formato testuale. Lo sviluppatore dovrà quindi seguire una serie di tecniche di implementazione che si ispirano alle WCAG 1.0 al fine di garantire l’accesso ai contenuti testuali equivalenti. La mancata accessibilità dovuta agli elementi non testuali è uno dei problemi maggiori riscontrati nei siti web attuali e pertanto, se dobbiamo dare un peso al requisito, il requisito 3 risulta essere tra i più importanti per gli utenti non vedenti – ribadendo che comunque per le pubbliche amministrazioni è fatto obbligo rispettare tutti i 22 requisiti nello sviluppo di nuovi siti internet.

Riferimenti WCAG 1.0

Di seguito sono riportati i riferimenti ai punti di controllo delle WCAG 1.0 al fine di fornire allo sviluppatore le informazioni per implementare contenuti conformi al requisito.

Punto di controllo 1.1 (Priorità 1). Fornire un equivalente testuale per ogni elemento non di testo

Come è stato chiaramente indicato nella motivazione di applicazione del requisito, è necessario garantire un equivalente testuale per una serie di contenuti che andremo ad analizzare qui di seguito.

Immagini

Riportiamo un esempio d’uso dell’attributo alt relativo a un’immagine. Il testo alt è destinato a fornire un testo alternativo, da usare principalmente quando l’immagine non viene visualizzata. L’errore più comune consiste nell’offrire una descrizione testuale dell’immagine senza valutare quale fosse la sua funzione nella pagina, con risultati incongrui o, in alcuni casi, assurdi. Talvolta questa scelta potrebbe sembrare la più opportuna, ma nella pratica molto spesso è quella sbagliata.

Un esempio di utilizzo dell’attributo alt è il seguente:

<img src="grafico.jpg" alt="Grafico vendite 2004" />

In questo caso un testo alternativo “Grafico vendite 2004” non sarà sufficiente a fornire informazioni equivalenti ad un utente non vedente e sarà necessario fornire una descrizione più completa del contenuto dell’immagine. Si ricorrerà allora all’attributo longdesc, che permette di accedere a una descrizione estesa dell’immagine specificando l’URI del documento che contiene tale descrizione.

Se nella pagina sono presenti diverse immagini e ciascuna necessita di una descrizione estesa di norma si creano file diversi, oppure è lecito creare un unico file contenente i puntatori che consentono di raggiungere direttamente la descrizione richiesta. I sistemi CMS (Content Management System) più recenti generano dinamicamente i documenti per l’attributo longdesc, ove richiesto.

<img src="grafico.jpg" alt="Grafico Vendite 2004"
longdesc="grafico.htm" />

Da HTML 4.0x l’attributo “alt” per le immagini è obbligatorio: la mancanza di tale attributo non consentirà di superare la validazione formale della pagina (requisito 1). Anche se le immagini sono esclusivamente a scopo decorativo è comunque necessario inserire l’attributo alt, senza valorizzarlo. Un lettore vocale leggerebbe descrizioni non contestualizzate, evitate quindi di usare codice simile al seguente in quanto l’utente con lettore di schermo per ogni voce di testo otterrà la lettura di “Pallino”.

<p>
<img src="pallino.jpg" alt="Pallino" /> Testo 1<br />
<img src="pallino.jpg" alt="Pallino" /> Testo 2<br />
<img src="pallino.jpg" alt="Pallino" /> Testo 3
</p>

Mappe immagine

Le mappe immagine sono un caso speciale di questa categoria. In alcune situazioni, le mappe immagine svolgono funzioni non replicabili con altri tipi di oggetti (per esempio, nel caso delle cartine geografiche usate come strumento di navigazione), ma possono svolgere anche altre funzionalità, come un indice alfabetico o una casella di ricerca, che possono risultare utili a tutti.

Non bisognerebbe quindi tralasciare la necessità di inserire gli equivalenti testuali in quanto si renderebbe difficile la navigazione agli utenti non vedenti che utilizzano dei lettori di schermo. Anche l’elemento <area> supporta il testo alt, che può essere utilizzato per realizzare menu in modalità testuale (come con l’attributo alt dell’elemento <img>). Secondo le raccomandazioni W3C HTML 4.0 e successive, questo attributo è obbligatorio e lo è a buon motivo, dal momento che può provvedere una valida alternativa per gli utenti con browser testuali.

Si riporta a titolo di esempio parte del codice di una mappa dell’Italia suddivisa per regioni, estraendo solo alcuni dati di tipo “rect” e “poly” (si tratta di una mappa lato client):

<img alt="Italia" src="italia.gif" usemap="#csmap" />
<map id="csmap" name="csmap">
<area shape="rect" alt="Sardegna" coords="114,238,160,31"
href="sardegna.htm" />
<area shape="poly" alt="Sicilia" coords="304,330,292,354"
href="sicilia.htm" />
<area shape="poly" alt="Calabria" coords="304,283,319,12"
href="calabria.htm" />
</map>

L’esempio di mappa rispetta la specifica XHTML 1.0 Strict. XHTML 1.1 ha cambiato la gestione delle immagini mappate lato client, in quanto ha eliminato l’utilizzo degli attributi “name” sostituendoli con gli attributi “id”, ridefinendo inoltre l’uso dell’attributo “usemap” trasformandolo da tipo URI a tipo IDREF. Pertanto il precedente esempio diventa:

<img alt="Italia" src="italia.gif" usemap="csmap" />
<map id="csmap">
<area shape="rect" alt="Sardegna" coords="114,238,160,31"
href="sardegna.htm" />
<area shape="poly" alt="Sicilia" coords="304,330,292,354"
href="sicilia.htm" />
<area shape="poly" alt="Calabria" coords="304,283,319,12"
href="calabria.htm" />
</map>

Da alcuni test effettuati, attualmente il supporto dei browser per questo codice è pressoché nullo: pertanto, in caso di utilizzo di pagine in formato XHTML 1.1 si consiglia – per le pagine che contengono mappe – di utilizzare XHTML 1.0 Strict.

Nel caso si utilizzino delle mappe immagine lato server al fine di rispettare il requisito 3 è necessario fornire testi alternativi per l’immagine (magari correlati di un elemento longdesc per le mappe più complicate seguire alcuni accorgimenti previsti dal Requisito 8.

Applet e oggetti

Quando si utilizzano oggetti, come le animazioni Macromedia Flash, è necessario predisporre una versione equivalente testuale per tutti gli utenti che non posseggono i plug-in necessari alla loro visualizzazione o per gli utenti che a causa di disabilità non possono interagire con tali contenuti. È bene ricordare che il W3C promuove l’utilizzo dell’elemento <object>, mentre considera errato l’uso dell’elemento proprietario <embed> (necessario per compatibilità con vecchie versioni di Netscape) e deprecato l’uso di <applet>. Nell’esempio seguente ci occupiamo dell’inserimento di una animazione Macromedia Flash in una pagina Web.

Il codice standard predefinito da Macromedia per le animazioni Flash è il seguente.

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase=http://download.macromedia.com
/pub/shockwave/cabs/flash/swflash.cab#version=6,0,0,0
width="400" height="300" id="movie" align="">
<param name="movie" value="movie.swf">
<embed src="movie.swf" quality="high" width="400"
height="300" name="movie" align=""
type="application/x-shockwave-flash"
pluginspage="http://www.macromedia.com/go/getflashplayer">
</object>

Per rendere accessibile questo contenuto è necessario modificarlo come indicato di seguito, che consente di presentare agli utenti una versione alternativa (si auspica equivalente) dei contenuti dell’animazione Flash nonché di visualizzare l’oggetto su diversi browser. In mancanza del necessario plug-in, sarà visualizzata un’immagine allo scopo di indicare tale situazione, e verranno fornite le stesse opzioni contenute nell’animazione Flash in formato testuale.

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
width="400" height="300">
<param name="movie" value="movie.swf" />
<img src="noflash.gif" alt="Macromedia Flash non disponibile" />
<ul title="opzioni alternative">
<li><a href="pagina1.htm">Pagina 1</a>
<li><a href="pagina2.htm">Pagina 2</a>
</ul>
<!--[if !IE]> <-->
<object type="application/x-shockwave-flash" data="movie.swf"
width="400" height="300">
<param name="movie" value="movie.swf" />
<img src="noflash.gif"
alt="Macromedia Flash non disponibile" />
<ul title="opzioni alternative">
<li><a href="pagina1.htm">Pagina 1</a>
<li><a href="pagina2.htm">Pagina 2</a>
</ul>
</object>
<!--> <![endif]-->
</object>

Frame

Per i frame è consigliato consultare gli esempi della sezione WCAG 1.0 per il requisito 2 in cui chiaramente si incentiva l’uso dell’attributo title per consentirne l’identificazione. In questo caso, è consigliabile utilizzare pure l’elemento <noframes> al fine di garantire un equivalente testuale agli utenti che non hanno accesso ai frame.

Pulsanti

Per ottenere una grafica accattivante, frequentemente si utilizzano le immagini in sostituzione dell’elemento <input type=”button” /> dei moduli (form). Anche tali elementi, al fine di essere fruibili anche da utenti che utilizzano sistemi di navigazione testuale (lettori di schermo), necessitano dell’attributo alt:

<form action="submit" method="post">
<input type="image" src="cerca.gif" id="cerca" alt="Cerca" />
</form>

In mancanza di tale attributo un utente non vedente non potrà sapere di che pulsante si tratti. È necessario che il testo alternativo del pulsante corrisponda, se presente, al testo contenuto nell’immagine oppure in mancanza dello stesso alla funzionalità prevista per l’immagine. Per esempio, l’immagine cerca.gif indicata nell’esempio potrebbe essere una lente d’ingrandimento ed un testo alternativo “lente d’ingrandimento” non sarebbe funzionale all’immagine.

Script

Quando si parla di script, comunemente ci si riferisce a JavaScript. È bene precisare immediatamente che JavaScript non è Java, con cui frequentemente lo si confonde: Java è stato creato da Sun Microsystems ed è un linguaggio di programmazione semicompilato, con cui è possibile creare applicazioni autonome mentre JavaScript (sviluppato da Netscape Corporation), è un linguaggio di programmazione interpretato, ovvero per poter funzionare deve esser contenuto in una pagina Web ed essere eseguito all’interno di un browser in grado di interpretarlo. Un programma Java può essere incluso in una pagina Web come oggetto, mentre gli script in JavaScript dipendono per il loro funzionamento dal client che li ospita. Quando il browser rileva codice JavaScript all’interno di un documento HTML, lo esegue e ne visualizza gli eventuali risultati sulla pagina Web. Sul computer che esegue il browser deve quindi essere attivo un interprete JavaScript, in grado di comprendere le istruzioni e di eseguirle. HTML può creare solamente pagine statiche, caratterizzate da una limitata interazione con l’utente. HTML non è in grado di “agire”: non può eseguire calcoli matematici, lavorare con le variabili o visualizzare dinamicamente un qualsiasi contenuto. JavaScript rende “reattiva” la pagina: è un linguaggio di programmazione, e quindi permette agli sviluppatori di implementare nelle pagine piccoli programmi, che saranno in grado di svolgere azioni semplici come modificare un elemento grafico quando il puntatore del mouse vi passa sopra ma anche di risolvere complesse formule e procedimenti matematici. È necessario tenere bene a mente che non tutti gli utenti possono fruire di queste possibilità di interazione e predisporre quindi una opportuna sezione <noscript> per rendere disponibile un contenuto alternativo. Nell’esempio seguente, lo script richiama un file esterno (sceltasiti.js) che consente di raggiungere un sito selezionandolo in un elenco a discesa predefinito: gli utenti che non possono utilizzare tale funzionalità, otterranno lo stesso elenco nella sezione <noscript>, che li presenterà come normali collegamenti invece che come voci di un elenco a discesa.

<script type="text/javascript" src="sceltasiti.js">
</script>


<noscript>
<ul>
<li><a href="/">Pagina Iniziale</a></li>
<li><a href="http://www.canale5.com/">Canale 5</a></li>
<li><a href="http://www.italia1.it/">Italia 1</a></li>
</ul>
</noscript>

Va comunque posta l’attenzione sul fatto che <noscript> è utilizzato dai programmi utente che non supportano gli script o con gli script disabilitati: un utente con tecnologia assistiva potrebbe non fruire di questo contenuto equivalente e, trovandosi davanti ad uno script inaccessibile (ovvero non rispettoso dei Requisiti 15, 16 e 17) potrebbe non poter interagire con il contenuto.

Arte ASCII ed emoticon

Sul Web è facile incontrare immagini generate con caratteri alfabetici. Vengono chiamate Arte ASCII e sono un residuo storico dei tempi delle BBS, quando i computer erano lenti e con scarse capacità grafiche.

Provate a leggere l’immagine seguente con un sistema di sintesi vocale: il risultato sarà assolutamente incomprensibile.

     .-._.-.
          ( O     O )
          /   . .   \
         .`._______.'.
        /(           )\
      _/  \   \    /  /  \ _
   .~   `  \   \  /  /  ‘   ~.
  {     -.   \   V  /   .-    }
_ _`.    \   |  |  |  /    .'_ _
>_       _}  |  |  | { _       _<
 /. - ~ ,_-'  .^.  `-_, ~ - .\
         ‘-'|/   \ |`-`

Sarà necessario fornire un testo equivalente e la possibilità di saltare la lettura dell’Arte ASCII:

<p> <a href="#ascii-art">salta la ASCII art</a> </p>

            .-._.-.
          ( O     O )
          /   . .   \
         .`._______.'.
        /(           )\
      _/  \   \    /  /  \ _
   .~   `  \   \  /  /  ‘   ~.
  {     -.   \   V  /   .-    }
_ _`.    \   |  |  |  /    .'_ _
>_       _}  |  |  | { _       _<
 /. - ~ ,_-'  .^.  `-_, ~ - .\
         ‘-'|/   \ |`-`

<p> <a name="ascii-art">Immagine di una rana<a> </p>

L’Arte ASCII resterà visibile agli utenti normovedenti e allo stesso tempo sarà possibile informare gli utenti non vedenti o con disabilità di tipo cognitivo del contenuto dell’immagine stessa grazie al testo nel link di destinazione del “salto”.

Le emoticons, vale a dire le oramai famose faccine che rappresentano le emozioni “digitali”, fanno parte della famiglia delle ASCII Art. Il RNIB (Royal National Institute for Blind) ne sconsiglia l’uso <http://www.rnib.org.uk/xpedio/groups/public/documents/publicwebsite/public_asciiart.hcsp> mentre il W3C consiglia di utilizzare l’elemento <abbr>:

<p><abbr title="sorriso">:-)</abbr>

Nel caso invece si stia agendo in ambienti come le chat, dove le emoticons sono trasformate automaticamente in immagini, è necessario che l’attributo alt fornisca una chiara spiegazione equivalente e non la semplice conversione in formato testo dello smile:

<img src="sorriso.gif" alt="Faccina che sorride" />

Punto di controllo 6.2 (Priorità 1). Garantire che all’aggiornamento dei contenuti dinamici vengano aggiornati anche i contenuti equivalenti

Come abbiamo avuto modo di indicare nella motivazione del requisito, in presenza di contenuti dinamici è necessario fornire una versione alternativa, (preferibilmente in formato HTML o testuale) che consenta l’accesso ai contenuti a queste categorie di utenti, nascondendo questa versione a chi invece dispone delle tecnologie necessarie per la normale visualizzazione della pagina. Utilizzando l’elemento <object>, se il browser non supporta quel particolare oggetto sarà reso disponibile il contenuto alternativo, a cascata. Queste versioni dovrebbero restare nascoste per utenti che invece dispongono delle tecnologie per la corretta visualizzazione dei contenuti. Utilizzando l’elemento <object> nel caso non sia disponibile il supporto a tale oggetto sarà reso disponibile il contenuto alternativo, il tutto configurabile a cascata.

Per dimostrare le potenzialità dell’elemento <object> per l’accessibilità, nell’esempio seguente è ipotizzato l’uso di una applet java per la visualizzazione delle ultime novità.

<object classid="java:News.class" width="468" height="60">
<object data="news.mpeg" type="video/mpeg">
<ul>
<li><a href="news1.html">Notizia 1</a></li>
<li><a href="news2.html">Notizia 2</a></li>
<li><a href="news3.html">Notizia 3</a></li>
</ul>
</object>
</object>

Innanzitutto come è facile notare si è utilizzato l’elemento <object> poiché l’elemento <applet> è stato deprecato. Se il visitatore del sito non ha la possibilità di caricare l’applet, sarà caricato un filmato .mpeg alternativo che presenterà le news e consentirà di accedere alle pagine relative. Se l’utente non ha neppure la possibilità di visualizzare i filmati, allora sarà presentata una lista di link (collegamenti), che potranno essere “vestiti” tramite CSS facendo presente che i contenuti dovranno essere fruibili e comprensibili anche senza l’uso dei fogli di stile (requisito 11).

Verifica del requisito

Il valutatore, al fine di verificare l’applicazione del requisito dovrà utilizzare strumenti di supporto come la barra dell’accessibilità per:

  • verificare la presenza di testi alternativi per le immagini (comprese le mappe immagine ed i pulsanti);
  • verificare la presenza di contenuti equivalenti per script ed oggetti;
  • verificare che i contenuti equivalenti di contenuti dinamici siano aggiornati con la stessa frequenza dei contenuti principali.

L’esperto dovrà quindi controllare i testi degli attributi “alt” e valutare se siano comprensibili e significativi per garantire informazioni. Per effettuare questa verifica potrà utilizzare la barra dell’accessibilità abilitando i testi alternativi in sostituzione delle immagini: se i testi risulteranno comprensibili, allora il sito internet avrà superato il requisito 3.

Tramite la Barra dell’accessibilità è possibile utilizzare:

Immagini

Elenco delle immagini utilizzate. Visualizza (in una nuova finestra) una lista delle immagini insieme al corrispondente elemento <img> (Punto di controllo 1.1).

Alterna immagini/testi alternativi. Rimpiazza tutti gli elementi <img> sulla pagina corrente con il contenuto dei corrispondenti attributi alt. Se un’immagine è priva di attributo alt verrà rimpiazzata con il testo NoAlt! (Punto di controllo 1.1).

Visualizza le immagini. Visualizza il contenuto dell’elemento <img> a fianco a ciascuna immagine (insieme all’attributo alt o la scritta NoAlt! se l’immagine ne è priva) e crea un margine rosso intorno a ciascuna immagine per renderla chiaramente identificabile (Punto di controllo 1.1).

Visualizza le mappe immagine. Mostra gli elementi <map> e il contenuto delle aree sensibili suddividendo le mappe immagine lato server dalle mappe immagine lato client (Punto di controllo 1.1).

Struttura

Name / Title dei frame. Elenca (in una nuova finestra) una lista delle pagine contenute nel frameset insieme ai rispettivi attributi “name” ed al contenuto dell’attributo “title” (Punto di controllo 1.1).

Javascript. Elenca su nuova finestra i javascript presenti nella pagina. L’esperto dovrà quindi verificare la disponibilità di elementi <noscript> (Punto di controllo 1.1).

Informazioni documento

Elenco dei frame. Visualizza (in una nuova finestra) un elenco degli URL delle pagine inserite nei frame, con il nome dei rispettivi elementi <frame>, contenuti nella pagina corrente (Punto di controllo 1.1).

Identifica Applet / Script. Visualizza l’elenco delle applet e degli script presenti all’interno della pagina (Punto di controllo 1.1). L’esperto dovrà quindi verificare la presenza di contenuti equivalenti per tali oggetti (Punto di controllo 6.2).

Al termine della verifica dei suddetti punti l’esperto potrà quindi dichiarare la conformità al requisito.

Potrebbero interessarti anche i seguenti articoli

  • Requisito 1 – Prima applicazione e verificaRequisito 1 – Prima applicazione e verifica Prima applicazione In caso di prima applicazione nel caso si utilizzino DTD di tipo Transitional l'enunciato richiede di evitare sia l'uso di attributi di […]
  • Requisito 1 – Enunciato, motivazione ed implementazioneRequisito 1 – Enunciato, motivazione ed implementazione Enunciato: Realizzare le pagine e gli oggetti al loro interno utilizzando tecnologie definite da grammatiche formali pubblicate nelle versioni più recenti […]
  • Requisiti 11, 12, 13, 14Requisiti 11, 12, 13, 14 Requisito 11 Enunciato: Usare i fogli di stile per controllare la presentazione dei contenuti e organizzare le pagine in modo che possano essere lette anche quando i […]
  • Requisiti 15, 16, 17Requisiti 15, 16, 17 Requisito 15 Enunciato: Garantire che le pagine siano utilizzabili quando script, applet, o altri oggetti di programmazione sono disabilitati oppure non supportati; […]
  • Requisiti 19, 20, 21, 22Requisiti 19, 20, 21, 22 Requisito 19 Enunciato: Rendere chiara la destinazione di ciascun collegamento ipertestuale (link) con testi significativi anche se letti indipendentemente dal proprio […]
Condividi:

Informazioni sull'autore

Roberto Castaldo
Roberto Castaldo
Sono nato e vivo a Napoli, ed opero professionalmente nel mondo dell'informatica da più di vent'anni. In realtà l'informatica, insieme alla musica e ad altre poche cose, è stato da sempre un mio chiodo fisso, e la buona sorte mi ha aiutato a trasformarlo in un mestiere. Sin dalle mie primissime esperienze lavorative - insegnavo dattilografia ed i primi rudimenti di informatica in una scuola privata - mi sono trovato a mio agio nel settore della formazione e della divulgazione, certamente aiutato dai miei studi classici. Nel 1987 ho iniziato la mia attività come insegnante d'informatica in un Istituto Professionale Statale - per circa due anni sono stato il più giovane insegnante di ruolo d'Italia. Ho avuto svariate esperienze anche nel settore privato come sviluppatore (TPascal - lo ricordate? - VB, ASP e, più di recente VB.NET ed ASP.NET), ma soprattutto come docente e come divulgatore. Ho effettuato attività di formazione presso le più grandi realtà imprenditoriali italiane (IBM, Omnitel, Telecom Italia, TIM, Unicredito, Ekip, BNL, SSGRR), ma anche all'estero in qualità di docente e/o progettista di percorsi formativi; gli argomenti spaziano dal mondo Office fino al multimedia ed alla programmazione avanzata ASP ed ASP.NET. Ho collaborato con l'Istituto Italiano per gli Studi Filosofici di Napoli, ho redatto articoli/tutorial per un'importante rivista informatica (Win98 Magazine), ed ho partecipato allo sviluppo di CD-Rom Multimediali (IBM, Selfin, BNL) curando personalmente la registrazione dei commenti audio ed il montaggio delle musiche (CoolEdit), l'eventuale connessione a database remoti, l'assemblaggio degli elementi testuali, grafici e multimediali (Director 8) fino alla creazione del master definitivo. Negli anni 1998-2000 ho collaborato con la Gazzetta dello Sport Online curando, in occasione dei più importanti avvenimenti sportivi (Mondiali ed Europei di calcio, Giro d'Italia, Campionato di Serie A) le pagine contenenti la traduzione in inglese e francese degli articoli in italiano. Il mio compito consisteva nell'inviare ai miei traduttori la cronaca in italiano, riceverne la traduzione, creare le pagine inglesi e francesi del sito www.gazzetta.it e pubblicarle sul server, il tutto entro 90 minuti dalla fine dell'evento. Nel frattempo, mi avvicinavo in maniera sempre più approfondita alle problematiche legate all'accessibilità di siti web, progettando percorsi di formazione ad hoc, ed aderendo entusiasticamente al progetto webaccessibile.org. Sono stato per diversi mesi membro del XML Protocol Working Group del W3C, ed attualmente partecipo ai lavoro del WAI Web Content Accessibility Guidelines (WCAG) Working Group e del E&O Education ad Outreach Working Group.

Commenti

È presente 1 commento:

  1. […] lo stesso per le mappe, oggetti, pulsanti input, etc (vedi approfondimento). Scarica il pdf di questo articolo Taggato con :Accessibilità, tag alt Share: function […]

Rispondi

Link e informazioni