Login
Cerca all'interno di JavaPortal
Help
Home Page Documentazione Forum Progetti Partner Pubblica!
Documentazione > Tutorial > Creare un sito accessibile
Modifica Impostazioni
Hide
Best Practices
EJB
Frameworks
Howto
J2EE
J2ME and Wireless
J2SE
JSP e Servlet
Java Application Server
Java IDE/Tools
Java Media
Java Security
Java Sys Admin
Java e XML
Java e SQL
OpenSource Java
Patterns
Repository
Tesi
UML
Web Services
Slide
White Paper di jws.it
project management
Eventi
Groovy

Hai una tesi in Java?
Tesine preparate
per esami?
Pubblica tutto su
JavaPortal!

Scrivi al nostro staff


Promozione K-Tech per il Javaday


Aristotele
Lo scopo del lavoro è quello di guadagnarsi il tempo libero


Guida alle JSP – Lez 1: Introduzione a JSP


Rss Feed
Home Page
Articoli
News
Forum
Classi

  Visualizza Commenti (0) Aggiungi Commento    
Add to Shortcuts
 
Vota l'articolo
Creare un sito accessibile
By Francesca Fusco
4 agosto 2008
Valutazione Acquisita: 40

  Creare un sito accessibile
Program Un sito accessibile è realizzato in XHTML Strict
Program Evitare vincoli di presentazione e tag
Program Aspetti da considerare per la creazioni di pagine accessibili
Program Valutare l’accessibilità di un sito durante lo sviluppo
Program Verificare l’accessibilità di un sito
Program Fonti

La creazione di un sito accessibile non riguarda solo i grafici o i web designer.

L’accessibilità dovrebbe essere presa in considerazione già al momento della scelta della tecnologia con cui si svilupperà il sito web o portale. La conoscenza approfondita delle diverse tecnologie e delle linee guida definite nel Decreto Ministeriale 8 luglio 2005 eviterà di dover ripetere due volte il lavoro o di dover cercare soluzioni di fortuna per sistemare il layout grafico.

È importante che lo sviluppatore, soprattutto quando si occupa della parte di presentation o lavora ad elementi che generano un layout grafico, sappia di cosa si parla quando ci si riferisce all’accessibilità. Spesso non è così.

Ormai in rete si trovano molte indicazioni per la creazione di siti accessibili. Questo articolo non vuole essere una guida sull’accessibilità. E’ più un punto di partenza per l’approfondimento di aspetti che interessano gli sviluppatori.



Un sito accessibile è realizzato in XHTML Strict top

La legge Stanca prevedeva la possibilità di utilizzare l’HTML Strict, invece  dell’XHTML Strict, per i siti già esistenti. Ma, a quattro anni dalla approvazione della legge, ci si auspica che tutti i siti siano stati rifatti.

L’XHTML ha una rigidità sintattica sconosciuta all'HTML. Questo consente la compatibilità con tutti i dispositivi di visualizzazione.

L’XHTML possiede solo alcuni tag dell'HTML di cui ne ridefinisce le regole sintattiche alla luce dell'XML. La scelta dell’XHTML è dovuta al fatto che non prevede tag di presentazione utilizzati invece dall’HTML, rendendo più facile la separazione dei contenuti dal layout grafico. Inoltre consente l’utilizzo di programmi utente XML tipo mathML – applicazione per la descrizione di formule matematiche; al momento non sono ancora supportati da Internet Explorer, ma presto lo saranno; sarà quindi possibile la diffusione del loro utilizzo.

Le nostre pagine web devono iniziare con la dichiarazione di XML e con il doctype che specifica l’utilizzo di XHTML Strict:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">

Il layout, anche quando generato dinamicamente, deve essere prodotto in XHTML Strict corretto.
Il primo problema che si trova ad affrontare uno sviluppatore web è che la tecnologia utilizzata potrebbe non generare codice XHTML Strict corretto.

Struts ad esempio produce codice XHTML corretto quando si utilizza il tag <html:xhtml> ma con delle eccezioni! Un errore che compie è che assegna lo stesso id a tutti i bottoni di una form che fanno riferimento alla stessa Action, mentre l’XHTML non prevede id duplicati all’interno della stessa pagina. Per ovviare a questo inconveniente si utilizzi la DispatchAction o la MappingDispatchAction anziché la Action. 



Evitare vincoli di presentazione e tag top

Le linee guida per la realizzazione dell’accessibilità sono redatte per permettere ai browser vocali di accedere a tutte le informazioni della pagina e renderla visibile con ogni dispositivo, qualunque sia la grandezza del monitor utilizzato o qualunque sia la velocità delle rete sulla quale stiamo navigando. Quindi se vogliamo ottenere pagine ad alta accessibilità dobbiamo evitare qualsiasi vincolo di presentazione e ogni tag che appesantisca la pagina. In pratica questo si traduce in:

  • separare i tag di presentazione dal codice (utilizzare i css per il layout grafico): usare i fogli di stile per controllare l'impaginazione e la presentazione. Non utilizzare comandi per il layout grafico all’interno dei tag e organizzare i documenti in modo che il loro contenuto possa essere consultato anche senza i fogli di stile associati (ad esempio utilizzare h1 h2 correttamente per dare risalto ai titoli e sottotitoli). Per lo sviluppatore si traduce in: nessun tag di presentazione nel codice generato. Prevedere l’attributo class=”nomeStile” all’interno del tag per assegnare un class definito nel css;

  • progettare pagine liquide, i cui contenuti siano in grado di espandersi e di contrarsi a seconda dell'ampiezza della finestra che li contiene senza sovrapporsi. Ciò si ottiene non bloccando le altezze e le larghezze dei box a grandezze fisse, ma usando misure relative (em e percentuale). Non utilizzare immagini grafiche contenenti scritte per convogliare informazioni testuali, ma usare testo.

  • evitare l’utilizzo di tabelle per l’impaginazione dei contenuti nella pagina.Potete visualizzare un esempio di pagina con layout organizzato su 2 colonne con layout grafico separato dal codice.


Per chi non ha molta dimestichezza con i CSS suggerisco la lettura di Guida Layout dei siti con i CSS  di html.it .



Aspetti da considerare per la creazioni di pagine accessibili top

 

punto 1)

Tutte le funzionalità rese disponibili utilizzando il javascript devono essere disponibili anche nel caso di assenza del javascript. Un esempio è il riempimento delle combo a cascata. Immaginate il caricamento delle province dopo aver selezionato una regione. Si può pensare di passare alla pagina web l’elenco di tutte le province e far gestire al javascript il filtro perché la combo delle province venga popolata solo dalle province appartenenti alla regione. Nel momento in cui javascript non è disponibile si deve prevedere un pulsante per ricaricare la combo lato server (utilizzando il tag <noscript>).

<select name="Regione" onChange="popolaProvincia(this.value)">
    <option value="12">Lazio</option>
    <option value="13">Marche</option>
    <option value="14">Molise</option>
</select>
<noscript><input type="submit" value="Popola Provincia"/></noscript><br/><br/>
<select name="Province" >
</select>

esempio combo

Il pulsante “Popola Provincia” comparirà nel caso in cui il browser non supporti gli script o siano stati disattivati dall’utente. 

punto 2)
Evitare che il contenuto delle pagine cambi senza che sia stato l’utente ad effettuare una azione che comporta il cambiamento. Nel caso

  • di contenuti che si aprono in una finestra pop-up (quando proprio non è possibile evitarlo) avvisare l’utente;
  • in cui un link apra una nuova finestra avvisare l’utente;
  • in cui il sito web utilizza una sessione che scade informare l’utente del tempo di validità della sessione.

punto 3)
Inserire sempre il testo alternativo alle immagini (attributi Alt e Longdesc) e a tutti gli oggetti visivi utilizzati all’interno del sito (aspetto da tener presente anche quando si utilizzano sistemi di Content management).

punto 4) 
Nelle form associare in maniera esplicita le etichette ai rispettivi controlli. L’etichetta relativa ad un controllo in una Label va posizionata a sinistra del controllo stesso. Con il tag Label utilizzate l’attributo for facendo riferimento all’id del controllo associato. Solo nel caso di option box o check box la label va posta a destra dell’oggetto.

Il seguente codice è estratto dall’esempio visto in precedenza:

                  <p>
                     <label
for="nome-utente">Nome utente</label>
                     <input type="text"
id="nome-utente"
                     size="40" />
                  </p>
                  <p>
                     <label
for="password">Password</label>
                     <input type="password"
id="password"
                     size="40" />
                  </p>


Se provate a selezionare la voce “Nome utente” con il mouse vedrete il focus passare nella relativa textbox. Se selezionate la voce “Password” il focus passerà alla textbox corrispondente.

A chi volesse approfondire l’accessibilità dei moduli consiglio di consultare la sezione dedicata alla realizzazione di form accessibili  del lau (laboratorio di accessibilità ed usabilità).

punto 5)
Rendere chiara la destinazione di ciascun collegamento ipertestuale (link) con testi significativi anche se letti indipendentemente dal proprio contesto, oppure associare ai collegamenti testi alternativi che possiedano analoghe caratteristiche esplicative. Per esempio, sono da evitare i link «clicca qui». Inoltre i collegamenti devono essere selezionabili e attivabili tramite comandi da tastiera o sistemi di puntamento diversi dal mouse. Se il link serve a scaricare un file scegliere formati come .txt e .html, in quanto non hanno bisogno dell’istallazione di programmi o plug-in. Nel caso in cui ciò non fosse possibile dare indicazioni dell’applicazione con cui aprire il file. In entrambi i casi è consigliabile fornire l’informazione delle dimensioni del file.

punto 6)
Per gli elementi multimediali prevedere una descrizione testuale che per lo meno riassuma i contenuti dell’elemento.

punto 7)
Per quanto riguarda le tabelle utilizzate per presentare dati ci sono 3 accorgimenti da rispettare:

  1. inserire l’attributo summary esplicitando il numero delle colonne come prima informazione e poi enunciando il contenuto ed il tipo di ogni colonna;
  2. utilizzare th per indicare la riga di intestazione;
  3. associare le celle di dati e le celle di intestazione che hanno due o più livelli logici di intestazione di righe o colonne. I tag da utilizzare sono scope=rows/cols per tabelle con due livelli logici e  id-header per tabelle con più livelli logici.

Esempio di codice che genera una tabella accessibile

<table border="1" summary="Cinque colonne. Da sinistra, il radiobutton per selezionare la voce, l'identificativo della voce, la denominazione, la provincia, il comune">
                     <tr>
                       
<th id="sel">
                           Seleziona
                        </th>
                        <th id="id-az">
                           ID
                        </th>
                        <th id="den">
                           Denominazione
                        </th>
                        <th id="prov">
                           Provincia
                        </th>
                        <th id="com">
                           Comune
                        </th>
                     </tr>
                     <tr>
                        <td headers="
sel cod01" class="ct">
                           <input type="radio" name="nomeazienda" id="rad01" />
                        </td>
                        <td headers="
id-az cod01">
                           <label for="rad01">01</label>
                        </td>
                        <td
id="cod01" headers="den">
                           Voce n. 1
                        </td>
                        <td headers="prov cod01">
                           LI
                        </td>
                        <td headers="com cod01">
                           Livorno
                        </td>
                     </tr>

</table>

I non vedenti utilizzano uno strumento in grado di leggere le informazioni riportate nella pagina html: lo Screen Reader. Vediamo come questo interpreta i comandi riportati nell’esempio. Lo Screen Reader leggerà il contenuto della cella che ha come id lo stesso contenuto dell’attributo header. La prima volta che lo Screen Reader incontrerà l’attributo header all’interno della pagina (headers="sel cod01") leggerà “Seleziona” “Voce n. 1”, ovvero il contenuto della cella con id sel e il contenuto della cella con id cod01 e così via.

Visualizza il codice dell’intera pagina.
Visualizza la pagina generata.

La creazione delle tabelle per lo sviluppatore si traduce il più delle volte nella necessità di inserire all’interno dell’elenco dei risultati un id univoco, composto esclusivamente da lettere e numeri, per ogni elemento dell’elenco e informazioni relative al numero ed al contenuto delle colonne.

Vorrei sottolineare ancora una volta che questi non sono tutti gli aspetti che interessano l’accessibilità ma solo quelli che lo sviluppatore dovrebbe tenere in considerazione. Non perché lo sviluppatore debba occuparsi della grafica delle pagine, ma perché sia in grado di mettere a disposizione del grafico tutti gli elementi perché si possano generare pagine accessibili.






Valutare l’accessibilità di un sito durante lo sviluppo top
E’ consigliabile verificare il proprio lavoro passo passo. Alcuni strumenti rendono veloce la verifica dell’accessibilità delle pagine. Tra queste segnalo, per gli utilizzatori di FireFox, i seguenti AddOn:

HtmlValidator: una icona a destra della barra di stato del browser vi comunicherà immediatamente se la pagina contiene warning o errori di validazione del codice. Semplice ed immediato, ritengo sia il più indicato per lo sviluppatore che voglia verificare la correttezza dell’XHTML generato durante lo sviluppo.

Web Developer Toolbar: toolbar che consente di disattivare il javascript, le immagini, i css; permette di avere informazioni sugli elementi della pagina, delle form e delle tabelle e di visualizzare la pagina con dimensioni diverse della finestra del browser.

esempio web developer tool

Fig. 1 Utilizzo di Web Developer Toolbar per modificare i css
 

Verificare l’accessibilità di un sito top

La verifica di accessibilità di una pagina web consiste di 2 fasi:

  1. una verifica tecnica, che in parte può essere effettuata automaticamente utilizzando strumenti informatici. Il superamento della verifica tecnica permette l’esposizione del bollino nella nostra pagina;
  2. una verifica soggettiva, effettuata sempre da una o più persone, magari con disabilità motorie e visive. La verifica soggettiva viene valutata per definire il livello di accessibilità del sito: stabilisce il numero di asterischi presenti nel bollino della nostra pagina.

fac simile logo accessbilità
 
1.Verifica tecnica

Nell’Allegato A “Verifica tecnica e requisiti tecnici di accessibilità delle applicazioni basate su tecnologie internet” - del Decreto Ministeriale 8 luglio 2005 vengono definiti i Requisiti tecnici e i diversi livelli per l'accessibilità agli strumenti informatici. Nell’Allegato sono definite le metodologie per la verifica tecnica (punto 2).

Tra gli strumenti di valutazione efficaci (come definito nell’articolo 11, comma 1, lettera b della legge n. 4 del 2004) ci sono il programma automatico fornito dal W3C e i programmi indicati nella lista degli strumenti più diffusi presenti nella pagina Evaluation, Repair, and Transformation Tools for Web Content Accessibility dello stesso sito del W3C.

Altre operazioni, oltre le verifiche automatiche, che dobbiamo eseguire per accertarci che il sito sia accessibile:

  • dobbiamo accertarci che il sito web funzioni correttamente anche se gli script non sono supportati, quindi una verifica da effettuare è quella di disabilitare l’esecuzione degli script nel browser.
  • dobbiamo disattivare i css nel nostro browser e verificare che i contenuti sono tutti visibili e consultabili.
  • dobbiamo navigare il sito con un browser testuale utilizzando la tastiera (per chi utilizza linux links; chi utilizza Windows può usare linx, un emulatore di browser testuale)
  • dobbiamo consultare il sito utilizzando uno screen reader (Jaws è il più diffuso) o un browser vocale (Home Page Reader per esempio). Segnalo anche FireVox, un addon per FireFox disponibile al  momento solo in lingua inglese. Jaws e Home Page Reader sono programmi molto costosi; per chi volesse provare Jaws è disponibile una versione italiana scaricabile liberamente con la limitazione che funziona 40 minuti, dopo di che si deve riavviare il computer per continuare ad usare il programma; chi volesse provare Home Page Reader può scaricare una versione light.

2.Verifica soggettiva 

E’ indispensabile ricorrere alla valutazione soggettiva dell’accessibilità di un sito, magari ricorrendo al supporto di persona con handicap. Infatti non esistono strumenti automatizzati che possono garantire la correttezza, ad esempio, del summary di una tabella o del testo alternativo che ha il compito di descrivere il messaggio che vorrebbe comunicare un’immagine.

Un suggerimento: Può essere utile l’utilizzo della tabella riassuntiva dei checkpoint, di cui Roberto Scano ha pubblicato la traduzione in italiano. Vi consiglio di stamparla e spuntare ogni punto di controllo via via che viene verificato e raggiunto.
 



Fonti top


Ufficio Italiano W3C

World Wide Web Consortium (W3C)

Diodati.org, Accessibilità e traduzioni dal W3C

PubbliAccesso.Gov.it

CNIPA:Centro Nazionale per l'Informatica nella Pubblica Amministrazione

HTML.it 

[LAU]Laboratorio di Accessibilità e Usabilità



Username:
Password:
To sign up for an account, click register... Register
Hide





Powered By



Campagna Anti-IF


Skin


PARTNER
Zio Budda
HostingJava


LICENZA



Eccetto dove diversamente specificato, i contenuti di questo sito sono rilasciati sotto licenza Creative Commons

Sitemap  © 2002-2004 Copyright Information. Privacy . Today is domenica 1 agosto 2010