Accessibilità e Javascript

Ora che gli sviluppatori web hanno una solida consapevolezza del livello strutturale rappresentato da XHTML e di quello relativo alla presentazione fondato sui CSS, è il momento di prendere in considerazione il livello dell'azione rappresentato da Javascript e in particolare la sua accessibilità.

Nel passato di Javascript si è fatto abuso, soprattutto perché molti hanno frainteso la sua finalità. Molti siti lo hanno usato solo per effetti di presentazione, soprattutto nelle numerosissime e alla fine noiose interfacce in DHTML.

Il tipico sito basato su DHTML non è molto accessibile e tutte quelle interfacce "rivoluzionarie" non si sono rivelate poi così interessanti o utili, tranne che per evidenziare l'abilità di chi le ha sviluppate.

Questo abuso ha dato a Javascript una brutta nomea. È arrivato il momento di invertire questa tendenza. Io ritengo che Javascript possa rappresentare un'importante aggiunta per un sito accessibile, purché si tengano presenti poche e opportune precauzioni.

In questo articolo vorrei esaminare la relazione tra il livello dell'azione di Javascript e quelli della struttura e della presentazione. Impareremo poche, semplici regole che possono aiutarci a mentenere accessibile un sito continuando a sfruttare per i suoi scopi la potenza di Javascript.

Una pagina di esempio

Immaginiamo di dover creare una semplice pagina accessibile per uno store online di libri. La pagina contiene una manciata di link per la navigazione, un articolo su un libro come contenuto principale e alla fine un piccolo form per ordinare il libro.

Tutto questo contenuto dovrebbe essere reso con un markup XHTML estremamente semplice. Titoli e paragrafi per l'articolo principale, i link e il loro contenitore per la navigazione. Il form dovrebbe consistere di campi di input con le relative label di identificazione. Potremmo aggiungere anche 3 <div>, uno per racchiudere la navigazione, un secondo per il contenuto, un terzo per il form.

Quindi aggiungeremo un po' di stili CSS per la presentazione. Margini e padding sui vari blocchi di contenuto, colore sui link e effetti di rollover sugli stessi, una leggera variazione di colore per il form. Niente di rivoluzionario, solo un po' stile per compiacere l'occhio del visitatore.

Ragionare per livelli

È importante capire che abbiamo appena creato 2 livelli: un livello strutturale in XHTML e un livello di presentazione con i CSS. Il livello rappresentato dal codice XHTML è sempre presente, senza di esso non avremmo una pagina web. Il livello dei CSS, invece, può essere assente.

In altre parole, abbiamo definito 2 diverse 'viste' dello stesso documento: quella della presentazione dove agiscono gli stili CSS e una vista 'semplice' dove non agiscono. Ecco, fondamentalmente, l'accessibilità è l'arte di rendere fruibile una pagina anche senza gli stili dei CSS, l'arte di assicurare la comprensione e l'uso del contenuto e della navigazione basandosi sulla semplice struttura definita a livello di codice XHTML.

È anche importante comprendere come la vista della pagina con i CSS sia più usabile di quella senza. I fogli di stile CSS riguardano solo la presentazione. E una buona presentazione, infatti, è un primo passo per ottenere una migliore usabilità. Ogni designer sa che un margine e un'interlinea un po' più ampia rendono il testo più facile da leggere, e quindi più usabile. Inoltre, potremmo usare i CSS per distinguere i link della navigazione principale da quelli contenuti nel corpo della pagina, cosa che ha anch'essa piccoli ma importanti benefici in termini di usabilità.

Sono cose note per chiunque abbia seguito gli ultimi sviluppi del web design. Il livello della struttura e quello della presentazione sono stati ampiamente esaminati, e stiamo lentamente creando una solida teoria sul modo di costruire strutture in XHTML e presentazioni con i CSS efficienti e accessibili. Non abbiamo ancora una simile esperienza con Javascript. Non abbiamo ancora ben indagato la sua applicazione nel contesto di siti accessibili.

Aggiungere Javascript

Javascript aggiunge il livello dell'azione. Se l'utente fa qualcosa, Javascript può far sì che la pagina (o l'intero sito) risponda in un certo modo. La finalità di questa azione, di questo comportamento, è quella di rendere il sito più usabile.

La nostra pagina di esempio potrebbe usare uno script per la validazione del form. Se concepito in maniera appropriata, uno script come questo rappresenta un'ottima aggiunta per l'usabilità: può infatti informare immediatamente l'utente sugli errori che può aver compiuto durante la compilazione del modulo invece di farlo rimanere in attesa di una risposta del server prima di poter correggere quegli errori.

Ora, dunque, abbiamo aggiunto alla nostra pagina il livello dell'azione. Esso si colloca esattamente sopra quello strutturale, ed è prossimo a quello della presentazione. Ciò significa che invece che a 2, ci troviamo ora di fronte, improvvisamente, a 4 viste dello stesso documento. La 'vista semplice' (solo XHTML) e quella 'semplice con presentazione' (XHTML + CSS) rimangono lì dove erano. Il livello dell'azione va a completare quella che possiamo definire la 'vista globale' (XHTML + CSS + Javascript). Dal momento che la maggior parte dei nostri visitatori vedrà la pagina in questo modo, su di essa concentreremo maggiormente la nostra attenzione.

E qui viene il primo allarme sull'accessibilità: la 'maggior parte' non significa 'tutti i visitatori'. Pertanto dobbiamo essere sicuri che la nostra pagina continui a funzionare anche senza Javascript. Questa regola tanto semplice è fortunamente sempre più condivisa. Nel caso della nostra pagina, se validiamo il form anche sul lato server, abbiamo rispettato la regola.

La quarta vista

C'è, tuttavia, un secondo allarme sull'accessibilità che tende ad essere sottovalutato. Lo scopriamo appena prendiamo in considerazione la quarta vista sul nostro documento, quella che chiameremo 'vista semplice con azione', ovvero XHTML + Javascript.

La maggior parte degli sviluppatori web ritiene che ogni browser con supporto di Javascript supporti anche i CSS. Se è vero nella maggior parte dei casi, ci sono alcuni browser che supportano Javascript ma non i CSS. Inoltre, è possibile che un utente imposti un foglio di stile personalizzato che va a sovrascrivere quello dell'autore della pagina: crea così un proprio livello di presentazione continuando ad usare il livello dell'azione definito dall'autore.

Se uno dei pochi utenti di Netscape 3 rimasti in circolazione visitasse la nostra pagina di esempio la visualizzerà secondo la 'vista semplice con azione'. Netscape 3, infatti, non ha il minimo supporto dei CSS, ma può gestire uno script per la validazione dei form. Il nostro script, dunque, dovrebbe tenere conto anche di questa possibile situazione (Javascript senza CSS). In altre parole, non potrebbe basarsi solo su cambiamenti di stile per informare l'utente degli errori di compilazione. Colorare di rosso i campi non corretti e dire "Per piacare, compila di nuovo i campi in rosso", non è consentito (perchè quell'utente potrebbe non vederli con quel colore, n.del.trad).

Fortunatamente gli script di validazione dei form sono più vecchi di Netscape 3, e la maggior parte di essi usa i classici alert Javascript. Gli alert non sono il massimo in termini di amichevolezza per l'utente, ma funzionano su tutti i browser che supportano Javascript. Inoltre, oggi abbiamo a disposizione sistemi molto più sofisticati per informare gli utenti. Potremmo ad esempio far comparire i messaggi di errore vicino ai campi del form, magari con un testo scritto a lettere chiare, grandi e quindi user-friendly. E allora, uno script ben concepito mostrerà l'alert solo a quei browser che non supportano queste funzionalità avanzate.

Una volta che lo script sia stato realizzato secondo queste linee guida, colorare di rosso i campi non corretti è consentito. L'effetto serve ora ad evidenziare ancora di più gli altri avvisi, e se non funziona niente viene perso. Rimane cruciale il testo del messaggio di errore. Non possiamo essere sicuri che l'utente finale riuscirà a vedere quei campi in rosso, per cui usare le parole "campi in rosso" non è consentito.

Stili per la 'vista globale'

Rimane un problema a livello di accessibilità: l'uso degli stili riservati alla 'vista globale' (XHTML + CSS + Javascript).

Supponiamo che il nostro menu di navigazione divenga sempre più grande. Decidiamo allora di creare uno script per renederlo più usabile. Inizialmente il menu mostrerà solo le categorie principali. Cliccando o passando con il mouse sopra una categoria saranno mostrati i link che essa contiene. In pratica, dobbiamo nascondere questi blocchi di link con display:none. Lo script si occupa di effettuare il passaggio tra display:none e display:block.

Questo script funziona bene nella 'vista globale'. Non funziona invece in quella 'semplice' (solo XHTML) o in quella 'semplice con azione' (XHTML + Javascript), dal momento che in queste viste gli stili CSS non sono supportati. Non è un problema se abbiamo strutturato correttamente il nostro XHTML. L'utente che non può contare sui CSS vedrà una lunga lista di link con le categorie come intestazione. Il sistema di navigazione è meno usabile, ma è ancora accessibile.

Il problema è nella 'vista semplice con presentazione' (XHTML + CSS). Se inseriamo la regola con display:none nel foglio di stile, il browser nasconderà ovviamente i blocchi con i link. Se Javascript non funziona o non è supportato, insomma, l'utente non avrà la possibilità di vedere e usare quei link. La navigazione non funziona, e il sito non è dunque accessibile.

Per fortuna la soluzione è semplice: se vogliamo usare regole di stile che nascondono il contenuto e che poi saranno modificate da uno script, impostiamo queste regole in Javascript. Invece di aggiungere display:none al foglio di stile, dovremmo aggiungere allo script una routine con l'evento onload che imposterà la proprietà display dei blocchi di link sul valore none. In questo modo, se lo script non funziona, i blocchi non vengono nascosti e la navigazione rimane accessibile.

Usare Javascript responsabilmente

Rivediamo cio che abbbiamo imparato. Primo il punto su Javascript:

Ogni Javascript dovrebbe migliorare l'usabilità del sito. Credo che su questo punto si dovrebbe insistere e molto nel corso dell'anno. C'è molta gente che usa gli script solo per impressionare e/o per provare la propria abilità con questo linguaggio. Se non si sa bene a cosa possa servire uno script, non usiamolo. Questo dovrebbe essere valido soprattutto per quelle complicate interfacce in DHTML.

Ci sono 3 regole generali per l'uso di Javascript in un sito accessibile:

1. Il sito dovrebbe funzionare anche quando il browser non supporta Javascript, ovviamente.
2. Uno script dovrebbe funzionare anche quando il browser non supporta i CSS. Uno script non può basarsi solo su cambiamenti di stile per conseguire l'obiettivo per cui è stato creato. Creare un livello di azione senza presupporre l'esistenza di un livello di presentazione a cui quello si appoggia può portare ad esiti imprevisti. Credo che dovremo prestare più attenzione a questo aspetto nel corso del prossimo anno.
3. Gli stili che nascondono contenuto e che saranno poi manipolati con uno script dovrebbero essere impostati con Javascript. Se si aggiunge un display:none al CSS e ci serviamo di Javascript per modificarlo, il sito avrà problemi se viene visualizzato con Javascript disabilitato e CSS abilitati.

Quando si crea un livello di azione con Javascript, dovremmo prestare attenzione a queste 3 regole. Combinandole con un po' di ragionamento logico, ci assicureranno un solido livello di accessibilità del sito anche quando si usano Javascript molto avanzati.

Si noti, però, che 'solido livello di accessibilità' non significa 'perfetta usabilità'. Il sito sarà sempre più usabile nella 'vista globale' con CSS e Javascript che in quella semplice. A questo non c'è rimedio, e tuttavia non dovrebbe impedirci di creare interfacce in Javascript usabili.

In un prossimo articolo parlerò in dettaglio del falso e potenzialmente pericoloso dibattito su "accessibilità vs. usabilità".