Garantire che l’utente possa controllare i cambiamenti temporizzati dei contenuti

Questa linea guida è tra quelle che creano più conflitto tra progettisti grafici e fautori dell’accessibilità, perché limita la realizzazione di interfacce utente basate sul movimento.

Gli oggetti in movimento sullo schermo e le funzioni temporizzate creano, infatti, numerosi tipi di problemi dal punto di vista dell’accessibilità:

• lampeggiamenti e sfarfallamenti possono causare crisi epilettiche in soggetti predisposti;
• le scritte scorrevoli sono poco leggibili da chi ha problemi di messa a fuoco o di nistagmo (si veda Capitolo 2, paragrafo “L’ipovisione”);
• l’interazione con oggetti mobili può essere difficile o impossibile per chi ha problemi di mobilità e usa dispositivi di puntamento alternativi (si veda Capitolo 2, paragrafo “Tecnologie assistive per disabilità motorie”);
• la temporizzazione di alcune funzioni può essere troppo breve per soggetti con disabilità cognitive o per chi naviga con uno screen reader.

Punto di controllo 7.1, priorità 1

Evitare effetti che generano immagini sfarfallanti

Il punto di controllo 7.1 trova la sua giustificazione nella necessità di proteggere da possibili crisi gli utenti che sono affetti, anche in maniera latente, da epilessia fotosensibile. Questo tipo di epilessia si manifesta con convulsioni, prodotte da un’anomala risposta del cervello a fenomeni di lampeggiamento che incidono sulla percezione del contrasto. Luci stroboscopiche, videogiochi, cartoni animati (famoso il caso di 685 bambini giapponesi colpiti tutti insieme da crisi dopo aver visto in TV una puntata dei Pokemon), o anche un sito web mal progettato, possono scatenare crisi da epilessia fotosensibile. Le WCAG 1.0 spiegano che gli attacchi possono essere indotti da sfarfallamenti compresi nella gamma tra 4 e 59 Hertz, con un picco di sensibilità intorno ai 20 Hertz.

La rivista Tempo medico, in un articolo intitolato Il maleficio arriva dal video, pubblicato sul n. 680 del 18 ottobre 2000, cita i risultati di uno studio scientifico compiuto dal CNR di Pisa in collaborazione con studiosi inglesi, sotto la guida del prof. Porciatti, in cui il picco di sensibilità viene posto a una frequenza inferiore rispetto a quella definita nelle WCAG 1.0:

In una ricerca realizzata su dodici volontari sani e undici adolescenti affetti da epilessia fotosensibile, Porciatti e i suoi collaboratori hanno dimostrato che nei soggetti normali l’attività elettrica tende a crescere parallelamente all’aumento del contrasto, fino a una certa soglia, per poi decrescere. Nei soggetti affetti da epilessia fotosensibile, invece, la risposta dell’attività elettrica cerebrale continua ad aumentare man mano che aumenta il contrasto, fino a raggiungere livelli doppi rispetto a quelli rilevati nei soggetti normali. Questa risposta anomala è stata rilevata dal gruppo di Pisa, soprattutto per frequenze di stimolazione tra i quattro e i dieci hertz, anche se studi condotti in precedenza mostravano che la frequenza che più facilmente scatena le crisi è quella attorno ai 15 hertz. Il difetto non è invece più rilevabile a frequenze maggiori.

L’epilessia fotosensibile è dunque una condizione patologica specifica, dovuta a una precisa alterazione neurofisiologica. La sua prevalenza tra i 4 e i 14 anni varia tra lo 0,5 e lo 0,8 per cento, ma l’incidenza appare in aumento, probabilmente proprio a causa della diffusione sempre maggiore di video utilizzati per la ricezione televisiva o per i videogiochi.

Sulle crisi da epilessia fotosensibile incidono non solo i contenuti video trasmessi, ma anche la frequenza di aggiornamento (refresh) del monitor utilizzato. Lo stesso articolo di Tempo medico cita un ulteriore studio:

I video diffusi nelle case erogano spesso stimolazioni luminose con caratteristiche di contrasto e frequenza corrispondenti a quelle che scatenano le crisi. Esiste tuttavia una certa differenza a seconda del tipo di schermo utilizzato. Per esempio, una ricerca realizzata da un gruppo di neurologi del Dipartimento di scienze neurologiche della Sapienza di Roma, guidato da Stefano Ricci, pubblicata sulla rivista Neurology, ha dimostrato che gli schermi a 50 hertz sono potenzialmente più pericolosi per chi soffre di questa forma di epilessia, mentre quelli a 100 hertz risultano più protettivi rispetto alla possibilità di scatenare le crisi.

Per capire quali sono i contenuti che occorre evitare per rispettare il punto di controllo 7.1, è disponibile sul sito del National Center for Accessible Media, NCAM, un esempio molto chiaro di oggetti sfarfallanti : mostra quattro campioni, dotati di una frequenza di aggiornamento dell’immagine rispettivamente di 4, 7, 20 e 59 Hertz. Meglio non guardarli, se si sa o si teme di poter incorrere in una crisi epilettica!

Per verificare se un brano video in formato AVI ha una frequenza di sfarfallamento pericolosa per i soggetti predisposti, è possibile utilizzare uno strumento gratuito, realizzato e distribuito dal Trace Center dell’Università di Wisconsin-Madison. Si tratta di un software per Windows, chiamato PEAT (Photosensitive Epilepsy Analysis Tool), scaricabile da http://trace.wisc.edu/peat/ . Uno strumento in grado di verificare la frequenza di sfarfallamento delle immagini animate in formato GIF è disponibile sul sito Webaccessibile.org, all’indirizzo http://www.webaccessibile.org/test/check.aspx .

Il punto di controllo 7.1, come tutti quelli della linea guida 7, è considerato un rimedio provvisorio, da dover attuare, cioè, fino a che i programmi utente non consentiranno all’utente di controllare direttamente il comportamento nocivo per l’accessibilità (in questo caso lo sfarfallamento). La questione delle raccomandazioni provvisorie è discussa in dettaglio nel primo paragrafo del Capitolo 15.

Inizio pagina

Punto di controllo 7.2, priorità 2

Non inserire oggetti intermittenti fissi o mobili

Il punto di controllo 7.2 si rivolge in particolare agli oggetti intermittenti fissi o mobili sullo schermo. Alla prima categoria appartengono i contenuti marcati con l’elemento BLINK, estensione proprietaria del linguaggio HTML, implementata originariamente in Netscape Navigator, ma non in Internet Explorer. L’uso dell’elemento BLINK produce, nei browser che lo supportano (Netscape, Firefox, Opera), il lampeggiamento delle scritte a cui è applicato, che diventano ciclicamente visibili e invisibili, con frequenza definita dal programma. L’effetto è veramente fastidioso, anche per persone non affette da problemi di vista o da epilessia. Non per niente il creatore dell’elemento BLINK, Lou Montulli, brillante programmatore a cui si devono numerose innovazioni per il Web, tra cui la realizzazione del browser testuale Lynx, ha definito BLINK the worst thing I’ve ever done for the Internet (la cosa peggiore che io abbia mai fatto per Internet).

Alla seconda categoria, quella cioè degli oggetti intermittenti in movimento, appartengono i contenuti marcati con l’elemento MARQUEE, la risposta di Microsoft all’elemento BLINK di Netscape.

Né BLINK né MARQUEE dovrebbero essere usati in un sito accessibile, perché sono elementi non standard: violano la linea guida 11, che raccomanda di usare tecnologie sviluppate dal W3C. Ma a maggior ragione non devono essere usati, perché creano lampeggiamenti e movimenti, che possono creare problemi in soggetti predisposti. Le Tecniche CSS per le WCAG 1.0 suggeriscono di usare i fogli di stile, se proprio si vuole ottenere un effetto di lampeggiamento: la proprietà text-decoration può assumere, infatti, il valore blink, che produce lo stesso effetto dell’omonimo elemento proprietario.

La differenza, rispetto all’uso dell’elemento, è che un foglio di stile che genera effetti fastidiosi può essere disabilitato dall’utente e sostituito con un foglio di stile personalizzato, rimuovendo così il problema. Tuttavia gli utenti che usano una tale precauzione sono ben pochi: infatti, per creare e attivare nel browser un foglio di stile personalizzato, è necessario un certo grado di conoscenza informatica, di cui purtroppo molti non dispongono. È preferibile perciò che gli sviluppatori evitino di ricorrere a effetti di lampeggiamento, anche se generati via CSS, se vogliono produrre documenti realmente accessibili.

Andrebbero evitati anche i lampeggiamenti generati per mezzo di script e oggetti incorporati Flash o Java, comunissimi, per esempio, nei banner pubblicitari. La pubblicità sul Web usa, infatti, il lampeggiamento e il movimento come vere e proprie tecniche per attirare l’attenzione dell’utente (si veda anche il paragrafo I lampi della pubblicità, nel Capitolo 1). Per di più, i banner pubblicitari non contemplano di solito alcun comando per fermare i lampeggiamenti o i movimenti al loro interno.

Inizio pagina

Punto di controllo 7.3, priorità 2

Creare documenti privi di contenuti in movimento

Il punto di controllo 7.3 è strettamente correlato al punto di controllo 8.1, che richiede la diretta accessibilità di script e oggetti di programmazione incorporati in un documento. Infatti, HTML e XHTML non sono in grado di produrre direttamente contenuti in movimento. Possono al massimo, tramite gli elementi IMG, SCRIPT e OBJECT, incorporare immagini, effetti grafici e oggetti di programmazione che generano o contengono elementi mobili.

Per soddisfare il punto di controllo 7.3, se proprio non è possibile realizzare documenti completamente privi di oggetti in movimento, bisogna almeno consentire agli utenti di fermare o evitare il movimento a propria discrezione. Gli oggetti incorporati devono perciò prevedere comandi per bloccare o eliminare il movimento. Il caso tipico è quello delle animazioni usate come messaggio di accoglienza in un sito: gli sviluppatori dovrebbero inserire comandi per consentire all’utente di saltarle o di fermarle. Il meccanismo usato in questi casi è, anche nei siti italiani, un comando in inglese, Skip intro, che significa “salta l’introduzione”.

Solitamente posizionato in basso, a sinistra o a destra, e non sempre visibilissimo, l’utilizzo di questo comando non è quasi mai un buon esempio dell’accessibilità, anche considerando il fatto che non tutti gli utenti conoscono l’inglese (l’equivalente italiano “salta l’introduzione” o, abbreviato, “salta intro” è meno diffuso). Spesso il comando per saltare l’animazione è esso stesso mobile, lampeggiante, reso poco leggibile dagli effetti grafici che vi sono applicati (Figura 10.1).

Una buona soluzione, invece, dal punto di vista dell’accessibilità, sarebbe quella di posizionare il comando per saltare l’animazione in alto nella pagina, in posizione ben visibile e con caratteri grandi e leggibili, meglio ancora se inserito nel codice HTML piuttosto che all’interno dell’oggetto Flash, in modo da dare all’utente la possibilità di attivare il comando immediatamente, senza dover aspettare il caricamento dell’animazione (Figura 10.2).

Una precauzione intelligente, da associare alla precedente, è quella di non far cominciare eventuali lampeggiamenti e cambiamenti rapidi del contenuto dell’animazione prima di qualche secondo, in modo da dare il tempo, a quegli utenti che sarebbero disturbati dal movimento rapido, di attivare il comando per saltare alla pagina successiva (avvertendoli, naturalmente, della presenza di oggetti in movimento e della possibilità di saltarli).

I siti realizzati in Flash hanno una forte propensione per le soluzioni grafiche complesse e dinamiche. Sono perciò quelli che più facilmente ignorano la richiesta del punto di controllo 7.3. Ne offre un esempio il sito del Dipartimento Infrastrutture Design Engineering Architettura dell’Università Gabriele d’Annunzio di Chieti e Pescara. Non solo nella schermata di accesso (mostrata in Figura 10.3 A) vi sono oggetti in movimento, ma non esiste un meccanismo visibile per fermare il movimento e/o passare alla schermata successiva. È solo passando con il mouse sulla scritta “idea container” che si scopre l’esistenza di un pulsante per effettuare l’accesso (Figura 10.3 B).

Inizio pagina

Punto di controllo 7.4, priorità 2

Evitare l’autoaggiornamento periodico dei documenti

Il punto di controllo 7.4 fa riferimento all’uso, deprecato dalle WCAG 1.0 ma tuttora diffuso, di inserire nella sezione HEAD di un documento HTML o XHTML un elemento META, avente la funzione di provocare l’autoaggiornamento temporizzato del documento caricato nel browser. Per ottenere, per esempio, che una pagina sia aggiornata ogni minuto, si adopera un codice HTML di questo tipo:

Perché l’uso di una tale funzione è nocivo per l’accessibilità? Le Tecniche HTML per le WCAG 1.0 lo spiegano così (sezione 1.1.3):

Gli sviluppatori non possono prevedere quanto tempo servirà a un utente per leggere una pagina; l’aggiornamento prematuro può disorientare gli utenti. Gli sviluppatori di contenuti dovrebbero evitare l’aggiornamento periodico, lasciando gli utenti liberi di decidere il momento in cui vogliono le informazioni più aggiornate.

L’imposizione dell’aggiornamento automatico temporizzato è dannosa in particolare per chi naviga con un sintetizzatore vocale: mentre un vedente può recuperare con una certa facilità il punto della pagina in cui si trovava prima dell’autoaggiornamento, chi, invece, deve basarsi solo sulle informazioni acustiche sequenziali, è costretto a una scansione molto più lenta e faticosa dei contenuti.

La home page di Repubblica.it fornisce un esempio di questo inaccessibile meccanismo. Si riaggiorna, infatti, ogni cinque minuti: un tempo più che sufficiente a un vedente mediamente abile nella lettura per leggere i titoli e scorrere anche i menu laterali; un tempo, al contrario, che può essere spiacevolmente insufficiente per chi naviga con uno screen reader. Immaginate la frustrazione di chi è arrivato ad ascoltare i due terzi della pagina e viene improvvisamente riportato, contro la propria volontà, all’inizio del documento!

L’autoaggiornamento temporizzato di una pagina web, per un utente che naviga con uno screen reader, è qualcosa che ricorda, neppure troppo alla lontana, il mito di Sisifo, a cui gli dei avevano inflitto la pena interminabile di spingere un pesante macigno fino alla cima di una montagna, solo per vederlo poi rotolare giù immancabilmente ogni volta.

Inizio pagina

Punto di controllo 7.5, priorità 2

Evitare il reindirizzamento automatico per mezzo di META

Il punto di controllo 7.5 può essere considerato il gemello del 7.4: si riferiscono entrambi all’uso deprecato della funzione di aggiornamento automatico per mezzo dell’elemento META, ma il 7.5 tratta quell’uso particolare dell’autoaggiornamento, che consiste nel reindirizzamento temporizzato, non richiesto dall’utente, a un altro documento. Riportiamo di seguito, adattandolo all’italiano, l’esempio deprecato, proposto nelle Tecniche HTML per le WCAG 1.0.

Si tratta di una tecnica disorientante, che impone all’utente un passaggio non richiesto ad altro sito o ad altro documento, e che rischia di non lasciargli tempo sufficiente per leggere completamente e comprendere la ragione del reindirizzamento. In luogo di questa tecnica poco accessibile, le Tecniche di base (Core Techniques) per le WCAG 1.0 consigliano, al paragrafo 7, due tecniche sostitutive, di cui la prima è ritenuta preferibile alla seconda:

1. Configurare il server affinché usi l’appropriato codice di stato (301). L’uso delle intestazioni HTTP è preferibile, perché riduce il traffico di rete e i tempi di scaricamento, può essere applicato a documenti non-HTML e favorisce i programmi che richiedono solo la sezione HEAD (per esempio, i verificatori di link). Inoltre, i codici di stato del tipo 30x forniscono informazioni come “spostato definitivamente” o “spostato temporaneamente”, che non possono essere inviate con l’aggiornamento tramite elemento META.
2. Sostituire la pagina che sarebbe stata reindirizzata con una pagina statica contenente un normale collegamento a una nuova pagina.

Inizio pagina