Tabelle, stili e modalità d'uso
Come creare tabelle accessibili per i layout e per i dati
A cura di Roberto Ellero | giovedì 17 luglio 2003
di Jim Byrne, The Making Connections Unit, January 2002.
articolo originale di Jim Byrne: http://www.mcu.org.uk/articles/tables.html
In questo articolo troverai:
· una discussione sull'opportunità di utilizzare le tabelle o i fogli di stile CSS per i layout di pagina
· tecniche per realizzare layout tabellari accessibili
· tecniche per realizzare tabelle di dati accessibili

Possiamo ancora utilizzare la tag 'table' per realizzare layout?
So che è una buona cosa realizzare siti accessibili, e che questo comporta scrivere codice HTML standard, ma mi sono spesso chiesto se fosse opportuno (ab)usare degli elementi di tabella per fare layout di pagina. Posso evitare l'uso improprio delle tabelle e sentirmi a posto, realizzare pagine accessibili, tuttavia mi troverei limitato nelle opzioni di design.
Per converso, posso abbracciare l'uso delle tabelle, che destruttura il codice confondendo la struttura con la presentazione, e comporre le mie pagine secondo l'estro della mia immaginazione.
Se sono un designer in gamba posso trarne giovamento riguardo l'usabilità del sito per la maggior parte dei visitatori.
E' stato un arduo dilemma, ma credo di essere giunto a una conclusione. Fino a quando i fogli di stile presenteranno gli attuali problemi, la tag table sarà mia amica.
Il controllo del layout è importante, ma sia che utilizzi i CSS, sia che adotti le tabelle o entrambi, non esiste una soluzione davvero soddisfacente.
I fogli di stile sono una scelta possibile, ma attualmente il loro uso costringe a sostituire i 'table hacks' con i 'CSS hacks': di fatto si devono escogitare workaround, si devono aggirare i bachi dei diversi browser e le incompatibilità.
E' indicativo dell'attuale stato dell'arte sui CSS che il World Wide Web Consortium (W3C ), nel quale si sviluppa il WAI (Web Accessibility Initiative), utilizzi ancora tabelle di layout per le proprie pagine.
Le linee guida per l'accessibilità dei contenuti del WAI riconoscono che i designer continueranno a usare tabelle per i layout - perciò includono informazioni su come si possono implementare nel modo più accessibile.
I designer non stanno andando con immediatezza verso l'abbandono delle tabelle di layout; questo principalmente perché gli editor visuali, editor WYSWYG (what you see is what you get), sono costruiti per facilitare la gestione delle tabelle, mentre è difficile controllare in modo visuale i CSS.
Questo tuttavia non autorizza ad ignorare il problema, o a dire che è sbagliato usare i fogli di stile.
Un più sensibile approccio è assicurare che le pagine realizzate siano in ogni caso accessibili.
Prima di addentrarmi nell'uso delle grandi potenzialità delle tabelle per il design, indugiamo per un po' a vedere cosa si perde adottando la vecchia politica "tabelle per layout".
Le pagine prive di tabelle di layout sono più veloci nel caricare - talvolta molto più veloci
A parte la home-page, questo sito [http://www.mcu.org.uk ] non fa uso di tabelle di layout - questo ha fatto sì che io ricevessi molte email di richiesta di spiegazioni riguardo la notevole velocità nel caricamento. Per la medesima ragione, Philip Greenspun nel suo libro fondamentale Philip and Alex Guide to Web Publishing stigmatizza l'uso di includere un'intera pagina in una struttura tabellare (credo sia scritto questo nel libro - sebbene, essendo un libro di notevole mole, non lo abbia ritrovato nel testo. Ma Philip Greenspun ripete il concetto nel suo articolo What can we learn from Jakob Nielsen?).
Il problema della velocità viene sollevato perché tutti i bit di una pagina web, all'interno di una tabella, devono essere caricati prima che si possa visualizzare il contenuto sullo schermo. Questo sicuramente succede con Microsoft Explorer. Così, se ci sono molte tabelle annidate in tabelle e molta grafica all'interno di celle di tabella - e ogni cosa nella pagina è inclusa in una tabella madre - si dovrà aspettare un po' prima di vedere qualcosa sul monitor (l'esperienza credo sia familiare a tutti). Per essere imparziale, non credo che Netscape Navigator lavori in questo modo; tuttavia sembra che la quota di mercato per Netscape stia perdendo terreno ultimamente.
Quindi, se la velocità è un tema importante (e quando non lo è?), usare tabelle di layout significa rallentare la visualzzazione delle pagine.
Le pagine che non usano tabelle di layout tendono ad essere più accessibili.
Una gran parte delle pagine senza tabelle sono ad una sola colonna con la navigazione ad inizio o a fine pagina - questa è una buona cosa per i non vedenti e per gli ipovedenti, e per coloro in generale che utilizzano screen reader di vecchia generazione. Il checkpoint 10.3 nelle linee guida per l'accessibilità (WCAG 1.0) - che riguarda le soluzioni provvisorie - allude a questi casi:
10.3 Fino a quando gli interpreti (comprese le tecnologie assistive) non renderanno in modo corretto il testo su più colonne, predisporre un testo lineare alternativo (nella stessa pagina o in un'altra) per tutte le tabelle che dispongono testo su colonne parallele e affiancate. [Priorità 3]
I lettori di schermo più recenti possono riconoscere colonne affiancate di testo (poiché decodificano sulla base dell'attuale HTML), ma quelli obsoleti leggono da sinistra a destra tutta la pagina, così il testo che si trova sulla stessa riga e in più colonne viene letto come una Linea continua.
Le pagine che non fanno uso di tabelle di layout sono di frequente standard compliant
Se si dovessero seguire gli standard HTML in modo rigoroso, si dovrebbero usare esclusivamente i fogli di stile per il layout di pagina - e ci sono eccellenti ragioni per farlo:
· Le mie pagine sarebbero più leggere e più veloci da caricare (questo inoltre preserva la banda).
· Perderei meno tempo a risolvere i problemi divuti alla incompatibilità fra i diversi browser.
· Sarebbe più facile realizzare siti accessibili a persone con disabilità.
· Le pagine standard compliant funzionano con la maggior parte dei browser e delle piattaforme.
Sfortunatamente, oggi la locuzione "in teoria" è ancora rilevante in relazione ai vantaggi sopra citati. La combinazione di browser datati, che interpretano solo una parte degli standard, e i nuovi browser che li interpretano in modi diversi, fa sì che la pratica del markup non corrisponda alla teoria.
In sostanza, evitare l'uso delle tabelle di layout significa più velocità e più accessibilità per gli utenti degli screen reader. Sono argomenti piuttosto convincenti per continuare a scrivere un HTML ben strutturato in conformità alla sua natura di linguaggio strutturale - e per evitare quella oscura sensazione che si prova quando si scrive HTML snaturato dalla sua origine.
Se quindi ci sono ottimi argomenti per non usarle, perché non dire "stai lontana tabella, deprecabile mostro, il tuo aspetto non è ben accetto qui"?
Per aiutarci a trovare una risposta, dobbiamo porci l'ovvia domanda - è l'abilità nel realizzare i contenuti ad essere importante, piuttosto che la loro disposizione in una singola colonna?
O per dirla in altro modo, dobbiamo avvalerci di bravi Web 'designer' o abbiamo bisogno di gente in grado di gestire in modo efficace i documenti pubblicati su Web?
Naturalmente, la risposta è sì, il design è importante e bravi webdesigner saranno sempre necessari, e non dovrebbe esserci la scelta fra un buon aspetto della pagina e la sua accessibilità. Contrariamente al modo di vedere tipico dei puristi del markup - il content e la sua presentazione non sono completamente separati.
Il design di una pagina Web: il layout; i colori; l'uso dello spazio vuoto; aspetti tipografici ecc. influenzano l'accessibilità (in un senso ampio) dei contenuti.
Design e layout non sono secondari alla comprensibilità - per questo dobbiamo acquisire la consapevolezza dell'importanza del design dal punto di vista della costruzione di siti accessibili (i clienti, comunque sia, ritengono che il visual design sia la parte più importante del loro sito).
E' solo la storia dei limiti del layout in HTML, che ci fa ritenere si debba scegliere fra una delle due cose. Se Tim Berners-Lee avesse avuto un pensiero più ispirato nel 1990, e inventando il Web lo avesse unito fin da subito ai CSS - avremmo noi oggi ancora questi problemi? No, naturalmente, sappiamo che il design è importante - e così anche il markup basato sugli standard. Con una combinazione matura di CSS e XHTML sin dall'inizio, ora saremmo avvezzi all'idea che è possibile generare un numero illimitato di layout con lo stesso markup - potendo vestire le pagine in modo adeguato alle diverse tipologie di pubblico.
La capacità di trasmettere l'informazione con il giusto aspetto in pagine Web è importante per almeno due ragioni:
1. Flessibilità e usabilità. Sia Jakob Nielsen che Steve Krug, nei loro libri sull'usabilità, sottolinenano i benefici che vengono dal fornire ai visitatori pagine dal layout familiare, che possa essere compreso istintivamente. Quali sono i più diffusi layout che troviamo navigando nel Web? Lasciando da parte i più recenti cambiamenti avvenuti negli ultimi tempi, i più comuni layout comprendono più di una colonna di testo. I più dispongono di una barra di navigazione lungo il lato destro o sinistro, e con la parte principale di contenuti sulla destra. Molti layout, naturalmente, sono più complessi e sono organizzati in più colonne.
2. L'aspettativa dei clienti. Le aziende e le organizzazioni che commissionano siti non comprendono che le pagine Web sono diverse dagli altri media più tradizionali.L'esperienza mi ha insegnato che la frase "dobbiamo assicurare di dividere la struttura dalla presentazione costrundo il sito" non significa nulla per la maggior parte dei clienti. (Non significa nulla anche per molti webdesigner, ma questa è un'altra storia). Come designer posso credere possibile educare i clienti, oppure assumere una posizione di retroguardia assicurando sia l'aderenza agli standard di accessibilità dei siti che realizzo (nei limiti consentiti dagli attuali browser), sia la conservazione di un look&feel favoloso.
Ci sono un paio di cose che potresti dirmi per tentare di convincermi che esistono modi accessibili di usare le tabelle di layout:
1. "Jim, non capisci che il Web è diverso dagli altri media - non puoi prevedere quale periferica e quale utente finale siano il tuo target - non è possibile in alcun modo definirli. Ciò che devi comprendere è questo: presentare il content in modo strutturato - lasciando la resa visuale ad un appropriato foglio di stile".
2. "Sì Jim, il layout è importante ma io non ho mai visto una pagina Web con il layout che suggerisci. Sei sicuro che i layout basati su colonne possano aiutare a migliorare l'accessibilità?"
In risposta alla prima osservazione, dico che comprendo perfettamente che la separazione fra presentazione e struttura è importante - vedi 'This HTML Kills' , che scrissi nel 1999 (che in seguito venne pubblicato su A list Apart). Sono un fautore della separazione struttura-presentazione - ma non penso che la questione sia definibile in termini chari, come può sembrare a prima vista. E' importante che il contenuto sia accessibile - nel senso più esteso - e non si può separare del tutto il content dalla sua presentazione. Il modo in cui viene presentata l'informazione è una parte importante del processo comunicativo, e questo include il modo in cui l'informazione viene visualizzata su monitor. Oggi, sia coloro che commissionano siti, sia coloro che ne fruiscono, utilizzano browser su computer desktop e non possiamo ignorarequesta utenza allo stesso modo in cui non possiamo dimenticarci del più ridotto gruppo che usa altre periferiche.
Riguardo la seconda domanda, mi sta bene che non hai mai visto il tipo di layout che propongo per aumentare l'accessibilità. Cerca quello che - per i tuoi interessi - è il più utilizzato nel Web - e copialo per il tuo sito. Fai questo e l'usabilità del tuo sito verrà aumentata. Penso che scoprirai che per copiare il layout prescelto avrai bisogno di analizzare le caratteristiche della tabella o del CSS.
Posto che siamo d'accordo che il design è importante - dobbiamo anche sapere se dovremmo oggi usare i fogli di stile per i layout. Si può utilizzare l'attuale implementazione dei CSS, (su browser attuali o datati) per disegnare pagine in modo da aumentare l'usabilità, l'accessibilità e rendere il design flessibile?
Il gruppo di Web standards ritiene di sì, e crede sia giusto per i designer andare fino in fondo e utilizzare solo HTML standard. Io supporto pienamente l'uso dei fogli di stile per i layout - ma non sono ancora pronti ad un uso su larga scala. Il supporto insufficiente di rilevanti proprietà dei CSS può generare pagine più inaccessibili di quelle fatte con tabelle di layout. Non sono i browser o gli altri user agent che non supportano i fogli di stile il problema, infatti il contenuto viene reso ugualmente seppure in modo diverso dal previsto. Il problema sono i browser che supportano i fogli di stile, ma che sono pieni di bachi ed erronea implementazione degli standard. Questi causano l'inaccessibilità delle pagine, laddove la grafica interviene ad oscurare il testo e le colonne flottanti che si sovrappongono. Vedi Little Shop of CSS Horrors per alcuni esempi di ciò che sto dicendo.
Anche i più recenti e importanti browser (ad esempio Internet Explorer, Netscape, Opera, iCab) non supportano ancora pienamente gli standard. Utilizzare fogli di stile per più di un semplice layout non è ancora alla portata di tutti - dal momento che occorre molto tempo per impadronirsi di tutti i trucchi per aggirare i problemi. Se trovi il tempo per testare con tutti i browser su tutte le piattaforme, allora non posso che venire incontro alla tua idea di liberarti dell'abitudine di usare le tabelle (forse dovremmo tutti prendere parte alla TLA, 'Tables for Layout Anonymous' - ti occupa solo un giorno - o un solo browser - alla volta).
Sono dell'idea che è bene andare verso l'uso dei CSS dell'HTML standard (meglio ancora XHTML). Tuttavia, so che molti designer usano tool che generano tabelle come layout di default - si deve comprendere che il problema esiste e fornire ai designer informazioni su come fare a rendere accessibili i layout tabellari.
Stai agitando le mani in segno di orrore dicendo, 'Jim ha abbandonato i suoi principi sull'accessibilità'. Puoi pensarlo, ma nella seguente parte dell'articolo spiegherò come fare layout tabellari accessibili per tutti i tuoi visitatori, inclusi gli utilizzatori di vecchi screen reader. Così facendo, spero di salvaguardare la mia credibilità come designer di layout accessibili. Attualmente, e nessuno mi ringrazierà per averlo detto, è probabilmente più facile per un Web developer creare pagine accessibili usando tabelle piuttosto che i CSS. Perché le cose cambino, basterà diffondere più informazioni sull'uso corretto dei CSS. Ci sono un sacco di informazioni disponibili sull'accessibilità delle tabelle, e pochissime sui trucchi per aggirare i bachi dei vari browser attualmente in uso.
Principi per rendere accessibili i layout tabellari
Tieni le tue celle in ordine
La prima regola per creare layout tabellari accessibili: assicurarsi che se interpretati da browser che non supportano le tabelle l'informazioni rimanga dotata di senso e nel giusto ordine. Come stabilisce il WAI: fare tabelle in modo che l'informazione presente in esse conservi senso dopo la linearizzazione.
Nei browser che non supportano le tabelle l'informazione è resa come una serie di paragrafi ad iniziare dalla prima cella in alto a sinistra, con movimento verso destra di cella in cella - mostrando i contenuti come vengono trovati. Una volta terminata la prima riga, l'elaborazione della seconda riga prosegue allo stesso modo - e così di seguito fino al termine. E' assai semplice mettere in ordine celle e contenuti, ma segue un esempio per chi è abituato ad imparare in modo visuale.
Un valido strumento che si può utilizzare per ottenere il rendering grafico dell'ordine delle celle nell'output dell'interprete è disponibile qui:
http://www.temple.edu/instituteondisabilities/piat/wave/ [il link apre una nuova finestra]
Il tool si chiama 'WAVE' e numera ciascuna cella di tabella nell'ordine di lettura del browser. WAVE presenta altre interessanti caratteristiche per testare l'accessibilità del tuo sito.
Un altro modo di testare l'accessibilità delle tabelle è vedere la pagina utilizzando un browser "solo testo", come ad esempio Lynx, che si trova al seguente indirizzo: http://lynx.browser.org/ . La versione per Mac si trova qui: http://www.lirmm.fr/~gutkneco/maclynx/.
E' tutto relativo? assolutamente
Il checkpoint 3.4 delle WCAG 1.0 statuisce:
3.4 Usare unità relative e non assolute nei valori degli attributi del linguaggio di marcatura e i valori della proprietà del foglio di stile. [Priorità 2]
Nei CSS, ad esempio, usare "em" o misure in percentuale invece di "pt" o "cm", che sono misure assolute. Se si usano misure assolute assicurarsi che il contenuto reso sia usabile (vedi la sezione sulla validazione).
Perché seguire queste indicazioni? Perché non è possibile stabilire a priori come l'utente finale vedrà la pagina e in quale modo vi accede; la pagina può essere visualizzata attraverso una TV o un palmare, oppure grazie ad una console giochi. Si prenda ad esempio una sola variabile: la dimensione dello schermo.
Quando disegnamo una pagina Web, non conosciamo la dimensione e la risoluzione del monitor degli utenti.
Non ha pertanto senso definire in pixel, in modo fisso, altezza e larghezza del layout, è prefereibile certamente definire le dimensioni in percentuale. Così facendo, le pagine verranno visualizzate in modo corretto senza riguardo alle dimensioni del monitor. (Approfondirò il tema del design per i diversi schermi in un prossimo articolo).
Nella tradizionale grafica su carta il designer sa ogni minimo dettaglio circa il risultato finale; le dimensioni, i colori, come verrà visto il design, come appariranno gli aspetti tipografici ecc.
Nel Web non è così - tutto ciò che si può fare è applicare un design flessibile - in modo da consentire una gradevole trasformazione del design e la sua accessibilità sulla più vasta gamma di periferiche utilizzabili.
Ci sono aree dove l'usabilità e un Web design accessibile possono confliggere. Ad esempio, una ricerca rivela che la migliore lunghezza di riga, per una lettura confortevole, è di 10/12 parole.
Con un approccio a misure relative, possiamo fare assai poco per adeguarci a questa misura.
Evitare la barra di navigazione
Avevo detto più sopra che è una buona idea usare una barra di navigazione, sulla sinistra di ciascuna pagina (non intendo limitare lo stile di alcuno, sentiti libero di ignorare la mia opinione). Questa è l'opinione mia e di Jeffrey Zeldman, ma tieni a mente che ciò può creare problemi a chi usa un lettore di schermo.
Ho poc'anzi descritto l'ordine di lettura delle tabelle - questo implica che se la navigazione è a sinistra, lo screen reader andrà incontro in ogni pagina ad una serie di link ripetuti.
Un visitatore che usa lo screen reader dovrà passare a rassegna in ciascuna pagina una lunga serie di link prima di giungere al contenuto.
Gli screen reader non possono fornire in modo agevole una panoramica di una pagina Web, onde consentire all'ascoltatore di andare velocemente all'informazione che interessa (alcuni browser vocali di nuova concezione possono farlo, ma solo se la pagina presenta un markup strutturato). Questa è la principale causa di perdita di tempo per i non vedenti e ipovedenti che utilizzano questi strumenti. Come risolvere il problema? Jim Thatcher, nel suo eccellente sito http://www.jimthatcher.com/ (dedicato a chi intende conformarsi con la Section 508 in America), suggerisce molti modi creativi di eliminare la marmellata di link [navigation jam].
Tutti sono meritevoli di attenzione, ma uno in particolare lo prediligo: un semplice link che invia al contenuto della pagina. Qui di seguito un esempio. Nel sito che promuove tutto ciò che di bello si può trovare nel West End of Glasgow, gestito da mia moglie Pat, la navigazione è consentita da una barra laterale sinistra in ciascuna pagina. Ad inizio pagina ho inserito il seguente codice HTML [il sito è stato modificato e non presenta le caratteristiche descritte]:
<A href="#maintext"><img src="http://www.glasgowwestend.co.uk/images/spacepixels.gif" height="2" width="2" hspace="0" vspace="0" alt="Skip over navigation bar" border="0"></A>
Questo aggiunge un'immagine con un testo alternativo - invisibile ai più - ben in evidenza a chi naviga con grafica disabilitata o con un browser solo testo. L'immagine collega ad un'ancora più in basso nella pagina, proprio in corrispondenza dell'inizio del testo principale. Questo si ottiene con il seguente codice:
<A name=maintext></A>
L'uso di questa tecnica non influenza il layout della pagina se visto con un browser grafico, nell'immagine si può vedere come il link appare in linx per Mac:

Fornire un efficace sommario
Un'altra utilissima tecnica per facilitare l'accesso alle tabelle è fornire del testo all'interno dell'elemento TABLE che costituisca un riassunto del contenuto della tabella. Questo si ottiene utilizzando l'attributo "summary". E' probabilmente più utile con le tabelle di dati, dove le relazioni fra le celle di tabella possono essere complesse, ma è altresì utile per i layout basati su tabelle. Un esempio di sommario potrebbe essere:
<TABLE summary="Questa è una tabella di layout. La colonna di sinistra contiene la barra di navigazione e la colonna di destra contiene il testo principale">
Per tabelle di dati complesse l'attributo "summary" può essere usato per fornire una versione testuale del contenuto attuale della tabella (sebbene per le tabelle con molti contenuti questo sia impraticabile), o per indicare che un link a una versione testuale è disponibile prima o dopo la tabella.
Non trattare le tabelle di layout come tabelle di dati
I consigli che seguono sono gentilmente forniti dal sito Idyll Mountain Internet.
· Quando si creano layout non si utilizzi <th>, <thead>, <tbody>, <caption>, ecc. Questi attributi hanno senso soltanto per dare una struttura alle tabelle di dati. Si eviti l'uso dell'attributo title nei layout basati su tabelle - sia nel tag table che nel tag td - poiché si evidenziano inutili tool tips.
· Colspan, rowspan e/o tabelle annidate possono essere utilizzati per far funzionare le tabelle in modo grafico e linearizzate.
Le tue alternative vacillano (o la tua tabelle non viene resa)?
Se tutto fallisce e non riesci ad assicurare che la tua tabella sia accessibile agli utenti di browser solo testo e vocali, dovresti fornire una versione alternativa solo testo dell'informazione contenuta dalla tabella. Inserisci un link alla versione alternativa prima dell'inizio della tabella - non all'interno della tabella stessa.
Potrebbe sembrare ovvio - ma mi è capitato molte volte di osservare questa 'tecnica' di disporre il link alla versione accessibile all'interno di una tabella non accessibile.
Netscape 1.1 (uscito nella metà degli anni '90) è stato il primo browser a riconoscere le tabelle. Alcuni browser non in grado di interpretare le tabelle non rendono in modo comprensibile il contenuto basato su tabelle. L'unico modo di venire incontro a chi usa questi vecchi browser è fornire una alternativa ad una sola colonna.
Per le ragioni che ho menzionato prima, sono riluttante a incoraggiare l'eliminazione delle tabelle di layout - nonostante il fatto precedente - e nonostante la consapevolezza che il loro uso va contro gli attuali standard HTML.
Ok, quanto detto è sufficiente per l'argomento layout tabellari accessibili - è il momento di parlare del corretto uso dell'elemento TABLE, ad esempio per l'informazione tabellare come gli orari degli autobus, i programmi televisivi, risultati di esami ecc.
Queste sono le tipologie di contenuto strutturato per le quali venne creato l'elemento table.
Solitamente queste tabelle di dati presentano intestazioni in alto e/o lungo un lato.


Tabelle di dati accessibili
Il primo passo verso la realizzazione di tabelle di dati accessibili è l'utilizzo corretto delle tag standard come TH, TD e (da HTML 4) CAPTION e SUMMARY.
Usate in modo appropriato, queste tag corredano la tabella di preziose metainformazioni.
Si dovrebbero utilizzare le seguenti tag per indicare le tipologie di contenuti:
· TH per le intestazioni
· TD per i dati
· CAPTION per dare alla tabella un breve titolo - che indichi i contenuti in generale.
L'attributo summary può essere utilizzato per fornire una dettagliata descrizione dello scopo della tabella - per aiutare chi usa la barra Braille o un browser vocale.
Può inoltre essere usato per spiegare meglio le finalità e i contenuti della tabella, se è molto complessa.
Ho visto esempi dell'uso dell'elemento summary come ripetizione integrale dei contenuti di una tabella - come alternativa al fornire un link ad una versione solo testo.
Ecco il codice relativo all’esempio proposto in precedenza: esempio_1.txt
L'attributo summary non è visibile a chi usa un browser di tipo standard GUI (Graphical User Interface) - ma viene interpretato dalla barra Braille e dai lettori di schermo.
Non è probabilmente una buona idea inserire un attributo summary in tutte le tabelle di layout (molti layout sono costituiti da innumerevoli tabelle anche annidate).
Se ti infastidisce il fatto che le tue pagine non passano la validazione di Bobby perché non hai inserito tutti i summary nelle tabelle (a parte quella principale) potrebbe essere una buona idea aggiungere un breve sommario come 'tabella di layout', o mettere l'attributo summary ma con un semplice spazio come contenuto.
Gli Headers sono per default centrati nelle celle. Non sono sicuro se molti usano la tag TD per le intestazioni invece della tag TH per questo motivo, ma se è così è bene notare che allineare gli Header è assai semplice. La cosa migliore è usare un foglio di stile per allineare le intestazioni a sinistra o a destra - ma l'attributo align lavora comunque bene in TH, ad esempio:
<TH align="left" style="text-align: left">Jim</TH>
Ho usato uno stile interno alla tag per esemplificare - ma è preferibile definire gli attributi di stile in un CSS esterno o nello Head del documento. Questo assicura che gli utenti con il loro proprio foglio di stile potranno annullare le tue preferenze.
Se utilizzi un foglio di stile per definire gli attributi della tua tabella puoi comunque lasciare i vecchi. Il tuo CSS annullerà i valori definiti all'interno delle tag, così come succederà con il foglio di stile personalizzato di un utente. Gli attributi datati, all'interno delle tag, consentiranno di visualizzare bene la tabella anche a chi usa un browser che non supporta i fogli di stile.
Come corollario, non usare TH come un modo di ottenere in una qualsiasi cella testo in grassetto e centrato - usa invece TD con l'appropriato markup di presentazione - preferibilmente con un foglio di stile.
Realizzare tabelle complesse accessibili
Finora, in relazione alle tabelle di dati, ogni cosa è stata ben comprensibile; nulla è stato detto finora, in grado di affaticare la tua corteccia cerebrale.
I problemi di accessibilità iniziano quando si devono realizzare tabelle più complesse, con molte tabelle e colonne.
Il problema centrale è come assicurare che le relazioni fra le intestazioni di tabella e i dati rimangano trasparenti a chi utilizza uno scrren reader o la barra Braille.
Se sei un utente accorto si tratta di una procedura semplice; guardi all'intestazione e percorri la colonna - o lungo una riga - per leggere i dati associati all'intestazione. Detto questo, come sa chi abbia tentato qualche volta ad insegnare statistica a studenti, ho notato che anche per utenti esperti interpretare tabelle non è un esercizio così facile - ma per il momento ignoriamo questo problema.
Come noto, le tecnologie assistive come gli screen reader o i display Braille leggono i dati tabellari una riga alla volta, da sinistra a destra e dall'alto verso il basso.
In una tabella con molte righe e colonne questo rappresenta una difficoltà, ad esempio sarà difficile ricordare a quale intestazione corrispondono i vari segmenti di informazione. Superata la prima coppia di righe, inizia a essere estremamente complicato.
Quello che segue è un esempio di tabella che illustra i bachi dei fogli di stile in Internet Explorer 5.x, preparata dal CCS Pointers group per http://css.nu/pointers/bugs.html. La tabella originale presenta 13 righe - ho estrapolato le prime cinque a scopo esemplificativo.
Uso degli attributi 'id' e 'headers'
Prova questo esercizio - nascondi le intestazioni delle colonne nella tabella qui sopra, ponendovi sopra un righello o un pezzo di carta - e gradualmente scorri i contenuti di ciascuna cella. Con ogni probabilità inizierai a sentire una certa ansia riguardo ciò che ogni cella rappresenta. Come persona in grado di vedere, posso dare una occhiata in cima alla colonna per rassicurarmi della natura dell'informazione che sto leggendo. Se utilizzo uno screen reader o una barra braille, non ho questa possibilità.
Per risolvere questo problema HTML 4 consente di usare nuovi attributi: 'id', 'headers e 'scope'.
ID e Headers
Dando ad ogni intestazione di tabella una etichetta univoca (usando l'attributo 'id') - e quindi associando ogni cella di dati a questa etichetta, usando l'attributo 'headers', i nuovi browser possono fornire adeguato feedback a chi utilizza tecnologie assistive.
Un esempio può servire di chiarimento: di seguito il codice HTML per la tabella qui sopra, con l'uso dell'attributo 'id' delle intestazioni e dell'attributo 'headers' in ciascuna cella di dati.
esempio_2.txt
Uno screen reader leggerà la prima riga di dati nel modo seguente:
CSS Property/ Problem: absolute/relative,
Description: absolute child loses position,
Workaround: set the width property of the parent element,
Notes/Footnotes: W demo
E la seconda riga:
CSS Property/ Problem: Classes set as number (i.e. P.1),
Description: recognized due to error-recovery,
Workaround: Illegal syntax; don't use,
Notes/Footnotes: W95, NT (6)
E così via.
SCOPE
L'attributo 'headers' funziona anche quando le intestazioni della tabella non sono allineate logicamente con le celle di dati cui sono collegate. Ad esempio, quando le intestazioni e i dati corrispondenti non sono parte della stessa colonna o riga.
Per le tabelle semplici, dove le intestazioni di colonna o di riga corrispondono, le coppie id/headers possono essere rimpiazzate con l'attributo 'scope'.
Questo attributo può avere un valore di 'col', 'row', colgroup o rowgroup. Quando si usa SCOPE con il valore di 'col' (ad esempio scope ="col") - stai dicendo al browser (o altri user agent) "ogni cosa in questa colonna si riferisce alla sua intestazione". Un esempio può fornire un chiarimento:
Utilizzando le prime due righe di dati della precedente tabella, 'scope' è usato come segue:
esempio_3.txt
Usi più avanzati dell'attributo scope si possono trovare nel sito del World Wide Web Consortium: http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.4
L'attributo ABBR
Le sopracitate tecniche sono ottime per coloro i quali non usano browser grafici - ma sollevano un problema. Se le intestazioni nella tabella sono molto lunghe, può diventare defatigante dover ascoltare sempre ripetuto il testo per ciascuna cella. La soluzione è fornire una abbreviazione per sostituire il testo intero dell'intestazione. L'attributo 'abbr' fa questo e viene impiegato nel modo seguente:
<TH id="header1" abbr="Property">CSS Property/ Problem</TH>
La prima occorrenza della intestazione verrà letta integralmente, ma le successive verranno sostituite dalle abbreviazioni, in questo caso dalla parola 'Property'. Questo fa risparmiare tempo e molto lavoro mentale nel processo.

Ulteriori tecniche HTML 4
Con l'introduzione di HTML 4 e HTML 4.01, il gruppo di lavoro del W3C ha escogitato rimedi per innumerevoli modalità di lettura dei browser, che causano problemi agli utenti. Uno di questi è stato l'incoraggiare gli autori a fare una netta separazione fra la struttura e la presentazione del documento. Sono stati introdotti nuovi elementi in grado di rendere opportunamente chiara la struttura dei documenti Web.
Nuovi elementi sono l'attributo AXIS e le suddivisioni COL, COLGROUP, THEAD, TBODY, e TFOOT. COL e COLGROUP sono scarsamente supportate negli attuali browser, così non caldeggio il loro utilizzo immediato. Ulteriori informazioni sui nuovi elementi ed il loro impiego sono disponibili qui: http://www.w3c.org.
THEAD, TBODY, e TFOOT
THEAD, TBODY, e TFOOT - in linea con le finalità dell'HTML - aggiungono valore strutturale alle tabelle HTML, dando informazioni riguardo quali parti della pagina Web costituiscono le intestazioni e i piè di pagina. I browser possono mostrare continuamente header e footer - mentre si fa lo scrolling della tabella. Questo è molto utile per periferiche con schermi piccoli come i palmari o telefoni connessi alla rete. I browser comuni non supportano questa funzionalità.
THEAD e TFOOT contengono la riga della tabella con le etichette identificative relative alle colonne. TBODY contiene le righe attive di dati. Anche se TFOOT apparirà a fondo pagina, lo standard W3C HTML 4 specifica che dovrebbe essere definito immediatamente dopo THEAD e prima di TBODY. Questo permette di mostrare velocemente una parte della tabella - infatti lo user agent non necessita di leggere l'intera tabella prima di poterne mostrare la parte visualizzabile su monitor.
esempio_4.txt
Specificando TFOOT prima di TBODY si causano problemi con i browser che non supportano la tag TFOOT, come alcune versioni di Netscape, anteriori alla 6.
Quando la tag TFOOT non viene riconosciuta, l'informazione footer viene mostrata in modo scorretto, ad esempio all'inizio della tabella, appena sotto l'intestazione.
Se si intende utilizzare TFOOT il miglior workaround è definire TFOOT dopo la tag TBODY - nonostante che in questo modo si vada contro gli attuali standard.
AXIS
L'attributo AXIS è una versione più sofisticata dell'attributo 'headers' - e può mostrare le relazioni fra gruppi di celle dovunque nella tabella. Chi codifica manualmente le tabelle, temo, non potrà utilizzare intensivamente l'attributo AXIS, poiché richiederebbe un notevole sforzo cerebrale per definirlo.
Solamente quando questa nuova tecnica troverà sbocco negli applicativi WYSWYG per il webdesign, si inizierà a vedere di frequente nelle pagine Web.
Una spiegazione dell'attributo 'AXIS' con esempi può essere letta nel sito Web Review.
Per amore di completezza, una considerazione conclusiva: si dovrebbe evitare l'uso dell'elemento PRE per i layout tabellari di dati - l'uso corretto dell'elemento TABLE è preferito perché consente alle tecnologie assistive di avvantaggiarsi delle caratteristiche di accessibilità delle tabelle.
Alcune riflessioni sulle tabelle di dati
Le nuove tag introdotte da HTML 4 forniscono utile struttura alle tabelle di dati e il loro uso aiuta a migliorare l'accessibilità delle tabella dati, per gli utenti di tecnologie assistive e per gli utenti delle tante nuove tecnologie di connessione - in particolare quelle con monitor di dimensioni ridotte, o che non prevedono l'uso delle mani. Tuttavia molte tag sono ancora male implementate nei browser attuali (ad es. COL e COLGROUP) - di conseguenza si richiede un approccio pragmatico.
La parola finale
Per riassumere, personalmente raccomando ancora l'uso delle tabelle per il layout delle pagine Web, nonostante il fatto che in questo modo si va contro gli attuali standard. Questo è un approccio pragmatico - non l'opzione che prediligo. Spero che assai presto i tool utilizzati per costruire siti Web saranno basati sull'uso dei fogli di stile, piuttosto che sulle tabelle per il layout, e che comprenderanno i necessari trucchi per i bachi conosciuti, in modo da le pagine generate risultino compatibili con i browser recenti - ma siano comunque visibili con i browser datati e non standard compliant. I costruttori di user agent, allo stesso medo, dovranno produrre browser standard compliant e affetti in minor misura da incompatibilità ed errori.
In relazione alla visualizzazione di informazione a monitor, e all'accessibilità riguardo i lettori di schermo datati, la nozione di un uso preferibile delle tabelle per i dati piuttosto che per il layout è indecidibile nella modalità bianco o nero. Le tabelle contenenti dati (laddove i dati occupano più di una riga in ciascuna cella) non sono più accessibili delle tabelle usate per il layout. Gli screen reader che non hanno la capacità di vedere la struttura HTML di una pagina si limitano a leggere da sinistra a destra lungo lo schermo, una riga alla volta. Quindi non fa differenza se si legge informazione in una cella di tabella o il testo di un articolo; a meno che le colonne di testo non siano significative lette trasversalmente di riga in riga, la pagina sarà in ogni caso inaccessibile.
Continuando su questa linea di pensiero - se si usa uno screen reader che decodifica l'HTML - perché non alterare l'attuale standard introducendo due nuovi attributi, 'data' e 'layout' - così sarà il lettore di schermo ad adeguarsi all'informazione. Potrebbe funzionare usando computer e monitor convenzionali - ma la ragione per cui potrebbe non essere una buona idea è che l'HTML non nasce per veicolare presentazione (su un monitor di PC o su altra periferica). L'HTML dovrebbe consentire un markup strutturale del contenuto di un documento, fornendo informazioni riguardo il tipo e il significato dei dati contenuti in ciascuna tag.
Il reale beneficio del mantenimento della distinzione fra struttura e presentazione dei documenti HTML potrà essere percepito in futuro, quando la percentuale dei PC sarà minore in proporzione con le altre periferiche di connessione alla rete, e il contenuto dei siti verrà processato automaticamente. Potrà accadere quando ci si potrà aspettare un reale 'payback', quando tutti si accorderanno su cosa siano gli standard e agiranno in conformità.
I layout tabellari e le linee guida del W3C per l'accessibilità
Alcune parti rilevanti delle linee guida:
Assicurarsi che le tabelle presentino la marcatura necessaria per essere trasformate dai browser accessibili e da altri user agent.
Le tabelle dovrebbero essere usate per la marcatura di informazioni squisitamente tabellari ("tabelle di dati"). Gli sviluppatori di contenuti dovrebbero evitare di usarle per i layout ("tabelle di layout"). Le tabelle, in qualsiasi modo vengano utilizzate, presentano problemi in particolare per gli utenti di lettori di schermo (si veda il punto di controllo 10.3)......
5.3 Non usare le tabelle per il layout, a meno che la tabella non sia comprensibile se linearizzata. Altrimenti, se la tabella non risulta dotata di senso, fornire un'alternativa equivalente (che potrebbe essere una versione linearizzata). [Priorità 2]
Nota. Quando gli user agent supporteranno il posizionamento con i fogli di stile, le tabelle non dovranno essere utilizzate per il layout. Vedi anche il punto di controllo 3.3.
Si noti che le parole 'non usare le tabelle per il layout' sono connesse da 5.3 alla condizione 'a meno che la tabella non sia comprensibile se linearizzata'.
La nota al checkpoint 5.3 dice 'Quando gli user agent supporteranno il posizionamento con i fogli di stile, le tabelle non dovranno essere utilizzate per il layout. Vedi anche il punto di controllo 3.3.'
Ne consegue:
Gli interpreti non supportano attualmente in modo affidabile e 'usabile' il posizionamento con i CSS, come è stato dimostrato in questo articolo, ciononostante è possibile creare layout tabellari dotati di senso se linearizzati. La mia interpretazione delle linee guida del W3C è che le tabelle si possono usare per il layout, almeno fino a quando i fogli di stile per il layout non saranno più affidabili.