Diodati.org | Accessibilità e traduzioni dal W3C      Leggi Omega Centauri!

Sponsor ufficiale di Diodati.org: Hosting a partire da 3,33 Euro/mese | Domini a partire da 10,79 euro/anno | Server dedicati a partire da 40 euro/mese, VPS Hosting da 30 euro/mese

Prima di lasciare definitivamente le tabelle, proviamo a rispondere ad un quesito apparentemente teorico, ma ricco invece di importanti conseguenze pratiche: è possibile distinguere in modo assoluto una tabella di dati ("data table") da una tabella d'impaginazione ("layout table")? Esiste cioè qualche tratto caratteristico che appartiene solo ad un tipo e non all'altro? Se vogliamo rispettare la raccomandazione delle WCAG 1.0 che ci consiglia di evitare per quanto possibile l'uso delle tabelle d'impaginazione, dobbiamo pur essere in grado di distinguere tra i due tipi con una certa sicurezza! Su quali tratti ci baseremo per operare tale distinzione?

Purtroppo la risposta a questa domanda non è affatto semplice o banale. Infatti i due tipi di tabella possono utilizzare gli stessi elementi e attributi HTML (ecco tra l'altro il motivo per cui i validatori automatici non sono in grado di determinare a quale tipo appartenga una tabella). La distinzione va effettuata a livello di contenuto, di significati.

Una prima cosa che possiamo notare è che una tabella di dati somiglia molto ad una tipica tabella di database. Esistono cioè delle relazioni orizzontali e verticali tra i contenuti delle celle: non possiamo spostare il contenuto di una cella ad un'altra colonna o ad un'altra riga senza alterare quei rapporti.

Consideriamo per esempio la tabella dei corsi di lezione, già analizzata in precedenza. Prendiamone solo una parte:

Se invertiamo il contenuto di cella "Mark Cottle" con il contenuto di cella "Dr. John Wroughton", alteriamo irreparabilmente i dati. Ci troveremo infatti Mark Cottle come insegnante del corso sulle conseguenze della Guerra Civile e il dr. Wroughton come insegnante del corso sull'Inghilterra degli Anglo-Sassoni. Analogo disastro succede se invertiamo "Mark Cottle" con "Introduzione all'Inghilterra degli Anglo-Sassoni": ci ritroveremo con il nome del professore al posto del nome del corso e viceversa. Insomma, per una simile tabella vale la seguente regola: non si può spostare il contenuto di una cella senza alterare le relazioni orizzontali e/o verticali tra i dati.

Possiamo essere dunque sufficientemente sicuri che abbiamo a che fare in questo caso con una tabella di dati.

Consideriamo ora la tabella seguente, che rappresenta una versione schematica e ridotta (priva di tabelle annidate) della tabella principale esterna che si trova in tabforma.htm.

Non considerando l'effetto sull'aspetto grafico della pagina in cui si trova la tabella, nulla ci vieterebbe, per esempio, di invertire il contenuto della cella n.3 (il menu di navigazione) con il contenuto della cella n.1 (la testata del sito), oppure il contenuto della cella n.4 (i link ad altri siti) con il contenuto della cella n.5 (il pie' di pagina). L'insieme delle informazioni veicolate dalla tabella conserverebbe il proprio significato, anche dopo aver scambiato di posizione le varie celle.

Ciò perché in una simile tabella non vi sono relazioni semantiche orizzontali e verticali tra le celle: il menu di navigazione è indipendente dalla testata, i link ad altri siti sono indipendenti dal pie' di pagina, l'articolo nella cella n.3 è indipendente da tutto il resto. Una simile tabella è usata unicamente allo scopo di disporre sulla pagina in certe posizioni precise i singoli contenuti. Possiamo essere sufficientemente sicuri, pertanto, di avere a che fare in questo caso con una tabella d'impaginazione.

Le cose, però, non sono sempre così semplici. Consideriamo adesso quest'altra tabella, ottenuta modificando la struttura della precedente.

Il contenuto della tabella è esattamente lo stesso. Ora lo abbiamo però sparpagliato in ben 28 celle (possibili motivazioni da parte dello sviluppatore: non volere tabelle annidate, ma volere maggior controllo sulla formattazione dei singoli contenuti). Vale ancora la regola vista per la tabella precedente? E' ancora possibile, cioè, scambiare di posizione i contenuti di due celle senza alterare la comprensibilità delle informazioni? Sì e no! O meglio, in certi casi sì, in altri no.

Potremmo per esempio scambiare di posto pie' di pagina e testata (la cella 28 con la 1), oppure una qualsiasi voce di menu con un'altra (p. es. la cella 24 con la 26): in entrambi i casi i gruppi di elementi significativi della tabella - testata, pie' di pagina, menu di navigazione, ecc. - continuerebbero a conservare la loro comprensibilità interna. Ma se invertiamo la cella 2 ("menu di navigazione") con la 16 ("voce di menu n.5") non si capirà più dove comincia il menu di navigazione. Analogamente, se invertiamo la cella 4 ("Link ad altri siti") con la 17 ("collegamento n.2") non si capirà come è strutturato il blocco dei link ad altri siti. Peggio ancora, se scambiamo di posizione la cella 20 ("voce di menu n.7") e la 21 ("collegamento n.3") avremo messo uno dei link ad altri siti nel menu di navigazione ed una voce di menu tra i link ad altri siti.

Insomma, la tabella che stiamo esaminando è in parte una tabella d'impaginazione e in parte una tabella di dati. Più precisamente, è una tabella d'impaginazione che contiene, tra gli altri, dei dati che ha senso organizzare in forma tabellare (il menu di navigazione, i link ad altri siti), cioè dati contenuti in celle che sono soggette, nella tabella data, a relazioni semantiche di tipo orizzontale e verticale. Una brutta gatta da pelare per il nostro proposito di trovare criteri di distinzione assoluti tra i due tipi!

Per quanto riguarda l'accessibilità, cosa dobbiamo fare in un caso simile? Conviene usare oppure no una tabella mista in un sito ad elevata accessibilità? Per fortuna, ci vengono in aiuto le WCAG 1.0, con il già citato punto di controllo 5.3, che raccomanda agli sviluppatori di non utilizzare tabelle di impaginazione che perdano di senso una volta linearizzate (o, se proprio non si può fare a meno di usarle, di fornire un'alternativa correttamente linearizzata).

La tabella mista dell'esempio precedente, linearizzata in un browser come Lynx, apparirebbe così:

c.1 Testata (nome del sito, ecc.)
c.2 Menu di navigazione
c.3 Articolo
c.4 Link ad altri siti
c.5 Voce di menu n.01
c.6 Occhiello
c.7 Gruppo n.1
c.8 Voce di menu n.02
c.9 data e autore
c.10 argomento
c.11 Voce di menu n.03
c.12 sommario: testo testo testo testo (...)
c.13 collegamento n.01
c.14 Voce di menu n.04
c.15 breve descrizione
c.16 Voce di menu n.05
c.17 collegamento n.02
c.18 Voce di menu n.06
c.19 breve descrizione
c.20 Voce di menu n.07
c.21 collegamento n.03
c.22 Voce di menu n.08
c.23 breve descrizione
c.24 Voce di menu n.09
c.25 collegamento n.04
c.26 Voce di menu n.10
c.27 breve descrizione
c.28 Piè di pagina (diritti d'autore ed altre informazioni)

E' evidente che la tabella, così linearizzata, perde senso quasi completamente. Dunque in un sito ad elevata accessibilità bisognerebbe evitare accuratamente di inserire una tabella con simili caratteristiche (è a scopo di impaginazione e si linearizza male).

Ma perché, allora, non considerarla piuttosto una tabella di dati, sia pure di un tipo un po' particolare? In realtà non possiamo classificarla come una tabella di dati, perché il suo scopo principale è disporre nella pagina in posizioni precise elementi che sono sostanzialmente indipendenti l'uno dall'altro (la testata è indipendente dal pie' di pagina, il menu di navigazione dall'articolo, ecc.): rimane dunque una tabella d'impaginazione, anche se contiene celle correlate semanticamente.

In conclusione di argomento, cerchiamo di riassumere le caratteristiche che appartengono rispettivamente alle tabelle di dati e a quelle d'impaginazione, ricordando però che possono verificarsi casi misti come quello illustrato più sopra.

• Tabelle di dati
  • sono utilizzate per rappresentare informazioni di natura esclusivamente tabellare: dati, cioè, che potrebbero essere inseriti in una tabella di database. In base a questa analogia, le celle marcate con TH corrisponderebbero ai nomi dei campi in una tabella di database
  • i contenuti di una qualsiasi cella sono correlati con quelli delle celle disposte sulla stessa riga (nel caso di tabelle multicolonna) e/o sulla stessa colonna
  • in tabelle con almeno due colonne non è possibile invertire di posizione i contenuti di due celle qualsiasi senza alterare la validità e la comprensibilità dei dati
  • possono essere rese accessibili, o più accessibili, utilizzando un apposito codice di marcatura strutturale (CAPTION, TH, COL, COLGROUP, THEAD, TBODY, TFOOT, summary, headers, id, scope)
  • sono tabelle di dati:
    • un calendario
    • un orario delle lezioni
    • una rubrica di nomi, indirizzi e numeri telefonici
  
   
• Tabelle d'impaginazione
  • sono utilizzate per disporre i contenuti sulla pagina in posizioni precise
  • i contenuti delle celle sono indipendenti gli uni dagli altri, non esistono correlazioni semantiche orizzontali e verticali
  • è possibile invertire i contenuti di due celle senza alterare la consistenza dei dati presenti nella tabella
  • sono accessibili se possono essere linearizzate senza perdere di significato
  • sono tabelle di impaginazione:
    • una griglia di righe e colonne i cui contenuti riproducono un'impaginazione basata su testata, tre colonne centrali e pie' di pagina
    • una tabella di un'unica cella, annidata in un'altra tabella, usata al solo scopo di aggiungere una distanza supplementare tra il suo contenuto e i margini della cella che la contiene
    • una tabella che contiene, insieme ad elementi grafici e testo, immagini spaziatrici invisibili, utilizzate per distanziare i contenuti visibili sulla pagina