Accessibilità

Notizie e suggerimenti pratici per un web accessibile a tutti. L’accessibilità della rete è un dovere dei designer e un bene condiviso.

Touchscreen e accessibilità

Siti accessibili ai touchscreen ed alcune implicazioni della loro diffusione.

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]

Gli strumenti per valutare l’accessibilità di un sito servono davvero?

Elenchi di tool più o meno utili, validazione del codice e accessibilità di un sito web. Come orientarsi?

Navigando su internet spesso capita di imbattersi in nuovi tool per valutare l’accessibilità di un sito. Non mancano post che presentano liste infinite di strumenti utili per rendere un sito “accessibile”, e che promettono di dare un contributo alla causa con pochi click.

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?

Background accessibili per Twitter

Inserire informazioni testuali in un’immagine è davvero la cosa migliore da fare?

Per chi utilizza Twitter, personalizzare la propria pagina è un ottimo modo per distinguersi dalla massa, ma ultimamente si sta diffondendo una pratica che più di una volta mi ha lasciato perplesso: l’inserimento di informazioni testuali all’interno dell’immagine di sfondo.

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

Il Web per non vedenti: qual è il giudizio degli utilizzatori di Screen Reader?

Un sondaggio rivolto ad utenti di Screen Reader mostra qualche sorpresa ed i progressi del web mobile.

WebAIM ha pubblicato i risultati di un recente sondaggio (Ottobre 2009), tra 665 utilizzatori di screen reader. E’ la seconda edizione di questo sondaggio: ne avevo infatti già parlato l’anno scorso, in un articolo sull’utilizzo dei lettori di schermo per effettuare test di accessibilità.

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.

Link accessibili da tastiera

L’importanza di mantenere l’outline sui link, anche utilizzando dei CSS di reset.

Apple KeyboardUna pratica fin troppo diffusa, spesso derivata dall’uso di CSS di reset, è quella di eliminare l’outline dai link e dagli altri elementi attivi di una pagina per scopi puramente estetici, con poche righe di codice:

: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

Come rendere accessibili i link “continua a leggere”

Alcune indicazioni per migliorare l’accessibilità dei link “continua…” sulle pagine di un blog.

Un elemento spesso presente su siti e blog è il link “continua a leggere”, che dall’homepage consente di approfondire la lettura dei post. Pochi giorni fa anche Smashing Magazine ha dedicato a questo elemento un’intera galleria di esempi, ma è stato considerato soprattutto il lato estetico, trascurando altri aspetti come l’accessibilità.

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.

Check My Colours: come analizzare il contrasto dei colori di un sito

E’ nata una nuova applicazione per analizzare i colori di una pagina web. Ecco qualche domanda a chi l’ha sviluppata.

Check My Colours

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.

Nascondere un elemento con i CSS in modo accessibile

I problemi nell’utilizzo del display:none e le alternative possibili.

Nella realizzazione di un sito è ricorrente la necessità di nascondere elementi presenti nel codice HTML: basti pensare agli skip link o alle tecniche di image replacement. Ci sono diversi modi per farlo con i CSS, ma non tutti sono corretti.

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.

Uno Screen Reader per i test

Tutto il necessario per effettuare dei test con uno screen reader sul proprio computer.

Utilizzare uno screen reader per i test sul proprio computer è fondamentale: se non ne avete mai sperimentato uno vi consiglio di farlo. E’ difficile rendersi conto di cosa voglia dire finchè non si prova personalmente.

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:

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?

Il costo di un sito accessibile

Quanto costa l’accessibilità? Un’analisi dei fattori da considerare nella creazione di un sito accessibile.

Realizzare un sito accessibile ha dei costi, inutile negarlo. Che ci sia da creare un nuovo sito o adattarne uno esistente, non è un’operazione fattibile senza spese, nonostante sia in vigore una normativa come la Legge Stanca che è stata proprio approvata come a costo zero.

Su questo blog l’intervista ad Elena Brescacin, una sviluppatrice non vedente, è stata l’occasione per tornare sull’argomento ed è quindi giusto approfondirlo.

Il costo dipende dal progetto

Sembra una banalità, ma quando si parla di accessibilità molti si tirano indietro immaginando spese enormi. In realtà non è così: si tratta di un investimento. Realizzare un sito che segua gli standard web e sia accessibile non è sempre così complicato o dispendioso in termini di tempo come si potrebbe pensare.

Ovviamente per portali complessi il discorso cambia, ma parlando di blog, siti statici e progetti senza enormi pretese è possibile ottenere facilmente ottimi risultati. Cosa serve? Un team di lavoro (o uno sviluppatore) competente, che conosca gli standard del W3C e realizzi siti accessibili come se fosse una regola, non un’eccezione. L’accessibilità è anche questione di professionalità.

C’è una grande differenza anche se il progetto deve occuparsi della creazione di un sito completamente nuovo o della ristrutturazione di uno esistente. A volte dover progettare da zero è molto più semplice e veloce.

Parlando più concretamente, in certi casi basta veramente poco perchè un sito segua i requisiti minimi: codice ben organizzato, uso coerente dei titoli h1-h6 ed una navigazione intuitiva possono essere quantificati in poche ore di lavoro.  L’accessibilità non è solo questo, ma sarebbe già un passo avanti per la maggior parte dei siti esistenti.

I costi di formazione e manutenzione

Per non essere troppo di parte, è bene comunque mettere in chiaro che un sito accessibile non resta tale se non viene mantenuto a dovere.

Posso fare un esempio pratico con WordPress: realizzare un tema accessibile non è difficile, ma chi inserisce i contenuti deve essere istruito. Il rischio altrimenti è di trovarsi un ottimo contenitore riempito di spazzatura, che renderà inutile il lavoro fatto.

Per questo motivo in un progetto serio è necessario prevedere anche delle spese per la formazione di chi dovrà occuparsi dei contenuti e per interventi di manutenzione successivi, a meno che non si parli di siti statici.

L’accessibilità è un investimento

E’ bene comunque comprendere fin da subito che l’accessibilità è una grande possibilità. Un sito accessibile segue gli standard, viene indicizzato meglio dai motori di ricerca e quindi porta migliori risultati di un sito non accessibile o ancora peggio interamente realizzato con tecnologie come Flash.

La logica conseguenza di tutto questo è che pubblicando un sito accessibile i potenziali clienti di un’azienda aumenteranno, e ci sarà anche un ovvio ritorno dal punto di vista dell’immagine.

Non è un caso che all’estero, dove la situazione è molto più evoluta rispetto all’Italia, numerose aziende abbiano capito l’importanza degli standard web e dell’accessibilità. L’etica non c’entra, perchè non è quello che interessa veramente: certe scelte sono dettate da vantaggi concreti.

Conclusioni

Ho cercato di realizzare un quadro generale sui costi di sviluppo di un sito accessibile, ma a questo punto vorrei avere anche il vostro punto di vista. Le tematiche correlate sono numerose e sicuramente possono essere approfondite: cosa ne pensate?

Dite la vostra nei commenti, anche se non avete esperienze personali a riguardo ogni contributo è ben accetto.