Accessibilità

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

Intervista ad Elena Brescacin: una Web Developer non vedente

Due chiacchiere con Elena “talksina” Brescacin sull’accessibilità della rete da un punto di vista pratico.

Elena Brescacin è una Web Developer non vedente classe 1980, con cui ho avuto l’occasione di collaborare recentemente per il suo blog personale.

Sono rimasto stupito dalla sua abilità e dalle capacità che ha dimostrato di avere, e così le ho proposto di fare un’intervista per questo sito. Le sue risposte possono essere utili più di tanti tutorial e linee guida, per far capire veramente cosa sia l’accessibilità e quanto sia importante ricercarla nello sviluppo di un sito.

Il risultato è una chiacchierata particolarmente lunga, ma quella di non sintetizzarla è stata una mia scelta. Spero che il risultato finale possa essere interessante per molti.

1. Ciao Elena, puoi fare una breve introduzione su di te?

Ciao, sono Elena Brescacin, 28 anni, cieca dalla nascita. Lavoro come web developer nel settore accessibilità dei siti web, ed ho tanti hobby tra cui la manipolazione dell’audio (realizzo jingle e suonerie), gli scacchi, l’arte marziale taekwon-do e generalmente dare una mano dove possibile ad amici blogger e webmaster.

2. Come sei diventata web developer? Quali strumenti usi per lavorare?

Ho iniziato da autodidatta nel 2000, dopo un paio di esperienze lavorative poco felici avute dopo la scuola superiore. Tramite html.it ho imparato a costruire le mie prime pagine web, il mio primo sito personale, con la possibilità di metterci gli audio e personalizzarlo a mio piacimento e soprattutto di capire che cosa gli altri sbagliassero quando i siti non erano accessibili.

L’interesse per l’accessibilità è venuto da solo, come esigenza di collaborazione tra utente disabile e sviluppatore (non c’è niente di meglio!). Poi ovviamente ho fatto dei corsi sull’argomento, e alla fine ho trovato lavoro nel mio settore.

Come strumenti, dipende dalle esigenze e dal lavoro; passo da prodotti commerciali a prodotti free, anche se la mia maggiore preferenza è per gli editor di codice, più che quelli visuali: questi ultimi mi complicano parecchio la vita in quanto le opzioni sono tutte grafica e punta-e-clicca, cosa che a un vedente aiuta, a un cieco invece crea solo problemi.

3. Quali problemi hai trovato nello svolgere il tuo lavoro, ad esempio con CMS come WordPress?

Come già detto, i problemi sono specialmente imputabili alle funzionalità degli editor visuali; io mi riferisco chiaramente soltanto alla disabilità visiva perché è quella che conosco, ma il problema riguarda tutti.

Che gli editor siano dei programmi per desktop, oppure implementati all’interno di un CMS free o commerciale, spesso gli sviluppatori non tengono conto delle esigenze di accessibilità nelle funzioni facilitate (pulsanti per aggiungere link, immagini, spostare oggetti, ecc) per cui con questi applicativi si possono realizzare siti completamente accessibili lato utente, ma lato amministratore non si riesce a fare quasi nulla.

Il risultato è che un cieco che voglia intraprendere l’esperienza dello sviluppo web, deve avere un’ottima conoscenza del linguaggio di marcatura o programmazione usato per il proprio applicativo. L’unico modo per poter gestire contenuti è quello di disabilitare l’editor visuale e scrivere il codice in formato testo, o comunque trovare degli escamotage che in quanto tali, rallentano di molto il lavoro.

Io sono una lottatrice e non mi lascio certo spaventare da un editor, però molti miei “colleghi” anche loro giovani, si sentono scoraggiati dall’esperienza del web perché costretti in qualche modo ad imparare un linguaggio, mentre i loro compagni vedenti possono sviluppare siti anche senza saper niente di codice.

Certo la padronanza di almeno un linguaggio di marcatura, scripting o programmazione, è un vantaggio perché aiuta a costruire meglio i siti e gli applicativi; di contro, lo svantaggio è che ci sono pochissimi sviluppatori ciechi e per questo l’accessibilità del web è poco sentita, considerata solo una cosa da addetti ai lavori, più che un’esigenza di molti. E le associazioni di categoria fanno troppo poco rispetto alle lacune che si dovrebbero colmare.

4. Hai un esempio pratico di problemi con l’amministrazione di WordPress?

Quando parlavo di “escamotage” posso fare un riferimento concreto: il sistema di widget di WordPress.

Nella versione 2.3 era a dir poco impossibile avere una barra laterale dinamica: i widget erano soltanto trascinabili tramite il mouse quindi mi dovevo far aiutare ogni volta.

Dalla 2.5 per fortuna hanno introdotto un link “aggiungi”, “modifica”, “rimuovi”… in modo che io posso anche da tastiera mettere e togliere i widget a piacimento. Il problema rimane nello spostarli: non posso accedere al drag&drop fattibile solo da mouse, quando basterebbe accanto a ogni widget aggiunto un paio di link “sposta su” e “sposta giù”.

L’escamotage sta nel crearsi un file di testo con tutti i nomi dei widget desiderati, poi rimuoverli tutti, e riaggiungerli uno a uno secondo l’ordine nuovo desiderato. Lavoraccio che, uno fa una volta, la seconda non lo fa più!

5. Quali sono i problemi principali con cui ti scontri navigando su internet, nonostante la tua esperienza?

I captcha.

Uno dei maggiori problemi che un cieco incontra navigando su internet, è oramai la quasi onnipresenza dei captcha, nati per impedire a chi fa pubblicità indesiderata di accedere ai vari servizi: dai semplici commenti su siti o blog, alle registrazioni su portali più complessi e piattaforme di commercio elettronico.

Talvolta questi test sono accompagnati da controlli audio, ma anche questi spesso e volentieri o sono solo in inglese, oppure non si sentono e non si capiscono. Il risultato è che le aziende che fanno pubblicità indesiderata hanno le fonti di reddito per aggirare questi controlli come vogliono, costruendo dei sistemi di calcolo sofisticati, oppure semplicemente pagando pochi dollari a studenti adolescenti ai quali, per dire, basta avere garantita ogni mese la ricarica del cellulare per compilare a mano i sistemi anti-robot.

Un cieco, da queste misure, sarà sempre e comunque discriminato per vari motivi:

  • la privacy che i captcha dovrebbero proteggere, viene nel nostro caso automaticamente violata in quanto dobbiamo dare, o far vedere, i nostri dati sensibili a terze persone. Quando si tratta di password o numeri di carta di credito, sinceramente, la fiducia vale ma sempre fino a prova contraria… per non parlare poi del fatto che ci son servizi che chiedono di compilare un test di sicurezza visuale pure per cambiare o ripristinare la password. Lasciamo stare.
  • anche trovando i siti di studenti che risolvono i captcha (onestamente ammetto di aver tentato di contattarne uno), dicono NO, in quanto loro compilano sì i captcha a 3 dollari l’uno, però devono aver la garanzia di doverne compilare almeno 100. E all’epoca me ne serviva uno.

Un altro grosso problema di accessibilità si ha quando si usano certe funzionalità AJAX, in cui i link sono cliccabili ma non sono visualizzati come tali. Un esempio è la versione standard di GMail, o molti siti di home banking, di cui posso usufruire solo navigando la pagina come se fosse un file Word anziché usare tutti i comandi rapidi che gli screen reader mi offrono.

Poi i flash che scorrono o che non hanno etichette nei controlli, i form con il focus che si muove in automatico sulle caselle di selezione o sui campi di testo, ed immagini e controlli senza testo alternativo.

6. Parlando invece di non vedenti senza la tua esperienza, com’è la situazione attuale della rete? Quali sono i problemi più diffusi?

La situazione è abbastanza difficile da due punti di vista: ci sono dei non vedenti senza esperienza che non hanno voglia di imparare e mettono in difficoltà gli sviluppatori chiedendo sempre la pappa pronta; dall’altro lato alcuni web developer pensano che la creatività venga limitata dall’accessibilità, ed i problemi continuano a rimanere.

L’unico modo per avere una rete accessibile è rispettare gli standard, evitando di “inventarsi” i metodi: ad esempio a che cosa serve creare i punti elenco con delle immagini, quando in HTML ci sono gli attributi ben definiti che permettono di mettere pure i disegnini ma lasciando la lista completamente accessibile?

Parlando dei blog, dovrebbero essere sempre accessibili anche tramite la tastiera, con la possibilità di attivare e disattivare la visualizzazione dei link non indispensabili come i tag: spesso e volentieri questi sono anche una decina per ogni articolo, il che può creare problemi (gli screen reader scorrono tutti i link di una pagina uno ad uno NdTom). Una soluzione per WordPress è in questo articolo di Studio404.

Una considerazione anche sul tabindex: viene messo come requisito di accessibilità, ma mi sento di consigliarlo quasi esclusivamente per i siti statici. In un sito dinamico come un portale o blog non si può mai avere un ordine logico definitivo e la navigazione tramite tab dall’inizio alla fine del blog è fondamentale. Usando il tabindex invece si altera l’ordine di scorrimento, ed il risultato è che un cieco non esperto viene costretto a saltare alcune parti, leggendo come minimo solo un 50% di quello che leggerebbe normalmente.

7. Ci sono dei siti “popolari” a cui vuoi rivolgere delle critiche perchè non accessibili?

Mi creano difficoltà i siti di news: ANSA, Corriere della Sera, Repubblica, Oggitreviso e altre testate giornalistiche che sono piene di Flash e pubblicità che scorrono. Un quotidiano non dovrebbe in alcun modo avere questi problemi! Benedetto chi ha creato i Feed RSS che mi permettono di leggere e scegliere i titoli che mi interessano.

8. Che consigli daresti agli sviluppatori interessati all’accessibilità dei propri siti?

Il consiglio che vale sempre è quello di attenersi più possibile agli standard del W3C, più specificamente alle WCAG 2.0 che, rispetto alla versione precedente, si riferiscono a tutte le tecnologie e non soltanto all’HTML.

Certo non si può imparare tutto a memoria, ma capire e conoscere gli standard è già un buon passo avanti. Inoltre c’è da considerare che non si può parlare di accessibilità senza citare l’usabilità; presentazione e contenuto vanno equilibrati per venire incontro alle esigenze di tutti, non soltanto alla propria creatività.

9. In conclusione, vorresti aggiungere qualcosa?

Solo che sarebbe ora di restituire al web il suo significato originale: worldwide web.

Tutti digitano www sulla barra indirizzi ma non sanno nemmeno cosa significa! La rete dovrebbe essere universale, ma oramai tutti (privati e aziende) vedono il web a modo loro senza rispettare l’accessibilità.

Ci sono situazioni in cui la mancanza di accessibilità può davvero nuocere al diritto sacrosanto di riservatezza delle persone. Basti pensare ai siti riguardanti la salute: un cieco con il bisogno di informazioni su specifici problemi medici sarà costretto a condividere per forza i problemi di salute con qualcuno, magari tutto per colpa di un captcha.

Se tutti gli sviluppatori avessero un po’ più di rispetto e sensibilità verso i fruitori delle loro creazioni, disabili o no, il web sarebbe migliore.

Web Accessibile: affrontare l’argomento in modo completo

Uno degli errori più comuni parlando di accessibilità è approfondire solo alcuni temi, correndo il rischio di confondere i propri lettori.

Icona accessibilitàL’accessibilità della rete è da tempo uno degli argomenti che mi appassiona di più, e cercare di seguire più fonti possibili sull’argomento è uno dei miei obiettivi principali. Proprio oggi mi è capitato di leggere un intervento in inglese su come rendere accessibile un sito web, intitolato “Paying attention to website accessibility“.

Il testo parla dell’importanza dell’argomento, limitando però il discorso a tre punti:

  • la conformità agli standard web del W3C
  • l’utilizzo di (X)HTML e CSS
  • l’utilizzo di JavaScript in maniera non intrusiva

Se da un lato sensibilizzare sui vantaggi di un sito accessibile è una buona cosa, post del genere rischiano di diventare controproducenti. Il pericolo maggiore è che l’accessibilità venga intesa erroneamente come l’applicazione di poche regole, quando la realtà è ben diversa.

Il rischio è soprattutto per i Web Designer con meno esperienza, che giustamente possono avere interesse ad avvicinarsi all’argomento. Basta poco per cadere in errore, soprattutto se si viene consigliati in maniera incompleta o sbagliata.

Tengo a sottolineare come la fonte citata sia semplicemente l’esempio più recente che mi sono trovato a considerare. Esistono tanti altri blog a cui potrei rivolgere le stesse osservazioni: è bene che si parli di accessibilità, ma è necessario affrontare l’argomento nel modo corretto. Un sito non diventa magicamente accessibile se il codice è valido o non utilizza le tabelle per il layout, così come non basta inserire i testi alternativi sulle immagini. Questi sono solo alcuni dei numerosi aspetti che aiutano a raggiungere l’obiettivo.

Gli argomenti da affrontare

Per chi volesse approfondire l’argomento, ho raccolto i collegamenti al materiale indispensabile: se doveste notare delle mancanze aspetto come sempre i vostri suggerimenti nei commenti.

Ecco le risorse principali da considerare:

Altri siti utili:

In conclusione, è bene parlare di web accessibile soprattutto perchè l’argomento non ha ancora l’attenzione che merita, ma va fatto con cognizione di causa. L’ambito è vasto ed affrontarlo in unica volta non è un’impresa facile.

Se non si ha la possibilità di approfondire a dovere tutti gli aspetti, in certi casi è meglio scrivere un post su un argomento più specifico: ci sarà sempre tempo per parlare del resto, senza il pericolo di confondere chi legge.

Come scrivere il testo alternativo sulle immagini

La realizzazione di un sito accessibile passa anche per gli attributi alt delle immagini: ecco come rispettare legge Stanca e WCAG 2.0

Uno dei primi punti da osservare per la realizzazione di un sito accessibile è l’utilizzo di testi alternativi sui contenuti non testuali come le immagini. Potrebbe sembrare un compito facile da assolvere, ma non è sempre così, soprattutto perchè a seconda delle situazioni le soluzioni possibili cambiano radicalmente.

Legge Stanca e WCAG 2.0

La normativa italiana e le linee guida del W3C sono molto precise a riguardo, questi sono gli enunciati:

Legge Stanca, requisito n°3

Fornire una alternativa testuale equivalente per ogni oggetto non di testo presente in una pagina e garantire che quando il contenuto non testuale di un oggetto cambia dinamicamente vengano aggiornati anche i relativi contenuti equivalenti predisposti. L’alternativa testuale equivalente di un oggetto non testuale deve essere commisurata alla funzione esercitata dall’oggetto originale nello specifico contesto.

WCAG 2.0, linea guida 1.1

Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.

Per ogni immagine presente sulla pagina è quindi necessario fornire un’alternativa testuale: il cosiddetto alt text.

Come usare l’attributo alt

Prima di tutto è d’obbligo tenere presente che ogni immagine inserita nel codice HTML di una pagina, soprattutto con doctype di tipo XHTML 1.0 Strict, necessita dell’attributo alt. Questo serve non solo quando l’attributo ha un valore, perchè è sempre utile indicare (ad esempio agli screen reader) che l’immagine non ha un significato rilevante e può essere saltata (usando alt=””). Questo accade spesso con le immagini puramente decorative, che sarebbe comunque meglio inserire tramite il foglio di stile.

Per eliminare ogni dubbio su cosa scrivere nell’attributo alt, la soluzione migliore è porsi una semplice domanda:

“Se dovessi illustrare al telefono la pagina che stai visitando, descriveresti l’immagine e il suo contenuto?”

Se la risposta è sì, allora è bene che quell’immagine abbia un testo alternativo, altrimenti non servirà a niente. Il metodo viene direttamente da Roger Johansson, e lo trovo perfetto per casi come questi.

L’importante è ricordarsi sempre di non esagerare, perchè è facile cadere nell’errore opposto: inserire troppe informazioni (inutili) in una pagina. Rendere accessibili le immagini di un sito non significa usare testi alternativi esageratamente lunghi e descrittivi: creerebbero solamente problemi. La cosa migliore è inserirli solo dove necessario, ad esempio in immagini che contengono del testo, per far arrivare all’utente lo stesso identico messaggio.

Conclusioni

Non è sempre facile trovare il giusto testo alternativo per le immagini di una pagina web. Le soluzioni variano a seconda dei casi, ma la regola fondamentale è ricordarsi che il testo alternativo deve servire per veicolare lo stesso messaggio dell’immagine, non per descriverla.

La differenza tra le due cose in certi casi potrebbe essere sottile, ma l’importante è essere coscienti del problema e cercare di risolverlo. Un sito accessibile passa anche per questi dettagli.

Addio layout elastici?

Pro e contro dei layout con misure definite in em. Sono ancora validi o non vale la pena spendere tempo e risorse per realizzarli?

I layout elastici sono definiti in questo modo per la loro capacità di adattarsi alle dimensioni del testo di una pagina. Ingrandendo i caratteri cambiano tutte le dimensioni di conseguenza: questi layout sono infatti definiti interamente in em, unità di misura relativa. Per chiarirvi le idee potete trovare un esempio pratico su CSS Zen Garden.

Chi ha realizzato un layout elastico sa quanto lavoro comporti, ma come sempre prima di cimentarsi in pratiche dispendiose è sempre bene valutarne pro e contro.

Conviene ancora realizzare siti interamente in em?

La domanda sorge da un dato di fatto: tutti gli ultimi browser offrono la possibilità di ridimensionare le pagine con un effetto zoom. In questo modo anche i layout a larghezza fissa non presentano grandi problemi, ancora meno le altre tipologie.

I layout elastici hanno sempre avuto la fama di essere accessibili e utili per l’utente che desidera personalizzare la dimensione dei caratteri, ma allo stato attuale l’unico browser che ottiene un vantaggio netto da questo tipo di design è Internet Explorer 6.

Mettendovi nei panni di un utente con problemi di vista o con la necessità di ingrandire il testo, cosa fareste? Molto probabilmente usereste un browser con la possibilità di zoomare le pagine, o un ingranditore di schermo, non IE6. E’ così assurdo come ragionamento? Non credo.

Per questo i layout in em ormai si stanno avviando verso l’estinzione. Considerando anche i tempi di sviluppo ed il rapporto costi/benefici, ormai non conviene più realizzare siti simili, a meno che non si abbia un ampio target di utenti utilizzatori di Explorer 6. Non esistono certezze assolute, ma a distanza di 5 anni dallo storico articolo di A List Apart sui layout elastici, è ormai tempo di metterli da parte per la maggior parte dei casi, tenendoli comunque presenti per le necessità impreviste.

Slideshow e gallerie di immagini accessibili

Le migliori soluzioni JavaScript per realizzare gallerie di immagini accessibili, utilizzando i framework jQuery e Mootools.

Dall’uscita di Lightbox le soluzioni JavaScript per realizzare gallerie di immagini si sono moltiplicate: le scelte a disposizione sono innumerevoli, ma non è solo l’aspetto estetico quello che conta. Molto spesso gli script disponibili in rete sono fin troppo pesanti per il loro scopo, o non tengono presenti gli standard minimi per quanto riguarda l’accessibilità dei contenuti.

In questo articolo troverete una selezione di alcuni effetti che consentono di creare gallerie di immagini accessibili: non intrusivi, degradano nel modo giusto se JavaScript è disabilitato, e si appoggiano a framework già collaudati come jQuery e Mootools. Potrebbero essere migliorati ulteriormente, ma sono un’ottima base di partenza.

SmoothGallery

Soluzione basata sulla libreria Mootools, consente di creare slideshow di immagini mettendo a disposizione vari parametri come lo scorrimento automatico ed il tempo riservato ad ogni fotografia. E’ possibile anche avere più set di immagini nella stessa galleria: funzione comoda per risparmiare spazio nella pagina.

In assenza di JavaScript, le immagini appaiono comunque precedute da titolo e descrizione. Il difetto riguarda i controlli, non è infatti possibile scorrere le foto da tastiera.

Slideshow 2

Un buon set di effetti a disposizione anche per questo script basato sul framework Mootools, che può essere a sua volta esteso con altre funzionalità, come l’anteprima delle immagini con Lightbox.

Notevole la realizzazione degli esempi: disabilitando JavaScript le funzionalità restano le stesse, spariranno semplicemente le transizioni. Ottimi anche i controlli, non c’è alcun problema a spostarsi tra le immagini utilizzando anche la tastiera.

Galleria

Probabilmente il migliore tra quelli presentati, questo script si basa su jQuery e pesa solamente 4kb. Non è intrusivo, degrada senza problemi in assenza di JavaScript o con i CSS disabilitati e può essere personalizzato facilmente anche nell’aspetto. Le immagini sono organizzate in una lista nel codice HTML: una soluzione ottimale.

Notevole anche l’efficienza dello slideshow, perchè le foto vengono caricate e mostrate solo quando disponibili, evitando attese nel momento dell’interazione.

Se conoscete altre soluzioni accessibili per la creazione di gallerie di immagini segnalatele nei commenti, è sempre utile conoscere le migliori risorse in questo ambito. Potete trovare altri script nel mio precedente post dedicato a Lightbox ed ai suoi cloni: se comunque volete uno slideshow accessibile il mio consiglio è di partire dagli script appena illustrati.

Dichiarazione di accessibilità: come scriverla

Suggerimenti utili per scrivere una dichiarazione di accessibilità evitando gli errori più comuni.

In molti siti e soprattutto in quelli che si preoccupano di essere accessibili, spesso viene inserita una dichiarazione di accessibilità per illustrare la conformità delle pagine agli standard in vigore.

Fondamentalmente una pagina autocelebrativa non serve a niente, soprattutto perchè inserirla non rende un sito automaticamente accessibile. Fornire informazioni utili ai propri visitatori resta comunque una buona idea, soprattutto se questo porta ad una migliore esperienza di navigazione.

Alcuni suggerimenti utili

Scrivendo una dichiarazione di accessibilità si possono commettere diversi errori. I consigli più semplici da imparare e da tenere sempre presenti sono:

  • Non addentrarsi troppo in dettagli tecnici che la maggior parte degli utenti non potrà capire: parlare di CSS, attributi alt sulle immagini, testi in em e progressive enhancement non serve a niente.
  • Mettere bene in evidenza un recapito per segnalare problemi ed errori.
  • Realizzare una pagina bene organizzata: è fondamentale suddividere le sezioni della dichiarazione con dei titoli, ad esempio parlando di navigazione, testi, collegamenti, ecc.
  • Non nascondere il collegamento: va bene inserire un link nel footer, ma non rendetelo invisibile, altrimenti tutti i presupposti di un sito accessibile spariranno fin dalla vostra dichiarazione di conformità agli standard.

Tenete comunque presente che non è obbligatorio inserire una pagina dedicata alla dichiarazione di accessibilità, anzi. Se il vostro sito è ben realizzato, nella maggior parte dei casi non avrete alcun bisogno di mettere in evidenza il vostro buon lavoro. Un sito è veramente accessibile quando gli utenti sono in grado di navigarlo senza nessun suggerimento da parte vostra.

A tale proposito proprio su questo sito non ho deciso di inserire una vera e propria dichiarazione di accessibilità, ma un semplice testo esplicativo nel footer. Nel caso ci siano problemi o gravi errori, il mio invito è sempre quello di contattarmi per segnalarli.

WCAG 2.0: le nuove linee guida

La seconda versione delle WCAG raggiunge lo stato di Proposed Recommendation: ecco tutto ciò che occorre sapere sulle nuove linee guida.

Dopo aver atteso a lungo, il 3 Novembre 2008 le WCAG 2.0 hanno raggiunto lo stato di Proposed Recommendation: il rilascio finale è questione di poco tempo, si parla di fine anno.

Sono passati diversi anni da quando è iniziato lo studio di una seconda versione per linee guida del W3C: basti pensare che le WCAG 1.0 risalgono al 1999. Già nel 2006 affrontai l’argomento su questo blog, parlando della presa di posizione di Joe Clark sulle pagine di A List Apart; da allora sono stati fatti diversi passi avanti, già evidenti al raggiungimento dello stato di Candidate Recommendation nel Maggio scorso.

12 linee guida

Le WCAG 2.0 sono costituite da 12 punti. In questi criteri vengono riassunte tutte le problematiche relative all’accessibilità, con l’obiettivo di dare indicazioni generali, non legate ad una particolare tecnologia o dispositivo. L’obiettivo viene così raggiunto senza perdersi in linee guida troppo specifiche e limitanti.

Ognuno dei 12 punti è poi suddiviso in 3 (o meno) livelli di conformità: le già famose A, AA, AAA, che servono ad indicare quali siano le priorità.

Cosa cambia dalle WCAG 1.0 alle WCAG 2.0

Chi da sempre si preoccupa di realizzare siti accessibili indipendentemente dai requisiti obbligatori e dalle linee guida può rimanere tranquillo. L’obiettivo delle WCAG 2.0 è proprio quello di avere delle indicazioni universali, indipendenti dalla tecnologia e dal dispositivo utilizzati: se vi siete preoccupati di realizzare dei siti accessibili preoccupandovi dei problemi reali e non semplicemente di seguire delle regole, molto probabilmente non dovrete cambiare niente.

Se volete approfondire il discorso e scoprire le differenze, è comunque disponibile una bozza comparativa tra tutti i checkpoint delle WCAG 1.0 e delle WCAG 2.0 appena pubblicate.

Risorse utili

Per non rimanere disorientati dall’enorme documentazione disponibile, ecco alcuni punti di riferimento per capire meglio e poter seguire senza problemi le WCAG 2.0:

  • L’accessibilità è 2.0: un ottimo articolo di Punto Informatico sulle nuove linee guida.
  • Understanding WCAG 2.0: una guida del W3C per capire ed implementare ogni singolo punto delle WCAG.
  • Techniques for WCAG 2.0: tutte le informazioni tecniche necessarie per osservare i requisiti, facendo riferimento a HTML, CSS e altri linguaggi. Interessanti anche gli esempi relativi al mancato rispetto delle linee guida.
  • Accessible forms using WCAG 2.0: una guida completa per realizzare form realmente accessibili

Se conoscete altre risorse utili disponibili, segnalatele e provvederò ad aggiungerle in questa pagina.

Testimonianze di accessibilità in Italia

Marco Bertoni pubblica sul suo blog importanti testimonianze sul tema dell’accessibilità della rete.

Da tempo chi si occupa di rendere il web un luogo sempre più accessibile si è trovato di fronte muri difficilmente superabili, spesso basati su un’ignoranza diffusa. In quest’ultimo periodo non è stato bello venire a sapere anche della chiusura dell’ufficio del CNIPA: ma queste tematiche sono davvero così importanti per il web?

La risposta è una sola: assolutamente sì.

La voce dei professionisti che vogliono rendere la rete un luogo accessibile a tutti continua nonostante tutto ad alzarsi, e nascono iniziative degne di attenzione.

In questi ultimi giorni, Marco Bertoni ha riservato uno spazio sul suo blog ad una serie di testimonianze di persone direttamente coinvolte nell’argomento. Sono in molti coloro che da anni si preoccupano di realizzare siti realmente accessibili, non solo per soddisfare una legge o alcune linee guida.

Così troviamo la lettera di Marco Pandolfi, che ha lavorato al sito del comune di Civitanova Marche, ed afferma:

[..] penso che chiusura o non chiusura dell’ufficio, dobbiamo continuare a diffondere questo tipo di cultura, senza aspettare che le leggi ce lo impongano. Io l’ho presa come una “mission”.

Segue la testimonianza di Carlo Poggi, che lavora nella redazione ligure del sito internet dell’Agenzia delle Entrate:

[..] quotidianamente mi adopero per suggerire ai colleghi come scrivere/pubblicare contenuti accessibili. [..]

E’ possibile leggere gli interventi raccolti seguendo questi collegamenti:

La speranza è che gli interventi raccolti da Marco continuino ad aumentare. E’ difficile andare contro corrente, combattendo la convinzione (sbagliata!) che rendere un sito accessibile sia un inutile spreco di tempo e risorse, ma non è un’impresa impossibile.

Sarebbe sicuramente più facile con l’aiuto di un intervento dall’alto, ma ognuno in questo momento può dare il suo contributo, senza bisogno di attendere oltre. Riunire le voci esistenti serve a far capire che l’argomento accessibilità non è mai stato sottovalutato, soprattutto da chi crede che accedere alle informazioni della rete sia un diritto di tutti.

L’accessibilità per i daltonici

Dal daltonismo agli altri disturbi della percezione dei colori: consigli e link utili per realizzare un sito accessibile.

Il daltonismo è spesso considerato l’unico problema nella visione dei colori, e nella relativa incapacità di distinguere il rosso dal verde.

In realtà la problematica è più ampia e complessa. Le percezioni possibili dei colori sono varie e riguardano buona parte della popolazione: l’8% dei maschi e l’1% delle femmine. Il daltonismo è solamente quella più diffusa, ed i colori problematici non sono solamente il rosso ed il verde.

Ragionando in termini percentuali, è comprensibile come la realizzazione di un sito accessibile anche a questa categoria di persone sia fondamentale.

Per non avere problemi a riguardo esistono da tempo gli standard web definiti dal W3C: i colori del testo e dello sfondo devono avere un sufficiente contrasto, sia per tenere conto delle persone che percepiscono i colori in maniera differente, che per la visione su schermi monocromatici.

Strumenti per la scelta dei colori

Fortunatamente esistono diverse risorse per poter realizzare siti che siano accessibili e attenti anche a queste tematiche. Tra i collegamenti più utili:

  • Colorblind Web Page Filter: un tool utilissimo per visualizzare una pagina esistente con diversi filtri attivi, ad esempio cecità al verde e rosso, o al blu e al giallo.
  • Ruota dei colori accessibili: scelti due colori, il risultato indica se il contrasto è sufficiente e se la combinazione è accessibile a tutti.
  • Colour Contrast Check: così come il tool precedente, indica se la combinazione di due colori selezionati rispetti gli standard indicati dal W3C. Segnala anche se i colori si avvicinano al valore corretto.
  • Colour Contrast Analyser (estensione per Firefox): un’estensione (installabile solo se registrati su addons.mozilla.org) per il browser di casa Mozilla che consente di risparmiare tempo nell’analisi del DOM di una pagina. Utilizzandola viene mostrata una tabella con tutte le combinazioni di colori di testo e background presenti, indicando se superano i requisiti minimi. Attenzione: non tiene conto delle immagini di sfondo e degli stati :hover nel CSS.
  • GrayBit: un tool che converte una pagina esistente in bianco e nero, per poter verificare se tutti i testi sono leggibili anche in versione monocromatica.
  • Contrast Analyser 2.1 (software): un semplice programma per Windows e Mac che consente di controllare il contrasto tra due colori specificati. Interessante la differenza di valutazione tra font di diverse dimensioni.

Raccomandazioni e consigli finali

Anche se la scelta di una combinazione di colori accessibile può sembrare un compito semplice, è necessaria attenzione soprattutto per i dettagli, che spesso fanno la differenza.

Un esempio può essere il contrasto tra testo ed immagini di sfondo, frequentemente trascurato. Altro caso è quello del mouseover: capita spesso di avere un contrasto sufficiente sullo stato normale dei link, per poi vedere combinazioni improponibili sugli stati :hover, :active e simili.

A volte può essere difficile mantenere un buon contrasto in tutte queste circostanze, ma per siti che si dichiarano aderenti agli standard è fondamentale che il testo sia sempre leggibile, in ogni situazione.

Concludo segnalandovi un recente test per misurare il vostro “Color IQ”: con un pò di pazienza ed un buon monitor potrete rendervi conto se avete difficoltà nella percezione dei colori.

Allarme accessibilità in Italia

Voci preoccupanti fanno presagire la chiusura di uno dei pochi punti di riferimento per l’accessibilità in Italia. Cosa fare?

Apprendo ora dal blog di Marco Bertoni che l’ufficio accessibilità del CNIPA potrebbe essere chiuso. E’ una di quelle notizie che non avrei mai voluto dare, perchè quel poco che in Italia è stato fatto in ambito accessibilità deriva proprio da lì. Sapere che molto probabilmente nessuno si occuperà più di queste tematiche è inquietante.

Per saperne di più vi rimando al suo intervento, chiarissimo nell’analisi: le cause sono da ricercare nell’ostruzionismo delle multinazionali, nel ridicolo scenario delle web agency italiane, ma soprattutto nella disinformazione. E’ assurdo ritenere l’accessibilità come un costo aggiuntivo, un lusso che può essere anche trascurato: non è così, anzi!

A questo punto per tutti coloro che sono interessati al rispetto degli standard web, alla realizzazione di siti accessibili ed usabili, al lavoro fatto con professionalità, cosa resta da fare? Ovviamente non disperarsi, perchè è sempre possibile vedere riconosciuto il proprio valore.

In Italia esistono web designer di talento, che sanno quello che fanno e non realizzano siti con Frontpage (o Dreamweaver in modalità WYSIWYG che dir si voglia). Paradossalmente però non lavorano quasi mai nelle web agency o nelle grandi aziende, a cui tali tematiche non interessano e che spesso limitano l’alta professionalità dei dipendenti per lavori di bassa qualità.

Viviamo in un paese dove determinate capacità sono viste come un extra, un costo aggiuntivo non necessario, ma non per questo bisogna smettere di crederci. Conoscete aziende interessate a web standards ed accessibilità? Io nel panorama italiano ne conto veramente poche, ma se avete dei nomi sarei curioso di saperne di più.

Sarà sicuramente difficile diffondere le proprie idee in uno scenario simile, ma come dice lo stesso Marco, anche io credo in un cambiamento che parta dal basso. Riconoscere l’importanza di certi temi in questo momento di ignoranza è un vantaggio, e va tenuto ben presente. Quando anche in Italia inizierà a sorgere l’interesse per l’accessibilità del web, molti professionisti che ora lavorano per pochi euro potranno sfruttare tutto il bagaglio di conoscenze accumulato.

Certo, sarebbe tutto più facile con un riconoscimento ufficiale, ma se nemmeno le stesse associazioni sono in grado di tutelare i disabili che rappresentano, è difficile che cambi qualcosa nell’immediato.