JavaScript e accessibilità
Lunedì 10 Maggio 2010 - 08:07
di Gabriele Romanato
Sfatiamo un luogo comune: 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:
- Creare una versione alternativa del sito senza script intercettando la stringa
HTTP_USER_AGENTdel browser (nel caso di Lynx contiene la sottostringaLynx) 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. - Creare degli “accessibility hooks” all’interno del codice delle pagine per far sì 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.
Categoria: Scripting | Permalink
Commenti
1
Fino a poco tempo fa si leggevano ancora post di web designer che sconsigliavano l’uso di javascript in favore dell’accessibilità!
Ottimo articolo e ottimi suggerimenti.
Interessantissima la gestione dei malfunzionamenti con i lettori di schermo.
# - postato da Giacomo Ratta - 10 Maggio 2010 - 14:44
2
“Mai generare gli attributi degli elementi tramite JavaScript”
Gli ID, ma per gli attributi in genere non sono d’accordo. Se l’attributo serve solo con javascript attivo allora è anche più giusto che venga generato da javascript.Ad esempio un “diplay:none” di un “tab” secondario.. è giusto che la classe o lo stile vengano dati direttamente da javascript
Credo che per l’accessibilità javascript sia molto d’aiuto.
# - postato da scienzedellevanghe - 10 Maggio 2010 - 14:52
3
Articoli simili dovrebbero essere scritti più spesso, ogni tanto un po’ di chiarezza fa bene. Bel post.
# - postato da Tommaso Baldovino - 12 Maggio 2010 - 09:12
4
Un bell’articolo su
Progressive Enhancement with JavaScripthttp://www.alistapart.com/arti.....avascript/
# - postato da bajo - 12 Maggio 2010 - 19:38
5
Non sono d’accordo. Secondo me l’utilizzo di javascript non migliora l’accessibilità ma l’usabilità di un sito web.
L’uso di javascript provoca inaccessibilità delle pagine web. Un sito con degli script al suo interno diventa accessibile solamente quando per gli effetti javascript è prevista una alternativa fruibile in ogni contesto, che equivale al non utilizzare javascript.Altrimenti non mi spiego la differenza tra la Gmail con javascript e la Gmail in html (visibile non solo quando la si sceglie dalle impostazione ma anche quando si naviga con browser non supportati ma con javascript abilitato). Gmail è perciò accessibile perchè in ogni situazione porta ai contenuti: l’utilizzo di javascript semplifica solamente l’esperienza utente ma non intacca le funzioni principali che sono l’invio di una mail e la lettura di quelle ricevute.
6
@Paolo, gmail è un esempio fuori luogo perché si tratta di una applicazione molto complessa.
Con javascript puoi migliorare l’usabilità del sito senza intaccare l’accessibilità. Ma deve essere lo scopo che ti sei prefisso.Ti faccio due esempi al volo: Html in movimento e ajax.
Provali prima a javascript abilitato, poi disabilitalo e vedi che resta pienamente navigabile ed accessibile.# - postato da scienzedellevanghe - 17 Maggio 2010 - 16:02