Realizzare siti Flash più usabili dei siti Html

Intervista agli autori di “Skip Intro”, il manuale edito da New Riders dedicato alla costruzione di siti Flash usabili

  1. Parlateci di voi [Risposta 1]
  2. Di quali argomenti si occupa il manuale? C’è un sito collegato al libro? [Risposta 2]
  3. Qual è il problema di Flash e perchè ci sono così tanti esperti di usabilità che si scagliano contro il suo uso? [Risposta 3]
  4. Qual è la soluzione? Come possiamo migliorare l’usabilità in Flash? [Risposta 4]
  5. Parliamo di accessibilità. È possibile costruire siti Flash accessibili alle persone disabili? [Risposta 5]

Parlateci di voi

Michelangelo Capraro

Sono un multimedia designer dal 1993 e lavoro per la stampa, realizzando anche Cd-Rom, siti e interfacce web. Ho “giocato” con Flash fin da quando veniva chiamato FutureSplash, anche se utilizzavo Shockwave di Director per i lavori dei clienti. L’ho adottato definitivamente a partire dalla versione 4, e da allora è sempre migliorato. Adesso uso la versione 5 o Flash MX.

Oggi lavoro alla PalmSource, un’azienda che realizza il sistema operativo per Palm, Handspring e Sony. Sono a capo dello User Experience Group e mi occupo della progettazione grafica del sistema operativo.

Duncan McAlester

Lavoro con il web dal 95/96, dove mi occupo di programmazione o progettazione come libero professionista su un’ampia sfera di progetti, da siti di intrattenimento ad applicazioni web.

Top

Di quali argomenti si occupa il manuale? C’è un sito collegato al libro?

Michelangelo Capraro

Skip Intro è un libro rivolto ai progettisti Flash che vogliono realizzare interfacce usabili. Lo abbiamo scritto in risposta al sentimento anti Flash maturato dalla comunità che si occupa di usabilità e anche in risposta al sentimento anti usabilità della comunità Flash.

Skip Intro non è stato scritto per chi ha già familiarità con l’usabilità, ma è un’introduzione alle regole principali che i progettisti web dovrebbero adottare per realizzare un sito Flash che sia usabile.

Alcuni degli argomenti che affrontiamo usano scenari (scenarios) e persone (personas), così da permettere la stesura di una lista di requisiti. In questo modo si impara a pensare per prima cosa agli utenti e a costruire componenti che rendano i siti più usabili.

Abbiamo cercato di affrontare tutti gli ambiti di usabilità Flash, dalle rigide regole di usabilità all’uso di ActionScript per costruire interfacce Flash.

Esiste un sito [nuova finestra] per il libro, al quale stiamo aggiungendo pian piano dei contenuti e presto anche degli articoli. Renderemo disponibili anche delle librerie di componenti Flash, così che gli sviluppatori possano semplicemente “trascinarli” nelle loro animazioni e ottenere grandi effetti grafici e interfacce usabili.

Top

Qual è il problema di Flash e perchè ci sono così tanti esperti di usabilità che si scagliano contro il suo uso?

Michelangelo Capraro

Il problema è la presenza di molti progettisti Flash che non si preoccupano dei loro utenti.

Realizzano siti con introduzioni composte da animazioni pesanti che richiedono parecchi minuti per essere scaricate e sono inutili da guardare.

Progettano interfacce che sono difficili da usare il cui solo scopo è impressionare altri progettisti, piuttosto che rendere la vita più semplice per le persone che utilizzano il sito.

Ecco perché molti guru dell’usabilità sono a ragione contro questo uso di Flash.

Flash può in realtà aiutare gli sviluppatori a realizzare siti web che siano più usabili dei normali siti costruiti con Html o Dhtml, anche se molti non se ne rendono conto.

Quel che è peggio è che i guru dell’usabilità non aiutano i progettisti Flash a capire come possono migliorarsi; si limitano a ridicolizzarli e a colpevolizzare il loro strumento: Flash.

A loro volta i progettisti Flash si offendono per le insolenze di qualche esperto di usabilità e così rifiutano di ascoltare i consigli che potrebbero aiutarli.

Duncan McAlester

Come per ogni tecnologia, è possibile creare un prodotto che sia usabile, ma anche esteticamente gradevole.

Flash è stato però presentato come uno strumento per realizzare animazioni e all’inizio è stato utilizzato soprattutto da chi da molta importanza all’aspetto grafico. Queste persone con tutta probabilità non davano molto peso o semplicemente non conoscevano l’importanza dell’usabilità. Anch’io all’inizio provavo le cose più accattivanti senza preoccuparmi degli utenti.

Accusare solo Flash, d’altro canto, è segno di miopia: per ogni sito Flash realizzato male, ce ne sono almeno 10 realizzati male in Html. La grande differenza è l’abuso che se ne può fare. È infatti molto più semplice abusare di Flash e realizzare degli orribili siti, per esempio includendo animazioni di 1 Mb come accadeva una paio d’anni fa; è più difficile commettere questi errori in Html.

La possibilità di creare queste enormi animazioni e altri effetti come il bottone back che non funziona, i motori di ricerca che non indicizzano le pagine, ecc. hanno dato ai guru dell’usabilità molti pretesti per criticare Flash. Sono comunque convinto che incolpare Flash non risolve il problema, ma al massimo riduce i danni, rendendo le animazioni da Mb più difficili da realizzare. Ma i problemi principali di usabilità non cambieranno, se gli sviluppatori non vengono educati.

Top

Qual è la soluzione? Come possiamo migliorare l’usabilità in Flash?

Michelangelo Capraro

Una soluzione è avvicinare gli esperti di usabilità e i progettisti Flash così da far capire ad entrambi quanto Flash sia uno strumento che può migliorare l’usabilità di un sito.

Come sviluppatori Flash, dobbiamo capire che la parte più importante di ogni progetto è l’utente finale con le sue richieste ed aspettative. Se riusciamo a soddisfare le sue esigenze, con o senza Flash, allora abbiamo costruito un’interfaccia efficace.

Duncan McAlester

Molto dipende da come sono educati i progettisti. I progettisti vogliono di per sé realizzare interfacce che gli utenti possano usare. Se andate in qualsiasi scuola di design e date un’occhiata alla facoltà che si occupa dei processi di stampa, vi accorgerete che passano molte ore a parlare di leggibilità, composizione, layout, tipografia, ecc: tutte cose che hanno a che fare con il design per l’utente.

Il web è ancora un mondo nuovo (paragonato alla stampa) e così le scuole ancora non hanno adeguato i loro corsi perché si parli anche di usabilità.

Top

Parliamo di accessibilità. È possibile costruire siti Flash accessibili alle persone disabili?

Michelangelo Capraro

. Quando abbiamo scritto il libro, Flash MX (e in particolare le opzioni per l’accessibilità) era in fase di costruzione, così non siamo riusciti a parlare di accessibilità. Flash MX offre comunque qualche opzione per rendere i progetti Flash accessibili. Permette di utilizzare la tastiera per navigare gli “hotspot” e si interfaccia con gli screen reader così da permettergli di leggere a voce il testo.

Anche se è positivo che Macromedia abbia incluso queste opzioni in Flash, lo avrebbe potuto fare meglio. Penso infatti che gli sviluppatori non spenderanno tempo per cercare di rendere le loro animazioni fruibili anche dalle persone disabili, poiché Macromedia ha reso l’uso delle opzioni di accessibilità difficile da usare. C’è bisogno che Macromedia renda queste funzionalità più facili da controllare.

Duncan McAlester

Ci sono anche alcune caratteristiche di accessibilità che sono ereditate direttamente da Flash.

Prima di tutto Flash è basato sui vettori, così è facile zoomare tutto quello che c’è sullo schermo e ottenere delle immagini pulite e nitide. Con l’Html è possibile aumentare la dimensione dei font, ma non è possibile ingrandire un’immagine senza includerne più copie a risoluzione diversa.

Anche la gestione dell’audio è trasparente in Flash. L’audio sul web (Real, QuickTime o solo Midi) non è molto adatto ad aiutare gli utenti, poiché è difficile sincronizzarlo con i movimenti del cursore. Con Flash è molto facile capire cosa sta facendo l’utente e presentargli dei suggerimenti sonori per aiutarlo o indirizzarlo.

Top

Un Web Accessibile a Tutti – Intervista a Joe Clark

  1. Ci parli di lei [Risposta 1]
  2. Quali sono gli argomenti trattati nel vostro libro “Building Accessible Websites“? [Risposta 2]
  3. Che cosa è l’accessibilità Web e perché è così importante nella costruzione di un sito? Quali fasi del ciclo di vita di un sito hanno a che fare con l’accessibilità? [Risposta 3]
  4. L’accessibilità web è utile solo alle persone disabili? [Risposta 4]
  5. In cosa differisce l’accessibilità web dalla usabilità web? [Risposta 5]
  6. Le specifiche Wai sono a volte difficili da applicare. Le pagine di un sito devono “degradare gentilmente”, ma allo stesso tempo è meglio usare i Css anche per il layout. Le due tecniche sembrano agli antipodi. È davvero possibile costruire un sito seguendo queste specifiche così restrittive? [Risposta 6]
  7. Cosa dire dei browser: Internet Explorer 6 e Netscape 6 interpretano correttamente i tag Html rivolti all’accessibilità? [Risposta 7]
  8. A parte il sito Wai, ci sono altre risorse online che ci potrebbe consigliare? [Risposta 8]

Ci parli di lei

Sono un giornalista [nuova finestra] e consulente di accessibilità [nuova finestra] a Toronto. Svolgo questo lavoro praticamente da 20 anni. Ho pubblicato circa 400 articoli su riviste e giornali e sto per pubblicare un libro, Building Accessible Websites [nuova finestra]. Mi occupo di consulenza su temi di accessibilità per un piccolo numero di clienti (soprattutto per la televisione e il cinema).

Top

Quali sono gli argomenti trattati nel vostro libro “Building Accessible Websites“?

Piuttosto che il solito manuale di programmazione, il libro è una chiara spiegazione di cosa sia l’accessibilità Web e delle regole per progettare siti accessibili.

Alcuni degli argomenti riguardano:

  • L’accesso alle informazioni e le leggi
  • Una breve spiegazione di come le persone disabili usano i computer
  • Multimedia
  • La navigazione
  • Tabelle e frame
  • Il testo e i link
  • La struttura della pagina
  • Le immagini
  • Come creare pagine accessibili fin dall’inizio

Top

Che cosa è l’accessibilità Web e perché è così importante nella costruzione di un sito? Quali fasi del ciclo di vita di un sito hanno a che fare con l’accessibilità?

In generale l’accessibilità viene incontro alle situazioni e difficoltà invariabili di alcune persone. Una persona con problemi alla vista continua ad averli anche quando visita un sito, tanto per fare l’esempio più comune.

Il Web non è un mezzo universale. Non è come la stampa: economica e disponibile senza troppe difficoltà. C’è un certo grado di elitarismo nel Web: c’è bisogno di un computer e di una connessione ad Internet, elementi con un certo costo. Allora perché l’accessibilità Web è importante? Perché non si vuole essere elitari inutilmente. Non bisogna impedire l’accesso ai siti per cause che queste persone non possono cambiare.

Oltre a questo, l’accessibilità è sempre più richiesta dalle norme di legge [nuova finestra]. Non ci sono decreti nati appositamente per l’accessibilità Web, ma ci sono dimostrazioni di quanto le leggi attualmente in vigore siano state applicate all’accessibilità Web.

Una persona non vedente, Bruce Maguire, ha vinto un caso [nuova finestra] contro le Sydney Olympics del 2000; ha sostenuto che il loro sito Web era per lui inaccessibile (Bruce legge il testo Web con un visualizzatore Braille e un lettore vocale), e le autorità australiane gli diedero ragione, richiedendo al comitato olimpico l’adeguamento del sito e il pagamento di una multa. (Non hanno mai aggiornato il sito, che si sarebbe potuto progettare nel modo corretto fin da subito, ma pagarono la multa).

Il decreto “Americans with Disabilities Act [nuova finestra] si applica senza equivoci anche al Web. Lo stesso dicasi per il “Disability Discrimination Act [nuova finestra] nel Regno Unito, e anche per tutte le forme legislative che proibiscono un trattamento non equo, ma sfavorevole nei confronti delle persone disabili. Inoltre, i servizi e i siti realizzati da chi lavora per o nel governo federale degli Stati Uniti devono essere accessibili e rispettare i requisiti “Section 508 [nuova finestra].

Meglio includere le politiche di accessibilità fin dall’inizio. È generalmente semplice realizzare un sito accessibile partendo da zero e molto noioso e spiacevole ritornare indietro e correggere errori in un secondo momento. Il mio libro, a dire il vero, spiega anche come migliorare un sito esistente, se questa è l’unica possibilità. Ci sono delle procedure che rendono il compito gestibile.

Top

L’accessibilità web è utile solo alle persone disabili?

In quasi tutti i casi, si. Personalmente sono stanco di sentire quei difensori dell’accessibilità che dicono “Se rendi il tuo sito accessibile, le persone potranno visualizzarlo con i loro Palm Pilot!”. Non vedo perché si debbano cercare delle giustificazioni al fatto che rendere un sito accessibile è utile soprattutto per rispondere alle esigenze delle persone disabili (più qualche altra esigenza, come i problemi di lingua, anche se non ne parlo molto nel libro).

In ogni caso un sito che si definisce accessibile non funzionerà bene su un Palm Pilot. Ci sono ancora troppi link (come le barre di navigazione) e troppo testo non pertinente perché valga la pena usarlo. Si è verificato il contrario con il caso Amazon [nuova finestra]. Amazon ha adattato il sito per i Pda e ha sostenuto che era fruibile anche con i software di sintesi vocale. Ma le cose non funzionano così.

Top

In cosa differisce l’accessibilità web dalla usabilità web?

L’interazione tra le due discipline sta diventando sempre più chiara.

Il problema principale è il seguente: se il tuo sito è immediatamente ed efficacemente utilizzabile da una persona non disabile, ma una persona disabile deve faticare per completare i suoi compiti e impiega il triplo del tempo, quanto accessibile è il tuo sito? Quanto è usabile?

Questo è riconducibile a due aree principali: la navigazione e le form.

I siti web “tipici” hanno troppi link da saltare. Questo non è solo un problema per le persone non vedenti che usano i sintetizzatori vocali, come invece tutti pensano. Un abile utilizzatore di sintetizzatori vocali può infatti evitare molto agevolmente i link, per esempio saltando completamente la barra sinistra di navigazione. Ma una persona con problemi motori potrebbe essere costretta a tabulare tra 80 o più link solo per posizionare il cursore sulla casella di ricerca. (E usare la tabulazione per navigare i link è in realtà il caso migliore e quello più veloce – alcuni metodi usati da persone con gravi problemi motori muovendo le mani e le braccia sono molto lenti).

I siti dovrebbero riordinarsi automaticamente così che gli elementi cruciali, come le caselle di ricerca o i più importanti livelli di navigazione siano in cima, mentre tutto il resto dovrebbe essere presentato di seguito secondo un ordine logico. Forse il protocollo CC/PP [nuova finestra] renderà un giorno tutto questo possibile. A dire il vero, ogni sito realizzato come insieme di moduli da un sistema di gestione dei contenuti potrebbe automaticamente riordinarsi in questo modo, ma nessuno si sta prendendo il disturbo di farlo. Non si prendono neppure la briga di riordinare gli elementi della pagina premendo un bottone invece che farlo automaticamente. Si stanno ancora studiano delle tecniche che risolvano questo problema.

Riguardo alle form, i miglioramenti per l’accessibilità sono molto semplici in Html. Le form sono già di per sé complicate da mettere insieme, così gli sviluppatori non hanno nessuna scusa per non includere i tag che migliorino l’accessibilità. Il problema è in realtà che i sintetizzatori vocali non sono stati aggiornati per usare queste caratteristiche (come <label> intorno al tag <input>). Potrebbe allora succedere che gli autori di contenuti abbiano svolto correttamente il loro lavoro, ma che la tecnologia per l’accessibilità non riesca ad interpretarlo. E i sintetizzatori vocali non sono per niente bravi nel leggere il testo, i bottoni, i radio button, i check box e i textarea e chiarire come tutti questi elementi siano collegati gli uni agli altri. È molto facile perdersi quando si compila una form online. Allora, se le persone non disabili possono usare la vostra form ma le persone disabili no, la vostra form è realmente usabile? (Anche in questo caso, rendere accessibili le form per persone con difficoltà motorie è molto difficile. Nessuno ha sviluppato un buon metodo per svolgere questo compito fino ad oggi).

Top

Le specifiche Wai sono a volte difficili da applicare. Le pagine di un sito devono “degradare gentilmente”, ma allo stesso tempo è meglio usare i Css anche per il layout. Le due tecniche sembrano agli antipodi. È davvero possibile costruire un sito seguendo queste specifiche così restrittive?

Le specifiche del Wai sono pessime, ma sono in fase di attenta revisione. Finalmente abbiamo una
title=”Wcag 2 Restructuring Proposal” target=”_blank”>bozza della versione 2.0 [nuova finestra] delle Web Content Accessibility Guidelines che è quasi decente. Siamo ancora lontani dal traguardo, ma rappresenterà un forte miglioramento. Al momento siamo ancora bloccati alla versione 1.0.

La frase “degradare gentilmente” è stata ampiamente fraintesa. Significa semplicemente che “le cose devono funzionare anche in condizioni che lo sviluppatore non ha potuto o saputo anticipare”. È facile da ottenere, soprattutto in siti che non usano elementi multimediali. Se si scrive Html valido e si usano gli elementi dell’Html nel modo consono (cioè, non si usa <p> per codificare un titolo), si è già a buon punto.

Non è “sicuramente meglio” usare i Css per il layout. È troppo difficile far sì che i layout creati con i Css funzionino consistentemente in tutti i browser; è molto più semplice usare le tabelle. Questo nel mondo reale, dal momento che chiunque abbia messo insieme più di qualche pagina ha usato le tabelle per il layout. I costruttori di sintetizzatori vocali hanno inoltre aggiornato il loro software per gestire le tabelle (con rare eccezioni). I Css, quando riuscite a farli funzionare, vanno bene; anche le tabelle vanno bene. Lo so che sembra esserci un’eresia, ma questa è la realtà. (Io uso Css e tabelle, e qualche volta nessuno dei due, per le circa 500 pagine che ho online. Non pretendo di essere un purista, ma nessun altro dovrebbe pretenderlo).

Top

Cosa dire dei browser: Internet Explorer 6 e Netscape 6 interpretano correttamente i tag Html rivolti all’accessibilità?

I browser sono solo mediocri quando si tratta di supporto all’accessibilità nell’Html.

Le ultime versioni di Mozilla [nuova finestra] gestiscono molte funzionalità correttamente. Sottolineano gli acronimi e le abbreviazioni con linee tratteggiate; vi danno l’accesso alle descrizioni lunghe (longdesc) delle immagini (ma non dei frame – nessun browser lo fa); gestiscono l’alt text per le immagini meglio di qualsiasi altro browser (visualizzano semplicemente il testo dell’alternate senza cornici o altri riferimenti grafici che non siano stati progettati per la pagina).

iCab [nuova finestra] ha un supporto molto buono: è l’unico browser che può leggere l’attributo summary di una <table>.

Il supporto per l’accessibilità di Internet Explorer [nuova finestra] è solo discreto. Dal momento che non sono visualizzate alcune funzionalità molto utili come le descrizioni lunghe, gli sviluppatori spesso non sanno neppure che è possibile aggiungerle all’Html.

Top

A parte il sito Wai, ci sono altre risorse online che ci potrebbe consigliare?

Gestisco il Web AccessiBlog [nuova finestra], un Weblog di link ad altri siti che trattano di accessibilità. Dovrei aggiornarlo più spesso (ho davvero bisogno di un sistema basato su database), ma so di sicuro che ha link a praticamente tutte le risorse attualmente disponibili in inglese (a volte anche in tedesco). C’è meno materiale disponibile su questo argomento di quello che potreste pensare.

Chiunque avesse domande relative all’accessibilità web dovrebbe iscriversi a WebAIM [nuova finestra] e alla mailing list del WAI-IG [nuova finestra]. O semplicemente chiedere a me.