Andrea Gandino

In effetti, guardando al titolo di questo articolo, mi rendo conto che non potevo sceglierne uno più generico. Non sono neanche sicuro che ci sarà una parte 2 sull’argomento, ma ho voluto cautelarmi nell’eventualità che un giorno io abbia voglia di ampliare i concetti illustrati nello sproloquio che segue.

Il fatto è che vorrei parlare per un attimo circa l’accessibilità di Javascript, e i problemi che comporta il programmare senza un criterio preciso.

Direttamente tratto dal corrispondente lemma su Wikipedia, troviamo che:

L’accessibilità, in informatica, è la capacità di un dispositivo, di un servizio o di una risorsa d’essere fruibile con facilità da una qualsiasi categoria d’utente.

Di fatto il problema principale quando si parla di accessibilità di Javascript è che non tutti gli utenti possono avere Javascript abilitato nel loro browser. Ciò è dovuto, almeno in parte, al fatto che Javascript è considerato una delle basi per gli attacchi via browser ai danni degli utenti, e ancora oggi, ad esempio, IE6 per Windows, se settato ad un livello di sicurezza ‘medio’ chiede all’utente se voglia o meno eseguire uno script, piuttosto che un altro.

Addirittura, alcune aziende e alcuni utenti, per eliminare completamente l’eventualità di subire un attacco tramite Javascript, lo disabilitano completamente, senza porsi troppe domande.

Diciamo che il risultato che otteniamo è che l’utenza è più che mai frazionata tra coloro che navigano con Javascript abilitato, coloro che si riservano la scelta di lanciare o meno gli script e coloro che invece ne ignorano completamente l’esistenza, lasciandolo disabilitato in modo permanente.

Recentemente con l’avvento di AJAX, Javascript è tornato più che mai d’attualità. AJAX permette di realizzare richieste asincrone al server, interagendo con pagine complesse che possono quindi interrogare un database, prenderne le informazioni, rimandare il contenuto informativo alla pagina d’origine, che può essere quindi aggiornata senza la necessità di ricaricarla.

I prezzi da pagare quando si usa AJAX sono essenzialmente due:

1. Se l’utente che carica la nostra pagina non ha Javascript abilitato, tutte le nostre funzionalità sviluppate attraverso AJAX risultano essere completamente inutili.
2. Ammesso che l’utente abbia Javascript abilitato, a meno di particolari accorgimenti l’utilizzo di AJAX nega all’utente la possibilità di usare correttamente il bottone per tornare indietro di una pagina: una volta caricate in un livello delle nuove informazioni prelevate da un database, è impossibile riavere il contenuto precedente mediante il classico ALT+freccia sinistra.

In realtà il punto 1 è quello veramente importante, perché non riguarda esclusivamente AJAX, bensì qualsiasi cosa realizzata tramite Javascript.

Se la regola generale per sviluppare un qualcosa di accessibile è non tagliare fuori potenziali utenti, nel nostro casi ciò si traduce in non tagliare fuori chi non usufruisce di Javascript.

Diciamo che coloro che non hanno Javascript abilitato devono comunque poter accedere al contenuto da noi preparato; in altri termini, il fatto di non avvalersi di Javascript non deve comunque pregiudicare una visita alla pagina che stiamo realizzando.

In termini tecnici, dobbiamo assicurarci che il nostro codice degradi graziosamente, traduzione (molto) libera dall’inglese graceful degradation, definizione che sta a significare quanto segue:

(La degradazione con grazia) è quella proprietà di un sistema in base alla quale, ove si verifichi un errore, il sistema continua a funzionare, sebbene con una qualità inferiore, invece che arrestarsi completamente.

Un esempio piuttosto banale è quello delle finestre popup. Tralasciando il fatto che i cosidetti ‘event handlers’ bisognerebbe trattarli in un’altra maniera, e non scrivendoli inline, per realizzare un popup normalmente scriveremmo:

<a href="#" onclick="window.open('http://www.example.com')">Apri il popup di Example.com</a>

Ad ogni click, la funzione open, chiamata dall’oggetto window, aprirà una nuova finestra del browser che mostrerà il sito passato come parametro, vale a dire http://www.example.com.

Notare che l’attributo href, che normalmente gestirebbe lui il sito cui punta il link, è settato a #, vale a dire la pagina corrente. In questo modo, siccome l’evento onclick è gestito da Javascript, nel momento in cui Javascript non è più utilizzabile, la direttiva onclick viene completamente ignorata, e il link viene eseguito cercando di andare all’indirizzo specificato dall’attributo href.

Ciò però si rivela un fallimento, visto che href esegue soltanto un refresh della pagina.

E’ il tipico scenario: “Con Javascript disabilitato, la funzionalità del link va a donne di facili costumi”.

Provando a migliorare il nostro link, proviamo a fare qualcosa di questo genere:

<a href="http://www.example.com" onclick="window.open(this.href)">Apri il popup di Example.com</a>

In questo modo, quando Javascript non è disponibile e pertanto si fa riferimento all’attributo href, il nostro link porta comunque alla pagina desiderata, sebbene non in un popup.

C’è di che essere allegri, è già un passo avanti.

Piccolo problemino: con Javascript abilitato la pagina corrente cambia non appena si clicca sul collegamento. Per ovviare a questo problema, inseriamo una semplice direttiva return: false; all’interno dell’evento, che, di fatto, disabilità il link dopo aver aperto la finestra popup, che è proprio quello che vogliamo.

<a href="http://www.example.com" onclick="window.open(this.href); return false;">Apri il popup di Example.com</a>

E’ chiaro come un ragionamento di questo tipo sia applicabile non solo ai popup, ma anche a qualsiasi altro tipo di collegamento, o evento, che preveda l’uso di Javascript (per esempio, un box a comparsa che sfrutta una di quelle belle librerie di effetti che si vedono in giro). Bisogna tenere sempre presente l’eventualità che Javascript non sia abilitato, e, cosa ancora più importante, bisogna che nessuno sia escluso dalla lettura della nostra pagina.

Ecco, per dirla tutta, c’è un’altra eventualità, più sottile. Siccome di browser ne esistono parecchi, e in particolar modo quelli vecchi risultano essere, per l’appunto… vecchi, è un dato di fatto che le funzioni che riguardano il DOM possano non essere presenti nello stesso modo su tutte le piattaforme.

Così, anche un utente che ci mette tutta la sua buona volontà tenendo Javascript abilitato, ma che ha la sfortuna di dover navigare su un browser che, ad esempio, non supporta la funzione del DOM getElementById, si trova nella stessa situazione di un utente che non ha Javascript abilitato: in pratica, se noi sviluppatori non prendiamo delle contromisure, la sua navigazione è compromessa.

Basta però un semplice controllo per ovviare al problema. Nei nostri script basta verificare che la funzione esista; in caso contrario, un return false; bloccherà l’esecuzione della funzione, non danneggiando (più di tanto) l’utente con un DOM incompleto.

if(!document.getElementById) return false;

Chiaramente, andrebbero fatti controlli molto più approfonditi, potenzialmente per ogni funzione DOM che usiamo, per avere uno script che davvero degradi con grazia.

Per concludere questa sbulaccata di roba, banale e nota ai più, andiamo a vedere chi beneficia di un codice che degrada con grazia:

1. Come detto, tutti gli utenti che non hanno Javascript abilitato ci ringrazieranno con riverenze multiple per non aver compromesso la loro visita al nostro sito.
2. Anche tutti gli utenti che navigano attraverso dispositivi diversi dal browser visuale ci ringrazieranno: i link saranno perfettamente leggibili sia da browser testuali, sia da browser vocali e così via.

3. Quella fetta di utenti che si sentono un po’ abbandonati, per il fatto di usare ancora un browser ‘datato’, non mancheranno certo di dimostrarci il loro amore :)

   Però, ragazzi, forse sarebbe il caso di passare ad un browser più moderno. Che ne dite?