Traduzione del primo capitolo del corso di javascript non intrusivo di Chris Heilmann. Dopo aver separato presentazione, dati e struttura, questo corso spiega un ulteriore livello di astrazione da raggiungere: le azioni.

Javascript è uno splendido strumento per aumentare l’usabilità di un sito web. E’ il layer aggiuntivo sopra il mark-up “cos’è questo testo” e il CSS “come dev’essere mostrato”. Javascript aggiunge una nuova dimensione, il “come questo elemento si comporta”.

Nelle pagine seguenti discuteremo e vedremo come possiamo usare Javascript, mantenendo invariata l’accessibilità. La tecnica di separare completamente Javascript dagli altri due livelli dello sviluppo web è diventata nota sotto il nome “Javascript non intrusivo”, dato che “Javascript accessibile” non definisce esattamente la tecnica in questione. E’ possibile avere un Javascript perfettamente separato ed essere ancora totalmente inaccessibili.

Comunque sia, entriamo nei dettagli.

Capitolo 1: Operazione Pulizia

Lo sviluppo web negli scorsi anni ha subito un cambiamento, abbiamo smesso di mescolare la presentazione con la struttura, e questo ha reso più facile il cambiare layout attraverso il sito cambiando semplicemente il foglio di stile. Ulteriore separazione è possibile evitando l’uso di ogni stile e classe inserita nel codice, preferendo l’ereditarietà e i selettori contestuali

diventa

CSS:

HTML:

e alla fine

CSS:

HTML:

La stessa evoluzione può e deve accadere per Javascript.

Tenere Javascript separato

La prima regola del club del Javascript non intrusivo è di non parlare mai del club del Javascript non intrusivo. No, aspettate, è…

1. Mai, in nessuna circostanza, aggiungere Javascript direttamente al documento.

Uno dei grandi pregi di Javascript è che può essere consegnato tramite un file separato. Come i CSS, questo significa che è possibile applicare una collezione di funzioni ad ogni pagina del sito, e se è necessario modificare una sua funzionalità, può essere fatto in un documento anzichè modificare ogni singola pagina.

Questo significa - tranne in casi particolari - che tutto ciò che è necessario vedere in un documento HTML è:

Questo è tutto ciò di cui avremo bisogno, non più inline Javascript. Leggete e ripetete.

2. Javascript è un miglioramento, non una funzionalità certa.

Possiamo usare Javascript solamente per migliorare una funzionalità già presente, non possiamo affidarci completamente ad esso. Il supporto Javascript può essere disattivato o filtrato tramite un proxy o un firewall di una compagnia sensibile ai problemi di sicurezza. Non è possibile considerarlo come garantito.

Questo non significa che non possiamo usare Javascript, ma solamente che dovrà essere aggiunto come una opzione piuttosto che come un requisito.

HTML:

Javascript:

E’ perfettamente valido, ed eviterà gli utenti di affrontare un reload di pagina quando è stato dimenticato l’inserimento di un valore.

HTML:

Javascript:

Apparentemente agisce allo stesso modo, ma ha un problema. Se Javascript è disattivato, il pulsante di invio non effettuerà alcuna azione, a prescindere dal numero di volte che l’utente frustrato lo premerà. Ripetiamo: non si può avere fiducia su Javascript, non bisogna affidarsi ad esso.

3. Controlla la disponibilità di un oggetto prima di accedere ad esso

Molti errori Javascript occorrono semplicemente perchè lo sviluppatore era troppo pigro per controllare se un metodo o un oggetto era disponibile o meno.

Javascript:

può risultare in un errore Javascript, quando l’oggetto o non è disponibile.

Javascript:

funzionerà in ogni situazione.

Questa tecnica è prevalentemente usata per controllare se un browser è abile a supportare una certa funzionalità Javascript. Nei giorni delle prove e degli errori durante lo sviluppo (non importava, pagava il cliente, o la .com per cui si lavorava) questo era effettuato tramite uno script di identificazione browser, un concetto malato dal principio (ogni volta che un browser era aggiornato o un nuovo browser era diffuso, lo script aveva bisogno di essere aggiornato). Per molti degli esempi usati attualmente è necessario controllare se il browser è in grado di capire il W3C DOM, il che ci porta alla prossima regola.

4. Create Javascript, non dialetti per specifici browser

A meno che sia presente un’ottima ragione, non dovremmo mai usare estensioni specifiche dei browser agli standard web. Il tempo di fare controlli per document.layers (Netscape 4.x) o document.all (Internet Explorer < 5.x) è passato. Tutti i browser moderni supportano il metodo DOM document.getElementById, e questo è quello che usiamo e controlliamo.

Javascript:

Il secondo controllo è necessario solamente in quanto alcune prime versioni di Opera sostenevano di supportare il DOM, ma non lo supportavano correttamente.

5. Non prendere in prestito variabili da altri script

Quando creiamo una funzione o una funzionalità dovremmo essere certi che tutte le variabili usate siano locali, per evitare che una funzione possa sovrascrivere una variabile usata da un’altra funzione.

Javascript:

6. Mantenere gli effetti indipendenti dal mouse

Assicurarsi che le cose possano funzionare solo in presenza di Javascript attivato non è abbastanza. Dobbiamo considerare gli utenti che non possono usare un mouse in parte o del tutto. Inoltre dobbiamo assicurarci che gli effetti attivati contemporaneamen da azioni del mouse e azioni di tastiera.

Il maggior problema con l’indipendenza dai mouse sono gli elementi dei moduli che vengono validati o attivano un effetto tramite onchange oppure onblur. Non usateli, semplicemente.

Un uso comune di questa tecnica inaccessibile è l’uso di box di selezione come navigazione.

HTML:

Javascript:

Prova questo esempio di modulo inaccessibile

Apparentemente il problema principale è che quando viene usata una tastiera per selezionare l’elemento tramite il tasto tab, premendo la freccia in basso per selezionare qualcosa non si potrà andare oltre la prima opzione, in quando send() verrà attivata non appena passerete dalla prima alla seconda opzione.

Utenti esperti di tastiera sapranno che è necessario premere alt+freccia in basso all’inizio per espandere l’intero menù prima di selezionare la voce. In ogni caso, questo non è noto a tutti gli utenti. Inoltre, l’esempio in questione non avrà effetto quando Javascript non è disponibile.

HTML:

Javascript:

PHP:

Prova questo esempio di modulo accessibile

Questo, in confronto, lavora perfettamente, ed risparmia una server hit inutile allo script send.php, che viene chiamato solo quando Javascript non è abilitato.

A proposito di onkeypress

Durante la lettura delle Linee Guida per l’Accessibilità dei Contenuti Web è richiesto di usare gestori di eventi indipendenti dalle periferiche nei nostri scripts:

Questo suona perfetto in teoria, ma nelle situazioni reali, il gestore di eventi onkeypress è mal supportato da diversi browser. Gli utenti che si affidano alla navigazione via tastiera normalmente hanno un tasto predisposto per simulare un click, di solito il tasto invio o la barra spazio, ed entrambi questo attivano l’evento onclick. Usando onkeypress è inoltre possibile sovrascrivere altre funzionalità di tastiera che gli utenti desiderano. Esempi sono la funzionalità Type Ahead di Mozilla, le Extensive Keyboard Shortcurts di Opera (come ‘A’ per il prossimo link) o i JAWS’ Keyboard Controls.

In questo modo facendo la giusta cosa prevista dalle linee guida, potremmo rendere il nostro script addirittura meno accessibile.

Negli esempi che seguiranno in questo corso, aggiungeremo onkeypress come gestore extra, ma lo terremo commentato. Questo verrà fatto per permettere di attivare questo evento nei casi necessari, o nel caso dobbiate passare un test di accessibilità tramite tool automatici piuttosto che con utenti reali.

http://www.onlinetools.org/articles/unobtrusivejavascript/chapter1.html

Chris Heilmann has been bouncing around the globe working for several agencies and companies. A web enthusiast from 1997 on workplaces include Munich, London, Santa Monica, San Francisco and Mumbai. Chris spends far too much time for his own good on his free PHP and Javascript resources, scripts and applications at http://www.onlinetools.org/ and generally strives to fight for a better, faster and more accessible web. More articles can be found at http://icant.co.uk