In questo tipo di contesto, l’alt text è davvero indispensabile? L’argomento viene trattato in maniera molto interessante su Rebuilding the Web, con alcune riflessioni degne di nota.

A cosa serve il testo alternativo?

Il testo alternativo serve per comunicare lo stesso significato di un’immagine quando quest’ultima non è visibile. Questo è un concetto fondamentale: molti infatti si confondono, pensando che l’alt text serva a descrivere un’immagine aggiungendo altri significati.

Il fattore determinante è il contesto in cui viene inserita l’immagine, che ne influenza il significato.

Prendiamo un’immagine come esempio:

Se fosse affiancata dal testo “Il mio gatto dorme sempre”, un testo alternativo valido potrebbe essere “E’ su un letto a fare l’ennesimo pisolino”. Oppure se il testo fosse “Ho un gatto da 7 anni”, potrei usare come alt “Dorme spesso ed è bianco”.

Questi esempi non sono assoluti, le combinazioni possibili sono tante e non è sempre intuitivo stabilire il testo alternativo migliore per un’immagine. Chiarire il concetto non è semplice, ma se vi vengono in mente esempi migliori fatemi sapere!

Immagini senza contesto

Nel caso  di immagini non accompagnate da alcun testo invece le cose diventano più complicate, proprio perché non esiste un contesto in cui inserire il testo alternativo.

Aggiungere un alt text come “Il mio gatto mentre dorme sul letto nella casa al mare in Versilia” comunicherebbe sicuramente informazioni utili, ma nel modo sbagliato. Il testo alternativo (lo dice la parola) deve servire a trasmettere un significato equivalente, senza aggiungere dettagli non intuibili altrimenti.

E le immagini sui siti di photo-sharing?

Proprio per questo motivo l’alt text perde significato sulle community che hanno al centro di tutto delle immagini. Qual è la soluzione migliore? Non è facile dare una risposta, ma una pratica corretta potrebbe essere sfruttare i campi destinati a titolo e descrizione per spiegare la foto, lasciando l’alt vuoto.

Prendendo l’esempio di Flickr, nell’ultimo redesign l’alt delle foto è “photo”. Serve a qualcosa? Non direi, sarebbe stato meglio lasciarlo vuoto. Sono presenti però titolo e descrizione, che se usati correttamente potrebbero proprio servire allo scopo desiderato.

In un sito simile, il problema di spiegare il significato di un’immagine non è una questione di accessibilità, ma di usabilità. Non sono infatti solo gli utenti non vedenti a voler conoscere il soggetto di un’immagine: anche tutti gli altri visitatori hanno bisogno di dettagli che non sono intuibili dal contesto.

Una parte di questo problema sarà progressivamente risolto grazie all’uso della tecnologia: basti pensare al gps che ricava la posizione di una foto ed ai dati exif, che vengono già mostrati in automatico. Per quanto riguarda il resto al momento non ci sono soluzioni: solo con una descrizione testuale aggiuntiva sarà possibile avere delle pagine veramente informative, usabili ed accessibili.

Le linee guida per la realizzazione di siti accessibili da tempo hanno chiarito un punto: è fondamentale offrire ad un utente la stessa esperienza di navigazione, indipendentemente dal dispositivo utilizzato. Se fino a poco tempo fa era ovvio pensare alla navigazione da tastiera oltre a quella via mouse, l’avvento dei touchscreen ha aggiunto un altro livello di complessità.

Non si tratta di una questione banale, perché utilizzare un touchscreen è un’esperienza totalmente diversa rispetto alla navigazione tradizionale: ve ne sarete resi conto se avete uno smartphone o un iPad.

Cosa dicono le linee guida

Tra i 22 requisiti per la verifica tecnica della legge Stanca, è da sottolineare il numero 16:

Garantire che i gestori di eventi che attivano script, applet oppure altri oggetti di programmazione o che possiedono una propria specifica interfaccia, siano indipendenti da uno specifico dispositivo di input.

Ed anche un passaggio del requisito 21:

I collegamenti presenti in una pagina devono essere selezionabili e attivabili tramite comandi da tastiera, tecnologia in emulazione di tastiera o tramite sistemi di puntamento diversi dal mouse.

Indicazioni di questo tipo esistono anche nelle WCAG, sia nella loro versione 1.0 che nella più recente 2.0. Un esempio è la linea guida 9 delle WCAG 1.0: Design for device-independence.

I problemi con i touchscreen

La differenza fondamentale tra un mouse ed un touchscreen è che per il secondo non esiste mouseover. Potrebbe sembrare una banalità, ma se pensate a quanti siti utilizzano i CSS o JavaScript per scatenare un evento al passaggio del mouse, potete rendervi bene conto dell’entità del problema (menu a tendina, tooltip…).

Fino ad ora la soluzione più utilizzata consiste nel trasformare il mouseover in un ulteriore clic, anche se questo aumenta la complessità della navigazione. E’ una soluzione efficace? Sì, perché risolve il problema, ma non è detto che sia quella ottimale.

Il discorso quindi si lega anche al tema usabilità ed al design delle interfacce: è inevitabile che l’arrivo di una nuova modalità di navigazione introduca nuove variabili.

Da evitare

Sono sicuramente da eliminare o rappresentare in maniera differente:

• contenuti leggibili solo con lo stato :hover (ad esempio testi con poco contrasto rispetto al background)
• link visibili solo al mouseover, normalmente poco distinguibili dal testo semplice
• azioni correlate al mouseover su un particolare elemento (le più comuni sono modifica e cancella)

Uno sguardo al futuro

I touchscreen sono ormai sul mercato da anni, e la loro presenza continua ad aumentare. Tralasciando le discussioni sulla loro effettiva utilità, è logico pensare che nei prossimi anni continueremo a vedere dispositivi che li utilizzano, seguendo l’esempio dell’iPad.

In questo scenario è obbligatorio considerarne la presenza, soprattutto se si realizzano siti con interfacce fuori dal comune. Proprio questa originalità a volte può rendere un sito inaccessibile: l’importante è ricordare che non esiste solo il mouse.

La prima cosa da fare è assicurarsi che sia possibile usufruire di tutti i servizi di un sito indipendentemente dal mezzo utilizzato per navigare. I touchscreen hanno introdotto nuovi fattori, e la situazione è destinata a diventare sempre più complicata: pensate a chi sta già utilizzando la propria console di casa per navigare dal televisore, o a chi sta usando lo stesso Tv LCD per collegarsi ad internet. In futuro i dispositivi connessi alla rete saranno sempre di più: forse sarà l’occasione buona per vedere considerare l’accessibilità una necessità e non un lusso per pochi.

[Foto di bark]

In queste circostanze però c’è un dettaglio da tenere sempre presente: un sito accessibile non può prescindere dalla validazione manuale, effettuata da una persona in carne ed ossa.

Gli strumenti automatici possono aiutare in determinate circostanze, ma alcuni tipi di controlli così come la scrittura del codice devone essere effettuati da uno sviluppatore. Per alcuni requisiti infatti non esistono ancora i mezzi per sostituire la mente di un web designer ben preparato, per fortuna di chi lavora nel settore.

I tool utili

Non è comunque corretto generalizzare, perché esistono vari strumenti efficaci. Questi tool vanno presi seriamente in considerazione quando un controllo manuale richiede troppo tempo o è effettivamente impossibile: sono un esempio il controllo del contrasto dei colori, della leggibilità per utenti daltonici, e la ricerca di errori HTML in lunghi estratti di codice.

Quelli di cui non posso fare a meno sono:

Graybit

Permette di convertire un sito esistente in bianco e nero. Utilizzando solo tonalità di grigio è molto più facile capire se il contrasto di determinati elementi sia sufficiente. E’ così possibile avere un’idea di come certi utenti potrebbero visualizzare il sito in esame.

Check My Colours

Avevo parlato già della creazione di Giovanni Scala: Check My Colours è un altro utile strumento per valutare il contrasto degli elementi di un sito web. Il test è molto severo e rigoroso, e fa bene il suo dovere.

Juicy Studio Tools

Questo sito offre diversi strumenti utili: il più famoso è quello per analisi del contrasto dei colori (esistente anche come estensione di Firefox), ma non è l’unico tool disponibile. Tra quelli esistenti, segnalo Image Analyser, che unisce in modo intelligente la praticità di un test automatico con la validazione manuale, per controllare che le immagini di una pagina abbiano il testo alternativo corretto.

Come realizzare un sito accessibile?

L’obiettivo di questo post non è spiegare passo dopo passo la realizzazione di un sito accessibile, ma una considerazione è d’obbligo: la progettazione di un sito che rispetti determinati requisiti inizia fin dalle prime bozze, ancora prima della realizzazione delle proposte grafiche.

Una parte fondamentale è anche la scrittura del codice delle pagine: realizzare un template HTML rispettando gli standard del W3C è un primo passo per la realizzazione di un sito accessibile. E’ molto più difficile fare il percorso a ritroso, analizzando a posteriori un sito già esistente.

Proprio per questo motivo l’utilizzo di qualsiasi validatore automatico viene dopo l’abilità di uno sviluppatore: se il codice di un sito è ben realizzato, renderlo accessibile sarà più facile. Ricorrere a tool esterni significa che molto probabilmente sono stati commessi degli errori in passato, o si è trascurato il tema dell’accessibilità in fase di creazione per poi pagare la scelta a caro prezzo.

L’incognita più grande resta però quella riguardante i contenuti. Non serve a niente realizzare un template accessibile (vedi Stardust per WordPress), se poi chi si occupa di gestire il sito non tiene conto di determinati problemi come l’alt text delle immagini o la leggibilità dei testi. Un sito accessibile può essere tale solo se tutte le parti coinvolte sono coscienti del problema e sanno come gestirlo, altrimenti è facile ritrovarsi con un risultato scadente.

Aggiornamento: è stato pubblicato proprio in questi giorni un interessante articolo sulle checklist dei test di accessibilità automatici. L’argomento è del tutto simile a quello trattato in questo post, con alcune proposte e raccomandazioni. Le conclusioni sono simili, ma vi consiglio di leggerlo (è in inglese): Can checklist accessibility be harmful?

Gli esempi sono numerosi, basta dare un’occhiata a siti come Twitter Background Gallery: sono tanti i profili dove oltre ad un’immagine di sfondo vengono inseriti link a siti web ed altre informazioni non presenti sulla propria homepage di Twitter. Se da un lato la soluzione può essere considerata come un metodo intelligente per aggirare un limite, dall’altro non vengono considerati tutti gli utenti che non hanno la possibilità di accedere a determinate informazioni.

Mi riferisco prima di tutto agli utenti non vedenti: sono tanti ad usare Twitter, perché proprio per le sue caratteristiche di social network ridotto ai minimi termini si presta bene a determinate esigenze. Può infatti essere utilizzato in modo efficace anche tramite screen reader, potendo contare su progetti come Accessible Twitter.

Prendendo alcuni profili come esempio, si trovano numerosi account italiani e stranieri ricchi di informazioni inaccessibili nell’immagine di background.

Un esempio è la pagina di @robingood, che sulla sinistra mostra i link ai vari social network su cui è presente. L’unica informazione disponibile anche in formato testuale, è il sito principale.

La stessa cosa succede in account come quello ufficiale di @TomTom, l’azienda produttrice di navigatori satellitari. Nella pagina in questione l’errore è banale: è stato inserito nell’immagine un testo che sarebbe potuto essere replicato facilmente nella sezione “Bio”, attualmente quasi vuota.

Un altro fattore da considerare è quello della risoluzione del monitor: certi sfondi sono illeggibili anche a risoluzioni come 1280×1024 pixel. In questi casi le informazioni non solo sono inaccessibili per i non vedenti, ma anche per tutti gli utenti con un monitor nella media (o con un netbook).

Quali sono i criteri da seguire?

La pratica migliore è quella più semplice: utilizzare immagini di sfondo a scopo decorativo, aggiungendo solo le informazioni che sono già disponibili in formato testuale nella pagina. La soluzione è l’inserimento del proprio logo e dell’indirizzo del  sito web, che dovrà comunque essere presente nel box “nativo” di twitter. E’ possibile sfruttare anche il testo inserito nella sezione “Bio”, come fa Stuart Robertson: nel suo sfondo replica in maniera più elegante gli stessi testi già accessibili in formato testo.

Del resto lo dicono anche le WCAG:

Linea guida 1.1 Alternative testuali: Fornire alternative testuali per qualsiasi contenuto non di testo in modo che questo possa essere trasformato in altre forme fruibili secondo le necessità degli utenti come stampa a caratteri ingranditi, Braille, sintesi vocale, simboli o un linguaggio più semplice.

Per avere qualche altro esempio pratico, è sufficiente dare un’occhiata ai profili dei professionisti più famosi sul web, nell’ambito del web design. Veerle Pieters ha un’immagine di sfondo che riprende i colori del suo blog personale, e Jeffrey Zeldman fa altrettanto, così come Clearleft e Larissa Meek. Johnathan Snook utilizza il proprio logo, e usa il background esclusivamente come decorazione.

Se decidete di personalizzare il vostro sfondo di Twitter, cercate di farlo con cognizione di causa. La tentazione di inserire numerose informazioni è grande, ma non è detto che sia una pratica utile, e che qualcuno effettivamente utilizzi queste indicazioni. E’ da evitare soprattutto l’inserimento di elementi dall’apparenza simile a pulsanti e link: il visitatore potrebbe provare ad interagire con questi testi, scoprendo successivamente che sono solo immagini.

Queste indicazioni potrebbero sembrare esagerate, ma si tratta di avere coerenza e lavorare con criterio. Se vi preoccupate dell’accessibilità dei siti web che realizzate, è bene che utilizziate gli stessi parametri anche nella personalizzazione del profilo su Twitter.

Vuoi seguirmi su Twitter?

Il mio profilo è @tomstardust

I risultati sono importanti: non condizioneranno in maniera rivoluzionaria le abitudini dei web designer attenti a queste tematiche, ma danno un quadro completo di questa specifica categoria di utenti. Tra le note più interessanti:

• Il 66,4% utilizza JAWS come screen reader principale
• Il 49% usa abitualmente più di uno screen reader, a seconda del contesto
• Il 53% degli utenti disabili usa uno screen reader su un dispositivo mobile
• I problemi principali sulle pagine web sono dati da CAPTCHA, contenuti Flash inaccessibili e link ambigui
• Il 46% pensa che il web stia diventando più accessibile che in passato
• Social Media: il 51% usa YouTube, il 47% un blog, il 42% Facebook ed il 38% Twitter
• Twitter è giudicata la piattaforma più accessibile
• Per trovare informazioni su una pagina, il 50% scorre i titoli (h1, h2…) ed il 22% usa la ricerca interna

Uno dei dati più sorprendenti riguarda l’utilizzo di dispositivi mobili. Sicuramente è un settore in cui sono stati fatti molti progressi nell’ultimo anno, e credo che abbia avuto una buona importanza anche l’uscità dell’iPhone 3Gs con VoiceOver. Potrebbe sembrare strano, ma i dispositivi touchscreen accessibili sono ormai realtà, e se siete interessati vi consiglio di leggere recensioni come quella di Marco Zehe, che racconta la sua esperienza personale con questo smartphone.

Rispetto all’anno scorso, le raccomandazioni rimangono più o meno le stesse: le intestazioni continuano ad avere una grande importanza per l’accessibilità di una pagina web, ed uno dei problemi principali sono ancora i CAPTCHA e Flash. In certi progetti è impossibile farne a meno, ma sapere che potrebbero creare problemi è già un primo passo.

:focus {
	outline: none;
}

Potrà sembrare una soluzione elegante, ma ai fini dell’accessibilità di un sito è assolutamente sconsigliato, perchè senza outline diventa impossibile navigare tramite tastiera, o comunque con dispositivi diversi da un mouse.

Non pensate che riguardi solo una minoranza di utenti: sono tanti coloro che scorrono il contenuto di una pagina premendo il tasto tab. In molti ad esempio si spostano tra i campi di un form in questo modo: eliminando l’outline sul focus rendete il vostro sito inaccessibile.

Lo stesso Eric Meyer, autore di uno dei più famosi CSS Reset, pur azzerando questo stile raccomanda di definirne altri per sostituirlo. Il mio consiglio è di lasciarlo inalterato per evitare problemi: perchè complicarsi la vita?

Una soluzione alternativa

A volte potrebbe comunque capitare di essere obbligati a modificare lo stile dei link, ad esempio su richiesta di un cliente particolarmente insistente. Un’alternativa in questi casi è lasciare il focus inalterato ed eliminare l’outline dallo stato active:

a:active {
	outline: none;
}

Così non apparirà il bordo tratteggiato al clic, ma la navigazione da tastiera resterà comunque possibile. Non è una soluzione ottimale, ma in situazioni particolari potrebbe essere un compromesso accettabile.

Foto: Macbook Keyboard by alcomm

E’ importante che certi elementi non abbiano solo un design attraente ma siano anche accessibili: non dovrebbe esserci alcun ostacolo nella navigazione del sito, a maggior ragione sui collegamenti più importanti.

Come deve essere un “continua a leggere” accessibile?

La prima cosa da tenere presente è che il testo deve essere chiaro. Scrivere “Continua” o “Clicca qui” non serve a niente se non ad aumentare la confusione, soprattutto se considerate che in una pagina spesso possono apparire anche una decina di link con etichette del genere.

La soluzione più sicura è quella di inserire nel link il titolo del post, in modo che appaia qualcosa di simile a:

Continua a leggere “Titolo del post”

Questo però non sempre è possibile, ad esempio per questioni di spazio nel caso di titoli molto lunghi.

In questi casi è l’attributo title che fa la differenza. E’ infatti l’unico modo per rendere il collegamento autoesplicativo, anche se letto al di fuori del proprio contesto. Basti pensare all’utente che con uno screen reader scorre tutti i link della pagina: senza title si troverebbe una serie di “Continua a leggere” assolutamente senza senso.

Ecco quindi una forma corretta:

<a href="#" title="Continua a leggere &quot;titolo del post&quot;">Continua a leggere</a>

Gli esempi da evitare

Non è possibile descrivere tutti gli esempi errati di utilizzo, ma alcuni casi sono più evidenti di altri. Tra gli errori da evitare ci sono sicuramente:

• i link “continua”, “clicca qui”, “leggi tutto” senza attributo title
• i link senza testo, come [...]
• i pulsanti “continua a leggere” realizzati con delle immagini, senza attributi alt o title
  

Per evitare di commettere errori banali, che potrebberò però far diventare il vostro sito inaccessibile, è sempre meglio curare dettagli come questi. Sono particolari apparentemente insignificanti, che però possono comportare gravi difficoltà nell’esperienza di navigazione.

Seguire queste raccomandazioni non richiede molto tempo: aggiungere l’attributo giusto o utilizzare il testo corretto è un lavoro da fare una volta in massimo 5 minuti, che eviterà problemi agli utenti rendendo il vostro sito più accessibile.

La scelta dei colori di una pagina web è uno degli elementi da considerare per avere un sito accessibile. Non è sufficiente tenere conto di alcune problematiche come il daltonismo o altri disturbi della percezione dei colori: esistono infatti numerose circostanze per le quali alcune scelte sbagliate potrebbero rendere un sito inaccessibile.

Basti pensare alla visualizzazione di una pagina senza CSS o con le immagini disabilitate: non avere dichiarato alcuni colori potrebbe rendere illeggibili alcuni testi.

In queste situazioni può tornare utile l’utilizzo di strumenti automatici: Check My Colours è un tool ancora in beta, realizzato dall’italiano Giovanni Scala, che promette molto bene.

Alcune domande all’autore

Per approfondire questa segnalazione ho voluto fare un paio di domande al suo creatore, anche per comprendere le ragioni della nascita di Check My Colours.

Come mai hai voluto creare un’applicazione di questo tipo pur esistendo già altre alternative simili?

Sin da quando ho iniziato a sviluppare siti ho sempre cercato di rendere i miei lavori pienamente accessibili per chiunque, sia dal punto di vista tecnico che umano. Quindi ho pensato che un’applicazione simile sarebbe stata d’aiuto.

Sì, è vero, esistono diversi tool simili, ma ad ognuno di questi manca “qualcosa”:

• Quasi sempre permettono di verificare solamente il CSS esterno. CheckMyColours verifica i colori di ogni singolo elemento del DOM, siano essi definiti in un foglio di stile esterno o all’interno della pagina HTML. Questo approccio oltre ad essere più completo, permette di avere un rapido quadro della situazione della propria pagina (una sola scelta errata dei colori nel css può rendere illegibile centinaia di links… Gli altri “validatori” segnalerebbero comunque un solo errore…)
• Non tutti gli strumenti attualmente online utilizzano gli algoritmi ufficialmente suggeriti dal consorzio W3C.
• Alcuni tools richiedono l’installazione locale, e quindi sono utilizzabili solamente su determinati sistemi operativi

Gli obiettivi principali di questa applicazione sin dall’inizio sono stati:

• avere come target principale i web designers. Fare una sola cosa, farla bene.
• facilitare le operazioni di controllo di una pagina già online
• ottenere risultati semplici da consultare
• fornire mezzi per la scelta dei colori in fase di sviluppo (il color picker)
• renderla utilizzabile su qualsiasi sistema operativo
• renderla utilizzabile su qualsiasi browser

Prevedi degli aggiornamenti per il futuro? Stai lavorando già a delle modifiche?

Ovviamente questo è solo l’inizio. L’attuale versione online è ancora in fase beta. Sto ricevendo diverse mail di segnalazioni, proposte, consigli, e certamente ne terrò conto. Una bozza di roadmap creata al volo potrebbe essere:

• correggere gli eventuali problemi della versione beta
• stilare delle FAQ
• migliorare il color picker
• creare un’area blog per aggiornamenti sull’applicazione e
• discussioni legate all’accessibilità.
• ottimizzare l’utilizzo su iPhone e altri dispositivi mobili
• permettere il salvataggio su pdf del report

Potete provare subito Check My Colours, tenendo presente che è in costante sviluppo. Se avete dei suggerimenti o delle proposte da fare, non esitate a contattare l’autore dal sito dell’applicazione.

Evitare il display:none

Un metodo diffuso, che però è sbagliato, è utilizzare display: none per nascondere totalmente la parte di codice desiderata. Questa tecnica è inaccessibile, perchè elimina l’elemento dalla pagina come se non esistesse. La maggior parte degli screen reader trovando un elemento con display: none lo salterà senza leggerlo.

Pensate all’intestazione di un sito ed ai link per facilitare la navigazione nascosti in questo modo: non facendoli leggere agli screen reader l’accessibilità della pagina viene compromessa.

Trovate anche un approfondimento sul comportamento degli screen reader in questo articolo di Roger Johansson.

La soluzione con position:absolute

La soluzione più semplice è utilizzare position: absolute invece di display: none:

.skip {
position: absolute;
left: -9999px;
}

In questo modo gli screen reader continueranno a leggere l’elemento nascosto. Per migliorare ulteriormente l’accessibilità della pagina con un occhio di riguardo alla navigazione da tastiera, è utile un’aggiunta del tipo:

.skip a:active, .skip a:focus {
position: absolute;
left: 1em;
}

Così usando il tasto tab per spostarsi tra i collegamenti della pagina, gli elementi nascosti appariranno quando selezionati.

L’alternativa: text-indent

Una soluzione alternativa per nascondere un elemento della pagina può essere la proprietà text-indent, con un valore negativo:

.skip {
text-indent: -9999px;
}

Questo metodo a volte viene usato per mantenere l’elemento contenitore nella pagina, facendo sparire solo il suo contenuto testuale. E’ da verificare nei vari casi il supporto dei browser, ma tutti quelli più importanti non dovrebbero avere problemi.

Testo nascosto con JavaScript

Un ultimo aspetto da considerare è la gestione di elementi della pagina che appaiono solo dopo un’azione dell’utente, usando JavaScript. E’ sbagliato nasconderli con i CSS: se questi elementi (ad esempio un menu a tendina) appaiono grazie a JavaScript, devono essere nascosti al caricamento della pagina secondo lo stesso principio.

La tecnica più semplice è usare JavaScript per assegnare una classe all’elemento desiderato e quindi nasconderlo (senza usare display: none!) tramite CSS.

E’ importante comprendere i problemi relativi al display: none descritti in questo articolo. Usandolo con cognizione di causa eviterete dei problemi ai vostri utenti: se conoscete altre soluzioni valide i commenti sono a vostra disposizione.

Come effettuare dei test?

Proprio in questi giorni ha parlato dell’argomento anche Roger Johansson, citando due interessanti articoli in inglese che spiegano dettagliatamente i passi da seguire:

• Configuring your machine for testing with a screen reader
• Setting up a screen reader test environment

Le istruzioni sono semplici, anche perchè i software da utilizzare sono gratuiti. Personalmente vi consiglio JAWS, quello più diffuso, che può essere usato gratuitamente in sessioni di 40 minuti.

Questo il necessario:

1. Una virtual machine per avere un ambiente di test isolato dal resto, che può essere facilmente messo in standby e ripristinato quando serve
2. Un browser che supporti le WAI-ARIA, come Firefox 3 o il futuro Internet Explorer 8
3. Una configurazione ideale dello screen reader scelto, per la quale vi consiglio di seguire il link segnalato in precedenza

Cosa pensano gli utilizzatori di screen reader?

Sperimentare il funzionamento di uno screen reader può servire anche a capire meglio i risultati del sondaggio di WebAIM, effettuato con circa 1100 utenti.

E’ un documento importante per comprendere le caratteristiche di un sito accessibile. Non sempre è facile trarre conclusioni univoche, perchè ogni utente ha le sue preferenze personali, ma alcuni dati sono indicativi: basti pensare che Flash è stato considerato un ostacolo difficile da comprendere dal 71.5% dei partecipanti, e che il 76% usa i titoli (headings) per muoversi nelle pagine.

La qualità dei vostri siti potrebbe migliorare anche con delle piccole modifiche: perchè non fare un test con uno screen reader?