Dove sono andati a finire, nel frattempo, tutti i DIV che riempivano il codice di cssforma.htm? Eliminati quasi tutti! Sono rimasti solo quelli che identificano veri contenitori generici, per i quali non esiste in (X)HTML un equivalente strutturale più specifico. Sono rimasti dunque i DIV che marcano la testata, le tre colonne centrali della pagina e il contenitore invisibile in cui tutte e tre sono racchiuse insieme al pie' di pagina. Lo scopo di questi DIV non è altro che quello di fungere da aggancio per gli stili che determinano la presentazione visuale della pagina: rappresentano l'equivalente evoluto della griglia di tabelle d'impaginazione usata in tabforma.htm. Ecco, ridotto all'essenziale, il codice che mostra la gerarchia dei DIV in struttura.htm:
<div id="testata">
... il contenuto della testata ...
</div>
<div id="corpo">
<div id="corposin">
... il contenuto della colonna sinistra ...
</div>
<div id="princip">
... il contenuto della colonna centrale ...
</div>
<div id="corpodes">
... il contenuto della colonna destra ...
</div>
<p id="piede">
... il contenuto del pie' di pagina ...
</p>
</div>
Il P che racchiude il pie' di pagina diventerà anch'esso un DIV nel momento in cui i suoi contenuti, diversificandosi, non potranno più essere definiti per mezzo di un unico paragrafo e si vorrà comunque che siano raccolti insieme sotto uno stile grafico omogeneo.
In conclusione di argomento, vale la pena di rimarcare un aspetto importante per l'accessibilità: se da un lato è fondamentale, per una buona comprensione dei documenti, valorizzare il più possibile le suddivisioni strutturali dei contenuti, dall'altro occorre ricordare che alcune tecnologie assistive come i lettori di schermo sono in grado di produrre una quantità ridondante di informazioni, per spiegare all'utente come sono strutturati i contenuti via via incontrati nella pagina.
Facciamo un esempio concreto. Consideriamo un forum di discussione in cui l'elenco dei messaggi è reso come una serie di elenchi puntati annidati, in cui titolo e autore di ogni risposta appaiono indentati (fanno parte cioè di un elenco più interno) rispetto a titolo e autore del messaggio precedente: si tratta di un'ottima soluzione dal punto di vista della percezione visiva dei rapporti strutturali.
- Messaggio n.1 – autore 1
- Messaggio n.2 – autore 2
- Messaggio n.3 – autore 3
- Messaggio n.4 – autore 1
- Messaggio n.5 – autore 3
Il guaio di questa soluzione è che un sintetizzatore vocale non leggerà di seguito solo l'elenco dei messaggi, ma, ogni volta che una risposta rappresenta l'inizio di un nuovo elenco (quattro volte su cinque, nell'esempio riportato), descriverà all'utente di che tipo di elenco si tratta e quanti elementi contiene. Tutto ciò può finire per appesantire insopportabilmente la lettura della pagina.
È vero che l'utente ha in genere la possibilità di disabilitare la verbosità del programma, riducendo tramite apposite opzioni di configurazione la quantità di metainformazioni che gli verrà letta, ma è comunque una buona pratica di sviluppo prevedere in anticipo degli strumenti per evitare, all'utente che naviga tramite lettore di schermo, di incorrere in lunghe litanie di dati strutturali. Nel caso degli elenchi annidati, si può creare ad esempio un meccanismo per nascondere, a scelta dell'utente, le risposte annidate o, in alternativa, per linearizzare tutte le risposte in un elenco semplice. Soluzioni di questo genere sono al confine tra accessibilità e usabilità.