Garantire la diretta accessibilità delle interfacce utente incorporate. Parte 2ª: gli oggetti Flash

Requisiti generali per l’accessibilità di Flash

Il 7 dicembre 2006, l’utente registrato come andy_woz posta sul forum del Web Standards Group la seguente domanda , che abbiamo tradotto dall’inglese:

Non che io voglia cominciare ora un’intera discussione sui pro e i contro di Flash e accessibilità. Tuttavia, ho provato a navigare dei contenuti Flash con VoiceOver in Mac OS X Tiger e ogni qual volta passa attraverso contenuti Flash si limita a dire “Scroll Area”. Esiste un modo per fargli dire qualcosa di più descrittivo, come “Contenuto animato che non influenza la navigazione nel sito”, o qualcosa di questo genere?

Volendo parlare del rapporto tra accessibilità e Flash Player, celeberrimo plug-in di Adobe per la riproduzione di interfacce grafiche, dinamiche e multimediali, la prima cosa che occorre mettere in chiaro è che si tratta di una tecnologia non compatibile con tutti gli screen reader.

Anche gli utenti di sistemi Linux si trovano nell’impossibilità di usare Flash con uno screen reader, e lo stesso vale persino per gli utenti di sistemi Microsoft, se usano un browser che non è in grado di far dialogare tra loro Adobe Flash e MSAA, le API per l’accessibilità di Microsoft.

I contenuti Flash, infatti, sono navigabili dagli utenti di screen reader solo disponendo di una ben precisa configurazione software, che è stata indicata da Bob Regan, uno dei maggiori esperti di uso accessibile di Adobe Flash, nella sua guida dell’agosto 2005 Best Practices for Accessible Flash Design . I requisiti software indicati da Regan sono i seguenti:

• Flash Player 6 o versioni successive;
• Windows 98, 2000 o XP (all’epoca Windows Vista non era ancora uscito);
• Microsoft Internet Explorer 5 o versioni successive;
• uno screen reader tra:
  • GW Micro Window-Eyes 4.2 o versioni succesive;
  • Freedom Scientific JAWS 4.5, 6.1 o versioni successive;
  • IBM Home Page Reader 3.04;
  • Dolphin HAL 6.50;
  • KDS PC Talker (usato in Giappone).

Ma perché Flash Player, che può essere installato pure su Macintosh e Linux, risulta compatibile solo con il browser e i sistemi operativi Microsoft, se l’utente adopera uno screen reader? La ragione è da ricercarsi nel modo in cui gli screen reader ricevono informazioni su ciò che avviene sullo schermo e, in particolare, all’interno di un’applicazione Flash.

L’intermediario tra Flash Player e lo screen reader è MSAA, acronimo di Microsoft Active Accessibility, ovvero la tecnologia che contiene le API per l’accessibilità sviluppate dal colosso americano del software. MSAA può essere concepito come un traduttore, in grado di far comunicare client e server. Nel nostro caso, il client è lo screen reader, il server è l’applicazione Flash. Un documento della base dati MSDN spiega come client e server usano MSAA per comunicare (How Active Accessibility Works ):

Usando Active Accessibility, un’applicazione client può:

• chiedere informazioni, per esempio su un elemento della UI [User Interface, cioè l’interfaccia utente] presso una particolare locazione;
• ricevere notifiche quando l’informazione cambia, per esempio quando un controllo diviene grigio o quando una stringa di testo è modificata;
• compiere azioni che influenzano l’interfaccia utente o i contenuti di un documento, per esempio premere un pulsante, aprire un menu e scegliere un comando.

Usando Active Accessibility, un’applicazione server può:

• fornire informazioni sugli oggetti della propria interfaccia utente e sui contenuti delle proprie finestre client;
• inviare notifiche quando la propria interfaccia utente cambia.

Non esistono attualmente altre API per l’accessibilità in grado di svolgere il ruolo di intermediario che MSAA svolge nel rapporto tra un’applicazione Flash e uno screen reader, ciò anche a causa della politica seguita dai produttori di Flash Player (prima Macromedia, ora Adobe), che hanno privilegiato l’integrazione con i prodotti Microsoft.

Fatto sta che parlare oggi di accessibilità degli oggetti Flash significa, per quanto riguarda i non vedenti, restringere il campo agli utenti di sistemi Microsoft che navigano con Internet Explorer: sicuramente una fascia molto ampia di utilizzatori, ma certamente non la totalità.

Pertanto, se si vogliono evitare discriminazioni trattando alcuni come utenti di serie A e altri come utenti di serie B, è importante:

1. non veicolare contenuti essenziali tramite oggetti Flash oppure
2. fornire un’alternativa non Flash.

In caso non si segua nessuna delle due precauzioni, si incorre in problemi di accessibilità come quelli evidenziati in Figura 12.1. Nel sito della cantante Mina, il menu di navigazione è un oggetto Flash che crea a schermo una lunga striscia scorrevole, contenente tutti i dischi pubblicati in carriera dalla celeberrima cantante. Facendo clic sulle miniature delle copertine, vengono visualizzati più in basso i dettagli del disco selezionato, con l’elenco delle canzoni, l’anno, i musicisti ecc.: tutte informazioni a cui un utente di browser testuali non può accedere, perché non esiste un’alternativa testuale al menu in Flash per selezionare i dischi. Nella stessa situazione viene a trovarsi anche un qualsiasi utente di screen reader che non usi l’accoppiata Windows-Internet Explorer.

Per tutte le altre categorie di utenti beneficiari dell’accessibilità – ipovedenti, sordi, disabili cognitivi e motori, nonché non vedenti che usano screen reader installati su sistemi Microsoft Windows – Flash offre tutti gli strumenti per creare contenuti accessibili (li esamineremo successivamente). Tuttavia, i problemi di compatibilità descritti in questo paragrafo non possono essere ignorati e rendono necessario un approccio particolare alla progettazione di contenuti Flash, basato sul medesimo concetto di progressive enhancement, introdotto a proposito dei modi per rendere accessibile l’uso di AJAX.

Inizio pagina

Il potenziamento progressivo nei siti Flash

Il teorizzatore del progressive enhancement (o potenziamento progressivo, in italiano) in siti realizzati con Flash è Bobby van der Sluis, autore di Developing Flash websites using progressive enhancement , un articolo pubblicato l’11 settembre 2006 sul sito di Adobe. L’articolo non solo descrive i passi necessari per sviluppare siti Flash basati sul progressive enhancement, ma fornisce anche esempi di codice e contenuti dimostrativi, che permettono di verificare direttamente l’applicabilità della teoria.

Il metodo teorizzato da van der Sluis riprende il concetto di sviluppo piramidale delle applicazioni web, illustrato in Figura 11.3. Rispetto ai quattro livelli dei contenuti, della struttura, della presentazione e dei comportamenti, gli oggetti Flash rappresentano un quinto livello, che deve in qualche modo essere reso scalabile: i contenuti inseriti in un oggetto Flash devono, cioè, essere resi accessibili anche a utenti che usano browser e tecnologie assistive non compatibili con Flash.

Qui andiamo incontro, però, a una difficoltà. I livelli di modifica corrispondenti a struttura, presentazione e comportamenti – ovvero linguaggi di marcatura, fogli di stile e JavaScript – si limitano ad agire sul livello base, quello dei contenuti (testi, immagini, suoni, animazioni ecc.), che esiste prima e indipendentemente dai livelli successivi. Nel caso di un oggetto Flash, invece, abbiamo un livello successivo, la cui caratteristica principale non è quella di modificare i livelli sottostanti, ma di comprendere in sé, oltre a funzioni dinamiche e interattive, anche i contenuti. Come dimostra l’esempio rappresentato in Figura 12.1, se eliminiamo un oggetto Flash, non solo abbiamo eliminato le interazioni che esso rende possibili, come la selezione di un disco da una discografia, ma anche i contenuti che vi sono inseriti, quindi lo stesso elenco dei dischi che formano la discografia.

Un oggetto Flash è un livello indipendente da tutto il resto, tanto da permettere la realizzazione di siti e applicazioni che non hanno bisogno affatto di livelli inferiori, se si esclude un minimo di codice di marcatura, necessario per comunicare al browser le proprietà generali dell’oggetto Flash che deve essere caricato.

Rendere un’applicazione Flash scalabile vuol dire allora realizzare una versione statica alternativa e, su questa versione, applicare i principi di sviluppo che abbiamo illustrato nel Capitolo 6, per quanto riguarda la corretta strutturazione e presentazione dei contenuti, e nel Capitolo 11, per quanto riguarda l’applicazione di un JavaScript non invasivo.

Il risultato finale di un simile lavoro di duplicazione e organizzazione dei contenuti sarà che le informazioni e i servizi disponibili grazie a Flash saranno disponibili, sia pure in forma differente e magari semplificata, anche per chi naviga con un browser testuale. Ciò vuol dire poter accedere ai contenuti anche con un browser che non visualizza le immagini, non supporta i fogli di stile, non supporta JavaScript, non permette l’installazione di Flash Player. Si tratta della più completa e forse complessa applicazione del principio di scalabilità.

Del resto, l’idea di duplicare i contenuti non è certo nuova. Essendo noto che i contenuti inseriti in un oggetto Flash non sono accessibili a chi usa programmi utente privi di supporto per questa tecnologia, sono molteplici i siti che offrono versioni alternative statiche, realizzate in HTML o XHTML. Si tratta però in genere di veri e propri siti paralleli, ciascuno con un proprio indirizzo web, diverso da quello del sito realizzato in Flash. Per rimanere in ambito musicale, il sito di Adriano Celentano offre un esempio di doppia versione Flash/XHTML (Figura 12.2). Dalla pagina di accoglienza , si può scegliere se esplorare la versione Flash o la versione XHTML di ciascuna delle due sezioni del sito (“Clan” e “Il mondo di Adriano”).

La soluzione di scalabilità usata nel sito di Celentano, e in numerosissimi altri, non ha, però, nulla a che vedere con il metodo del potenziamento progressivo.

Il sistema descritto da Bobby van der Sluis è differente e si basa sull’idea di un unico sito che si adatta alle caratteristiche del programma utente con cui lo si naviga: non più siti paralleli, ma un solo sito scalabile.

Il potenziamento progressivo, in un simile modello progettuale, ha il solo scopo di rendere migliore e più soddisfacente l’esperienza dell’utente, non quello di consentirgli di accedere ai contenuti: in una forma o nell’altra, i contenuti (o i loro equivalenti) e le funzioni di base devono essere disponibili sempre, qualsiasi sia il grado di supporto alle varie tecnologie da parte del browser utilizzato.

Possiamo identificare cinque livelli di fruizione dei contenuti web, che rappresentano altrettanti livelli di scalabilità. Un sito Flash accessibile, realizzato con il metodo del potenziamento progressivo, deve consentire all’utente di fruire dei contenuti senza perdite d’informazione, qualsiasi sia il livello a cui può accedere, tra i cinque di seguito elencati:

1. modalità solo testo: immagini, video e animazioni non sono disponibili; tutti i contenuti grafici sono sostituiti da testi alternativi; collegamenti e moduli funzionano normalmente; i contenuti sono strutturati rispettando il valore semantico degli elementi di HTML e XHTML;
2. modalità grafica: uguale in tutto alla precedente, solo che immagini, video e animazioni sono ora disponibili, in luogo dei rispettivi testi alternativi;
3. modalità grafica con CSS: uguale alla precedente, con l’aggiunta del livello della presentazione, gestito per mezzo dei fogli di stile (l’aspetto grafico del documento può variare profondamente);
4. modalità grafica con CSS e JavaScript: uguale alla precedente, con l’aggiunta di trasformazioni dinamiche e interattive, rese possibili da JavaScript (collegamenti e moduli possono funzionare in modo differente rispetto ai livelli precedenti);
5. modalità Flash: la fruizione delle informazioni e dei servizi si sposta in tutto o in parte all’interno di un’interfaccia Flash (non sono aggiunti nuovi contenuti, ma può cambiare completamente la loro organizzazione e il modo di utilizzarli).

In questo modello evolutivo, i contenuti esistono fin dal livello base. Il passaggio da un livello al successivo coincide con il potenziamento progressivo dell’esperienza utente. Già conosciamo, dai Capitoli 6 e 11 di questo libro, i metodi per ottenere un potenziamento progressivo fino al quarto livello, quello dei comportamenti definiti da JavaScript.

Il punto nuovo, e che rappresenta l’essenza del metodo proposto da van der Sluis, è l’aggiunta di Flash ai livelli precedenti, fatta anch’essa con un criterio di potenziamento progressivo. Il metodo di van der Sluis si basa sull’implementazione di uno script di sua creazione, dall’esotico nome di UFO (acronimo di Unobtrusive Flash Objects, cioè “Oggetti Flash non invasivi”). Lo script, giunto alla versione 3.22, e il modo di impiegarlo sono descritti con dovizia di particolari in una sezione del sito di van der Sluis.

Lo script contiene una serie di controlli che permettono di verificare il supporto del browser per JavaScript e per Flash. Collegato a un file HTML o XHTML, ha la funzione di generare al volo – usando per quanto è possibile il DOM e metodi standard – il codice di marcatura necessario a incorporare nel documento un oggetto Flash, che andrà a sostituire i contenuti statici che vengono mostrati, come alternativa, agli utenti che usano browser privi di supporto per JavaScript e/o Flash. Lasciamo che sia lo stesso van der Sluis a descrivere come funziona il suo prodotto, che peraltro è distribuito gratuitamente sotto una licenza Creative Commons ed è liberamente utilizzabile:

UFO segue i principi del potenziamento progressivo, che vuol dire progettare e costruire pagine web, avendo in mente molteplici scenari d’uso. Cominciate con il produrre una pagina web destinata al più ampio pubblico possibile, che includa contenuti di sostituzione accessibili e indicizzabili dai motori di ricerca (come testo, collegamenti e immagini in HTML o XHTML), adatta sia agli utenti che non hanno l’appropriato plug-in Flash o supporto per JavaScript (per esempio: browser testuali, dispositivi mobili) sia a strumenti automatici come i robot indicizzatori [web crawlers]. UFO potenzia automaticamente la vostra pagina web, scambiando il contenuto di sostituzione con un filmato Flash in tutti i casi in cui il supporto per Flash e JavaScript sia sufficiente.

Il Listato 12.1 mostra un esempio di documento XHTML minimale, in cui è inserito il codice di marcatura (evidenziato col grassetto) che consente lo scambio automatico tra contenuti statici e oggetti Flash, in presenza dei requisiti di compatibilità sopra descritti.

La procedura per conferire allo script UFO la gestione del caricamento di oggetti Flash consiste di quattro passi. Il primo passo è l’inserimento nel codice di marcatura di normali contenuti strutturati, accessibili e indicizzabili dai motori di ricerca, che svolgono il ruolo di alternativa statica per i contenuti Flash. L’elemento radice del blocco dei contenuti statici deve essere associato a un id, il cui valore sarà usato come riferimento per lo script UFO (nell’esempio, l’elemento contenitore è il DIV con valore di id="ufoDemo").

Il secondo passo è il collegamento del file ufo.js, per mezzo di un elemento SCRIPT nella sezione HEAD del documento.

Il terzo passo è la creazione di una variabile (FO, nell’esempio riportato), in un secondo elemento SCRIPT, che contiene tutti i parametri necessari al caricamento dell’oggetto Flash. Tra i vari parametri vi sono l’indirizzo del file SWF contenente l’applicazione Flash, la dimensione in pixel che l’oggetto occuperà all’interno del documento, la versione di Flash Player considerata come requisito minimo per caricare il filmato.

Il quarto passo consiste nel collegare la variabile che richiama l’oggetto Flash con l’id unico del blocco che contiene i contenuti rimpiazzabili. Ciò viene fatto, nell’esempio del Listato 12.1, con la riga UFO.create(FO,"ufoDemo"); posta alla fine del secondo elemento SCRIPT.

I punti tre e quattro del procedimento possono essere ripetuti tante volte, quanti sono gli oggetti Flash da caricare nel documento. L’importante è che ogni blocco di contenuti statici rimpiazzabili abbia un identificativo unico.

Bobby van der Sluis fornisce una dimostrazione pratica del funzionamento del metodo di progressive enhancement per Flash, per mezzo di un piccolo sito d’esempio, scaricabile, completo di tutti i file necessari, dall’indirizzo http://download.macromedia.com/pub/developer/progressive_enhancement.zip . Le immagini successive mostrano in quattro passaggi la scalabilità del sistema. La Figura 12.3 illustra la condizione minima che un sito accessibile deve supportare: la consultazione in modalità solo testo. Al posto dei contenuti grafici, vi sono solo testi alternativi. Corrisponde al punto 1 dell’elenco di cinque punti presentato più sopra, che descrive il potenziamento progressivo dell’esperienza utente, a partire da un documento di solo testo per finire a un documento Flash.

La Figura 12.4. rappresenta il gradino successivo. I contenuti grafici hanno sostituito i testi alternativi, ma il documento è privo di presentazione e comportamenti. Corrisponde al punto 2 dell’elenco di cinque punti.

La Figura 12.5. illustra il punto 3 dell’elenco di cinque punti: un sito statico, fornito di contenuti grafici e con una presentazione generata grazie ai fogli di stile, ma senza supporto per JavaScript. L’immagine, come le due precedenti, mostra solo la parte superiore della pagina, mentre la gran parte dei contenuti si trova più in basso e non è visibile.

Finalmente, la Figura 12.6 mostra il sito Flash, che sostituisce i contenuti statici, non appena viene rilevato il supporto del browser per JavaScript e la presenza del plug-in Flash Player, in una versione pari o superiore a quella richiesta dai parametri inseriti nel secondo elemento SCRIPT del Listato 12.1. Grazie alla flessibilità delle interfacce Flash, tutti i contenuti sono racchiusi nello spazio rettangolare mostrato dall’immagine. Possono essere resi alternativamente visibili e invisibili, usando i quattro link nella testata (Home, Testimonials, Video, Merchandise).

Inizio pagina

Tradurre contenuti Flash in contenuti non Flash

C’è un’ultima questione, non trascurabile, che riguarda il metodo del potenziamento progressivo applicato a oggetti Flash. Come procedere nella creazione dei contenuti? È meglio partire con l’applicazione Flash, per poi “tradurla” in una serie di contenuti statici strutturati, oppure è meglio partire da contenuti HTML o XHTML, per poi “copiarli” all’interno di un oggetto Flash, aggiungendovi tutte le interazioni e gli abbellimenti estetici del caso?

Secondo van der Sluis, la cosa migliore è partire dall’oggetto Flash:

Benché la teoria del potenziamento progressivo parta quasi sempre con la versione base, non potenziata, di un sito web, spesso l’approccio più pratico ai progetti Flash è considerare i contenuti Flash come punto di partenza e tradurli poi in contenuto HTML.

[…] Quando traducete i vostri contenuti Flash in HTML, provate a pensare in termini di intestazioni, testo, collegamenti, immagini e semplici moduli. Dovete anche decidere come tradurre differenti tipi di media complessi in contenuti di base, il che può essere molto impegnativo. Per esempio, qual è secondo voi il modo migliore di descrivere l’esperienza di un pilota in una corsa automobilistica, mentre siete seduti al posto del passeggero accanto a qualcuno che sta guidando una comune berlina?

Non è facile rispondere a questa domanda. Per alcuni tipi di contenuti Flash, come testi strutturati, immagini, moduli, tabelle, collegamenti, è relativamente semplice creare un equivalente in HTML. Ma per altri tipi di contenuti la questione è più complessa. Per esempio, come “tradurre” un video Flash in contenuti statici? La soluzione suggerita da van der Sluis consiste nell’utilizzare alcuni fotogrammi chiave estratti dal video, presentandoli in successione, accompagnati ciascuno da una didascalia. Il metodo è illustrato in Figura 12.7.

La Figura 12.8 mostra invece il video Flash da cui sono tratti i fotogrammi, video che viene visualizzato solo dai browser dotati di adeguato supporto.

Se per i video l’estrazione di alcuni fotogrammi è una buona soluzione, per altri tipici contenuti Flash è molto più difficile, se non impossibile, creare veri equivalenti statici. Prendiamo il caso dei giochi. Anche di un gioco, naturalmente, è possibile fornire immagini dimostrative e opportune spiegazioni testuali; tuttavia non è possibile replicare in alcun modo, in una pagina HTML statica, le interazioni che avvengono all’interno del gioco, soprattutto se si tratta di un gioco d’azione.

Se un gioco Flash è basato su interazioni che si svolgono in un ambiente grafico complesso, un utente che navighi in modalità solo testo all’interno dell’equivalente HTML del gioco non può giocare. Al massimo può essere informato sulle caratteristiche del gioco.

È importante, dunque, non dimenticare mai la specificità di alcuni contenuti e i limiti intrinseci dell’accessibilità. Vi sono contenuti Flash che semplicemente non possono essere scalati verso forme più semplici e diverse di fruizione. In casi simili, il massimo che si può fare è sforzarsi di rendere direttamente accessibile l’interfaccia utente dell’applicazione, limitandosi a fornire – come equivalenti non Flash – descrizioni, spiegazioni e immagini. Queste di certo non svolgono la stessa funzione del contenuto che vanno a sostituire, come richiederebbe invece il concetto di equivalente definito dalle WCAG 1.0 (si veda in proposito il Capitolo 4), ma sono di sicuro meglio di niente.

Tirando le somme di quanto detto fin qui, ci sembra che, nel progettare applicazioni Flash da rendere accessibili con il metodo del potenziamento progressivo, possa essere utile procedere nel modo seguente:

1. definire i contenuti e gli elementi di navigazione del sito indipendentemente dalle tecnologie che si deciderà di adoperare in fase di realizzazione;
2. implementare in HTML o XHTML tutti i contenuti, opportunamente strutturati, che ha senso marcare con questi linguaggi (menu di navigazione, testi, titoli, immagini, tabelle, moduli ecc.);
3. applicare tramite CSS e JavaScript la presentazione e i comportamenti che si ritengono necessari;
4. realizzare gli oggetti Flash da incorporare nel sito;
5. cercare di “tradurre” nel codice di marcatura ciò che è possibile rendere in forma statica dei contenuti dinamici degli oggetti Flash (per esempio, dei fotogrammi tratti da un video, accompagnati da didascalie, o la descrizione di un gioco con le relative schermate).

Il lettore più attento si sarà accorto che stiamo proponendo un procedimento un po’ diverso da quello suggerito da van der Sluis, che era di partire dall’oggetto Flash. Certo, se quest’ultimo è già stato realizzato, non si può fare altro che cercare di tradurlo in contenuti HTML. Tuttavia, nel caso in cui la progettazione di un sito parta da zero, ci sembra che la cosa migliore sia definire i contenuti in modo indipendente dalla tecnologia e prima di partire con l’implementazione di Flash, specificando preliminarmente cosa può essere fatto anche in HTML e cosa deve rimanere invece appannaggio esclusivo di Flash, perché non replicabile in forma statica. Un testo, per esempio, è sempre un testo, così come un menu resta un menu, non importa se siano realizzati in HTML, in Java, in Flash o in un altro linguaggio.

Questi e altri contenuti possono essere definiti a priori e sviluppati parallelamente per HTML e per Flash, rispettando le peculiarità di entrambi gli strumenti. Progettare i contenuti indipendentemente dalla tecnologia permette di studiarli fin dall’inizio in modo che siano scalabili; potranno così coprire le esigenze di un pubblico molto ampio, a partire da chi usa un browser testuale per finire con gli utenti di applicazioni Flash.

Fare il contrario, cioè progettare prima la parte Flash di un sito e poi cercare di tradurla in HTML, rischia di rendere tutto più difficile. Infatti, chi progetta interfacce Flash raramente pensa agli aspetti strutturali dei contenuti, perché quest’aspetto, in Flash, è un’astrazione. La cosa principale, per uno sviluppatore di interfacce Flash, non è definire la struttura dei contenuti in termini di titoli, paragrafi, tabelle, elenchi ecc., ma progettare un’esperienza utente affascinante e coinvolgente: un risultato che viene perseguito, di solito, puntando sulla raffinatezza della grafica e delle azioni richieste all’utente (scoprire la posizione di comandi nascosti, generare l’apertura a cascata di schede tra loro collegate, trascinare oggetti da una posizione all’altra ecc.).

In Flash, presentazione e comportamenti sono intimamente legati ai contenuti. Non è facile separare le parti e, soprattutto, non esiste un equivalente degli elementi strutturali di HTML: un testo diventa un titolo se è scritto in grande e messo nella posizione giusta, non perché abbia uno status differente dal blocco di testo, scritto in caratteri più piccoli, che svolge il ruolo di testo in paragrafi (Figura 12.9).

Inoltre, l’ordine dei contenuti può essere completamente diverso da quello che sarebbe il loro ordine logico in un documento HTML. Sullo stage, la lavagna virtuale che serve per assemblare i pezzi di un’interfaccia Flash, i blocchi logici possono essere sovrapposti su più livelli, portati momentaneamente fuori dall’area visibile, riposizionati con lo scorrere del tempo: tutti fattori che non aiutano a chiarire le relazioni strutturali tra i contenuti.

Ribadiamo perciò l’invito a definire i contenuti, i loro rapporti e gli elementi di navigazione prima di cominciare ad assemblare i pezzi nell’ambiente di lavoro di Flash. Una tale precauzione permetterà di organizzare i contenuti in una gerarchia e in una sequenza che abbiano senso in HTML, non solo in Flash.

La priorità va lasciata a Flash solo quando si tratta di realizzare applicazioni che, per la loro natura dinamica e interattiva, non possono avere un vero equivalente in HTML o XHTML (Figura 12.10).

Inizio pagina

Rendere Flash direttamente accessibile

Per quanto sia giusto e necessario preoccuparsi della scalabilità di un sito web realizzato in Flash, allo scopo di garantire un accesso di base ai contenuti anche a chi dispone di tecnologie obsolete o non compatibili, è un dato di fatto confermato dalle statistiche che la grande maggioranza degli utenti navighi con browser perfettamente in grado di caricare contenuti realizzati con Flash. Tra gli stessi non vedenti, moltissimi usano Internet Explorer su sistemi Windows, il che permette loro, almeno in teoria, di navigare con il proprio screen reader tra i contenuti Flash così come possono navigare tra i normali contenuti HTML.

È dunque compito irrinunciabile degli sviluppatori che si occupano di accessibilità cercare di rendere direttamente accessibili gli oggetti Flash.

Comandi per l’accessibilità in Flash Professional

Gli interventi necessari a rendere direttamente accessibile un’applicazione Flash sono molteplici, perché differenti sono le esigenze derivanti dalle varie disabilità che lo sviluppo accessibile cerca di compensare. In linea generale, un’applicazione Flash che voglia definirsi direttamente accessibile deve, in accordo con il dettato della linea guida 8 delle WCAG 1.0:

• consentire la navigazione con uno screen reader;
• permettere l’esecuzione di tutti i comandi anche da tastiera;
• contenere testi che siano leggibili per un ipovedente o un cieco ai colori e comprensibili per un disabile cognitivo;
• fornire sottotitoli per i contenuti audio e audiodescrizioni per i contenuti video;
• permettere di bloccare il movimento e il suono.

Si tratta, come è facile verificare, delle medesime caratteristiche che sono richieste a un documento HTML per essere giudicato accessibile. Molto diversi, però, sono i metodi per arrivare al risultato, perché diversi sono gli strumenti di sviluppo a disposizione di un progettista Flash, rispetto a quelli a disposizione di un esperto di linguaggi di marcatura e fogli di stile.

Mentre quest’ultimo può rendere usabile un documento HTML a un utente di screen reader semplicemente marcando i contenuti con gli opportuni elementi strutturali, un progettista Flash non può fare altrettanto, non esistendo nel software per sviluppare interfacce Flash l’equivalente di titoli, paragrafi, citazioni, abbreviazioni, definizioni ecc. A rendere le cose più complicate, contribuisce la grande differenza esistente tra il modo prettamente visuale, in cui un progettista Flash immagina e organizza l’esperienza dell’utente, e il modo seriale, un contenuto alla volta, in cui un lettore di schermo può accedere ai contenuti. Insomma, rendere accessibile un’applicazione Flash a un utente di screen reader è cosa non proprio intuitiva e certamente più complessa, rispetto agli interventi richiesti per sopperire ad altre disabilità.

È perciò indispensabile che un progettista Flash, se vuole essere in grado di sviluppare contenuti accessibili a un non vedente, si impratichisca nell’uso di uno screen reader. Solo provando e riprovando a navigare come un cieco, potrà rendersi conto se sta sviluppando un’applicazione accessibile oppure no.

Un elemento ignoto a chi non abbia mai fatto simili prove è, per esempio, il meccanismo con cui Flash Player e uno screen reader interagiscono. Lo spiega bene Bob Regan, a pagina 5 della sua già citata guida alla progettazione accessibile con Flash (Best Practices for Accessible Flash Design ):

Flash Player crea un elenco degli oggetti presenti sullo schermo e lo registra nell’albero del documento [data tree] di MSAA. Lo screen reader legge questa lista, non appena incontra un contenuto Flash. Quando sullo schermo si verificano dei cambiamenti, l’albero del documento di MSAA viene aggiornato. I cambiamenti nell’animazione inducono lo screen reader a ripartire dall’inizio, ricominciando daccapo la lettura della lista.

Di base, gli oggetti di testo in un’animazione Flash sono letti dagli screen reader, i quali sono anche in grado di identificare pulsanti e frammenti animati collegati a script. Gli screen reader, tuttavia, non possono vedere gli elementi grafici sullo schermo e determinarne il significato. Spetta al progettista assegnare una descrizione testuale a ciascun elemento grafico o animato in un oggetto Flash.

[...] Dato che gli screen reader cominciano sempre dalla parte superiore dell’animazione e possono leggere soltanto una cosa per volta, vi sono certi tipi di contenuti Flash complessi che semplicemente non possono essere resi accessibili.

Il brano citato ci dà alcune informazioni importanti:

• uno screen reader legge i contenuti di un oggetto Flash nell’ordine in cui li trova registrati nel data tree di MSAA, senza nulla sapere delle priorità visive definite dal progettista, che potrebbero indurre altri ordini di lettura o di azione negli utenti vedenti;
• ogni cambiamento dinamico nei contenuti provoca la rilettura dall’inizio dei dati registrati dal player Flash nel data tree di MSAA, il che può sfociare in una drammatica inaccessibilità dei contenuti, se vi sono routine che inducono lo screen reader a ripartire di continuo dall’inizio;
• se lo sviluppatore non etichetta adeguatamente gli oggetti e i controlli dell’animazione, questi rimarranno incomprensibili per chi usa un lettore di schermo, anche se hanno un significato ovvio per chi invece può vederli (per esempio, un pulsante con un’etichetta grafica, ma privo di equivalente testuale, sarà per un non vedente solo un “button” dalla funzione imprecisata).

Sembrerà strano, ma una buona parte del lavoro sull’accessibilità che può essere eseguito all’interno di Flash si risolve nella compilazione dei campi di una finestra di dialogo piuttosto semplice, disponibile, a seconda dei casi, in versioni leggermente differenti, come mostrato in Figura 12.12 A e B.

La finestra di dialogo Accessibilità può essere attivata o dal menu Finestra → Altri pannelli di Flash oppure premendo l’icona azzurra dell’accesso universale (Figura 12.13), sulla destra del pannello Proprietà, laddove sia disponibile.

La finestra Accessibilità non è disponibile per tutti gli oggetti presenti sullo stage, ma solo per quelli che hanno lo status di Pulsante o di Clip filmato. È disponibile inoltre quando non è selezionato alcun oggetto e, in tal caso, le impostazioni per l’accessibilità riguardano l’intera applicazione Flash (Figura 12.12 A).

Vediamo ora in dettaglio le impostazioni che possono essere definite tramite questa finestra (si faccia riferimento alle Figure 12.12 A e B per la localizzazione delle singole opzioni).

• Rendi accessibile il filmato. Quando questa casella è spuntata, l’oggetto Flash viene reso accessibile agli screen reader. È l’opzione predefinita. In caso l’animazione non contenga informazioni significative per un non vedente, la casella dovrebbe essere deselezionata.
• Rendi accessibile l’oggetto. Quando questa casella è spuntata, Flash Player passa allo screen reader le informazioni di accessibilità relative a un oggetto interno all’animazione. L’opzione è selezionata per impostazione predefinita; quando è disattivata, l’oggetto e tutti i suoi discendenti vengono ignorati dallo screen reader. È preferibile dunque deselezionarla per gli elementi decorativi e per quelli che si ritiene non necessario corredare di un testo alternativo.
• Rendi accessibili gli oggetti secondari. Questa opzione, attiva per impostazione predefinita, compare solo per gli oggetti definiti come Clip filmato. Se la casella è spuntata, tutte le informazioni relative agli oggetti contenuti nell’oggetto selezionato vengono passate allo screen reader. In alcuni casi, può essere necessario deselezionare la casella, per evitare che l’ascoltatore sia subissato di informazioni inutili e, soprattutto, che eventuali cambiamenti ciclici negli oggetti secondari possano far ricominciare daccapo la lettura dei contenuti dell’animazione. Se una clip è usata come pulsante, l’opzione di rendere accessibili gli oggetti secondari non è più attiva, perché Flash tratta tutti i pulsanti come oggetti unici, anche se contengono oggetti secondari.
• Etichetta automatica. Se questa opzione è selezionata, Flash considera gli oggetti di testo statico contenuti all’interno di un oggetto grafico o nelle vicinanze di un controllo di modulo come l’etichetta di quell’oggetto o di quel controllo. Il testo trattato come etichetta svolge, in sostanza, una funzione di accessibilità analoga a quella dell’elemento LABEL in HTML. Se più testi si trovano nelle vicinanze di un controllo di modulo, solo uno sarà trattato come la sua etichetta. Affinché un testo contenuto all’interno di un oggetto grafico possa essere considerato come la sua etichetta, è necessario che sia attiva, per l’oggetto contenitore, l’opzione Rendi accessibili gli oggetti secondari (Figura 12.14).
• Nome. Il testo inserito in questo campo viene letto automaticamente dagli screen reader. Compilare il campo Nome è il modo più semplice e diretto per fornire un’etichetta a pulsanti e campi modulo. Il nome scelto deve essere sintetico e allo stesso tempo rappresentativo del controllo a cui è associato, affinché la navigazione con uno screen reader risulti comprensibile e, allo stesso tempo, non noiosa. Ciò che si scrive in questo campo sovrascrive l’etichetta automatica, se ne è disponibile una (ma il testo dell’etichetta viene letto ugualmente, anche se non più con il valore di etichetta). Nei casi in cui la funzione di un pulsante sia definita da un’icona, diventa fondamentale compilare il campo Nome, altrimenti un utente di screen reader non potrà avere idea della funzione del pulsante.
  

  Figura 12.14. Con l’opzione Etichetta automatica selezionata,
  la stringa di testo “Premi! ” posta all’interno di un ovale
  diventa l’etichetta di un pulsante.

• Descrizione. Questo campo è destinato a contenere informazioni più dettagliate di quelle inserite nel campo precedente. Poiché anche il testo nel campo Descrizione viene letto automaticamente dagli screen reader compatibili con Flash Player, è importante valutare con attenzione se e quando inserire una descrizione, allo scopo di non annoiare l’ascoltatore. Se l’oggetto Flash contiene contenuti semplici (per es. un banner pubblicitario) oppure troppo complessi per poterli rendere accessibili a un utente di screen reader, la cosa migliore è fornire un unico equivalente testuale per l’intera animazione. Ciò può essere fatto compilando i campi Nome e/o Descrizione quando è spuntata la casella Rendi accessibile il filmato, e, allo stesso tempo, disabilitando la casella Rendi accessibili gli oggetti secondari, in modo da evitare che eventuali contenuti animati interni inducano lo screen reader a ricominciare ciclicamente la lettura dei dati generati da Flash Player.
• Tasto di scelta rapida. Permette di associare una scorciatoia da tastiera all’azione di un pulsante. Tuttavia, la sola impostazione di questo parametro non rende attiva la scorciatoia, ma serve solo a consentire a MSAA di passare il valore allo screen reader affinché possa annunciarlo all’utente (funzione, per altro, ancora non supportata). Per attivare realmente la scorciatoia, è necessario creare uno script che abbia lo scopo di intercettare la pressione del tasto prescelto, associandola alla funzione prevista dalla scorciatoia.
• Indice. Questo campo, corrispondente all’inglese TabIndex, va compilato con un valore numerico positivo. È uno degli strumenti più potenti al servizio dello sviluppatore che desidera migliorare l’accessibilità della propria applicazione Flash. Consente infatti di determinare l’ordine di tabulazione degli oggetti e, allo stesso tempo, l’ordine di lettura da parte degli screen reader (se la funzione è supportata) ancorandoli alla reale logica dei contenuti piuttosto che alla sequenza automatica generata da Flash Player (Figura 12.15). I valori di indice, così come accade per l’attributo tabindex in HTML, non devono essere continui: se un oggetto ha indice 1, il successivo può anche avere indice 20. L’ordine di lettura segue il crescere delle cifre, anche in presenza di buchi nella serie numerica. Se due o più animazioni Flash vengono incorporate all’interno di un’altra animazione, i valori di indice dei loro oggetti devono essere esclusivi. Se invece oggetti provenienti da animazioni differenti hanno valori di indice uguali, l’ordine di lettura risultante sarà caotico: se, per esempio, l’animazione A ha tre oggetti a, b, c con valore di indice di 1, 2 e 3 e l’animazione B ha anch’essa tre oggetti a', b' e c' con valore di indice 1, 2 e 3, l’ordine di lettura risultante sarà a, a', b, b', c, c', generando la totale confusione delle sequenze.
  

  Figura 12.15. Tramite il menu Visualizza → Mostra ordine di tabulazione è possibile visualizzare
  sullo stage il numero di indice associato a ciascun oggetto. Il numero viene mostrato in un rettangolino poco leggibile, posizionato nell’angolo in alto a sinistra della cornice di delimitazione di ogni oggetto.

Inizio pagina

Istruzioni per l’accessibilità in ActionScript

Tutte le funzioni che possono essere definite usando le opzioni nelle finestre di dialogo di Flash Professional, e molto altro ancora, possono essere definite anche attraverso ActionScript, un linguaggio di scripting basato – come JavaScript – sullo standard ECMAScript 262 e sviluppato specificamente per Flash.

In Flash Professional 8 è inclusa la versione 2.0 di ActionScript, ma nel frattempo la Adobe ha pubblicato la versione 3.0, che è già supportata da Flash Player 9.0, grazie a un esecutore di comandi chiamato AVM2, cioè ActionScript Virtual Machine 2, che coesiste con lo AVM1, che esegue il codice ActionScript 2.0.

In ActionScript 3.0, le proprietà relative all’accessibilità appartengono alla classe AccessibilityProperties e sono definite nel manuale di riferimento sul sito di Adobe .

Riportiamo di seguito, in traduzione italiana, le concise spiegazioni offerte a corredo, che illustrano tutto ciò che è importante conoscere per usare correttamente le proprietà per l’accessibilità di ActionScript 3.0:

La classe AccessibilityProperties permette di controllare la presentazione di oggetti Flash agli aiuti per l’accessibilità, come gli screen reader. È possibile attaccare un oggetto AccessibilityProperties a qualsiasi oggetto display, ma il player Flash leggerà l’oggetto AccessibilityProperties solo per determinati tipi di oggetti: interi file SWF (rappresentati per mezzo di DisplayObject.root), oggetti contenitori (DisplayObjectContainer e sottoclassi), pulsanti (SimpleButton e sottoclassi) e testo (TextField e sottoclassi).

La proprietà name di questi oggetti è la più importante da specificare, perché gli aiuti per l’accessibilità forniscono agli utenti i nomi degli oggetti, svogendo una funzione essenziale per la navigazione. Non bisogna confondere AccessibilityProperties.name con DisplayObject.name: sono cose separate e non correlate. AccessibilityProperties.name è un nome che è letto ad alta voce dagli aiuti per l’accessibilità, mentre DisplayObject.name è essenzialmente un nome di variabile visibile soltanto al codice ActionScript.

Per determinare se il player Flash è in esecuzione in un ambiente che supporta gli aiuti per l’accessibilità, si può usare la proprietà Capabilities.hasAccessibility. Se si modificano oggetti AccessibilityProperties, è necessario chiamare il metodo Accessibility.updateProperties() affinché le modifiche abbiano effetto.

Le proprietà che possono essere associate all’oggetto AccessibilityProperties sono le seguenti:

• Description. Il valore è di tipo stringa e corrisponde al campo Descrizione della finestra Accessibilità; si applica a un intero file SWF, a contenitori, pulsanti e testo;
• ForceSimple. Il valore è di tipo booleano (true/false, ovvero sì/no). Se il valore è true, Flash Player esclude dalla presentazione accessibile gli oggetti secondari contenuti nell’oggetto display a cui si applica la proprietà. Corrisponde alla voce Rendi accessibili gli oggetti secondari della finestra Accessibilità, ma secondo una logica inversa: se forcesimple è vero, gli oggetti secondari non sono accessibili;
• Name. Il valore è di tipo stringa e corrisponde al campo Nome della finestra Accessibilità; si applica a un intero file SWF, a contenitori, pulsanti e testo; da non confondere con la proprietà DisplayObject.name;
• NoAutoLabeling. Il valore è di tipo booleano. Corrisponde all’opzione Etichetta automatica della finestra Accessibilità, ma agisce con logica inversa: se il valore della proprietà è true, allora l’etichettatura automatica è disabilitata; il valore predefinito è false. Si applica soltanto all’intero file SWF;
• Shortcut. Il valore è di tipo stringa. Corrisponde all’opzione Tasto di scelta rapida nella finestra Accessibilità. Si applica a contenitori, pulsanti e testo. La sintassi per il valore della proprietà consente l’uso di nomi lunghi per i tasti modificatori e del segno “+” per indicare le combinazioni. Esempi di valori validi sono Ctrl + F, Ctrl + Shift + Z ecc.;
• Silent. Il valore è di tipo booleano. Corrisponde all’opzione Rendi accessibile l’oggetto della finestra Accessibilità, ma agisce secondo una logica inversa: se il valore è true, allora l’oggetto è reso inaccessibile agli screen reader. Il valore predefinito è false. Si applica all’intero file SWF, a contenitori, pulsanti e testo.

Dopo aver introdotto le proprietà, vediamo come si usano in pratica. Il codice nel Listato 12.2 definisce con ActionScript 3.0 alcune proprietà per l’accessibilità di un oggetto animato e le rende attive.

Le medesime proprietà richiedono in ActionScript 2.0 un codice leggermente diverso, come mostra il Listato 12.3.

Immaginiamo ora di dover impostare l’ordine di tabulazione per tre oggetti di testo statico, posti all’interno di altrettante clip filmato, a formare qualcosa di simile al pulsante “Premi!” di Figura 12.14. Per gli oggetti di testo statico non è disponibile la finestra Accessibilità né è possibile assegnare un valore di Indice all’oggetto contenitore, perché non si tratta di una proprietà ereditabile dai figli (i testi contenuti). Dunque, per modificare l’ordine di tabulazione relativo ai testi statici, bisogna ricorrere ad ActionScript, usando un codice come quello del Listato 12.4. La proprietà tabIndex svolge la stessa funzione del campo Indice nella finestra Accessibilità.

Inizio pagina

Componenti d’interfaccia accessibili in Flash Professional

Un grosso aiuto a chi cerca di sviluppare applicazioni Flash accessibili è offerto dai componenti d’interfaccia predefiniti, disponibili nell’ambiente di sviluppo di Flash Professional. Usando questi componenti, è possibile implementare in modo rapido e funzionale elementi interattivi accessibili, alcuni dei quali offrono funzionalità analoghe ai tipici controlli di modulo presenti in HTML (Figura 12.6).

Elenchiamo di seguito i componenti che possono essere resi accessibili, aggiungendo per ognuno una breve descrizione nonché l’indispensabile comando ActionScript che serve per abilitare l’accessibilità (che, per impostazione predefinita, non è attiva). Va precisato che la riga di codice che serve per renderli accessibili deve essere impostata una volta sola per ciascun componente, qualunque sia il numero di sue istanze utilizzate nell’animazione. Eseguita l’attivazione, le opzioni di accessibilità possono essere impostate e modificate per mezzo della finestra Accessibilità (Figura 12.12), le cui funzioni sono state illustrate in un paragrafo precedente.

Alert

Il componente Alert visualizza una finestra di avviso che contiene un messaggio per l’utente e i pulsanti per consentirgli di effettuare una scelta. La finestra di avviso può contenere una combinazione qualsiasi di pulsanti Sì, No, OK e Annulla. Per attivare l’accessibilità del componente, occorre aggiungere la riga di codice mx.accessibility.AlertAccImpl.enableAccessibility().

Button

Il componente Button è un pulsante rettangolare ridimensionabile, che, se attivo, può essere controllato sia col mouse sia con la tastiera. Per attivare l’accessibilità del componente, è necessario aggiungere la riga di codice: mx.accessibility.ButtonAccImpl.enableAccessibility().

CheckBox

Una casella di controllo (CheckBox) è una casella quadrata che può essere selezionata o deselezionata. Quando è selezionata, nella casella è visualizzato un segno di spunta. È possibile aggiungere un’etichetta di testo a sinistra, a destra, in alto o in basso. La casella viene attivata quando un utente fa clic su di essa oppure se le passa il focus con il tasto di tabulazione. Una volta attivata, è possibile utilizzare comandi da tastiera per controllarla. La riga di codice che serve per attivare l’accessibilità è: mx.accessibility.CheckBoxAccImpl.enableAccessibility().

ComboBox

La casella combinata (ComboBox) consente all’utente di effettuare una sola selezione da un elenco a comparsa e può essere statica o modificabile. Una casella combinata modificabile consente all’utente di immettere il testo direttamente in un campo di testo presente all’inizio dell’elenco e selezionare una voce dall’elenco a comparsa. Il componente ComboBox è costituito da tre sottocomponenti: Button, TextInput e List. Quando viene effettuata una selezione nell’elenco, l’etichetta della selezione viene copiata nel campo di testo presente nella parte superiore della casella combinata. La selezione può essere effettuata sia con il mouse sia con la tastiera. Quando l’elenco a discesa di una casella combinata è attivo, i tasti alfanumerici spostano la selezione nell’elenco verso l’alto o verso il basso, sulla voce successiva che inizia con lo stesso carattere. La riga di codice ActionScript per attivare l’accessibilità è: mx.accessibility.ComboBoxAccImpl.enableAccessibility().

DataGrid

Il componente DataGrid consente di creare viste e applicazioni con dati strutturati. Dal punto di vista dell’utente, è qualcosa di analogo a una tabella HTML, essendo organizzato per righe, colonne e celle. La riga di codice ActionScript per attivare l’accessibilità per il componente DataGrid è: mx.accessibility.DataGridAccImpl.enableAccessibility().

Label

Un componente Label (etichetta) è una singola riga di testo. È possibile specificare che un’etichetta venga formattata in HTML. I componenti Label non hanno bordi, non possono essere attivati e non inviano alcun evento. Il ruolo che svolgono è quello di fornire un’etichetta per un campo di input, come l’equivalente elemento LABEL in HTML. La riga di codice ActionScript per attivare l’accessibilità è: mx.accessibility.LabelAccImpl.enableAccessibility().

List

Il componente List è un elenco a scorrimento con possibilità di selezione singola o multipla. Un elenco può anche visualizzare immagini, compresi altri componenti. Il componente List viene attivato quando si fa clic su di esso con il mouse o quando viene selezionato con il tasto Tab. Una volta attivato, è possibile utilizzare comandi da tastiera per controllarlo. I tasti PgSu e PgGiù scorrono le voci verso l’alto o verso il basso. La riga di codice ActionScript per attivare l’accessibilità è: mx.accessibility.ListAccImpl.enableAccessibility().

NumericStepper

Il componente NumericStepper consente a un utente di incrementare o diminuire un valore all’interno di un insieme ordinato di numeri. Consiste di un numero in una casella di testo, visualizzato accanto a piccoli pulsanti freccia su e giù. Quando un utente fa clic sui pulsanti, il numero aumenta o diminuisce in maniera incrementale in base all’unità specificata nel parametro stepSize, fino a quando l’utente non rilascia i pulsanti o finché non viene raggiunto il valore minimo o massimo. Il testo contenuto nella casella di testo del componente NumericStepper è modificabile. Quando un’istanza del componente NumericStepper è attiva, è possibile utilizzare comandi da tastiera per controllarla. La riga di codice ActionScript per attivare l’accessibilità è: mx.accessibility.NumericStepperAccImpl.enableAccessibility().

RadioButton

Il componente RadioButton consente all’utente di selezionare una singola opzione tra una serie di possibilità. Questo componente deve essere utilizzato in un gruppo di almeno due istanze RadioButton. Solo un membro del gruppo può essere selezionato in un determinato momento. La selezione di un pulsante di scelta in un gruppo deseleziona il pulsante di scelta già selezionato. Quando l’utente fa clic o preme il tasto Tab per spostarsi in un gruppo di componenti RadioButton, viene attivato solo il pulsante di scelta selezionato. Se l’istanza del componente è attiva, è possibile utilizzare comandi da tastiera per controllarla. La riga di codice ActionScript per attivare l’accessibilità è: mx.accessibility.RadioButtonAccImpl.enableAccessibility();

TextArea

Il componente TextArea racchiude l’oggetto Textfield nativo di ActionScript. Un componente TextArea può anche essere formattato in HTML o come un campo password. Quando è abilitato, segue le stesse regole di attivazione e di navigazione di un oggetto TextField di ActionScript. Se un’istanza del componente TextArea è attiva, è possibile utilizzare comandi da tastiera per controllarla. Questo componente è reso accessibile in modo predefinito e non è necessario alcun codice ActionScript per attivarne l’accessibilità.

TextInput

TextInput è un componente di testo a riga singola, da usare come campo di input in un modulo. Un componente TextInput può anche essere formattato in HTML o come un campo password. Quando è abilitato, segue le stesse regole di attivazione e di navigazione di un oggetto TextField di ActionScript. Se un’istanza del componente TextInput è attiva, è controllabile con comandi da tastiera. Questo componente, così come TextArea, è reso accessibile in modo predefinito. Non è necessario, perciò, alcun codice ActionScript per attivarne l’accessibilità.

Window

Un componente Window visualizza il contenuto di una clip filmato all’interno di una finestra con una barra del titolo, un bordo e un pulsante di chiusura opzionale. È possibile utilizzare una finestra ogni volta che sia necessario presentare all’utente delle informazioni oppure una scelta che ha la precedenza su ogni altra cosa nell’applicazione (può servire, per esempio, quando occorre che l’utente inserisca i propri dati di accesso oppure confermi una nuova password). Un componente Window può essere a scelta obbligatoria oppure no. Una finestra a scelta obbligatoria impedisce che l’input del mouse e della tastiera sia diretto ad altri componenti fuori della finestra. Il componente Window supporta anche il trascinamento; un utente può fare clic sulla barra del titolo e trascinare la finestra e il suo contenuto in un’altra posizione. Il trascinamento dei bordi non ridimensiona la finestra. La riga di codice ActionScript per attivare l’accessibilità del componente è: mx.accessibility.WindowAccImpl.enableAccessibility().

Inizio pagina

Buone pratiche per l’accessibilità degli oggetti Flash

Abbiamo esaminato finora gli strumenti per l’accessibilità che Flash Professional 8 e Flash Player mettono a disposizione di sviluppatori e utenti. Riassumiamoli brevemente:

• In Flash Player:
  • la capacità di passare a MSAA i dati disponibili all’interno dell’applicazione e di rendere automaticamente accessibili anche da tastiera gli eventi definiti per il mouse;
• in Flash Professional 8:
  • i componenti accessibili predefiniti (pulsanti, caselle di controllo, campi di input ecc.);
  • le opzioni del pannello Accessibilità;
  • le istruzioni ActionScript per l’accessibilità.

È molto, ma non basta: gli ingredienti, da soli, non fanno un piatto cucinato. Per questo, occorre una ricetta. Ecco, dunque, alcune regole di “cottura”, che possono aiutare il lettore a usare gli “ingredienti” di Flash per l’accessibilità, in modo da tirarne fuori un “piatto”, cioè un’applicazione Flash che sia realmente accessibile e – perché no? – piacevole da usare anche per gli utenti di tecnologie assistive.

La principale fonte di riferimento per i suggerimenti riportati di seguito è la già citata guida di Bob Regan sulle migliori pratiche di progettazione accessibile per Flash.

Inizio pagina

Fornire equivalenti testuali

È il requisito di accessibilità più importante. Un utente di screen reader non può sapere cos’è un oggetto, che funzione abbia e in che stato si trovi, a meno che lo sviluppatore non si sia preoccupato, tramite le opzioni del pannello Accessibilità o attraverso opportuno codice ActionScript, di impostare nomi, descrizioni ed etichette per gli oggetti che compongono l’animazione.

Questo è, però, solo il principio generale. L’applicazione pratica è soggetta alla più ampia variabilità e deve essere affidata necessariamente al buon senso, all’esperienza e, soprattutto, ai test sul campo dello sviluppatore. Non tutti gli oggetti di un’animazione, infatti, devono essere forniti di un equivalente testuale. Va valutato con attenzione se si tratta di contenuti essenziali per la comprensione o solo decorativi; e, se si è scelto di applicare un equivalente, va studiato un testo alternativo che rappresenti il miglior compromesso tra l’esigenza di informare e il bisogno di non annoiare.

In certi casi, sarà sufficiente un testo alternativo per l’intero file SWF, che può essere applicato tramite la finestra Accessibilità, compilando i campi Nome o Descrizione, spuntando la casella Rendi accessibile il filmato e deselezionando allo stesso tempo la casella Rendi accessibili gli oggetti secondari.

Quando si scende al livello del singolo oggetto, si dovrà decidere se renderlo accessibile oppure silenzioso. Nel primo caso, si potrà scegliere se fornire un nome o una descrizione usando gli appositi campi della finestra Accessibilità, oppure servirsi della funzione di autoetichettatura, associando all’oggetto un testo inserito direttamente sullo stage.

In tutte queste operazioni, le prove fatte con uno screen reader sono essenziali, perché aiutano a trovare il giusto equilibrio tra il dare troppa informazione e il darne troppo poca.

Inizio pagina

Fornire informazioni contestuali

È un altro elemento essenziale per l’accessibilità dei contenuti Flash, che però tende a essere facilmente trascurato, perché richiede di considerare gli elementi d’interfaccia da un punto di vista diverso da quello dell’utilizzo visivo.

Un esempio di questo concetto è fornito dal sito Flash della società inglese Thevoid, una schermata del quale è mostrata in Figura 12.17. Il sito offre un’innovativa interfaccia grafica, basata sulla metafora di una scatola di pillole, che può essere osservata da vari punti di vista. Le etichette sulla scatola contengono le informazioni sulla società.

Il progettista dell’interfaccia ha fornito un aiuto contestuale (indicato in Figura 12.17 da una freccia), che si apre premendo il pulsante help. Purtroppo, il testo di aiuto non è ascoltabile né con JAWS né con Window-Eyes, benché il sito risulti ben navigabile da tastiera e il resto delle informazioni venga letto normalmente dai due screen reader. Probabilmente chi ha sviluppato l’interfaccia utente aveva in mente solo o soprattutto un visitatore che esplora i contenuti con gli occhi, come suggeriscono l’invito a fare clic, presente nel testo di aiuto, e l’apertura di alcuni contenuti in finestre pop-up.

Gli aiuti contestuali, al contrario, servono soprattutto a chi non può vedere. Tipici elementi d’interfaccia, che possono aver bisogno di informazioni contestuali per essere compresi da un non vedente, sono i controlli complessi realizzati unendo più oggetti grafici: per esempio, cursori e potenziometri come quelli usati per aumentare o diminuire il volume del suono. Mentre la funzione e l’utilizzo di simili strumenti risultano intuitivi per chi può vederne l’aspetto, un utente di screen reader dipende completamente dalla presenza di informazioni contestuali. È necessario, perciò, che il progettista inserisca etichette in grado di comunicare a un ascoltatore informazioni sui valori correnti di questi controlli e su come modificarli (premesso, naturalmente, che siano stati resi modificabili da tastiera).

Un altro caso in cui sarebbe molto utile un aiuto contestuale per chi usa un lettore vocale è quello dei menu che aprono dinamicamente contenuti diversi a seconda del pulsante premuto. Chi naviga in modalità visuale di solito non ha difficoltà a capire quale voce di menu è selezionata, perché gli sviluppatori hanno cura di usare indizi visivi, come il cambio di colore, di dimensioni o di posizione della voce di menu selezionata. Un simile indizio è però inesistente per chi ascolta soltanto, non potendo vedere i contenuti. Occorrerebbe perciò aggiungere testi contestuali nascosti, in grado di informare l’utente di screen reader di ciò che avviene nell’applicazione, sostituendo i segnali visivi, che non possono essere percepiti da questa categoria di utenti.

Fornire informazioni contestuali è qualcosa che va al di là della semplice cura di applicare un testo alternativo ai singoli oggetti. Si tratta, infatti, di mettersi nei panni di chi non può vedere, sforzandosi di rendergli chiare le relazioni tra i vari elementi d’interfaccia, oltre che i ruoli e gli stati di tutti gli oggetti significativi. A tal scopo, non è sbagliato fornire una descrizione generale dell’intera animazione che, per non appesantire la lettura degli screen reader, può essere collocata nel codice HTML invece che all’interno dell’oggetto Flash, collegandola a quest’ultimo per mezzo di un link ben visibile, posto all’interno dell’animazione.

Inizio pagina

Controllare l’ordine di lettura

È un altro degli strumenti essenziali per garantire l’accessibilità dei contenuti Flash. L’ordine di lettura può essere definito mediante la proprietà Indice della finestra Accessibilità o usando la proprietà tabIndex di ActionScript. Entrambi i metodi permettono di definire l’ordine in cui i singoli elementi d’interfaccia verranno selezionati tramite Tab e letti da uno screen reader. Insieme all’uso accorto dei testi alternativi e delle informazioni contestuali, stabilire la corretta sequenza di lettura è fondamentale per far capire l’organizzazione dei contenuti a chi non può osservarla visivamente.

L’immagine in Figura 12.18 tenta di illustrare con un esempio tratto dalla realtà del Web i problemi di comprensibilità che sorgono da una sequenza di tabulazione sbagliata. La schermata nell’immagine, tratta dal sito Geoterra , mostra una piccola applicazione in grado di calcolare l’energia prodotta dai mulini a vento, in base alla velocità del vento.

Spostando i due cursori in basso a sinistra, che rappresentano la velocità del vento (23) e il numero dei mulini (4), cambiano dinamicamente i valori numerici in alto a destra, che corrispondono al numero di kilowatt/ora prodotti e al numero di case che è possibile alimentare con quell’energia. Il testo sotto il titolo “Harness the Wind” (“Utilizza il vento”) fornisce le necessarie informazioni contestuali, che permettono di capire cosa contiene la scheda. Tuttavia l’ordine di navigazione da tastiera e l’ordine di lettura da parte dello screen reader non seguono l’ordine logico dei contenuti, ma quello automatico. Così, navigando i contenuti con JAWS o con Window-Eyes, vengono letti, nell’ordine: a) la didascalia; b) i dati sull’energia prodotta; c) le etichette e i valori dei due cursori (23 e 4).

Dato un simile ordine di lettura, un utente di screen reader va incontro a due problemi: 1) non capisce a cosa si riferiscano le slider bars, cioè i cursori, annunciati dalla didascalia, visto che, subito dopo, trova dei valori energetici non modificabili direttamente; 2) una volta che abbia trovato i due cursori, se pure riesce a modificarne la posizione (cosa che ci è sembrata impossibile da tastiera), è costretto poi a navigare a ritroso, cioè a ritornare al blocco dei valori energetici che aveva letto prima, se vuole avere un riscontro del risultato del loro spostamento: qualcosa di profondamente controintuitivo.

Il problema potrebbe essere risolto facilmente, impostando opportuni valori di tabIndex, in modo da invertire la sequenza e far leggere, nell’ordine: a) la didascalia; b) i cursori per modificare i valori; c) i dati sull’energia prodotta (tutto questo senza alterare la composizione grafica dell’applicazione).

L’effetto, insomma, dovrebbe sempre seguire la causa, mai precederla. Ragionamenti analoghi possono essere fatti per qualsiasi sito realizzato in Flash, che presenti un ordine logico dei contenuti diverso dalla sequenza di tabulazione automatica.

A partire da Flash Player 8, non è più necessario definire l’ordine di tabulazione per tutti gli oggetti dell’animazione. Come spiega Bob Regan, “l’ordine di lettura può essere specificato parzialmente. L’autore deve elencare soltanto gli oggetti che vuole controllare. Gli oggetti rimanenti seguiranno l’ordine di lettura predefinito, dopo i valori specificati” (nelle versioni precedenti di Flash Player, invece, la mancanza anche di un solo valore di indice determinava il ritorno alla lettura della sequenza predefinita).

Può essere, infine, altrettanto importante rimuovere alcuni oggetti dall’ordine di lettura, cosa che può essere fatta in vari modi: a) collocando fuori dallo stage l’oggetto che non deve essere letto, e avendo cura che i bordi del suo rettangolo di delimitazione si trovino almeno 1 pixel all’esterno; b) impostando in ActionScript la proprietà .silent al valore true; c) impostando la proprietà ._visible al valore false (ma in questo caso l’oggetto sarà invisibile per tutti, non solo per gli screen reader); d) togliendo il segno di spunta accanto all’opzione Rendi accessibile l’oggetto nella finestra Accessibilità.

Inizio pagina

Controllare il movimento nelle animazioni

Vi sono almeno tre tipi di controllo sul movimento degli oggetti animati, che riguardano strettamente l’accessibilità. Il primo tipo consiste nel rendere inaccessibili gli oggetti secondari. Come già spiegato in precedenza, la presenza di cambiamenti all’interno di un’animazione induce gli screen reader a ricominciare daccapo la lettura dei contenuti. L’effetto è simile a quello del refresh automatico di una pagina HTML, una pratica deprecata ai fini dell’accessibilità (si veda in proposito il commento al punto di controllo 7.4 nel Capitolo 10). Per impedire la rilettura automatica dei contenuti in un’animazione Flash, è consigliabile rendere inaccessibili gli oggetti che cambiano ciclicamente e che non sono significativi per un utente di screen reader. Uno dei modi per farlo è disabilitare l’opzione Rendi accessibili gli oggetti secondari nel pannello Accessibilità.

Il secondo tipo di controllo beneficia gli utenti deboli di vista e con difficoltà cognitive. Consiste nel “congelare” gli oggetti in movimento dopo uno o due secondi o nel fornire strumenti ben visibili per fermare il movimento. Gli oggetti in movimento costante, infatti, possono generare in un ipovedente una perdita tale di contesto, da rendergli difficile o impossibile mantenere il segno nella lettura dei testi. Similmente, un utente affetto da problemi cognitivi, per esempio un dislessico, può trovare nel movimento una causa di distrazione tale, da impedirgli di leggere e capire i contenuti.

Il terzo e ultimo tipo di controllo sul movimento beneficia i soggetti predisposti a subire crisi da epilessia fotosensibile (si vedano in proposito i commenti ai punti di controllo 7.1 e 7.2 nel Capitolo 10). Poiché questi utenti possono avere crisi scatenate da oggetti lampeggianti o sfarfallanti sullo schermo, è una buona pratica di progettazione quella di evitare del tutto lampeggiamenti e sfarfallamenti, qualsiasi sia la frequenza di imtermittenza.

Garantire l’accesso da tastiera

Rendere gli oggetti di un’animazione Flash navigabili da tastiera è indispensabile per garantire l’accessibilità dei contenuti a non vedenti e utenti con disabilità motorie, che non sono in grado di utilizzare il mouse.

Flash Player già rende attivabili da tastiera gli oggetti agganciati a eventi del mouse. Tuttavia, vi sono dei casi in cui lo sviluppatore deve prendere precauzioni particolari. Uno di questi è l’utilizzo di clip filmato per definire l’area attiva di un’altra clip usata come pulsante: una soluzione adoperata di frequente, perché permette di riutilizzare più volte le proprietà di un oggetto, senza doverle ricreare daccapo ogni volta. Tramite la proprietà .hitArea di ActionScript è possibile, infatti, collegare due clip tra loro, in modo che l’area attiva del primo pulsante abbia la forma della seconda clip (per esempio: clip_quadrato.hitArea = clip_cerchio).

Sorge qui un problema di accessibilità, perché gli screen reader non riconoscono come pulsante una clip che abbia definito solo lo stato di premuto (hit, in inglese). La cosa si può risolvere in modo semplice. Come suggerisce Bob Regan nella sua guida, basta applicare una clip trasparente allo stato up, cioè non premuto, dell’oggetto che deve agire da pulsante, per far sì che gli screen reader lo riconoscano come tale.

Un’altra soluzione teoricamente utile per garantire l’accesso da tastiera consiste nell’impostare tasti di accesso rapido per determinate funzioni o oggetti dell’animazione.

Inizio pagina

Svelare i contenuti progressivamente

Grant Skinner è considerato uno dei guru della progettazione di interfacce Flash. Il sito della sua società (Figura 12.19), ovviamente realizzato in Flash, consiste in tre livelli di contenuti, che si aprono in schede concatenate. Una simile struttura ci offre l’occasione di introdurre il concetto dello svelamento progressivo, come buona pratica di sviluppo di siti Flash e, in generale, dei siti dinamici.

Il concetto importante per l’accessibilità è che più i contenuti e i comandi di navigazione presenti nell’interfaccia di un sito sono numerosi, più difficile e faticoso sarà navigarvi per un utente di screen reader, costretto a scorrere tutti gli elementi uno alla volta, senza aver la possibilità di saltare in un sol colpo i blocchi non interessanti o già letti, come fa invece un vedente.

Una buona soluzione consiste, allora, nel cercare di tenere più basso possibile il numero di oggetti che uno screen reader deve pronunciare, navigando all’interno di un’interfaccia Flash. Ciò non vuol dire – si badi bene – che bisogna ridurre al minimo gli oggetti visualizzati nell’applicazione, ma che bisogna ridurre al minimo gli oggetti accessibili a uno screen reader in un dato momento. Ecco, appunto, in cosa consiste lo svelamento progressivo: nel rendere accessibili ai lettori vocali solo ed esclusivamente i contenuti che in un certo momento ha senso leggere, in base alle scelte effettuate dall’utente.

In strutture simili a quella in Figura 12.19, una volta che è stata aperta una scheda di un livello interno, sarebbe meglio rendere indisponibili agli screen reader i contenuti delle schede di livello superiore, con l’eccezione del comando di chiusura della scheda corrente. In tal modo, l’ascoltatore potrà focalizzare la propria attenzione sul contenuto nuovo e non sarà costretto a riascoltare ciò che ha già letto (limitarsi a invertire l’ordine di lettura, mettendo al primo posto la scheda appena aperta, costringe comunque a riascoltare i contenuti già noti, dopo che è terminata la parte nuova).

In un’interfaccia Flash costruita col criterio dello svelamento progressivo, scegliendo una voce di menu dovrebbero accadere le seguenti cose: 1) la voce di menu appena usata si trasforma nel pulsante di chiusura della scheda che ha aperto (è esattamente quel che accade nel sito gskinner.com); 2) gli oggetti esterni al nuovo contenuto vengono resi temporaneamente inaccessibili, per esempio usando la proprietà .silent di ActionScript. Quando viene invece usato un pulsante di chiusura, dovrebbero accadere queste altre cose: 1) la scheda chiusa viene resa inaccessibile agli screen reader; 2) gli oggetti esterni alla scheda chiusa vengono resi nuovamente accessibili; 3) il pulsante di chiusura appena adoperato si ritrasforma in una voce di menu.

Tutto ciò non coinvolge necessariamente – vale la pena di ripeterlo – la visibilità degli oggetti resi alternativamente accessibili/inaccessibili. I contenuti non selezionati possono, infatti, rimanere totalmente o parzialmente visibili, magari spostati sullo sfondo o modificati con qualche effetto grafico che ne sottolinea la temporanea disattivazione, quando il centro della scena è occupato da contenuti differenti. Anzi, la sovrapposizione parziale dei contenuti, con la possibilità di riselezionare quelli portati in secondo piano, è una delle soluzioni più usate nella progettazione di interfacce Flash.

Inizio pagina

Attivare l’accessibilità dei componenti d’interfaccia

Se si devono implementare in un’interfaccia Flash elementi interattivi come finestre d’avviso e controlli di modulo, è possibile utilizzare i componenti d’interfaccia, introdotti a partire da Macromedia Flash MX 2004. Ne abbiamo elencato le caratteristiche in uno dei paragrafi precedenti (Componenti d’interfaccia accessibili in Flash Professional). Ciò che è importante ricordare, come buona pratica di sviluppo, è la necessità di attivare l’accessibilità per ciascuno dei componenti utilizzati (non per le singole istanze), dal momento che questa caratteristica è di base disattivata. Il codice ActionScript da utilizzare allo scopo è contenuto nel paragrafo già ricordato.

Inizio pagina

Fornire sottotitoli e audiodescrizioni per i contenuti audiovideo

Poiché Flash è utilizzato sempre più spesso come strumento per diffondere sul Web contenuti multimediali, diventa esigenza fondamentale di accessibilità corredare tali contenuti di sottotitoli e di audiodescrizioni: i primi vanno a vantaggio di chi è sordo o duro d’orecchi, le seconde aiutano i ciechi a contestualizzare i contenuti audio. I commenti ai punti di controllo 1.4 e 1.5 delle WCAG 1.0, inseriti nel Capitolo 4, trattano tutti gli aspetti relativi ad audiodescrizioni e sottotitolazioni (in generale, non solo relativamente a Flash).

Qui è solo il caso di ricordare che esistono tre modi per sottotitolare dei contenuti diffusi all’interno di oggetti Flash. Il primo consiste nell’importare all’interno dell’area di lavoro di Flash tracce audio già sottotitolate con altre applicazioni: è un metodo che offre poca flessibilità dal punto di vista grafico. Il secondo sistema è il più potente dal punto di vista delle possibilità di personalizzazione dell’interfaccia, ma è anche il più complesso e faticoso da utilizzare: consiste nel piazzare direttamente sullo stage gli oggetti di testo che rappresentano i sottotitoli, modificandone a piacimento l’aspetto e la sincronizzazione. Il terzo e ultimo metodo è quello di associare i sottotitoli al brano multimediale solo al momento della riproduzione in streaming: ciò viene fatto per mezzo di un file XML contenente i sottotitoli, composto secondo uno dei vari standard esistenti.

Inizio pagina

Garantire il controllo sulla riproduzione dell’audio

Moltissime interfacce Flash contengono tracce sonore che partono automaticamente al caricamento della pagina. Questa soluzione, soprattutto se il volume del suono è alto, rischia di creare serie difficoltà a chi usa uno screen reader. Non basta, infatti, che ci sia un pulsante per fermare la colonna sonora dell’animazione (e talvolta non c’è neanche quello): se il volume è troppo alto rispetto a quello della voce sintetica dello screen reader, l’utente potrebbe non riuscire a sentire le etichette dei pulsanti; non saprebbe, quindi, come bloccare i suoni che gli impediscono di capire le parole: un circolo vizioso. Dal punto di vista dell’accessibilità, sarebbe meglio, dunque, se la colonna sonora partisse solo in seguito a un comando volontario dell’utente.

Chi usa uno screen reader deve poter attivare e fermare i suoni, le voci e le musiche di un’animazione Flash come e quando ne ha bisogno.

Se proprio lo sviluppatore desidera che l’utente comune ascolti la musica per caricamento automatico, senza doverla avviare volontariamente, potrebbe comunque salvaguardare l’accessibilità, avendo cura di creare una partenza silenziosa o a volume molto basso per i soli utenti di screen reader (che sono certamente una minoranza). Una simile alternativa è programmabile con relativa facilità: è sufficiente creare una condizione basata sull’uso del metodo Accessibility.isActive() di ActionScript. Se il valore di ritorno è true, vuol dire che c’è uno screen reader attaccato al browser. In tal caso, si potrà programmare una partenza dell’animazione a suono disattivato o a volume molto basso; viceversa, se la risposta è false, vuol dire che nessuno screen reader è presente e che perciò è possibile far partire la colonna sonora automaticamente, non appena si ha l’informazione di ritorno da parte di MSAA (va precisato, però, che, se l’uso del metodo Accessibility.isActive() avviene troppo presto, prima che si sia stabilita la comunicazione tra Flash Player e lo screen reader, possono aversi dei falsi negativi).

Per quanto riguarda i comandi per fermare, riattivare e modificare il suono, lo sviluppatore dovrebbe aver cura di renderli accessibili non solo agli utenti di screen reader, ma anche a ipovedenti e disabili motori: tutti, non solo i non vedenti, possono trovare comodo, infatti, governare i suoni dell’applicazione. Ciò vuol dire che tali comandi dovrebbero essere chiaramente etichettati e adoperabili da tastiera, ma anche ben visibili. Non vanno bene, per gli scopi dell’accessibilità, le microscopiche iconcine dai colori sbiaditi e dalla simbologia ambigua, posizionate nel punto più invisibile dell’interfaccia, o magari nascoste in un menu che appare solo al passaggio del mouse. Purtroppo per i gusti del design di tendenza, in questo caso accessibile fa rima con visibile: più un comando è grande, contrastato e ben distanziato da tutto il resto, più sarà facile scorgerlo e servirsene, anche da parte di un utente che vede poco e ha problemi di puntamento e di mobilità.

Inizio pagina

Non vincolare i contenuti al colore

Questa raccomandazione è analoga a quella contenuta nella linea guida 2 delle WCAG 1.0. Rimandiamo al Capitolo 5 di questo libro per una trattazione dettagliata di tutti gli aspetti connessi a un uso accessibile del colore.

Qui ci limitiamo a ricordare l’importanza di bilanciare la ricerca di soluzioni grafiche d’effetto, tipica di chi sviluppa interfacce Flash, con la necessità che i contenuti rimangano ben leggibili. Ciò vuol dire fare attenzione, tra le altre cose, al contrasto cromatico e di luminosità tra primo piano e sfondo.

Un grafico che non abbia dimestichezza con le problematiche dell’accessibilità tenderà a ignorare che esiste una rilevante percentuale di utenti (tra l’8% e il 10% della popolazione maschile) che ha una percezione dei colori alterata, in particolare sull’asse rosso-verde. È necessario, perciò, che i progettisti di siti Flash prendano confidenza con gli strumenti software per la verifica della leggibilità degli accoppiamenti di colore.

Piuttosto, però, che arrabbattarsi con il calcolo di percentuali e soglie di contrasto, che ha poco senso quando applicato a interfacce grafiche concepite con criteri del tutto diversi da quelli tipici dei siti in HTML, consigliamo ai progettisti di siti Flash di utilizzare un software interattivo come Fuji ColorDoctor, attualmente giunto alla versione 2.01 e liberamente scaricabile da http://www.fujitsu.com/global/accessibility/assistance/cd/ .

Fuji ColorDoctor si presenta con un’area di lavoro suddivisa in due metà (Figura 12.21). Nella finestra di sinistra è possibile caricare i siti che si desidera valutare dal punto di vista dei colori, digitandone l’indirizzo in un’apposita barra, simile a quella di un comune browser web. La tendina Conversion filter permette di scegliere un tipo di filtro cromatico tra i quattro disponibili: protanopia, deuteranopia, tritanopia, grey scale (scala di grigi). Ciascuno simula la visione alterata tipica di chi soffre di un deficit della percezione dei colori.

Dopo aver scelto il filtro, la pressione del pulsante Convert image genera nella finestra di destra un’immagine corrispondente all’area del sito visualizzata nella finestra di sinistra, alla quale viene applicato il filtro selezionato dall’utente. La casella di controllo Real-time conversion, se spuntata, rigenera di continuo l’immagine, compatibilmente con le disponibilità di memoria del computer usato: una funzione utile per valutare la leggibilità di contenuti che cambiano ciclicamente, come è molto comune che accada nei siti realizzati con Flash.

Se i contenuti conservano una sufficiente leggibilità qualsiasi sia il filtro applicato, si può essere ragionevolmente certi di aver realizzato un sito accessibile anche a utenti affetti da cecità ai colori.

Inizio pagina

Fornire soluzioni per gli ipovedenti

Vi sono molte persone che vedono poco, ma non tanto poco da dover navigare esclusivamente con un ingranditore di schermo; altre che usano di solito software ingrandenti, ma si trovano occasionalmente a usare il computer di qualcun altro, su cui non è installato l’ausilio di cui hanno bisogno. Tutte queste persone, per poter leggere senza problemi i contenuti web, hanno bisogno di ingrandire, spesso di parecchie unità, la dimensione base dei caratteri nei siti da essi navigati.

Per i siti realizzati in HTML secondo criteri di accessibilità, le funzioni del menu Visualizza di un qualsiasi browser risolvono in genere il problema, consentendo di ingrandire a sufficienza i caratteri. Per i siti Flash purtroppo non funziona così: per quanto si tenti di variare il fattore d’ingrandimento usando i comandi del browser, i testi rimangono tristemente bloccati alla dimensione fissata dal progettista. Poiché i caratteri scelti dagli autori di siti Flash sono quasi sempre molto piccoli, e resi spesso ancor più difficili da decifrare a causa di sfondi ed effetti grafici, il problema di accessibilità che tocca gli utenti con problemi di vista è molto serio (Figura 12.22).

Ma perché i comandi del browser non agiscono sui testi di un’animazione Flash? La ragione è che tutto ciò che si trova all’interno di un file SWF, che è il supporto di archiviazione e distribuzione dei contenuti Flash, è invisibile all’esterno. Gli oggetti Flash incorporati in un documento HTML o XHTML sono contenuto rimpiazzato, replaced content: vuol dire che il browser conosce soltanto lo spazio che deve riservare nella pagina per visualizzarli. Ci pensa poi un altro software, il plug-in Flash Player, a riprodurne i contenuti.

Bisogna allora arrendersi alla non ridimensionabilità dei testi di un sito Flash? Per fortuna no: esistono delle soluzioni.

La più semplice consiste nel fornire, all’interno della stessa interfaccia Flash, degli strumenti – possibilmente ben visibili – per modificare e ingrandire i caratteri: per intenderci, qualcosa di simile ai pulsanti con le etichette “A+” e “A-”, che si trovano ormai in una moltitudine di siti realizzati in HTML o XHTML.

Un’altra soluzione è quella proposta di recente da Niqui Merret, una sviluppatrice Flash interessata a coniugare design e accessibilità. In un articolo del 24 settembre 2006, intitolato Text-Resize in the browser sets the scale of SWF , la Merret illustra un metodo per aggiornare dinamicamente la grandezza dei caratteri all’interno di un oggetto Flash, in modo che corrisponda ai ridimensionamenti effettuati dall’utente usando i comandi del proprio browser, proprio come se si trattasse di un documento HTML: quel che serviva, per risolvere il problema di accessibilità che abbiamo descritto all’inizio di questo paragrafo. Un esempio funzionante è disponibile all’indirizzo http://niquimerret.com/fontresize/ .

Il metodo escogitato dalla Merret è molto ingegnoso e sfrutta i più recenti sviluppi nel campo del JavaScript non invasivo. Si basa sullo script UFO di Christian Heilmann, di cui abbiamo parlato nella prima parte di questo capitolo, che usa in congiunzione con uno script sviluppato da Lawrence Carvalho e pubblicato su A list apart (Text-Resize Detection ). Integra, infine, le funzioni dei due script, per mezzo di un terzo script sviluppato da lei stessa.

Come si ricorderà, lo script UFO ha lo scopo di visualizzare i contenuti Flash solo nei browser forniti di supporto per questa tecnologia e/o per JavaScript e si serve allo scopo di un DIV contenitore, identificabile per mezzo di un attributo id, nel quale va inserito l’oggetto Flash. Lo script di Carvalho serve, invece, per determinare la dimensione base del testo impostata nel browser e per recuperare i valori dei ridimensionamenti effettuati dall’utente. Come usare questi dati per ridimensionare i testi all’interno dell’oggetto Flash? La soluzione proposta da Niqui Merret consiste in alcune semplici operazioni:

• definire l’altezza e la larghezza del file SWF al 100% nei parametri dello script UFO;
• attribuire al DIV contenitore l’altezza e la larghezza in pixel dell’oggetto SWF;
• modificare dinamicamente l’altezza e la larghezza del DIV contenitore, passandogli i parametri del ridimensionamento operato dall’utente nel browser, grazie allo script di Carvalho opportunamente modificato.

L’impostazione delle dimensioni dell’oggetto Flash al 100% fa sì che la sua grandezza si adatti dinamicamente a quella del DIV contenitore, rispondendo in tempo reale alle modifiche fatte dall’utente tramite i normali comandi del browser. Chi desidera approfondire la tecnica di ridimensionamento che abbiamo descritto, troverà tutti i file di codice necessari, all’interno di un archivio compresso scaricabile dal sito di Niqui Merret, all’indirizzo http://niquimerret.com/fontresize/scaledemo.zip .

Inizio pagina

Un caso di successo: il sito della scrittrice J.K. Rowling

Dopo tante raccomandazioni per l’accessibilità dei siti Flash, è il caso di dare uno sguardo al Web reale e vedere se esistono siti che le applicano in tutto o in parte. Un caso significativo, sia per la notorietà del personaggio sia per la qualità dell’implementazione accessibile, è certamente il sito della scrittrice Joanne Rowling, autrice della celeberrima saga di Harry Potter.

La pagina di accoglienza del sito , mostra in posizione privilegiata il collegamento alla versione Flash accessibile (Figura 12.23). Seguono collegamenti alle versioni testuali in varie lingue, compreso l’italiano, e infine i collegamenti a sei versioni Flash “normali”, in altrettante lingue differenti, che sono inaccessibili, perché non consentono navigazione da tastiera né hanno altri ausili per l’accessibilità.

Si può discutere sull’opportunità di aver implementato l’accessibilità in una versione Flash separata del sito, solo in inglese, che penalizza chi ha bisogno dell’accessibilità e non conosce quella lingua. Tuttavia il fatto stesso che esista una versione Flash accessibile, peraltro di buona qualità, e la posizione privilegiata in cui è stato posizionato il link per accedervi sono senz’altro punti a favore del sito della Rowling, rispetto ai tantissimi altri siti Flash che sono tristemente off-limits per gli utenti con disabilità, a causa delle soluzioni progettuali scelte dai produttori.

Appena aperta la versione del sito, la prima cosa che s’incontra è il comando accessibility tools, evidenziato dall’ovale a sinistra in Figura 12.24, che permette di aprire le opzioni per l’accessibilità disponibili nel sito. Nell’ovale sulla destra della stessa figura è evidenziato, poi, l’equivalente testuale di uno dei suoni riprodotti dall’applicazione (doorbell rings, cioè “suona il campanello della porta”). L’equivalente testuale si autoaggiorna dinamicamente, rispecchiando il mutare dei suoni di ambientazione.

La Figura 12.25 mostra le opzioni di accessibilità che vengono visualizzate dopo aver premuto il pulsante accessibility tools.

Notiamo subito che il comando pause movements permette di bloccare gli oggetti in movimento, come richiede la linea guida 7 delle WCAG 1.0, o meglio il punto di controllo 8.1, che raccomanda di applicare alle interfacce incorporate, come sono gli oggetti Flash, gli stessi principi di accessibilità validi per i contenuti HTML.

Il comando unmute sounds riattiva i suoni dopo che sono stati bloccati. Premendolo, si trasforma nell’opzione predefinita mute sounds, che serve per interrompere il suono. Si tratta, come abbiamo già avuto modo di segnalare, di un’opzione essenziale per l’accessibilità, perché consente a un utente di screen reader di eliminare e ripristinare a piacere i suoni che possono interferire con la lettura dei contenuti da parte della sintesi vocale.

Il comando magnify daily news è utile per gli ipovedenti (anche se è scritto, forse, in caratteri troppo piccoli per servire veramente allo scopo). Premendolo, il riquadro con le ultime notizie del sito viene ingrandito e i contenuti diventano più leggibili (Figura 12.26).

Le opzioni del menu per l’accessibilità mostrato in Figura 12.25 sono completate da open site help, che apre una scheda con tre scelte (Figura 12.27 A):

1. site overview, che contiene una breve descrizione dell’organizzazione del sito;
2. sound glossary, che elenca tutti i suoni usati nell’applicazione, spiegandone la funzione e fornendo per ognuno la possibilità di ascoltarlo separatamente;
3. keyboard controls, un’utilissima rassegna di combinazioni di tasti che gli screen reader JAWS e Window-Eyes mettono a disposizione degli utenti, per eseguire le principali funzioni di navigazione (nella Figura 12.27 B sono visibili i comandi per Window-Eyes).

Tutto il sito accessibile è ovviamente navigabile da tastiera. Anche le funzioni più comunemente eseguite con il mouse, come far scorrere il testo in una pagina facendo clic sulle frecce alle estremità della barra di scorrimento laterale, sono eseguibili da tastiera. Il sito Flash di J.K. Rowling dimostra che anche un’interfaccia grafica molto sofisticata e dinamica, com’è tipico che siano le applicazioni Flash, può essere resa accessibile, purché si abbiano il tempo, la voglia e le capacità di applicare le raccomandazioni di accessibilità, secondo i mezzi che la tecnologia adoperata mette a disposizione dello sviluppatore.

Inizio pagina

Oggetti Flash intrinsecamente inaccessibili

Tra i vari giochi in Flash presenti sul sito http://www.nickjr.com/ , ve n’è uno basato sul colorare (uno dei tanti presenti sul Web). La caratteristica positiva è che i colori possono essere selezionati e applicati alle figure anche da tastiera, senza un vincolo esclusivo all’uso del mouse, come capita invece in altri casi. Possiamo dire, allora, che è un gioco accessibile? Per un disabile motorio legato all’uso della tastiera, certamente sì, è accessibile. Ma per un non vedente? Ha senso per un non vedente colorare? Forse, per chi non vede, può avere senso l’esercizio di abilità di usare comunque l’applicazione, ma non certo l’attività del colorare in se stessa, perché esercitarla e apprezzarla – il che è lo scopo del gioco – prevede la capacità di vedere i colori.

Alla fine, dunque, per quanto lo sviluppatore possa essersi impegnato a rendere accessibile agli screen reader l’interfaccia della sua applicazione, il gioco resterà inaccessibile per un cieco, nella sua essenza, a causa dell’impossibilità materiale di vedere i colori e l’effetto che produce la loro diversa applicazione alle figure.

Questo esempio non vuole essere un esercizio di filosofia fine a se stesso, ma un invito rivolto ai progettisti Flash interessati all’accessibilità a riflettere sempre con attenzione sugli scopi e i requisiti d’uso delle applicazioni che stanno sviluppando.

Prima di mettersi all’opera per implementare le varie caratteristiche di accessibilità che abbiamo incluso tra le buone pratiche di sviluppo, è indispensabile chiedersi se l’applicazione a cui si sta lavorando può essere tradotta in una differente modalità sensoriale. Ciò vale soprattutto per i giochi, che costituiscono una fetta rilevante di ciò che si produce usando la tecnologia Flash.

Molti giochi richiedono una specifica abilità sensoriale. Spesso si tratta della vista, nel caso, per esempio, di attività come colorare, spostare oggetti in una determinata posizione, sparare a un bersaglio mobile, evitare ostacoli muovendosi a gran velocità ecc. Altre volte si tratta dell’udito: distinguere la più alta o la più bassa tra una serie di note, riconoscere una voce, una canzone, un suono ecc.

In tutti i casi simili, l’accessibilità è in un certo senso impotente: per quanto si seguano con diligenza le buone pratiche di sviluppo, non si può tradurre una specifica abilità sensoriale in una differente. Si può riconoscere un suono solo con l’udito, non con la vista né col tatto né tantomeno con un equivalente testuale. Se si forniscono alternative visive, tattili o logiche a un gioco che richiede una capacità di discriminazione uditiva, non si è realmente reso accessibile quel gioco, ma si è realizzato un gioco diverso (esistono giochi – si veda per esempio http://www.gamesfortheblind.com/ – creati appositamente per i non vedenti, in cui il giocatore deve muoversi e agire all'interno dello scenario del gioco, interpretando opportunamente il variare di appositi suoni e ascoltando voci sintetiche che forniscono informazioni