vai ai contenuti
vai al menu

Regione Piemonte per l'Accessibilità e l'Usabilità



WCAG 2.0 e il Javascript: come comportarsi?

Introduzione

Le pagine web stanno diventando sempre più interattive e dinamiche: spesso ci troviamo a consultare pagine che sono complesse applicazioni basate sull'insieme di tecnologie chiamato AJAX (Asynchronous JavaScript and XML), le cui funzionalità fanno uso per larga parte di JavaScript. Sono ormai lontani i tempi in cui i Javascript servivano per effetti di abbellimento, come la scia di stelline dietro al puntatore del mouse: possiamo dire che oggi questi costituiscono un elemento chiave dell'interattività dei migliori siti contemporanei.

Ma cos'è il JavaScript e a cosa serve? Nato nel 1995 a supporto di Netscape Navigator, è un linguaggio che viene interpretato direttamente dal browser e che quidi permette di arricchire le pagine HTML con funzioni di rapida esecuzione, interattive e dinamiche. Negli anni successivi il JavaScript si è evoluto nella sintassi, nel supporto da parte dei vari browser e anche nel modo di utilizzo, passando dal DHTML (Dinamic HTML) nel 2000 al Javascript non invasivo e ad AJAX nel 2005. Attualmente il JavaScript è usato per realizzare le RIA (Rich Internet Application), che possono essere considerate come applicazioni internet così ricche da assomigliare a un software vero e proprio (con una barra di funzioni, generalmente sotto forma di iconcine per una maggiore compattezza e fruibilità).

I browser stanno migliorando progressivamente il loro supporto dei Javascript, ma quali difficoltà possono incontrare le persone con disabilità nel loro uso? In altre parole, come si concilia questo scenario con l'accessibilità? Vedremo nel seguito quali risposte cercano di dare le WCAG 1.0, le successive WCAG 2.0 e la Legge Stanca. Ricordiamo che la Legge Stanca, nella versione attuale, fa riferimento alle WCAG 1.0, mentre è in corso una revisione dei Requisiti Tecnici della Legge Stanca basata sulle più recenti WCAG 2.0.

Prima di tutto, possiamo elencare qui sotto, indipendentemente dalla versione delle WCAG, i principali problemi che l'uso non corretto del javascript può portare:

  • Navigazione: il javascript non correttamente usato può discriminare nell'uso di strumenti diversi dal mouse, come la tastiera o altre tecnologie assisitive.
  • Contenuti dinamici: il javascript permette di manipolare i contenuti delle pagine, ma gli utenti potrebbero non percepire i contenuti dinamici in assenza di avvisi espliciti .
  • Controllo da parte dell'utente: cambiamenti automatici, redirezionamenti delle pagine, apertura di nuove finestre sono meccanismi facilmente realizzabili con il javascript, ma possono creare disorientamento negli utenti di tecnologie assisitve senza avvisi e accorgimenti opportuni.

Da un punto di vista molto generale, possiamo dire che le pagine web dovrebbero far uso del Javascript in modo da evitare i problemi sopra citati. Questo è sicuramente il punto centrale della questione. Vediamo però nell'ordine come standard internazionali e la legge italiana hanno affrontato il tema.

Le WCAG 1.0 e la Legge Stanca

Le WCAG 1.0 (Web Content Accessibility Guidelines) non considerano il Javascript come una tecnologia di riferimento standard, per cui richiedono che contenuti e funzionalità principali di una pagina web siano fruibili anche con javascript disabilitati (checkpoint 6.3). Vedremo che questa importante considerazione costituisce una differenza sostanziale dalle WCAG 2.0.

Inoltre le WCAG 1.0 richiedono una compatibilità diretta con le tecnologie assitive e raccomandano di evitare il ricorso ad eventi che dipendono esplicitamente da un dispositivo particolare di input, discriminando così gli utilizzatori di altri dispositivi (checkpoint 8.1 e 9.3 ).
I requisiti tecnici della Legge Stanca riprendono le WCAG 1.0 (6.3, 6.4, 9.2, 9.3) e stabiliscono che le funzioni principali siano attive anche a Javascript disabilitati (req. 15) e che i Javascript non introducano discriminazioni nell'uso dei dispositivi di input come tastiera, mouse, altri sistemi (req. 16).

E' facile intuire quale impatto abbiano le WCAG 1.0 e i relativi requisiti della Legge Stanca nella progettazione delle moderne pagine web, basate su Javascript e in particolare su AJAX. E' richiesto infatti che le principali funzioni siano fruibili anche a Javascript disabilitato, anche se ovviamente in una forma meno interattiva ed usabile. Per far fronte a questa richiesta, esistono due strade: la graceful degradation (decadimento parziale), secondo cui l 'accessibilità è concepita come una sorta di bonifica fatta a posteriori, ed il potenziamento progressivo (progressive enhancement), basato su una versione iniziale delle pagine con funzioni verificate a Javascript disattiivo e su una successiva implementazione dei Javascript. La seconda strada è certamente la più indicata, e sebbene sembri più faticosa, a lungo termine presenta vantaggi nella gestione e manutenzione delle funzioni, al punto da diventare uno standard di buona realizzazione, detto anche JavaScript non invasivo (unobtrusive JavaScript). Si tratta di un insieme di buone pratiche, secondo cui la progettazione di una funzionalità per le pagine web deve distinguere nettamente fra i contenuti, la struttura (i tag HTML con valore semantico preciso), la presentazione (fogli di stile) ed i comportamenti. Secondo il potenziamento progressivo, il Javascript deve intervenire su quest'ultimo livello, i comportamenti, e dovrebbe evitare di manipolare contenuti, struttura e presentazione. In altre parole, dovrebbe intervenire dinamicamente su classi e identificatori degli elementi, in modo da cambiarne il comportamento sulla base di una struttura e una presentazione semplici anche in assenza di Javascript.

Le WCAG 2.0, i concetti principali

Le WCAG 2.0 fotografano una situazione più aggiornata del web, in cui i javascript sono parte integrante della navigazione, per cui la scrittura di pagine web con Javascript non può più essere considerato in sè causa di problemi di accessibilità. Come fare quindi? Considerare in questa nuova versione i javascript? Le WCAG 2.0 vanno in questa direzione, ma con un accorgimento importante: per non incorrere nel rischio di obsolescenza nel giro di qualche anno, è stata scelta un'impostazione neutrale rispetto alla tecnologia. In altre parole, le WCAG 2.0 sono state create in modo da applicarsi in linea di massima alle diverse tecnologie Web, ora e in futuro. Per far ciò, le WCAG 2.0 fanno riferimento in maniera generica a un insieme di programmi utente e di tecnologie.
Vediamo allora quali sono i principali "attori" in gioco per capire se un contenuto web è accessibile, facendo riferimento diretto alle definizioni date dal W3C nel glossario.

  • programmi utente (user agent): qualsiasi programma che recuperi e presenti contenuti web agli utenti. Per esempio, un web browser (Internet Explorer, Mozilla Firefox, Safari, Google Chrome, Opera), lettori multimediali, componenti aggiuntivi (plug-in) ed altri programmi - incluse le tecnologie assistive - che aiutino a trovare, a mostrare e ad interagire con i contenuti Web.
  • tecnologie assistive dell'utente: strumenti hardware e/o software che interagiscono come programma utente o in abbinamento con i principali programmi utente, per fornire funzionalità adatte ai bisogni degli utenti con disabilità, che vanno oltre a quelle offerte dai principali programmi utente.
  • tecnologia dei contenuti web (o semplicemente tecnologia): si tratta di meccanismi atti a codificare le istruzioni che verranno rese, interpretate o eseguite da un programma utente. Le tecnologie per il contenuto Web possono includere linguaggi di marcatura, formattazione di dati o linguaggi di programmazione, che gli autori possono utilizzare da soli o combinati tra loro per differenti esigenze. Alcuni esempi comuni di tecnologie per contenuto Web includono HTML, CSS, SVG, PNG, PDF, Flash, e JavaScript.

Secondo le WCAG 2.0, una tecnologia dei contenuti web è usata in modo compatibile con l'accessibilità (in inglese accessibility supported) quando questa "funziona con le tecnologie assistive e con le caratteristiche di accessibilità previste da sistemi operativi, browser e altri programmi utente". Nello specifico, affinché una tecnologia di contenuto Web possa essere definita compatibile con l'accessibilità, deve soddisfare contemporaneamente entrambi i seguenti punti, che sottolieano proprio la necessità di buon supporto da parte dei programmi utente ed una buona interazione con le tecnologie assisitive:

  1. La tecnologia di un contenuto web deve essere compatibile con le tecnologie assistive dell'utente. Ciò significa che il modo in cui la tecnologia è utilizzata è stata sottoposta a test per l'interoperabilità con le tecnologie assistive degli utenti nella lingua(e) del contenuto,
  2. La tecnologia di un contenuto Web deve usare dei programmi utente che supportano l'accessibilità e che siano disponibili agli utenti. Ciò si ottiene se si verifica almeno uno dei seguenti casi:
    • La tecnologia deve essere supportata nativamente con i programmi utente ampiamente diffusi, a loro volta compatibili con l'accessibilità (come HTML e CSS);
    • La tecnologia deve essere compatibile con plug-in ampiamente diffusi, a loro volta compatibili con l'accessibilità;
    • Il contenuto deve essere disponibile in un ambiente protetto, come una rete universitaria o una rete aziendale, e il programma utente richiesto dalla tecnologia ed usato dall'organizzazione è a sua volta compatibile con l'accessibilità;
    • Il programma utente o i programmi utente che supportano la tecnologia sono compatibili con l'accessibilità e sono disponibili per il download o acquistabili in una modalità che non impegni maggiormente una persona con disabilità rispetto ad un normodotato e sia agevole da trovare e da ottenere per una persona con disabilità così come per un normodotato.

Le funzionalità della tecnologia possono essere utilizzate in modo non compatibile (ovvero, possono non funzionare con le tecnologie assistive, ecc.) fino a quando non entrano in contatto con la necessità di essere conformi a un qualsiasi criterio di successo (per esempio, quando la stessa informazione o funzionalità è disponibile anche in un altro modo accessibile).

Quindi come usare il javascript compatibilmente con le WCAG 2.0?

Dopo le necessarie premesse della precedente sezione, possiamo finalmente dare una risposta: il Javascript è una tecnologia disponibile nativamente sui principali programmi utente (cioè in tutti i browser recenti) e se utilizzata in modo da essere fruibile con le tecnologie assisitve è compatibile con l'accessibilità.

Le WCAG 2.0 hanno definito per i javascript le tecniche per gli script lato client (parte di un ampio insieme di tecniche per le principali tecnologie dei contenuti web) . Nel seguito trovate l'elenco dei titoli delle tecniche, ognuno con la sua numerazione preceduta dalla sigla SCR (client-side Scripting). Riassumendo, possiamo dire che le tecniche per i Javascript si possono raggruppare in tre insiemi, relativi alle tre principali problematiche per i JavaScript presentate all'inizio:

  • La possibilità di usare diversi dispositivi di input, la corretta definizione dell'evento onchange nei menù a tendina. Eventi definiti solo per il mouse (per esempio onlick, onmouseover e onmouseout) vanno abbinati a corrispondenti eventi per tastiera (onkeypress, onfocus, onblur), se esistono (per esempio il doppio click non ha analogo evento da tastiera, e quindi non andrebbe usato). Va detto che ormai i browser supportano l'evento onclick anche per la tastiera, ma occorre valutare se tale fatto non ostacoli la corretta navigazione da tastiera (per esempio attivando, alla sola pressione del tasto tab usato per la navigazione, funzionalità inaspettate per l'utente).
  • Il controllo delle pagine, dal punto di vista di eventuali operazioni temporizzate, alert (da usarsi solo per avvisi importanti), apertura di nuove finestre, oppure scorrimento di contenuti.
  • In caso di modifica dei contenuti della pagina (DOM, Document Object Model), deve essere garantita una corretta lettura da parte degli screen reader. Se possibile, la nuova porzione di contenuto andrebbe posizionata sotto l'elemento che la attiva, mentre se ciò non è possibile occorre portare la lettura dello screen reader in una posizione utile per percepire la modifica (agire sul focus). In generale, l'utente deve essere avvisato se qualcosa cambia dinamicamente nella pagina e dove.

Aprofondimento sulle tecniche per i javascript

  • SCR1: dare la possibilità all'utente di estendere il tempo previsto per effettuare operazioni temporizzate (per cui soino definiti intervalli temporali di default)
  • SCR2: prevedere eventi javascript in modo da permettere l'uso di dispositivi di input diversi dal mouse (per esmepio la tastiera). Tecnica relativa al criterio di successo 2.1.1 e 2.2.1
  • SCR14: tecnica che riguarda gli alert javascript non essenziali; per questi occorre permettere all'utente di abilitare/disabilitare gli avvisi. Tecnica relativa al criterio di successo 2.2.4
  • SCR16: avvisare l'utente quando sta per scadere un limite di tempo definito dal programma per effettuare alcune operazioni. Tecnica relativa al criterio di successo 2.2.1.
  • SCR18: se si usano alert javascript per segnalare errori di compilazione di un form, l'alert deve descrivere testualmente l'errore e alla sua chiusura il focus deve essere portato sul campo di input in questione. Tecnica relativa al criterio di successo 3.3.1 e 3.3.3.
  • SCR19: usare l'evento onchange in modo che sia possibile scegliere i valori anche con dispositivi diversi dal mouse. Tecnica relativa al criterio di successo 3.2.2 e 3.2.5.
  • SCR20: usare sia funzioni precifiche per la tastiera sia per altri eventuali dispositivi (sebbene i recenti browser offrano un supporto sempre più ampio degli eventi standard). Tecnica relativa al criterio di successo 2.1.1.
  • SCR21: aggiungere contenuti alla pagina usando le funzioni specifiche previste per la modifica del Document Object Model (DOM). Tecnica relativa al criterio di successo 1.3.1.
  • SCR22: fare ricorso a script che permettano di fermare il lampeggiamento del testo . Tecnica relativa al criterio di successo 2.2.2.
  • SCR24: usare tecniche di potenziamento progressivo per l'apertura di nuove finestre e avvisare l'utente. Tecnica relativa al criterio di successo 3.2.5.
  • SCR26: inserire contenuti dinamici nel DOM immediatamente dopo l'elemento che attiva tale inserimento (per aggiornamenti sincroni) al fine di garantire una corretta sequenza sia della lettura da parte degli screen reader che della navigazione da tastiera (tab order). Tecnica relativa al criterio di successo 2.4.3.
  • SCR27: dare la possibilità di riordinare sezioni della pagina intervenendo sul DOM in maniera indipendente dal dispositivo di input. Tecnica relativa al criterio di successo 2.4.3.
  • SCR28: usare menù espandibili e collassabili per superare blocchi di contenuto. Tecnica relativa al criterio di successo 2.4.1.
  • SCR29: aggiungere azioni accessibili da tastiera agli elementi statici dell'HTML (definire tabindex)
  • SCR30: usare gli script per cambiare il testo dei link, agendo sul DOM per rendere se necessario il testo più dettagliato. Tecnica relativa al criterio di successo 2.4.4 e 2.4.9
  • SCR31: usarre gli script per cambiare il colore di sfondo o del bordo di un elemento che ha ricevuto il focus. Tecnica relativa al criterio di successo 2.4.7.
  • SCR32: definire meccanismi di validazione lato client dei form ed aggiungere eventuali messaggi di errore nel DOM in maniera compatibile con la lettura sequenziale degli screen reader. Tecnica relativa al criterio di successo 3.3.2 e 3.3.3.
  • SCR33: usare script per lo scorrimento dei contenuti e definire meccanismi per bloccarlo. Tecnica relativa al criterio di successo 2.2.1e 2.2.2
  • SCR34: calcolare la grandezza e posizione in modo che sia in proporzione alla dimensione del testo. Tecnica relativa al criterio di successo 1.4.4 e 1.4.8.
  • SCR35: rendere le azioni accessibili da tastiera usando l'evento onlcick relativo ad ancore e bottoni (poichè garantiscono un comportamento standard). Tecnica relativa al criterio di successo 2.1.1.
  • SCR36: definire un meccanismo che permetta agli utenti di mostrare del testo che si muove, scrolla o autoaggiorna in un'altra finestra o oarea di dimensioni maggiori. Tecnica relativa al criterio di successo 2.2.1
  • SCR37: creare meccanismi di avviso diversi dagli alert in modo indipendente dal dispositivo: per fare ciò rendere gli avvisi attivabili da link o bottone e garantire la corretta lettura e tabulazione per i nuovi contenuti inserendoli subito dopo l'elemento che li attiva. Tecnica relativa al criterio di successo 2.4.3.

Un esempio particolarmente utile delle complesse problematiche legate ai JavaScript è dato dalla tecnica SCR32: in essa si descrive come costruire un meccanismo di validazione di un form senza ricorrere agli alert (troppo invasivi) e nel contempo aggiungendo dinamicamente dei contenuti di supporto alla compilazione e con il focus posizionato in modo tale da consentire una lettura corretta con gli screen reader. Sostanzialmente, l'istruzione Javascript focus() permette di fare ciò, a patto che l'elemento su cui attivare il focus sia un link, ancora, area di una mappa o un elemento modulo.

Un ulteriore fattore di complessità è dato dagli screen reader, che possono essere usati in due modalità diverse: con la memoria virtuale attiva, che permette agli utenti una navigazione più completa, oppure con la memoria virtuale disattiva, con cui si può navigare solo attaverso link, ancore e gli altri elementi che possono avere il focus. In questa seconda modalità l'utente non viene avvisato dei cambiamenti del DOM, a meno di complesse operazioni e comunque dovendo rileggere il contenuto dall'inizio. Nel caso di memoria virtuale attiva le cose non vanno molto meglio: fino alla versione di Jaws 7, infatti, i cambiamenti dinamici vengono considerati solo in conseguenza degli eventi onclick e onkeypress. Per cambiamenti dinamici più generali previsti da AJAX, invece, viene coinvolto l'evento onreadystatechange (collegato all'oggetto XMLHttpRequest), che è supportato nella memoria virtuale solo dalla versione 8 di Jaws. A queste considerazioni si deve aggiungere il fatto che l'interazione fra Jaws ed i web browser può campbiare a seconda del tipo di brwoser e della sue versione, e che altri screen reader hanno comportamenti lievemente diversi.

Se proprio avessimo bisogno di attivare il focus su elementi che nativamente non lo supportano? Una prima soluzione (non compatibile con la sintassi dell'XHTML) consiste nell'uso dell'attributo tabindex valorizzato a -1, che permette di ricevere il focus senza però alterare l'ordine definito per le tabulazioni. Una seconda soluzione, molto più complessa ma più strutturata, consiste nell'uso dei ruoli, stati e proprietà definiti dalle WAI-ARIA, oggetto di un nostro approfondimento specifico.

Link utili

Aggiornamento: maggio 2012

Torna su

stampa la pagina


Torna su


Torna su