Nessun risultato. Prova con un altro termine.
Guide
Notizie
Software
Tutorial
  • Lezione 46 di 72
  • livello avanzato
Indice lezioni

Tabelle di dati e d'impaginazione: linearizzazione

Rendere lineari i dati contenuti in una tabella per comprenderne la struttura logica
Rendere lineari i dati contenuti in una tabella per comprenderne la struttura logica
Link copiato negli appunti

Sempre discorrendo di metodi per discernere tabelle dati da tabelle d'impaginazione, consideriamo quest'altra tabella, ottenuta modificando la struttura della tabella visualizzata al termine della precedente lezione.

c.1 - Testata (nome del sito, ecc.)

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 testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo testo

leggi il seguito

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 - Pie' di pagina (diritti d'autore ed altre informazioni)

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? È 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.23

breve descrizione

c.24

Voce di menu n.09

c.25

collegamento n.04

c.28 Pie' di pagina (diritti d'autore ed altre informazioni)

È 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.

Ti consigliamo anche