Building Accessible Web Sites

Joe Clark, giornalista canadese, ha scritto un libro tutt’altro che canonico dedicato al mondo dell’accessibilità dei siti web.

Clark utilizza un approccio critico, pratico, quasi pedante. L’approccio di chi ha sbattuto più volte la testa e ha maturato una vasta esperienza sul campo. Clark è a dire il vero una persona che difficilmente risulta subito simpatica, come abbiamo scoperto intervistandolo via email e chiacchierando con lui via Icq.

Ma questo suo atteggiamento provocatorio, quando è rivolto al mondo dell’accessibilità web, diventa proficuo.

Se vi aspettate di leggere un manuale che tesse le lodi del W3c e del Wai siete fuori strada. Joe Clark è spesso critico rispetto alle linee guida Wai perché le giudica troppo generiche per essere efficaci e molto spesso in antitesi tra loro. Una scelta che può sembrare infelice, ma che l’autore motiva approfonditamente, tanto che alla fine vi troverete d’accordo con lui.

Secondo Clark con il termine accessibilità web si intende un sito utilizzabile proficuamente dalle persone disabili. Anche in questo cozza contro l’inflazionato incipit di Tim Berners Lee e ripreso dal Wai che vorrebbe un web accessibile universalmente da tutti, da chi ha un Pentium 90 a chi si diverte con i Pda. Ma Joe Clark è realista e sa che solo sulla carta un sito accessibile è un sito che funziona con ogni periferica.

Si tratta di un testo spesso controcorrente rispetto a quello che siamo soliti leggere a proposito dell’accessibilità web. Ecco qualche esempio:

  • rendere i caratteri dimensionabili via browser è inutile: per questo ci sono gli ingranditori di testo, ormai presenti per ogni piattaforma e molto più efficaci rispetto ai browser
  • l’uso dei Css è importante, ma usare i layout a tabella va altrettanto bene
  • Bobby è uno strumento inaffidabile per il test delle pagine: non provate neppure ad usarlo
  • i D-Link non devono essere impiegati: alterano in modo irrimediabile l’aspetto della pagina
  • meglio lasciare i campi delle form vuoti piuttosto che riempirli con del testo allo scopo di aiutare gli screen reader più datati

Joe Clark è un vero professionista perché analizza ogni caratteristica dell’accessibilità web in profondità. Il solo capitolo relativo alle immagini occupa 60 pagine e c’è spazio per ogni possibile cavillo riguardo il loro uso.

E’ bravo anche perché non cade in facili tranelli. Un esempio per tutti: è consapevole che l’attributo alt non dovrebbe essere visualizzato come suggerimento dai browser, a differenza dell’attributo title.

Alcune scelte sono a dire il vero discutibili: secondo l’autore bisognerebbe impiegare sempre l’attributo title oppure non utilizzarlo mai. Probabilmente non è il caso di essere così estremisti, soprattutto con l’accessibilità del contenuto di un sito.

Questo approccio pone senza dubbio dei problemi. Cosa facciamo: diamo retta a lui o alle linee guida del W3c? Utilizziamo i D-Link oppure no? Compiliamo i campi delle form o li lasciamo vuoti? Noi abbiamo la nostra opinione, molto vicina a quella dell’autore, e che trovate in ogni puntata del nostro corso di accessibilità web.

Joe Clark è convinto che poche linee guida sono sufficienti per garantire un buon livello di accessibilità: un uso corretto delle immagini partecipa da solo a metà del lavoro. Le divide così in 3 categorie (base, intermedia, avanzata) che corrispondono alla difficoltà e al lavoro richiesto per incorporarle nei proprio siti. Molte volte un livello base è già sufficiente per realizzare un sito discretamente accessibile.

L’autore eccelle, oltre che nella già citata accessibilità delle immagini, anche nell’indicare le strategie per realizzare filmati accessibili, in particolare con i sottotitoli e le descrizioni visive e sonore. Un argomento solo a prima vista banale, ma tra i più impegnativi per chi si occupa di accessibilità web. Proprio questo importante capitolo è quello che vi presentiamo in esclusiva: avete la possibilità di scaricarlo gratuitamente dal nostro sito.

In tema di accessibilità, va detto che il libro contiene un Cdrom allegato nel quale potete trovare (ad eccezione delle immagini) tutti i capitoli, oltre a risorse di approfondimento. Un aiuto indispensabili per gli utilizzatori di screen reader.

A noi il testo è piaciuto perché è un’analisi non banale al mondo dell’accessibilità web. Capirete quanto è ancora irto di spine il percorso di chi è impegnato in questa disciplina e quanto lavoro il Wai deve affrontare per aiutare realmente gli sviluppatori nella realizzazione di siti accessibili.

Siamo però ancora lontani da quello che vorremmo leggere a proposito di accessibilità web, ovvero che siamo di fronte ad una disciplina con un suo ciclo di vita e che necessita di adeguate figure professionali strettamente interconnesse con gli altri campi dello sviluppo in internet.

Non aspettatevi indicazioni sull’accessibilità di Java, dei file Pdf o di standard come Svg: l’autore ammette l’ignoranza in materia e li ha esclusi dal libro.

Se cercate invece un testo classico, che approndisca soprattutto il ruolo delle tecnologie e degli strumenti come screen reader e browser vocali, potreste trovare più interessante un manuale come Constructing Accessible Web Sites edito da glasshaus.

Capitolo gratuito

Grazie ad un nostro accordo con la casa editrice New Riders avete la possibilità di scaricare un intero capitolo in esclusiva. Si tratta del capitolo 13, Multimedia, a nostro avviso uno dei più riusciti del manuale.

Abbiamo chiesto a Joe Clark di introdurre l’argomento per i nostri lettori:

Il web è più vasto di una semplice rete di pagine Html. La multimedialità – il video e l’audio, oltre che Flash – è uno dei componenti più attraenti dell’esperienza nel web e per questo motivo deve essere accessibile alle persone disabili. Per realizzare delle presentazioni multimediali accessibili possiamo basarci su decenni di pratica della televisione, dei video e dei film ed usare i sottotitoli (per chi non sente) e le descrizioni audio (per chi non vede).

From Building Accessible Web Sites, Isbn 073571150X, Chapter 13, Copyright 2002.
Reproduced by permission of New Riders.

Scarica il capitolo “Multimedia” [Pdf, 2.4 MBytes]

Informazioni

Building Accessible Web Sites ¤ di Joe Clark ¤ pagine 430 ¤ prezzo 39.99 dollari ¤ lingua inglese ¤ edito da New Riders

Intervista a Eric Meyer

Quando abbiamo deciso di rivolgere qualche domanda ad Eric Meyer, il sito della casa editrice New Riders già ospitava un’intervista, che vi consigliamo di leggere senza indugi.

Per questo motivo abbiamo pensato di rivolgere all’autore qualche domanda un po’ più provocatoria, soprattutto perché ci aiuti a capire quali sono i veri vantaggi dei Css e fino a dove possiamo spingerci nel loro utilizzo.

  1. Qual è l’approccio del tuo ultimo libro, Eric Meyer on Css, e come hai scelto i casi studio? [Risposta 1]
  2. Siamo davvero pronti per il tuo libro? Niente più tabelle per il layout o spacer gif? Cosa possiamo dire ai nostri clienti quando si lamenteranno che non riescono a vedere il sito con Netscape 4.x? [Risposta 2]
  3. Quanto è complessa la curva di apprendimento per uno sviluppatore che proviene dalla vecchia scuola “tabelle per layout”? [Risposta 3]
  4. Tra le cause che tengono gli sviluppatori lontani dall’adottare i Css nei loro layout, c’è la gestione non perfetta da parte dei browser. Ma perché si verifica questo? [Risposta 4]
  5. A volte è possibile vedere documenti dove l’autore usa trucchi o complicate soluzioni per interagire con i browser meno recenti (@import per nascondere i Css con Netscape 4.x e commenti per Internet Explorer 5 e Opera). Altri cercano invece di riconoscere il browser lato client o lato server, così da inviare un versione personalizzata del Css. Altri scelgono semplicemente di non fare niente. Qual è la tua opinione? [Risposta 5]
  6. Navigando in Internet è possibile incontrare molti siti personali o blog che sono realizzati ricorrendo pesantemente ai Css. Lo stesso non sembra ancora accadere per i siti commerciali e in generale per i siti che dispongono di molti contenuti. Wired è stato il primo esempio, anche se soffre di alcuni problemi con la validità del codice. È più impegnativo usare i Css con i siti complessi? Quali sono i compromessi? [Risposta 6]
  7. Pensi che lo standard Css sia completo o che gli manchi qualche importante caratteristica? [Risposta 7]

Qual è l’approccio del tuo ultimo libro, Eric Meyer on Css, e come hai scelto i casi studio?

Eric Meyer on Css è quasi interamente pratico in natura. È composto da 13 progetti, ognuno dei quali inizia con un semplice documento al quale vengono applicati stili sempre più complessi. Il testo è stato scritto in modo da consentire agli utenti di seguire il libro e vedere i progetti che evolvono man mano.

I file di base dei progetti, così come tutti quelli che sono stati utilizzati per realizzare le schermate del libro, sono disponibili sul sito dedicato.

Ho creato tutti i progetti partendo da zero, scegliendo ognuno con un occhio rivolto ad un aspetto ben preciso dei Css. Due progetti, ad esempio, trattano quasi esclusivamente del posizionamento, uno si concentra sugli stili per la stampa, un altro si preoccupa dei form e il primo esamina la conversione di un design realizzato con tabelle e font in uno che usa i Css.

Il sito web contiene i dettagli su tutti e 13 i progetti, oltre a del materiale aggiuntivo, ad esempio alcune appendici che sono state eliminate dal libro per preservare spazio.

Top

Siamo davvero pronti per il tuo libro? Niente più tabelle per il layout o spacer gif? Cosa possiamo dire ai nostri clienti quando si lamenteranno che non riescono a vedere il sito con Netscape 4.x?

Non penso sia arrivata la fine per le tabelle di layout, e il libro non ha questa pretesa. Se usate delle semplici tabelle per le aree principali della pagina e poi impiegate i Css per i contenuti di queste tabelle, otterrete una pagina decente in Netscape 4.x e la pagina voluta nei browser più recenti.

Ammetto che il libro non prende molto in considerazione Netscape 4.x, ma diciamolo: è un browser vecchio di 5 anni, più di metà dell’era del “web popolare”, quello che è cominciato con il rilascio di Mosaic 1.0. Era un browser contemporaneo di Internet Explorer 3, e di quest’ultimo nessuno ormai si preoccupa più.

Detto questo, se un webmaster si occupa di un sito con un buon numero di utenti che usano Netscape 4.x, allora dovrà fare un po’ di più per andare incontro a questo browser, ovviamente.

La vera domanda è: la pagina deve apparire identica in Netscape 4.x e in Internet Explorer 6?

Per me no. Fintantoché la pagina è comprensibile nei vecchi browser, può apparire leggermente diversa. Un esempio in questo senso è il sito di Fox Searchlight.

Questo sito non è preciso al pixel in Netscape 4.x rispetto ai browser recenti, ma la resa è molto buona. Se non paragonate Netscape 4.x e Mozilla fianco a fianco, probabilmente non vi accorgereste neppure che sono diversi.

Top

Quanto è complessa la curva di apprendimento per uno sviluppatore che proviene dalla vecchia scuola “tabelle per layout”?

Non troppo complessa. L’ostacolo principale è che dovete lasciar perdere tutto quello che avete imparato con il layout basato su tabelle. Quando abbracciate il layout basato sui Css, ci sono sicuramente dei cambiamenti. Se però mantenete delle tabelle di base e usate i Css per il contenuto, allora la curva di apprendimento è praticamente lineare. Ogni autore che ho incontrato e che è passato dalle tabelle ai Css mi ha detto che non può credere di aver pasticciato con tabelle annidate in tabelle e spacer gif quando i Css avrebbero reso le cose molto più facili.

Top

Tra le cause che tengono gli sviluppatori lontani dall’adottare i Css nei loro layout, c’è la gestione non perfetta da parte dei browser. Ma perché si verifica questo? Ecco alcune possibili cause che vorremmo esplorare con te:

perché sono pochi gli sviluppatori che usano i Css per il layout e così i produttori di browser non sentono la necessità di migliorarli

Questo poteva essere vero nel 1998, ma non oggi. Praticamente ogni sito usa i Css in qualche modo. Sono d’accordo che molti li usano senza sfruttarne le potenzialità, ma la maggioranza li usa almeno ad un livello che potremmo definire moderato. È comunque vero che alcuni siti mischiano i Css con i tag font, il che è una sciocchezza. Gli autori dovrebbero usare uno o l’altro, ma non entrambi nei loro design.

perché le specifiche Css sono scritte in inglese, e ogni lingua è per definizione ambigua (molti non sono bug, ma diverse interpretazioni delle specifiche)

Questa è una parte del problema. Ci sono stati casi in cui le specifiche Css 2 erano contraddittorie, come ci si può aspettare da un documento di grosse dimensioni. Il Css Working Group sta cercando di risolvere questi limiti con le specifiche Css 2.1, che sono quasi complete. Comunque ogni documento scritto in un linguaggio per umani è aperto alle interpretazioni.

perchè i Css sono complessi e così è complessa la loro implementazione

Questo è esattamente il nocciolo della questione. I Css sembrano molto semplici quando gli date un’occhiata, ma in realtà sono così complicati che la maggior parte dei comportamenti inaspettati sono in realtà casi particolari. Alla fine degli anni 90 i produttori di browser non hanno prestato la giusta attenzione alle sottigliezze dei Css, o hanno scelto deliberatamente di ignorarle. Solo in tempi recenti hanno cominciato a correggere gli errori fatti.

perché il layout basato su Css è una materia nuova

Penso che il layout basato sui fogli di stile sembri nuovo perché solo recentemente i browser li gestiscono più o meno correttamente, così da farci prendere in considerazione la loro adozione.

Top

A volte è possibile vedere documenti dove l’autore usa trucchi o complicate soluzioni per interagire con i browser meno recenti (@import per nascondere i Css con Netscape 4.x e commenti per Internet Explorer 5 e Opera). Altri cercano invece di riconoscere il browser lato client o lato server, così da inviare un versione personalizzata del Css. Altri scelgono semplicemente di non fare niente. Qual è la tua opinione?

Uso @import per nascondere i Css a Netscape 4.x, quindi penso che questi stratagemmi possano benissimo essere utilizzati: ho impiegato alcuni di questi trucchi almeno in uno dei progetti per il libro. Penso comunque che sia facile eccedere nel loro utilizzo. Se il vostro foglio di stile è composto per metà da trucchi e regole che si appoggiano ai bug dei browser, state probabilmente sbagliando l’approccio. A me è capitato di scartare alcune progettazioni perché troppo avanzare per i browser di oggi senza impiegare un gran numero di trucchi. Questo accade per tutti i media e non è una sorpresa che si verifichi anche nel web.

Personalmente non mi piace l’uso di codice lato server per riconoscere il browser, perchè è un procedimento che introduce un carico extra al server ed è utile in pochissime situazioni. L’unico caso in cui questo sforzo è necessario si verifica quando il contenuto deve variare a seconda dei browser. Se invece volete inviare Css diversi a browser diversi, probabilmente state scegliendo una soluzione inutilmente complessa: un solo foglio di stile dovrebbe essere sufficiente.

Top

Navigando in Internet è possibile incontrare molti siti personali o blog che sono realizzati ricorrendo pesantemente ai Css. Lo stesso non sembra ancora accadere per i siti commerciali e in generale per i siti che dispongono di molti contenuti. Wired è stato il primo esempio, anche se soffre di alcuni problemi con la validità del codice. È più impegnativo usare i Css con i siti complessi? Quali sono i compromessi?

A dire il vero, quando Wired è stato convertito ad un layout basato sui Css, i loro problemi con il codice valido riguardavano esclusivamente la codifica degli Url, non il markup. Ci sono pagine vecchie di 3 anni che non sono valide, ma possono essere sistemate gradualmente. Comunque la pagina principale del sito è valida, o almeno lo era quando la ho scritta io.

Se usate i Css per il layout, è più semplice ottenere pagine valide perché il codice è più semplice e più logico. Invece di districarvi tra tabelle annidate e tag td avete la possibilità di concentrarvi sui paragrafi e sui div. Quando ho abbandonato le tabelle dal mio sito personale a Gennaio 2002 è stato molto più semplice convalidare le pagine e correggere gli errori di validità.

Top

Pensi che lo standard Css sia completo o che gli manchi qualche importante caratteristica?

Lo standard Css non sarà mai realmente completo. La sua evoluzione potrebbe cessare un bel giorno, ma ci sarà sempre qualcuno che si lamenta perché non fa quello che lui vuole.

Così com’è oggi, lo standard non dispone di un modo per legare un elemento ad un altro in termini di layout: non potete dire “rendi questo elemento alto come quest’altro”. Sarebbe una caratteristica che aiuterebbe il posizionamento degli elementi, e forse sarà aggiunta in un prossimo futuro, ma dovremmo poi gestire qualcosa di complesso.

Penso che nessun linguaggio di presentazione, non importa quanto ricco e potente, potrà mai soddisfare tutte le richieste degli autori.

Il fatto che una caratteristica mancante sia importante oppure no dipende dalla persona a cui si pone la domanda. Quella che per me è una lacuna cruciale, potrebbe essere di importanza minima per qualcun altro, e viceversa.

Un esempio è dato dalle “variabili”, la possibilità di definire una parola chiave e assegnarle un significato, per poi utilizzarla da qualunque parte all’interno del foglio di stile. Conosco alcuni autori che pensano si tratti di un’enorme lacuna dello standard, ma personalmente la cosa non mi ha mai preoccupato.

Top

Eric Meyer è uno “Standards Evangelist” per Netscape Communications, il che vuol dire che cerca di spargere la voce sul perché gli standard sono una “cosa buona”. Realizza soluzioni basate sugli standard ed è anche l’autore di 3 libri, nonché di un gran numero di articoli. Il suo principale ambito lavorativo è rappresentato dai Cascading Style Sheets, in parte perché è stato uno dei primi ad adottarli, ma soprattutto perché li trova infinitamente affascinanti e utili.