JavaScript e accessibilità: esigenze a confronto

JavaScript e accessibilità non sono due modi contrastanti di vedere il Web. Entrambi hanno come scopo principale il miglioramento dell’esperienza utente, perseguito con modalità diverse.

Infatti, JavaScript opera principalmente sul livello del comportamento di una pagina Web, mentre l’accessibilità è più rivolta alla strutturazione di quest’ultima. Il problema sorge in un unico caso: quando JavaScript non è supportato o è supportato parzialmente.

Il primo caso riguarda quei programmi utente che non offrono supporto nativo a JavaScript. Tipico il caso dei browser testuali (come Lynx) che, pur riconoscendo l’elemento script, non eseguono il codice ivi contenuto. In questo caso, se vogliamo usare degli script, ci sono due alternative:

1. Creare una versione alternativa del sito senza script intercettando la stringa HTTP_USER_AGENT del browser (nel caso di Lynx contiene la sottostringa Lynx) o, meglio ancora, verificando che il browser supporti JavaScript estraendo informazioni sul suo conto lato server (per esempio, in PHP è possibile farlo tramite la funzione built-in
   get_browser()). Un approccio del genere viene seguito da siti come Amazon e documentato in questo mio post.
2. Creare degli “accessibility hooks” all’interno del codice delle pagine per far si che i browser che non supportano JavaScript possano accedere lo stesso al contenuto. Per esempio, se ho un link che punta ad un box nascosto tramite JavaScript, posso usare un ancora sul link e un ID sul box per fare in modo che quando l’utente attiva il link (in Lynx premendo Invio) il browser lo reindirizzi sul box:

   <p><a href="#box">Visualizza</a>

   </p> <div id="box">...</div>

   Mai generare gli attributi degli elementi tramite JavaScript: il browser che non supporta JavaScript leggerebbe degli elementi senza attributi, e quindi attivando il link non succederebbe nulla, o meglio, il browser ricaricherebbe il documento.

Il secondo caso riguarda quei programmi utente, come i lettori di schermo, che hanno un supporto parziale a JavaScript. In particolare, il problema principale per questo tipo di programmi è il rendering del contenuto generato dinamicamente tramite script. Ricordiamo questo: i lettori di schermo non sono browser, e quindi leggono quello che il browser del computer carica. Nel caso del contenuto generato tramite script, i lettori di schermo supportano correttamente il contenuto generato quando viene caricata la pagina, ossia durante l’evento load. Per quello che riguarda gli altri eventi, i lettori di schermo leggono il contenuto dinamico solo se gli elementi su cui si attiva l’evento possono ricevere focus da tastiera. Cosa accade in questo caso? Se il lettore di schermo legge il documento con la sua memoria virtuale attivata, allora la lettura del documento ripartirà esattamente dal punto in cui viene inserito il nuovo contenuto. Viceversa, se tale memoria virtuale non è attiva, la lettura ripartirà dall’inizio della pagina. Va da se che questo può rivelarsi davvero problematico se stiamo usando una tecnologia come Ajax.

In altre parole, non bisognerebbe mai delegare a JavaScript la generazione di contenuto vitale per la comprensione delle nostre pagine, cercando sempre di usare un meccanismo di ripiego (fallback mechanism) per quei casi in cui JavaScript non è supportato o è supportato solo in parte.

Autore: Gabriele Romanato