Requisito 7
Enunciato: Utilizzare mappe immagine sensibili di tipo lato client piuttosto che lato server, salvo il caso in cui le zone sensibili non possano essere definite con una delle forme geometriche predefinite indicate nella DTD adottata.
Riferimenti WCAG 1.0: 9.1
Riferimenti Section 508: 1194.22 (f)
Motivazione
Abbiamo già visto nel requisito 3 come le mappe immagine necessitino di testi alternativi per le selezioni di tipo grafico al fine di garantire la possibilità di utilizzare i contenuti della mappa anche ad utenti dotati di tecnologie assistive o di configurazioni particolari. La mappa immagine su lato server è una tecnologia “vecchia”. In pratica, quando l’utente clicca su un punto di una mappa le coordinate del mouse (x,y) vengono passate all’applicazione che controlla se tale area è all’interno di unsensibile e – in caso positivo – esegue l’azione (solitamente apertura di collegamenti). Siccome tutte le informazioni sono gestite sul lato server di fatto risulta impossibile fornire alternative testuali.
La mappa immagine sul lato client invece è quella che utilizziamo normalmente. In essa sono definiti alcuni oggetti con forme fisse:
default: specifica l’intera immagine sensibile.
rect: definisce un’area rettangolare.
circle: definisce un’area circolare.
poly: definisce un’area poligonare.
Le mappe immagine lato client, supportate ormai da pressoché tutti i browser, sono maggiormente adatte alla modalità di navigazione testuale di quanto lo fossero le progenitrici mappe immagine lato server, a condizione che gli elementi area che le compongono siano dotati del relativo testo alt.
Implementazione
Il requisito chiede di garantire la fornitura di informazioni che non impediscano ad alcune categorie di utenti di poter fruire dei contenuti della pagina web. Lo sviluppatore dovrà quindi seguire delle semplici raccomandazioni che si ispirano alle WCAG 1.0 al fine di garantire l’accesso ai contenuti alle diverse categorie di utenti. Sarà quindi richiesto di verificare se le funzionalità predisposte tramite mappa immagine lato server possono essere rese fruibili anche tramite mappa immagine lato client: ove ciò non fosse possibile, è necessario implementare mappe sensibili su lato server rispettose del requisito 8.
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 9.1 (Priorità 1). Fornire mappe immagine sul lato client invece di mappe immagine sul lato server, con l’eccezione dei casi nei quali le zone non possono essere definite con una forma geometrica valida
Le mappe immagine su lato server vengono utilizzate prevalentemente per applicazioni in cui si richiede una costante interazione tra contenuto Web e server. Un esempio può essere un’applicazione di rappresentazione del piano regolatore di un comune o altra applicazione GIS in cui l’utente deve posizionare il cursore del mouse in un determinato punto di una mappa creata dinamicamente secondo le selezioni operate dall’utente. L’uso più comune che attualmente si riscontra di tali applicazioni è legato ai servizi di consultazione pubblica dei numeri telefonici che forniscono la possibilità di localizzare un determinato utente nella mappa di una città consentendo inoltre di creare dei percorsi e/o di fornire altre informazioni correlate al punto selezionato dall’utente.
È chiaro che, utilizzando questo sistema e senza seguire le indicazioni del requisito 8, la mappa immagine sul lato server non sarà accessibile agli utenti che utilizzano browser testuali o che possono operare esclusivamente tramite tastiera o con tecnologie assistive che non emulano il movimento e le funzionalità del mouse.
Le sole ragioni che potrebbero portare a preferire le mappe immagine sul lato server sono quindi legate alla complessità della rappresentazione tramite le normali figure geometriche previste per le mappe immagine lato client.
Un ulteriore esempio di necessità delle mappe immagine sul lato server può essere il caso in cui le aree sulla mappa sono volutamente mantenute “segrete”: per esempio, la mappa di una caccia al tesoro on-line: le destinazioni dei collegamenti non possono essere rese pubbliche. Le immagini sensibili lato server risultano molto utili nel caso di mappe con informazioni di tipo geografico dove ogni punto è attivo e quindi raggiungibile da un evento tramite mouse: sviluppare lo stesso risultato con una immagine sensibile lato client risulterebbe molto complicato e di fatto ingestibile dagli sviluppatori.
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 mappe immagine sensibili lato server.
Tramite la Barra dell’accessibilità è possibile utilizzare:
Immagini
Visualizza le mappe immagine. Visualizza gli elementi <map> e il contenuto delle aree sensibili suddividendo le mappe immagine sensibili lato server dalle mappe immagine sensibili lato client (Punto di controllo 9.1).
Al termine della verifica dei suddetti punti l’esperto potrà quindi dichiarare la conformità al requisito.
Requisito 8
Enunciato: In caso di utilizzo di mappe immagine lato server, fornire i collegamenti di testo alternativi necessari per ottenere tutte le informazioni o i servizi raggiungibili interagendo direttamente con la mappa.
Riferimenti WCAG 1.0: 1.2
Riferimenti Section 508: 1194.22 (e)
Motivazione
Abbiamo visto nei requisiti precedenti come sia necessario fornire informazioni testuali alternative per immagini ed oggetti. Nel caso delle mappe immagini su lato client la presenza di testi alternativi per le singole aree sensibili consente di poter accederne ai contenuti.
In presenza di mappe immagine lato server, la maggior parte del codice si trova sul server Web. Al clic sull’area sensibile, il browser non deve fare altro che concatenare le coordinate dei pixel dell’area all’URL previsto e inviarle al server, a cui tocca tutto il resto del lavoro. Questo chiaramente rende difficile la fruibilità di tali mappe ad un utente non vedente, ad un utente con disabilità motorie, cognitive e ad utenti che non utilizzano il mouse (es: utenti con computer palmari): se non vengono forniti degli equivalenti testuali gestibili tramite tastiera per ogni area definita come cliccabile.
Implementazione
Il requisito chiede di garantire la fornitura di informazioni che non impediscano ad alcune categorie di utenti di poter fruire dei contenuti della pagina web. Lo sviluppatore dovrà quindi seguire delle semplici raccomandazioni che si ispirano alle WCAG 1.0 al fine di garantire l’accesso ai contenuti alle diverse categorie di utenti. Sarà quindi richiesto di verificare se le funzionalità predisposte tramite mappa immagine lato server possono essere rese fruibili anche ad utenti non vedenti, utenti con disabilità motorie e/o cognitive ed utenti che non utilizzano il mouse. Nel caso sia indispensabile usare una mappa immagine lato server, è necessario utilizzare collegamenti di tipo testuale che consentano la fruibilità anche agli utenti che utilizzano la tastiera o tecnologie di input alternative che non consentono di interagire con la mappa immagine non rendendo quindi accessibili le destinazioni dei collegamenti.
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.2 (Priorità 1). Fornire collegamenti di testo ridondanti per ogni zona attiva di una mappa immagine sul lato server
In presenza di mappe immagine lato server, la maggior parte del codice si trova sul server Web. Al clic sull’area sensibile, il browser non deve fare altro che concatenare le coordinate dei pixel dell’area all’URL previsto e inviarle al server, a cui tocca tutto il resto del lavoro. Questo chiaramente rende difficile ad un utente non vedente la fruibilità di tali mappe se non vengono forniti degli equivalenti testuali gestibili tramite tastiera per ogni area definita come cliccabile.
Per creare una mappa immagine lato server che rispetti il requisito 3, sono necessari i seguenti elementi:
- l’immagine deve essere in un formato supportato (gif, jpeg, png);
- il linguaggio di marcatura deve essere conforme al requisito 1;
- un file di mappa immagine che definisca l’azione delle aree sensibili;
- una serie di collegamenti ipertestuali equivalenti alle aree sensibili, oppure una funzionalità equivalente al contenuto dinamico generato.
Il codice generato si presenterà del tutto simile al seguente.
<p>
<a href="http://www.miosito.com/generamappa.asp">
<img src="mappa.gif"
alt="Mappa della gara" ismap="ismap" />
</a>
</p>
<ul>
<li><a href="inizio.htm">Punto di Partenza</a></li>
<li><a href="ristoro.htm">Punto di Ristoro</a></li>
<li><a href="fine.htm">Punto di Arrivo</a></li>
</ul>
L’elemento <img> necessita quantomeno dell’attributo alt ed eventualmente dell’attributo longdesc: in questo caso, per esempio, l’attributo longdesc potrebbe essere necessario se la mappa descrive con precisione un percorso. L’utente dotato di lettore di schermo otterrà quindi un risultato come il seguente:
Immagine. Mappa della gara
Collegamento. Punto di partenza
Collegamento. Punto di ristoro
Collegamento. Punto di arrivo
Una versione testuale dei collegamenti è necessaria, poiché la mappa immagine lato server invia al browser le coordinate all’interno delle quali l’utente può azionare il proprio mouse: gli utenti che non ne sono dotati o non possono utilizzarlo potranno fruire dei contenuti grazie alla versione alternativa, in questo esempio i link testuali che consentono di aprire il collegamento relativo al punto di partenza e al punto di arrivo della mappa.
I testi equivalenti di supporto per le mappe immagini lato server risultano essenziali non solo ad utenti non vedenti ma anche ad utenti con disabilità di tipo motorio e/o di tipo cognitivo.
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 mappe immagine sensibili lato server;
- verificare la presenza di collegamenti ipertestuali equivalenti alle zone sensibili della mappa immagine sensibile lato server.
Tramite la Barra dell’accessibilità è possibile utilizzare:
Immagini
Visualizza le mappe immagine. Visualizza gli elementi <map> e il contenuto delle aree sensibili suddividendo le mappe immagine sensibili lato server dalle mappe immagine sensibili lato client (Punto di controllo 9.1). Sarà quindi compito dell’esperto, in presenza di mappe immagini sensibili lato server, verificare all’interno della pagina web la presenza di contenuti collegamenti ipertestuali equivalenti alle aree sensibili (Punto di controllo 1.2).
Al termine della verifica dei suddetti punti l’esperto potrà quindi dichiarare la conformità al requisito.
Requisito 9
Enunciato: Per le tabelle dati usare gli elementi (marcatori) e gli attributi previsti dalla DTD adottata per descrivere i contenuti e identificare le intestazioni di righe e colonne.
Riferimenti WCAG 1.0: 5.1, 5.5, 5.6
Riferimenti Section 508: 1194.22 (g)
Motivazione
Il requisito riguarda esclusivamente le tabelle dati, ossia tabelle non utilizzate per impaginazione ma che contengono informazioni in forma tabellare. Gli sviluppatori spesso utilizzano erroneamente attributi ed elementi previsti per le tabelle dati: un esempio è l’uso dell’elemento <th> per scrivere dei testi in grassetto).
In altri casi di necessità, invece, tali attributi non sono utilizzati o sono utilizzati in modo non corretto: a titolo di esempio, si riscontra la mancanza di utilizzo degli elementi ed attributi che consentono agli utenti non vedenti di poter accedere ai contenuti di una tabella dati. La creazione di una tabella dati, infatti, va curata garantendo la possibilità agli utenti di navigarne i contenuti consentendo di collegare una determinata cella di dati (di una colonna o riga) ad una cella di intestazione (di colonna o riga), un po’ come avviene nel gioco della battaglia navale. Il requisito chiede quindi di garantire la possibilità di lettura dei contenuti della tabella in modo comprensibile a tutti gli utenti.
Implementazione
Il requisito chiede di garantire la fornitura di informazioni che non impediscano ad alcune categorie di utenti di poter fruire dei contenuti delle tabelle dati contenute in una pagina web. Lo sviluppatore dovrà quindi seguire delle semplici raccomandazioni che si ispirano alle WCAG 1.0 al fine di garantire l’accesso ai contenuti alle diverse categorie di utenti. Sarà quindi richiesto di verificare l’utilizzo di elementi ed attributi in modo conforme alle specifiche e soprattutto l’accessibilità dei dati contenuti nelle tabelle.
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 5.1 (Priorità 1). Per le TABELLE DATI, identificare le intestazioni per righe e colonne
Questo punto di controllo per il Livello 1 informa lo sviluppatore che, nel caso vengano utilizzate delle tabelle per presentare dei dati, egli deve identificare in modo chiaro le celle contenenti i dati dalle intestazioni di righe e colonne. Pertanto, le tabelle dati richiedono l’uso degli elementi <tr>, <td>, <th> e <caption> e dei relativi attributi.
L’elemento <caption> identifica il titolo della tabella. È posizionato solitamente all’inizio della tabella ed è personalizzabile graficamente tramite fogli di stile.
L’elemento <tr> identifica una riga di una tabella e può contenere elementi <th> ed elementi <td>. La sua modalità di visualizzazione può essere personalizzata tramite fogli di stile.
L’elemento <th> identifica una cella di intestazione, ovvero un punto di riferimento per la lettura dei contenuti dei dati tabellari ed è contenuto all’interno dell’elemento <tr>. Solitamente tali celle vengono evidenziate dal browser con testo in grassetto rispetto all’impostazione predefinita del carattere (ove tale impostazione non viene modificata tramite fogli di stile).
L’elemento <td> identifica una cella contenente dati ed è contenuto all’interno dell’elemento <tr>. La sua modalità di visualizzazione può essere personalizzata tramite fogli di stile.
Di seguito è rappresentato un esempio di tabella dati semplice. Come si noterà l’elemento <table> contiene l’attributo “summary” che, come vedremo nell’analisi del presente requisito, è richiesto per tutte le tipologie di tabelle.
<table border="1" summary="Sommario tabella...">
<caption>Esempio di tabella dati</caption>
<tr>
<td></td>
<th>Intestazione Colonna 1</th>
<th>Intestazione Colonna 2</th>
</tr>
<tr>
<th>Intestazione Riga 1</th>
<td>Col. 1 Riga 1</td>
<td>Col. 1 Riga 2</td>
</tr>
<tr>
<th>Intestazione Riga 2</th>
<td>Col. 2 Riga 1</td>
<td>Col. 2 Riga 2</td>
</tr>
</table>
Nel nostro caso ho utilizzato l’attributo “border” solamente per rendere visibili le dimensioni della tabella nell’esempio senza quindi utilizzare i CSS collegati: in realtà, anche il bordo si deve comunque controllare con i CSS.
Il codice di esempio precedente in un browser genererà una tabella come mostrato nella figura successiva: sarà compito dei fogli di stile e di un corretto utilizzo del selettore CSS “class” e dell’attributo HTML “style” il “vestire” graficamente la tabella. Vorrei comunque sconsigliare l’uso dell’attributo style in quanto non presente nella DTD XHTML 1.1 e successive: per migliorare l’aspetto della tabella si dovranno quindi utilizzare i fogli di stile utilizzando l’attributo HTML “class”.
Figura 4.4 Tabella di esempio.
Nel caso di tabelle con più righe o colonne, come informare il programma di lettura dello schermo del corretto ordine di lettura dei contenuti? Un aiuto ci viene fornito dall’attributo headers, che specifica l’elenco delle intestazioni collegate a una cella contenente dati.
Per utilizzare questa funzionalità, ogni cella di intestazione deve aver valorizzato l’attributo id. Si riporta in versione italiana un esempio tratto dal sito W3C, che prevede la creazione di una tabella contenente i nomi di due persone (nel nostro caso, i due onorevoli firmatari del primo disegno di legge sull’accessibilità presentato da IWA/HWG) e le informazioni relative alle preferenze personali riguardo il caffè: quantità, tipo e se il caffè viene zuccherato o meno.
Caffè consumato da ogni onorevole
|
Nome |
Tazze |
Tipo di caffé |
Zucchero? |
|---|---|---|---|
|
A. Palmieri |
10 |
Espresso |
No |
|
C. Campa |
5 |
Decaffeinato |
Sì |
Dalla tabella è chiaro che per consentire una corretta lettura dei contenuti a un utente che utilizza un lettore dello schermo è necessario che la tabella sia strutturata in modo da garantire la comprensione delle informazioni. Nel nostro caso, il lettore dovrà quindi leggere ogni volta la riga di intestazione (riga in grassetto) con il relativo valore, ossia per la prima riga:
Nome: A. Palmieri, Tazze: 10, Tipo: Espresso, Zucchero: No
Come si noterà dal codice seguente, valorizzando l’attributo id e assegnando i relativi valori alle celle contenenti dati (celle di tipo <td>) potremmo affiliare le intestazioni ai dati in modo semplice.
<table summary="Questa tabella contiene la
rappresentazione del numero
di caffè consumati da ogni onorevole,
con il tipo di caffè (decaffeinato o normale),
e se consumato con zucchero.">
<caption>Caffè consumato da ogni onorevole</caption>
<tr>
<th id="intestazione1">Nome</th>
<th id="intestazione2">Tazze</th>
<th id="intestazione3" abbr="Tipo">Tipo di caffè</th>
<th id="intestazione4">Zucchero</th>
</tr>
<tr>
<td headers="intestazione1">A. Palmieri</td>
<td headers="intestazione2">10</td>
<td headers="intestazione3">Espresso</td>
<td headers="intestazione4">No</td>
</tr>
<tr>
<td headers="intestazione1">C. Campa</td>
<td headers="intestazione2">5</td>
<td headers="intestazione3">Decaffeinato</td>
<td headers="intestazione4">Sì</td>
</tr>
</table>
Il programma di lettura dello schermo leggerà i dati della tabella nel modo seguente:
Caption: Caffè consumato da ogni onorevole
Summary: Questa tabella contiene la rappresentazione del
Numero di caffè consumati da ogni onorevole,
con il tipo di caffè (decaffeinato o normale),
e se consumato con zucchero.
Nome: A. Palmieri, Tazze: 10, Tipo: Espresso, Zucchero: No
Nome: C. Campa, Tazze: 5, Tipo: Decaffeinato, Zucchero: Sì
Si noterà che anziché leggere “Tipo di caffè” il sistema legge “Tipo”, in quanto è stata definita un’abbreviazione (attributo abbr) per non rendere ridondante e pesante la lettura ad ogni riga di una frase lunga. È necessario precisare che in questo caso si parla di attributo abbr che ha funzionalità inversa dell’elemento <abbr> e che è spiegato nel Punto di controllo 5.6 richiesto da questo stesso requisito. Un sommario delle tabelle (definito con l’attributo summary) è particolarmente utile per le tecnologie assistive utilizzate dagli utenti non vedenti. Qualsiasi tabella di dati dovrebbe contenere delle informazioni preventive, valorizzando l’elemento <caption>, eventualmente sostituibile dall’attributo title se si desidera renderlo visibile esclusivamente agli utenti non vedenti.
Punto di controllo 5.5 (Priorità 3). Per ogni tabella definire un sommario dei contenuti
Mentre l’elemento <caption> e l’attributo title rappresentano un “titolo” della tabella, l’attributo summary è di fatto una guida all’utente sul contenuto e sull’organizzazione della tabella dati. Nella nostra tabella di esempio sui caffè consumati dagli onorevoli, l’attributo summary descriveva chiaramente l’organizzazione dei contenuti.
<table summary="Questa tabella contiene la
rappresentazione del numero
di caffè consumati da ogni onorevole,
con il tipo di caffè
(decaffeinato o normale),
e se consumato con zucchero.">
...
...
</table>
Gli utenti non vedenti, ricevendo informazioni descrittive dei contenuti grazie al contenuto dell’attributo summary, potranno valutare se fruire del contenuto della tabella o passare al paragrafo successivo.
Punto di controllo 5.6 (Priorità 3). Fornire abbreviazioni per le etichette di intestazione
Un attributo interessante per l’elemento <th> è senz’altro abbr: grazie a tale attributo un lettore dello schermo leggerà il valore contenuto in abbr in sostituzione del contenuto della cella, in modo da eliminare pesanti ripetizioni. Nel nostro esempio (caffè consumati dagli onorevoli) era presente la seguente riga di codice:
<th id="intestazione3" abbr="Tipo">Tipo di caffè</th>
Il lettore dello schermo leggerà “Tipo” invece che “Tipo di caffè”, seguito dal valore della relativa cella contenente le informazioni richieste.
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 tabelle dati;
- verificare l’uso corretto degli elementi <caption>, <tr>, <th> e <td> secondo le specifiche;
- verificare la presenza dell’attributo summary.
Tramite la Barra dell’accessibilità è possibile utilizzare:
Struttura
Tabelle dati semplici: Visualizza gli elementi <table>, <th>, <td> sulla pagina corrente insieme agli attributi raccomandati per il linguaggio di marcatura di tabelle di dati semplici (summary, scope). Un attributo vuoto indica che l’attributo non è stato utilizzato pur essendone raccomandato l’uso (Punti di controllo 5.1, 5.5 e 5.6).
Al termine della verifica dei suddetti punti l’esperto potrà quindi dichiarare la conformità al requisito.
Requisito 10
Enunciato: Per le tabelle dati usare gli elementi (marcatori) e gli attributi previsti nella DTD adottata per associare le celle di dati e le celle di intestazione che hanno due o più livelli logici di intestazione di righe o colonne.
Riferimenti WCAG 1.0: 5.2
Riferimenti Section 508: 1194.22 (h)
Motivazione
Abbiamo già visto nel requisito precedente come sia necessario consentire una corretta lettura dei contenuti nelle tabelle dati. Se una tabella dati è complessa, sarà necessario applicare una serie di tecniche: è possibile utilizzare ulteriori elementi che consentono agli utenti con tecnologie assistive di poter comprendere i contenuti e di fruirne secondo l’ordine logico stabilito dallo sviluppatore.
La finalità del requisito chiede quindi, anche in questo caso, di poter garantire la fruibilità di una tabella dati ad utenti dotati di tecnologie assistive o di configurazioni particolari.
Implementazione
Il requisito chiede di garantire la fornitura di informazioni che non impediscano ad alcune categorie di utenti di poter fruire dei contenuti delle tabelle dati complesse contenute in una pagina web. Lo sviluppatore dovrà quindi seguire delle semplici raccomandazioni che si ispirano alle WCAG 1.0 al fine di garantire l’accesso ai contenuti alle diverse categorie di utenti. Sarà quindi richiesto di verificare l’utilizzo di elementi ed attributi in modo conforme alle specifiche e soprattutto l’accessibilità dei dati contenuti nelle tabelle complesse.
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 5.2 (Priorità 1). Per le TABELLE DATI che hanno due o più livelli logici di intestazioni di righe o colonne, usare marcatori per associare le celle di dati e le celle di intestazione
Come abbiamo già accennato nelle motivazioni del requisito, non sempre le tabelle dati hanno una struttura semplice come quella rappresentata nel requisito precedente. Per le tabelle con strutture più complesse, è possibile utilizzare gli elementi e gli attributi idonei:
- l’elemento <thead> raggruppa le righe di intestazione (elementi <tr>, <th> e <td>);
- l’elemento <tbody> raggruppa le righe interne alla tabella (elementi <tr> e <td>);
- l’elemento <tfoot> raggruppa le righe di chiusura della tabella (elementi <tr> e <td>);
- gli elementi <col> e <colgroup> raggruppano le colonne;
- gli attributi “axis”, “scope” ed “headers” descrivono relazioni più complesse fra i dati.
Immaginiamo ora una tabella contenente i dati relativi a delle spese per viaggi: mentre nella tabella di esempio per il requisito precedente leggere i contenuti con un lettore dello schermo era piuttosto semplice, una tabella come di questo tipo risulterà di difficile interpretazione senza l’utilizzo di elementi ed attributi adeguati. Per esempio, utilizzando l’attributo headers in modo scorretto non verranno lette le intestazioni prima del valore di una cella dati: sfido chiunque a ricordarsi, dopo una ventina di righe di tabella, quali erano i valori delle intestazioni. Un esempio di tabella dati complessa è rappresentato qui di seguito. È comprensibile come gli attributi headers siano necessari per rendere comprensibile il contenuto agli utenti che utilizzano lettori dello schermo. Di seguito è rappresentato il codice della tabella in cui sono utilizzati elementi ed attributi in modo conforme a quanto richiesto dal requisito.
<table summary="Questa tabella contiene le spese generali
suddivise per affiliazione (nominativo ed ufficio
di competenza e per descrizione (Tipologia di spesa
ed importo">
<caption>Spese generali anno 2005</caption>
<colgroup span="2" />
<colgroup span="2" />
<thead>
<tr>
<th colspan="2" id="affiliazione">Affiliazione</th>
<th colspan="2" id="descrizione">Descrizione</th>
</tr>
<tr>
<th id="nominativo">Nominativo</th>
<th id="ufficio">Ufficio</th>
<th id="tipologia" abbr="Tipo">Tipologia di spesa</th>
<th id="importo">Importo</th>
</tr>
</thead>
<tfoot>
<tr>
<td colspan="4">Aggiornata al 27 maggio 2005</td>
</tr>
</tfoot>
<tbody>
<tr>
<td headers="affiliazione nominativo">Bianchi Michele</td>
<td headers="affiliazione ufficio">Amministrazione</td>
<td headers="descrizione tipologia">Carburante</td>
<td headers="descrizione importo">250,00</td>
</tr>
<tr>
<td headers="affiliazione nominativo">Rossi Mario</td>
<td headers="affiliazione ufficio">Acquisti</td>
<td headers="descrizione tipologia">Cancelleria</td>
<td headers="descrizione importo">112,15</td>
</tr>
<tr>
<td headers="affiliazione nominativo">Scano Roberto</td>
<td headers="affiliazione ufficio">Vendite</td>
<td headers="descrizione tipologia">Consumabili</td>
<td headers="descrizione anno">400,00</td>
</tr>
</tbody>
</table>
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 tabelle dati complesse;
- verificare la presenza degli elementi ed attributi previsti dalle specifiche per le tabelle dati semplici;
- verificare l’uso corretto degli elementi <thead>, <tbody>, <tfoot>, <col>, <colgroup> e degli attributi “axis”, “scope”, “headers” secondo le specifiche.
Tramite la Barra dell’accessibilità è possibile utilizzare:
Struttura
Tabelle dati complesse. Visualizza gli elementi <table>, <th>, <td>, <thead>, <tbody>, <tfoot>, <col>, <colgroup> sulla pagina corrente insieme agli attributi raccomandati per il linguaggio di marcatura di tabelle di dati complesse (summary, scope, id, headers). Un attributo vuoto indica che l’attributo non è stato utilizzato pur essendone raccomandato l’uso (Punto di controllo 5.2).
Ordinamento delle celle in tabella. Visualizza l’ordine (numerico) di tabulazione ed i bordi delle celle delle tabelle sulla pagina corrente (Punto di controllo 5.2). Grazie a tale funzionalità l’esperto può verificare il corretto ordine di lettura.
Al termine della verifica dei suddetti punti l’esperto potrà quindi dichiarare la conformità al requisito.