Come e perché realizzare una tabella accessibile?

La scorsa settimana abbiamo visto per sommi capi cosa si intende per accessibilità di un sito web, quali sono gli organismi che si occupano di definire gli standard dell’accessibilità (mediante delle raccomandazioni che gli autori delle pagine web dovrebbero rispettare) e qual è la tipologia di utenti che usufruisce di queste raccomandazioni.
In questo articolo vedremo, sempre in modo superficiale, una delle linee guida contenute nella prima versione delle WCAG che riguarda l’utilizzo delle tabelle e il loro sviluppo per renderle accessibili.
Perché creare tabelle che si trasformano elegantemente?
La linea guida che fa riferimento a questo punto è la numero cinque delle WCAG 1.0 e dice di creare tabelle che si trasformino elegantemente: questa raccomandazione indica chiaramente di assicurarsi che le tabelle abbiano la marcatura necessaria per essere trasformate in maniera elegante e poter essere lette anche da altri dispositivi, come per esempio uno screen reader.
Le tabelle possono essere usate in due differenti modi: per raccogliere e mostrare dati in tabelle di dati appunto, o per disporre i contenuti di un layout web; in questo secondo caso prendono il nome di tabelle d’impaginazione. Il W3C raccomanda di utilizzare le tabelle per incasellare dati tabellari e sconsiglia il secondo impiego.
Le tabelle di dati servono dunque per visualizzare informazioni di carattere tabellare in cui sono definite specifiche relazioni orizzontali e verticali tra i contenuti delle celle. Visualizzare una tabella dati con un normale browser permette all’utente una rapida scansione visuale in modo da ottenere subito una visione d’insieme di come i dati sono strutturati, ma ti sei mai chiesto come vengono letti questi dati da un non vedente che utilizza uno screen reader?
Punto di controllo 1: Per tabelle di dati, identificare le intestazioni di righe e colonne.
La linea guida numero cinque ha sei punti di controllo, il primo dei quali indica che per le tabelle di dati bisogna identificare le intestazioni di riga e colonna.
Supponiamo di avere una classica tabella come quella mostrata in questo esempio.
Come puoi notare non è stato utilizzato nessun marcatore per rappresentare le intestazioni della tabella (nome del corso, docente, descrizione, ecc.) che sono state rese in grassetto mediante l’utilizzo dell’elemento “<b>” che le evidenzia (in grassetto) per la sola presentazione visuale.
In questo modo la tabella è inaccessibile per un utente non vedente che utilizza uno screen-reader.
Come trasformare una tabella in modo da renderla accessibile?
Il modo più semplice per aumentare la leggibilità di una tabella di dati, soprattutto per chi naviga utilizzando uno screen reader, è identificare le celle d’intestazione marcandole con l’opportuno elemento strutturale “<th>” – l’acronimo sta per “table header”, cioè “intestazione di tabella” – che definisce una cella contenente informazioni di intestazione.
Guarda l’esempio della tabella precedente realizzata mediante l’utilizzo dell’elemento strutturale “<th>”.
Come puoi vedere dal markup utilizzato, tutte le celle delle prime due righe della tabella sono state realizzate mediante l’utilizzo dell’elemento “<th>”, mentre nell’esempio precedente, queste prime due righe erano realizzate con l’utilizzo di normali “<td>”, il cui contenuto era evidenziato poi con lo stile grassetto.
L’utilizzo dell’elemento “<th>” ha aggiunto un’informazione strutturale in più: in questo modo comunichiamo a qualsiasi software, anche non visuale, che il contenuto di quella cella è un’intestazione.
L’aspetto estetico delle intestazioni può essere poi completamente modificato mediante l’utilizzo dei fogli di stili.
Punto di controllo 2: Per tabelle di 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.
Questo punto di controllo suggerisce di usare gli elementi “<thead>”,”<tfoot>” e “<tbody>” per raggruppare righe, “<col>” e “<colgroup>” per raggruppare colonne e gli attributi “axis“, “scope” e “headers” per descrivere relazioni più complesse fra i dati.
Gli elementi “<thead>”,”<tfoot>” e “<tbody>” servono per differenziare la tabella in tre parti: testata, footer e corpo. Questa suddivisione va utilizzata nel caso di tabelle molto lunghe e consente all’utente di scorrere sul monitor il corpo della tabella indipendentemente dalla testata o dal footer.
Qui puoi vedere il nostro esempio precedente con l’aggiunta di questi nuovi accorgimenti.
Per quanto riguarda l’utilizzo degli attributi “axis“, “scope” e “headers” – che servono per descrivere relazioni più complesse fra i dati – ti rimando a un prossimo articolo in cui vedremo il loro utilizzo in modo più dettagliato.
Punto di controllo 3: Non usare tabelle per impaginazioni a meno che la tabella non sia comprensibile se letta in modo linearizzato. Altrimenti, se la tabella non risulta leggibile, fornire una alternativa equivalente (che può essere una versione linearizzata).
Il terzo punto di controllo indica chiaramente di non utilizzare le tabelle per impaginare i contenuti all’interno del layout della pagina web. In caso contrario bisogna fornire un’alternativa equivalente, come per esempio una versione linearizzata della tabella.
Che cosa si intende per versione linearizzata di una tabella?
La versione linearizzata di una tabella non è altro che un processo per convertire in una serie di paragrafi uno dopo l’altro i contenuti delle celle di una tabella (per esempio, in fondo alla pagina). I paragrafi seguiranno lo stesso ordine delle celle del documento d’origine. Le celle dovrebbero avere senso se lette di seguito e dovrebbero includere elementi strutturali (che creino paragrafi, titoli, liste, ecc.) in modo che la pagina conservi il senso dopo la linearizzazione (fonte: aib.it).
Punto di controllo 4: Se per l’impaginazione viene usata una tabella non usare nessun marcatore di struttura per la formattazione della resa visiva.
Il punto di controllo quattro suggerisce di non utilizzare marcatori di struttura – come per esempio potrebbe essere l’elemento “<th>” – per la sola presentazione estetica dei contenuti. Questo è un errore che commettono ancora in tanti: il foglio di stile predefinito dei principali browser visualizza in grassetto e allineato al centro il contenuto di una cella marcata con l’elemento strutturale “<th>”.
Per rendere un contenuto di una cella centrato e in grassetto, in caso non si tratti di un’intestazione di tabella, bisogna utilizzare i fogli di stile; in questo caso basterebbe creare una regola con le seguenti proprietà e assegnarla alla cella interessata per ottenere il risultato desiderato:
.center-bold {text-align:center;font-weight:bold;}
Punto di controllo 5: Per le tabelle, fornire sommari.
Il quinto punto di controllo suggerisce di fornire sempre dei sommari per le tabelle, mediante l’utilizzo dell’attributo “summary” dell’elemento “<table>”.
I sommari sono utili specialmente per chi legge in modalità non visuale. Un sommario può descrivere in che modo la tabella rientra nel contesto del documento in cui è inserita. Se non è presente una didascalia, è assolutamente fondamentale fornire un sommario.
Vediamo la tabella del nostro esempio precedente sviluppata adesso mediante l’utilizzo dell’attributo “summary” per fornire un riassunto dello scopo e della struttura della tabella per browser non visuali.
Come puoi notare, visualizzando la pagina con un normale browser visuale non sembra cambiare nulla, dal punto di vista estetico la tabella è rimasta uguale, ma in questo modo abbiamo fornito una descrizione del contenuto della tabella per tutti quegli utenti che si trovano a visitare la pagina mediante l’utilizzo di un browser non visuale.
Punto di controllo 6: Fornire abbreviazioni per le etichette di intestazione.
Il punto di controllo numero sei suggerisce di usare delle abbreviazioni per le etichette di intestazione mediante l’utilizzo dell’elemento “<abbr>”.
Perché si rende necessaria questa precauzione? Uno screen reader – quando legge i dati contenuti all’interno di ogni singola cella della tabella – generalmente legge anche il contenuto delle celle di intestazione associate e,nel caso di intestazioni molto lunghe, la lettura ripetitiva di queste ultime può diventare fastidiosa.
Conclusioni
Con l’articolo di oggi hai visto come con qualche piccolo accorgimento è possibile rendere accessibile una tabella in modo che possa essere letta da qualsiasi dispositivo.
Per ulteriori approfondimenti ti consiglio di leggere l’ottimo libro scritto da Michele Diodati edito da Apogeo, dal titolo: “Accessibilità – guida completa” (qui una versione del testo consultabile online).
12 commenti
Trackback e pingback
-
Perché tabelle e divitis rendono il tuo sito inaccessibile? | Your Inspiration Web
[...] Oltre al peso spropositato, che ha come conseguenza diretta un caricamento molto rallentato, c’è da tenere in considerazione il ...





Grazie! Bell’articolo… non avevo mai riflettuto sull’accessibilità delle tabelle, o almeno non mi è mai capitato di inserire dati tabellari… Alcune di queste cose non le sapevo, le terrò a mente ;)
Ciao Francesco, grazie a te per essere passato.
In effetti l’inserimento dati tabellari all’interno di una pagina web è qualcosa che non capita frequentemente e con qualche piccolo accorgimento possiamo renderle completamente accessibili a qualsiasi dispositivo.
A presto.
Grazie per aver pensato a questo aspetto. Ancora non ho avuto modo di capire come muovermi per quanto riguarda l’accessibilità e ora, tramite questi articoli, comincio a capire qualcosa in più :)
Ciao Antonio, noto che l’argomento accessibilità viene spesso messo da parte da molti sviluppatori che generalmente tendono più a concentrarsi sulla validazione del codice, senza preoccuparsi di rendere il contenuto sematico e accessibile.
mi trovo perfettamente d’accordo.
Io ultimamente ho imparato a scrivere codice perfettamente validato, ma ora piano piano voglio imparare a scrivere codice anche perfettamente accessibile, perchè ritengo sia un argomento abbastanza importante.
Ottimo Antonio, ammiro questa tua voglia di imparare e cercare di migliorarti continuamente, è una caratteristica che in pochi possiedono.
Aggiungo che quando le cose vengono fatte con passione non c’è niente e nessuno che può impedirti di raggiungere ciò che ti sei prefissato.
Ti faccio un grande in bocca al lupo per questa tua professione.
Grazie… è esattamente quello che hai spiegato tu: è la passione che mi fa andare avanti :)
La passione smuove anche le montagne!
peccato che alcuni browser non supportino bene i display dei div del tipo table td etcc altrimenti anche li si poteva abbandonare le tabelle
splendido articolo Nando
Grazie Aldo (ti chiamo un po’ aldo e un po’ antonio, spero vada bene uguale), per i complimenti.
Si hai perfettamente ragione, in effetti non ho mai utilizzato la proprietà “table” del modulo “display” del CSS, perchè il solito Internet Explorer non la supporta ancora, nemmeno nella sua ultima versione (le ultime versioni di tutti gli altri principali browser invece dovrebbero supportarla).
Dovrai fare qualche test per vedere se lo sviluppo viene semplificato realizzando le tabelle direttamente dal foglio di stile.
no ie non le supporta
ho provato tempo a fare qualcosa per vedere se riuscivo a spostare li uno sfondo a pina larghezza sull’esempio di gotochina (li usano una tabella) e in parte c’ero riuscito
ma credo che cmq non sia nemmeno nell’interesse comune specie in funzione html5 con i nuovi tag
certo che pero avere un solo tipo di tag (vecchio o nuovo) e gestire solo gli annidamenti e non altri tag annidati penso potrebbe essere un vantaggio in fase di trasformazione