Creare tabelle che si trasformino elegantemente

Punto di controllo 5.1, priorità 1

Una tabella di dati con false intestazioni

Le tabelle, generate in HTML dall’elemento TABLE, possono essere usate in due modi del tutto opposti: per incasellare dati tabellari (tabelle di dati) o per costruire griglie che servono per disporre i contenuti sulla pagina (tabelle d’impaginazione). L’uso proprio, raccomandato dalle Specifiche HTML, è il primo, ed è quello che tratteremo in questo e nei successivi paragrafi (per informazioni sull’uso improprio rimandiamo, invece, al paragrafo Tabelle d’impaginazione che non si trasformano elegantemente, più avanti in questo stesso capitolo).

Il modo più elementare per migliorare la comprensibilità di una tabella di dati, soprattutto per chi naviga in modalità non visuale, è identificare le celle d’intestazione, marcandole con l’opportuno elemento strutturale, che è TH.

Consideriamo un caso relativamente semplice: una tabella che elenca le regioni e le province italiane, associando a ciascuna regione le relative province. Per rendere la tabella graficamente più interessante, il grafico ha però previsto che i nomi di regione siano alternativamente alla sinistra o alla destra del nome delle relative province.

Per brevità, il Listato 8.1 riporta il codice di marcatura relativo a due sole regioni, il Lazio e la Campania. I nomi delle regioni e le celle di appartenenza sono messi in evidenza solo graficamente attraverso i fogli di stile del Listato 8.2, ma semanticamente non c’è alcuna differenza tra le celle: sono tutte marcate con l’elemento TD. I capoluoghi di regione, Roma e Napoli, sono a loro volta messi in evidenza con il grassetto, tramite l’attributo di presentazione B.

L’attributo rowspan serve per distendere una singola cella sullo spazio occupato da più colonne. Sull’uso di questo attributo, in congiunzione con celle che si espandono su più righe (tramite l’attributo colspan), si vedano anche i Listati 8.6 e 17.4.

Il selettore td[rowspan] ha lo scopo di selezionare solo le celle che hanno un attributo rowspan. Le uniche due celle con questa caratteristica sono quelle che contengono i due nomi di regione. Ed ecco, dunque, che “Lazio” e “Campania” appaiono in caratteri maiuscoli, su sfondo grigio e con allineamento al centro, mentre le celle con i nomi delle province appaiono con i soli stili base impostati tramite il selettore td (larghezza della cella, bordo e spaziatura interna). L’aspetto grafico della tabella così formattata è visibile in Figura 8.1 A e dà l’idea di una struttura chiaramente comprensibile, data la netta differenza di formattazione tra i nomi di regione e i nomi delle relative province.

Tutta la chiarezza, però, scompare, non appena si linearizza la tabella e si tolgono gli stili, come mostrato nella Figura 8.1 B. Quest’ultima è la modalità di fruizione seriale tipica degli screen reader. Il nome della regione Campania finisce tra i nomi delle province Avellino e Benevento e, non avendo alcun rilievo particolare, né di posizione né di altro tipo, perde del tutto la funzione di intestazione che svolgeva con chiarezza nella vista grafica della tabella.

Diventa allora indispensabile, se si vuole garantire accessibilità alle tabelle di dati per gli utenti che navigano in modalità non grafica, prendere una serie di accorgimenti, che consentano di compensare l’impossibilità di vedere direttamente le relazioni tra le celle. Marcare con elementi TH le celle d’intestazione, cioè quelle celle che contengono le informazioni di riferimento per altre celle o altri gruppi di celle che fanno parte della stessa tabella, è il primo e più semplice accorgimento per l’accessibilità delle tabelle (vedremo in seguito quali sono gli altri accorgimenti).

Inizio pagina

Metodi per riconoscere le celle d’intestazione

In una tabella di dati, le celle d’intestazione occupano solitamente la prima riga dall’alto e/o la prima colonna a sinistra (almeno nei paesi in cui si scrive da sinistra a destra, come in Italia, Europa Occidentale e America), ma può darsi il caso di tabelle di dati più complesse, con righe o colonne d’intestazione inserite anche nel mezzo della tabella. La posizione della cella, dunque, come mostra la tabella in Figura 8.1, non sempre garantisce della sua funzione.

Sorge a questo punto un problema per gli sviluppatori: come fare a riconoscere in una tabella quali sono le celle d’intestazione, così da poterle marcare opportunamente?

Di solito una cella d’intestazione è riconoscibile perché rappresenta il genere di una specie, ovvero la categoria sotto la quale vengono catalogati gli individui o gli oggetti che fanno parte della medesima riga o colonna (o del gruppo di righe o di colonne coperto dalla medesima cella d’intestazione). Se una colonna è intitolata, per esempio, “fiori”, gli oggetti che ne formano il contenuto saranno “rosa”, “margherita”, “giglio”, “orchidea” ecc., ma non “cane”, “gatto”, “topo” o “automobile”. In HTML e XHTML, la cella che contiene la parola “fiori” andrebbe marcata con TH, mentre quelle che contengono i nomi dei singoli fiori andrebbero marcate con TD. Se poi “cane” e “gatto” fossero nella stessa colonna di “fiori”, saremmo molto probabilmente in presenza di un errore di composizione della tabella.

La tabella di Figura 8.1 A contiene relazioni del tipo genere/specie: i nomi delle regioni sono generi (o contenitori), cioè oggetti più generali, rispetto ai nomi delle province, i quali sono specie (o contenuti) rispetto alle regioni. In virtù di tale relazione, le celle che contengono i nomi “Lazio” e “Campania” avrebbero dovuto essere inseriti in celle TH invece che in celle TD.

La relazione categoria/oggetto (o genere/specie o, anche, contenitore/contenuto) non è l’unica possibile tra celle d’intestazione e celle di dati. Un’altra relazione, più complessa, è quella che si sviluppa su due assi: proprietà/valore e oggetto/valore.

Immaginiamo una tabella che metta a confronto due o più frutti, valutandoli in base alle caratteristiche nutrizionali (per esempio, calorie, minerali, vitamine ecc.). I nomi delle caratteristiche nutrizionali rappresentano le proprietà nella relazione proprietà/valore; i nomi dei frutti rappresentano, invece, gli oggetti, nella relazione oggetti/valori. Ogni singolo valore nutrizionale ha significato solo in base a una duplice relazione: con la proprietà (la caratteristica nutrizionale), da un lato, e con l’oggetto (il frutto) dall’altro. In questa duplice relazione, le celle che contengono i nomi delle caratteristiche nutrizionali e i nomi dei frutti sono tutte celle d’intestazione, cioè elementi TH, mentre le celle che contengono i valori nutrizionali sono tutte celle di dati (elementi TD).

La tabella in Figura 8.2 esemplifica i due tipi di relazione appena descritti. Questo modello può essere utilizzato per identificare le celle da marcare con l’elemento TH in un’infinita serie di tabelle, basate sulla duplice relazione proprietà/valore, oggetto/valore. La disposizione delle proprietà in riga e degli oggetti in colonna non è tassativa: ha senso anche la dislocazione inversa, con gli oggetti in riga e le relative proprietà in colonna.

Inizio pagina

Celle che agiscono come intestazione e come dati

È importante precisare che le celle d’intestazione possono stratificarsi su più livelli. È possibile, cioè, che una o più celle d’intestazione siano, a loro volta, specie di un genere. Se, per esempio, riuniamo sotto la categoria “Minerali” le voci “Ferro”, “Calcio” e “Fosforo” della tabella in Figura 8.2, avremo un nuovo livello di intestazione, più generale.

Per quanto riguarda la marcatura, però, queste celle non saranno tutte TH. C’è, infatti, un’indicazione nelle DTD strict e transitional di HTML 4.01, che impone agli sviluppatori – ricordiamo che le DTD sono documenti normativi – di marcare con TD le celle che agiscono, allo stesso tempo, come celle di dati e celle d’intestazione (TH is for headers, TD for data, but for cells acting as both use TD). Pertanto, le voci raccolte sotto l’etichetta collettiva “Minerali” rimangono intestazioni per quanto riguarda i valori numerici già marcati con TD, ma diventano celle di dati rispetto all’intestazione “Minerali”: in presenza di una situazione come quella illustrata in Figura 8.3 vanno perciò marcate non più con TH, ma con TD.

Come distinguere, allora, il ruolo d’intestazione di una cella marcata con TD? Per mezzo di appositi attributi, che saranno descritti nei commenti ai punti di controllo 5.2 e 5.3.

Inizio pagina

Punto di controllo 5.2, priorità 1

Uso dell’attributo scope

Come abbiamo detto, marcare con TH le celle d’intestazione è solo il primo passo verso una completa accessibilità delle tabelle di dati. Ma perché non basta l’uso di TH? In realtà, per le tabelle più semplici, basta e avanza (lo screen reader JAWS, per esempio, considera le celle della prima riga e della prima colonna di una tabella come celle d’intestazione, anche in mancanza di una marcatura specifica). Diventa però insufficiente, quando possono sorgere ambiguità su quale sia il gruppo di celle per il quale una cella TH funge da intestazione. Cosa impedirebbe, per esempio, di considerare la cella “Lazio” della Figura 8.1 A come intestazione per le cinque celle che si trovano sotto di essa invece che per le cinque celle alla sua destra? Inoltre le celle d’intestazione possono essere stratificate su più livelli (Figura 8.3) oppure possono valere per un numero di celle inferiore all’intera lunghezza di una riga o di una colonna o, ancora, possono avere relazioni con celle che si trovano in righe o colonne differenti.

Occorre allora, dovunque un’ambiguità sia possibile, aiutare le tecnologie assistive a fare le giuste associazioni, specificando per mezzo della marcatura quali sono precisamente le relazioni tra celle d’intestazione e celle di dati.

In base alle specifiche W3C il metodo più semplice per chiarire l’estensione del campo di applicazione di una cella d’intestazione è usare l’attributo scope, parola inglese che significa, appunto, “portata”, “ambito”, “raggio d’azione”. Sono quattro i valori possibili di scope:

1. row – indica che la cella corrente fornisce informazioni d’intestazione per il resto della riga di cui fa parte;
2. col – la cella corrente fornisce informazioni d’intestazione per il resto della colonna di cui fa parte;
3. rowgroup – la cella corrente fornisce informazioni d’intestazione per il resto del gruppo di righe di cui fa parte;
4. colgroup – la cella corrente fornisce informazioni d’intestazione per il resto del gruppo di colonne di cui fa parte.

Passiamo dalla teoria alla pratica, applicando l’attributo scope alla tabella di Figura 8.2. Vi aggiungeremo, però, nello spazio vuoto in alto a sinistra, una nuova cella d’intestazione, contenente la voce “Frutti”. Senza l’uso di un metodo per associare le celle tra loro, non è possibile sapere se il campo d’applicazione di questa cella è la riga di cui fa parte o la colonna (una cella non può valere come intestazione per la riga e, allo stesso tempo, per la colonna di cui rappresenta l’intersezione).

Si noti che l’inserimento dell’intestazione “Frutti” ha richiesto di trasformare le celle che contengono i nomi dei frutti da elementi TH a elementi TD: agiscono, infatti, allo stesso tempo da celle d’intestazione per la riga di cui fanno parte e da celle di dati per l’intestazione “Frutti”.

La Figura 8.4 mostra graficamente le relazioni tra le celle della tabella.

Come dovrebbe essere letta una simile tabella da uno screen reader conforme alle Specifiche W3C? Premettendo a ogni cella di dati le celle d’intestazione che la contestualizzano. Per esempio:

pere, kilocal. × 100 g.: 41; pere, ferro mg.: 0,3; pere, calcio mg.: 6; pere, fosforo mg.: 11;

pesche, kilocal. × 100 g.: 27; pesche, ferro mg.: 0,4; pesche, calcio mg.: 4; pesche, fosforo mg.: 20; ecc.

In realtà le modalità di riproduzione delle tabelle marcate per l’accessibilità variano da uno screen reader all’altro e a seconda delle impostazioni scelte dall’utente, ma ciò che non dovrebbe mai mancare, in uno screen reader ben progettato, sono dei comandi per consentire all’utente di navigare tra le celle a propria discrezione e farsi leggere, all’occorrenza, tutte le informazioni d’intestazione di ogni singola cella. Tuttavia, il supporto per l’attributo scope è, in base alle prove che abbiamo svolto, molto carente. JAWS, per esempio, anche nelle versioni più recenti, non sembra in grado di rendere in modo appropriato le relazioni tra celle stabilite per mezzo di questo attributo, almeno in una tabella come quella di Figura 8.4, nella quale prendono il sopravvento le scelte automatiche del programma nel determinare le celle d’intestazione e l’ambito in cui agiscono.

Inizio pagina

Uso combinato degli attributi headers e id

Per le tabelle di dati più complesse, l’unico modo per creare associazioni inequivocabili tra celle d’intestazione e celle di dati consiste nell’usare gli attributi correlati headers e id.

Il funzionamento è il seguente. L’attributo id, in base alle DTD di HTML e XHTML, deve avere un valore unico per l’intero documento: non possono esistere due elementi con id uguale. Pertanto, inserire un attributo id con un dato valore in una cella d’intestazione rende quella cella unica e riconoscibile all’interno dell’intero documento. Tutte le celle di dati che dipendono da quella cella d’intestazione possono richiamarsi a quel valore di id per mezzo dell’attributo headers. Se, dunque, una cella ha un valore di headers uguale al valore di id di un’altra cella, per una tecnologia assistiva conforme significa che la seconda è una cella d’intestazione della prima e il suo contenuto dovrà, perciò, essere letto prima di quello della cella con l’attributo headers, in modo da rendere manifesta all’utente la relazione tra le due celle.

Il Listato 8.4 mostra un esempio ridotto all’essenziale di un simile meccanismo di associazione.

Una tecnologia assistiva conforme dovrebbe leggere il contenuto delle due celle TD nel modo seguente: “nome: Giuseppe; cognome: Mazzini”.

Perché allora non usare il meccanismo di associazione tra headers e id per rendere accessibile la tabella del Listato 8.1? Le associazioni da inserire sono elementari, come mostra il Listato 8.5.

Purtroppo una simile tabella non sarà veramente accessibile perché ha un solo livello di intestazioni di riga e di colonna. In un caso simile, prende il sopravvento nello screen reader, a meno di non modificare le sue impostazioni predefinite, il meccanismo di attribuzione automatica del ruolo di intestazione di riga alla prima cella disponibile della prima colonna. Ciò fa sì che “Avellino”, invece di “Campania”, sia considerata impropriamente la cella d’intestazione del secondo blocco, anche in presenza di una marcatura come quella del Listato 8.5. Tuttavia il codice di questo listato ci è servito come un primo approccio per “scaldare i muscoli”, in vista dell’esempio ben più complesso che esamineremo tra breve.

Prima, però, dobbiamo aggiungere un paio di informazioni. Innanzitutto, una cella di dati può essere collegata a più di una cella d’intestazione. Per esempio, il valore 2,6 nella tabella riprodotta in Figura 8.2 dipende dalle celle d’intestazione “Ferro mg.” e “Noci”. In tal caso, il valore dell’attributo headers deve riportare i valori di id di entrambe le celle d’intestazione da cui dipende. Un attributo headers può contenere, infatti, più valori separati per mezzo di spazi, in base a quanto stabiliscono le Specifiche HTML 4.01.

Inoltre, dato che una cella può agire allo stesso tempo da cella d’intestazione e di dati, è possibile che essa contenga sia un attributo id sia un attributo headers.

È arrivato dunque il momento di mettere insieme tutte queste informazioni, proponendo un esempio di tabella di dati con vari livelli di celle d’intestazione e con relazioni tra le celle stabilite per mezzo dell’uso combinato degli attributi headers e id.

La tabella in Figura 8.5 è una versione più complicata del modello di tabella in Figura 8.2. In questa nuova tabella, ogni valore numerico ha un vero e proprio “albero genealogico”. Prendiamo un valore a caso: per esempio il 21,3 che si trova nella cella immediatamente a destra della cella “proteìne”. Se, per contestualizzarlo relativamente alla riga, basta fare riferimento appunto alla cella “proteìne”, per contestualizzarlo relativamente alla colonna non basta riferirlo soltanto a “magra”, che è la cella d’intestazione direttamente collegata al valore 21,3. Infatti, “proteine, magra: 21,3” non significa nulla, se letto fuori contesto. L’“albero genealogico” completo, relativamente alla colonna, è: carne > fresca > bovino > vitellone > magra. Dunque, per far capire a un ascoltatore che cosa rappresenta quel 21,3, è necessario che lo screen reader possa leggere in sequenza: “carne, fresca, bovino, vitellone, magra, proteìne: 21,3”. Analogamente, il valore 1725 nell’ultima cella in basso a destra può essere compreso e contestualizzato rispetto all’intera tabella solo se la sintesi vocale è in grado di leggere “carne, conservata, suino, prosciutto, cotto, kilojoules: 1725”.

La Figura 8.6 presenta il quadro d’insieme di tutte le relazioni tra le celle della tabella, definite per mezzo di attributi headers e id. Dato il loro numero, consigliamo al lettore di aiutarsi con la seguente legenda, che permette di decifrare l’”albero genealogico” di ciascuna cella:

• C = carne; CF = fresca; CC = conservata; B = bovino; S = suino; P = pollame;
• VI = vitellone; BA = bovino adulto; FA = faraona; SA = salsiccia; PT = prosciutto;
• M1 = (vitellone) magra; S1 = (vitellone) semigrassa; G1 = (vitellone) grassa;
• M2 = (bovino adulto) magra; S2 = (bovino adulto) semigrassa; G2 = (bovino adulto) grassa;
• PE = petto; CO = coscia; FR = fresca; SE = secca; CR = crudo; CM = crudo magro; CT = cotto;
• PR = proteine; LI = lipidi; GL = glucidi; KC = kilocalorie; KJ = kilojoules.

In base a tale legenda, se una cella di dati contiene la sequenza di valori di headers C CF P FA CO PR, significa che lo screen reader, per contestualizzarne il contenuto, deve premettere alla lettura del valore della cella la lettura in sequenza delle intestazioni: “carne” (C), “fresca” (CF), “pollame” (P), “faraona” (FA), “coscia” (CO), “proteine” (PR).

Il Listato 8.6 riporta il codice di marcatura della tabella in Figura 8.5. I contenuti messi in evidenza col grassetto saranno analizzati nel paragrafo successivo. L’uso degli elementi THEAD e TBODY verrà descritto nel Capitolo 17. L’attributo summary, che compare nell’elemento TABLE, sarà trattato diffusamente nel commento al punto di controllo 5.5, più avanti in questo stesso capitolo (il simbolo --> nel Listato indica che il testo nel codice di marcatura va scritto di seguito, anche se nella pagina stampata va a capo).

Inizio pagina

Accorgimenti per l’accessibilità delle tabelle di dati

La prima cosa da dire, commentando il codice del Listato 8.6, è che realizzare la marcatura di una tabella di questo tipo non è né breve né semplice. Affinché l’esito finale sia soddisfacente, è indispensabile controllare con certosina pazienza l’esatta corrispondenza tra gli id delle celle d’intestazione e gli headers delle celle di dati.

Inoltre, ha importanza anche l’ordine in cui sono elencati i valori dell’attributo headers, se sono più d’uno. Ascoltare “carne, fresca, bovino, vitellone, magra, proteìne: 21,3” è cosa diversa dall’ascoltare “carne, proteìne, bovino, fresca, magra, vitellone: 21,3”. La prima sequenza è significativa e comprensibile, la seconda no. Per ottenere un ordine di lettura corretto, è necessario inserire i valori di headers in una sequenza significativa.

Alla fine, però, tutto rimane affidato alla tecnologia assistiva utilizzata dall’utente: spetta a essa, infatti, decidere se riprodurre l’ordine delle intestazioni così come l’ha codificato lo sviluppatore, oppure secondo un ordine diverso, dipendente dai propri algoritmi interni.

Ciò premesso, l’uso di headers e id resta il primo e indispensabile accorgimento per l’accessibilità di una tabella di dati complessa come quella in Figura 8.5.

Tolto l’uso dell’attributo summary, che esamineremo nel commento al punto di controllo 5.5, un secondo accorgimento utile è l’uso dell’elemento CAPTION, che serve per generare una didascalia visibile per la tabella. Si veda sull’argomento anche il paragrafo Uso di CAPTION e dei raggruppamenti di righe e colonne, nel Capitolo 17.

Un terzo, e poco conosciuto, accorgimento per l’accessibilità – visibile nel codice del Listato 8.6 e anche in Figura 8.5 – è l’inserimento di accenti all’interno di alcune parole. Nella nostra tabella, accenti sono stati inseriti sulla “i” della penultima sillaba delle parole “proteìne”, “lipìdi”, “glucìdi” e “kilocalorìe” dopo aver constatato che, senza quegli accenti, la pronuncia dello screen reader utilizzato per le prove era sbagliata. Siccome tali parole svolgono nella tabella il ruolo di intestazioni, è importante che l’ascoltatore le capisca bene. Le sintesi vocali hanno la tendenza a leggere le parole del gergo tecnico-scientifico (e anche molte parole comuni) con accenti sbagliati; perciò, inserire gli accenti interni alle parole più difficili è un modo per aiutare il software a produrre una lettura corretta. Si tratta di un accorgimento non essenziale per l’accessibilità, ma che – in determinate circostanze – può rilevarsi senz’altro utile.

Un quarto accorgimento è l’uso dell’elemento ABBR per ottenere la lettura di “kilocalorìe” al posto della sigla kcal, e di “kilojoules” al posto della sigla kj (spesso è necessario usare delle sigle come intestazioni, per evitare l’eccessivo allargamento orizzontale della tabella, che è di per sé una causa di inaccessibilità). Purtroppo il contenuto esteso di ABBR (e di ACRONYM) non viene letto in modo predefinito dagli screen reader. Se l’utente è sufficientemente evoluto da abilitarne la lettura modificando le impostazioni di base del suo lettore di schermo, potrà ricevere l’informazione completa, altrimenti gli toccherà ascoltare sigle più o meno incomprensibili.

Il quinto e ultimo accorgimento, il più importante di tutti, è il test sul campo. Noi abbiamo verificato la reale accessibilità della tabella nel Listato 8.6, sottoponendola all’esame di un amico non vedente, Nunziante Esposito, membro della Commissione O.S.I. dell’Unione Italiana dei Ciechi e degli Ipovedenti . Abbiamo chiesto a Esposito di navigare la tabella con uno screen reader e di rispondere alle tre domande seguenti:

1. qual è il valore dei lipidi per la carne di bovino adulto magra?
2. quante chilocalorie fornisce il petto della faraona?
3. qual è l’apporto di proteine del prosciutto crudo magro?

Le sue testuali risposte sono state le seguenti:

1. carne fresca bovino adulto magra lipidi: 5,1;
2. carne fresca pollame faraona petto chilocalorie: 107;
3. carne conservata suino prosciutto crudo magro proteine: 28,6.

Non solo i valori numerici forniti sono esatti per confronto con la Figura 8.5, ma la forma delle risposte ci dice senza ombra di dubbio che lo screen reader usato da Esposito ha reso, per ciascuna cella di dati, tutte le intestazioni del suo “albero genealogico”, e le ha rese nell’ordine corretto: il che era esattamente lo scopo che intendevamo raggiungere.

Inizio pagina

Inizio pagina

Inizio pagina

Punto di controllo 5.3, priorità 2

Tabelle d’impaginazione che non si trasformano elegantemente

Una tabella d’impaginazione (layout table) non serve per incasellare dati di natura realmente tabellare, come un indirizzario o un calendario mensile. Serve per posizionare in punti specifici della pagina dei pezzi di contenuto, secondo una disposizione che risponde a una sua logica (estetica o contenutistica), che non è, però, quella della relazione diretta, orizzontale e verticale, tra i dati inseriti nelle celle.

La tabella d’impaginazione è in sostanza una griglia, una sorta di rastrelliera virtuale alla quale attaccare, nella posizione che si ritiene più comoda o gradevole, i vari pezzi che compongono il puzzle di contenuti di un documento o di una sua parte. Così come a una rastrelliera fisica è possibile attaccare degli oggetti – per esempio cappelli, ombrelli, biciclette ecc. – in una qualsiasi posizione libera, senza che vi sia necessità di rispettare un ordine particolare, allo stesso modo nella rastrelliera virtuale di una tabella d’impaginazione si possono inserire dati che non hanno nessun rapporto reciproco diretto e vincolato dalla sequenza.

L’ordine e la coerenza dei dati inseriti in una tabella d’impaginazione non derivano dall’ordine logico e sequenziale delle celle, ma dall’aspetto grafico con cui la tabella e i suoi contenuti sono formattati: è per questa ragione che l’uso delle tabelle a scopo d’impaginazione è considerato a rischio per l’accessibilità. È possibile, infatti, che ciò che appare sensato alla vista, non lo sia affatto quando viene fruito in modalità testuale o attraverso uno screen reader.

Come verificare la sensatezza e la coerenza dei dati inseriti in una tabella d’impaginazione? È possibile farlo per mezzo di un procedimento chiamato linearizzazione (o serializzazione).

Consiste nell’estrarre i dati da una tabella, partendo dalla prima cella in alto a sinistra e continuando verso destra e verso il basso, fino a quando non si è raggiunta l’ultima cella in basso a destra (per le lingue che si scrivono da destra a sinistra, il procedimento va invertito, partendo dalla prima cella in alto a destra, invece che dalla prima a sinistra). I blocchi di dati estratti dalle celle vanno inseriti, nello stesso ordine in cui sono estratti, in una serie di paragrafi o di punti elenco successivi: tante sono le celle della tabella, tanti saranno i paragrafi o i punti elenco generati. La lettura sequenziale dei contenuti estratti dirà chiaramente se la tabella linearizzata ha senso, come richiede il punto di controllo 5.3, oppure no.

Ma perché la linearizzazione rende conto dell’accessibilità di una tabella d’impaginazione? Il motivo è che la lettura dei suoi contenuti da parte di un sintetizzatore vocale segue esattamente l’ordine seguito dalla linearizzazione: se i contenuti linearizzati hanno senso, avranno senso anche quando letti da un sintetizzatore vocale.

Un esempio aiuterà a capire quali sono le tabelle d’impaginazione che non hanno senso una volta linearizzate. Consideriamo una tabella come la seguente.

Tabella 8.1 Una tabella d’impaginazione che perde senso una volta linearizzata

Elementi grafici decorativi	Arte	Elementi grafici decorativi	Computer
	Antiquariato, Architettura, Artigianato, Cinema, Danza, Fotografia, …		Acquisti, Aziende, E-book, Grafica, Hacking, Hardware, …
Elementi grafici decorativi	Scienza	Elementi grafici decorativi	Sport
	Ambiente, Astronomia, Biologia, Chimica, Fisica, Medicina, …		Allenamento, Arti marziali, Atletica, Attrezzatura, Ciclismo, Disabili, …

Questa tabella riproduce una struttura di presentazione visuale simile a quella usata, fino a qualche anno fa, da molti motori di ricerca organizzati a directory, contenenti cioè vasti cataloghi di collegamenti ad altri siti, suddivisi per categorie. Usando il procedimento di linearizzazione descritto in precedenza e non considerando gli elementi grafici decorativi, otteniamo la seguente sequenza di contenuti:

1. Arte
2. Computer
3. Antiquariato, Architettura, Artigianato, Cinema, Danza, Fotografia, ...
4. Acquisti, Aziende, E-book, Grafica, Hacking, Hardware, ...
5. Scienza
6. Sport
7. Ambiente, Astronomia, Biologia, Chimica, Fisica, Medicina, …
8. Allenamento, Arti marziali, Atletica, Attrezzatura, Ciclismo, Disabili, ...

In questo caso la relazione logica tra nome della categoria e contenuto viene persa con la linearizzazione: le voci “antiquariato” e “architettura” a quale categoria appartengono? E la voce “scienza” a quali contenuti rimanda? Come si capisce che è un’intestazione?

La precedente è, insomma, una tabella in cui la linearizzazione non produce una trasformazione elegante (graceful transformation) dei contenuti. Perciò, non dovrebbe essere usata in un documento che aspira a essere accessibile. Se proprio non si può fare a meno di inserire una tabella simile in una pagina web, dovrebbe essere accompagnata da una versione linearizzata accessibile, che può essere realizzata, per esempio, per mezzo di un elenco di definizioni.

Vale la pena di precisare, comunque, che, almeno negli ultimi tempi, è diventato piuttosto difficile trovare sul Web tabelle d’impaginazione che perdono significato in seguito alla linearizzazione. Per quanto, dunque, le tabelle continuino a essere utilizzate largamente in modo improprio (cioè per posizionare blocchi di contenuti e non per incasellare dati tabellari), tuttavia il danno reale per l’accessibilità, almeno nel caso della navigazione con sintesi vocali, è relativamente limitato.

Il danno vero provocato dalle tabelle d’impaginazione è quello inferto alla flessibilità dei contenuti in modalità grafica: le impaginazioni realizzate con tabelle sono rigide e mal si adattano alla fruizione con caratteri ingranditi o con dispositivi dallo schermo piccolo. Altro danno non trascurabile è quello prodotto dall’aumento, a volte sconsiderato, del peso e della complessità dei documenti, soprattutto quando abbondano le tabelle annidate e l’uso di elementi e attributi di presentazione.

Inizio pagina

Punto di controllo 5.4, priorità 2

Non usare TH per le tabelle d’impaginazione

Il punto di controllo 5.4 ha lo scopo di evitare che una marcatura strutturale usata impropriamente possa confondere chi usa un sintetizzatore vocale, dandogli l’idea che vi siano tra i contenuti della tabella relazioni gerarchiche che potrebbero non sussistere.

Il caso tipico è l’uso dell’elemento TH per ottenere un effetto di testo in grassetto, allineato al centro della cella. Al posto di TH è consigliabile, ovviamente, usare le proprietà di formattazione dei fogli di stile (nel caso specifico, text-align: center per l’allineamento centrato e font-weight: bold per il grassetto).

Inizio pagina

Punto di controllo 5.5, priorità 3

Uso dell’attributo summary di TABLE

Nelle tecniche HTML per le WCAG 1.0 viene fornita la seguente spiegazione, per chiarire l’importanza del punto di controllo 5.5:

I sommari sono utili specialmente per chi legge in modalità non visuale. Un sommario delle relazioni fra le celle è importante soprattutto per tabelle con intestazioni annidate, celle che si espandono su colonne o righe multiple, o altre relazioni che possono non risultare ovvie dall’analisi della struttura della tabella, ma apparire evidenti in una riproduzione visuale della tabella. Un sommario può anche descrivere in che modo la tabella rientra nel contesto del documento in cui è inserita. Se non è presente una didascalia, è assolutamente fondamentale fornire un sommario.

Il sommario di una tabella viene fornito per mezzo dell’attributo summary dell’elemento TABLE. Per capire come impostare il valore di summary, può essere utile pensare al tipo di descrizione del contenuto della tabella che faremmo parlando al telefono con qualcuno a cui vogliamo spiegare ciò che stiamo vedendo.

A proposito di questo punto di controllo, è sorta nel tempo una disputa tra gli sviluppatori: l’attributo summary deve essere inserito anche nelle tabelle d’impaginazione? E se sì, che testo deve recare?

Secondo alcuni, la scelta migliore sarebbe usare l’attributo e dargli come valore Tabella a scopo d’impaginazione, o qualcosa di simile: l’idea è quella di fornire all’utente che naviga in modalità non visuale la minima informazione necessaria, per capire che la tabella in cui si è imbattuto non contiene dati realmente tabellari. Un altro partito sostiene l’idea di non usare affatto summary nelle tabelle d’impaginazione, perché l’informazione fornita sarebbe inutilmente prolissa, secondo l’idea che agli utenti interessano solo i contenuti, e che siano rapidamente e comodamente fruibili, non le informazioni sul contenitore (cioè il codice di marcatura). Un terzo partito sostiene invece l’utilità, tutta legalistica, di avere un summary vuoto (summary=""), in modo da soddisfare almeno formalmente la richiesta del punto di controllo 5.5 e ottenere il superamento delle validazioni automatiche di accessibilità.

Gli estensori delle WCAG 2.0 sembrano intenzionati a risolvere il conflitto di vedute a monte, eliminando la presenza dell’attributo summary dal novero dei requisiti per la conformità alle linee guida. Tuttavia specificano che nelle tabelle a scopo d’impaginazione questo attributo deve essere o omesso o vuoto, risolvendo così la questione anche nel merito (si veda http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#F46 ).

Inizio pagina

Punto di controllo 5.6, priorità 3

Uso dell’attributo abbr di TH e TD

Uno screen reader con adeguato supporto per l’accessibilità deve essere in grado di premettere, alla lettura del contenuto di ciascuna cella di dati, la lettura del contenuto di tutte le celle d’intestazione che vi sono associate. Se una cella d’intestazione contiene un testo molto lungo, la sua lettura ripetitiva da parte di un sintetizzatore vocale rischia di diventare molto noiosa. Per abbreviare i tempi di lettura, il punto di controllo 5.6 suggerisce di impostare abbreviazioni per i contenuti di TH giudicati troppo lunghi, usando a questo scopo l’attributo abbr, come nell’esempio seguente.

Nella realtà quotidiana del Web, si verifica più facilmente il caso opposto: in una tabella che ha un ampio sviluppo orizzontale, è spesso necessario abbreviare i testi nelle celle d’intestazione, che devono poi essere resi accessibili fornendo la forma estesa delle abbreviazioni tramite elementi ABBR o ACRONYM, come è stato fatto nel Listato 8.6 per le sigle kcal. e kj.

Inizio pagina