Il primo è usare l’attributo “for” sulla label, con un valore corrispondente all’id dell’elemento associato:

<label for="email">email:</label>
<input type="text" id="email" />

Il secondo è inserire il campo del form all’interno della label:

<label>email: <input type="text" /></label>

Personalmente preferisco il primo metodo, ma il secondo è comunque valido e riconosciuto come corretto.

Label nascoste

Un metodo molto diffuso ultimamente è quello di non visualizzare la label, inserendo un placeholder all’interno del campo, o usando JavaScript per nascondere al clic un valore che fa da segnaposto, come il classico “inserisci qui la tua email”.

Questa tecnica può essere tranquillamente utilizzata, ma non autorizza ad eliminare l’etichetta associata. La label deve essere sempre presente, anche se invisibile.

HTML5 e le label

Parlando di HTML5, il discorso è più o meno analogo. C’è un interessante articolo di Steve Faulkner sull’argomento con alcuni test pratici: HTML5 accessibility chops – form control labeling.

Dai risultati si nota come il metodo più sicuro per far riconoscere una label al browser (o a una tecnologia assistiva come uno screen reader) sia sempre l’attributo for abbinato ad un id.

Un altro metodo efficace è l’utilizzo dell’attributo aria-labelledby, che viene riconosciuto come valido:

<label id="email">email</label>
<input type="text" aria-labelledby="email">

Inserire il campo input all’interno di una label non è un metodo pienamente supportato, quindi con HTML5 è meglio evitarlo, almeno per ora.

Creare un form accessibile non è complicato, seguendo queste poche indicazioni avete tutti gli elementi per utilizzare correttamente le label. La cosa importante è ricordarsi di avere sempre un minimo di attenzione ai dettagli. Basta veramente poco per rendere un form accessibile, con qualsiasi specifica.

Come funzionano gli access key?

Associando ad un elemento di tipo a, area, button, input, label, legend e textarea l’attributo accesskey=”…” , è possibile indicare al browser una scorciatoia per raggiungere quell’elemento. Generalmente per utilizzare l’access key è necessario premere alt in combinazione con il tasto indicato.

I problemi degli access key

Il problema fondamentale è che non è mai stato definito uno standard su quali elementi di un sito debbano essere raggiungibili tramite access key. Considerando poi che non esiste nemmeno una regola su quali lettere utilizzare, il risultato è decisamente caotico.

Non solo un utente dovrebbe imparare per ogni sito degli access key diversi, ma potrebbe anche trovare dei conflitti con altre scorciatoie già definite dal sistema. Ogni browser infatti ha delle abbreviazioni predefinite per accedere ai menu (File, Modifica, ecc…), ed ognuno di loro si comporta in maniera diversa: in certi casi gli access key hanno la precedenza, in altri no.

Un altro fattore da considerare è che gli utenti utilizzatori di screen reader utilizzano molte altre scorciatoie, anche queste da aggiungere alla lista.

Inserire degli access key in una pagina non assicura quindi la possibilità di raggiungere velocemente determinati link, ma potrebbe aumentare la confusione. Se siete interessati ad approfondire il discorso, vi consiglio di leggere parte del capitolo 14 del libro “Accessibilità: guida completa” di Michele Diodati, dove questi problemi vengono descritti ampiamente. Il testo è di qualche anno fa ed alcuni esempi non sono aggiornati, ma è ancora oggi utilissimo.

Come fornire delle scorciatoie?

E’ comunque importante fornire dei metodi per muoversi all’interno di una pagina anche senza mouse. La soluzione migliore, ormai largamente diffusa, è quella di inserire degli skip link per saltare al contenuto principale di una pagina o al menu di navigazione. Solitamente queste scorciatoie sono posizionate ad inizio pagina, nascoste via CSS, e permettono a chiunque di andare immediatamente al contenuto desiderato.

Una soluzione di questo tipo è inserita anche nelle tecniche consigliate per adempiere al punto 2.4.1 delle WCAG 2.0.

La possibilità di utilizzare gli access key rimane, ma da requisito è passata a suggerimento: considerando i possibili problemi il mio consiglio è di trovare soluzioni alternative e non utilizzarli. Su questo sito ad esempio è presente uno skip link per saltare al contenuto, visibile anche premendo il tasto tab dopo il caricamento della pagina.

[foto di alcomm]

I problemi

In questo scenario, esistono numerose società che sviluppano applicazioni e tecnologie basate su un linguaggio come l’HTML: il loro nemico più grande è il codice non valido. Basti pensare a come sarebbe molto più semplice lavorare sempre su pagine validate, prive di errori e warning, anche semplicemente durante lo sviluppo di un sito web. Se però iniziano ad essere presenti errori e codici non standard, ecco che una gran parte del tempo verrà impiegato per correggere questi problemi. Se si parla poi di progetti come la creazione di un nuovo motore di rendering o di un browser, il tempo perso in questa direzione sarà ancora maggiore.

A questo proposito è illuminante un post di Rebuilding the Web riguardo al linguaggio HTML ed all’importanza della sua validità. L’autore dell’articolo racconta la sua esperienza in una piccola azienda che progettava la realizzazione di un browser standard-compliant: era impossibile pensare di gestire tutte le eccezioni generate dal codice non valido con un piccolo team di lavoro. Per questo i motori di rendering sul mercato restano sempre gli stessi, a meno che qualche soggetto importante non decida di investire, potendoselo permettere. Anche Apple e Google hanno deciso di puntare su Webkit (open-source) per Safari e Chrome piuttosto che realizzare un proprio rendering engine: la spesa sarebbe stata troppo elevata.

Meno del 10% del web ha codice valido

La colpa di tutto questo è proprio da ricercare nella diffusione del codice HTML non valido: se l’intero web non avesse errori non ci sarebbero problemi, ma è chiaro che questa rimarrà un’utopia. In passato ci sono state anche delle discussioni sul comportamento dei browser: c’era chi proponeva di visualizzare solo le pagine con codice valido, ma questo significherebbe impedire l’accesso a più del 90% dei siti web.

I dati che si trovano sulla rete sono impressionanti:

• una ricerca del 2001 di Dagfinn Parnas, analizzando i siti indicizzati su dmoz.org, ha rivelato che solo lo 0.71% aveva codice HTML valido.
• nel 2006 Rene Saarsoo ha ripetuto lo studio, ed i siti validi erano diventati il 2.58%.
• un progetto di ricerca di Opera del 2008, chiamato MAMA, ha analizzato 3 milioni e mezzo di pagine e quelle valide erano il 4.13%.

Fortunatamente la tendenza è in aumento, ma i numeri restano ridicoli ed per ora ben poco influenti.

L’utopia di un web migliore

Con un quadro di questo genere, è facile comprendere come le conseguenze del codice HTML non valido riguardino tutti. Se utilizzate un qualsiasi browser, o a maggior ragione uno screen reader, un editor WYSIWYG o un motore di ricerca state pagando la presenza di milioni di pagine web errate. Enormi risorse continuano ad essere investite per gestire gli errori contenuti in queste pagine, ed in futuro lo scenario non sarà molto diverso.

Non esiste una soluzione immediata al problema, ma se una pagina web può essere validata senza grande sforzo, perchè non impegnarsi a raggiungere questo obiettivo? Anche questi sono costi di sviluppo da considerare, ma esistono anche dei vantaggi: una pagina valida non ha problemi ad essere visualizzata in tutti i browser e viene indicizzata senza problemi dai motori di ricerca.

Nel vostro prossimo progetto pensate seriamente alla validità del codice HTML, con un minimo di attenzione in più darete il vostro contributo per un web migliore.

[foto: Heberger Site]

Escludendo qualche rara eccezione, la maggior parte delle proprietà hanno nomi diversi e sono supportate in maniera differente a seconda del browser: questo non semplifica il lavoro degli sviluppatori. Basti pensare ad una proprietà ormai diffusa su tutti i browser (escludendo il solito Internet Explorer): border-radius. Su Firefox è necessario utilizzare il prefisso “moz-”, su Safari e Chrome bisogna anteporre “webkit-” , ed ognuna di queste forme ovviamente non è riconosciuta dal W3C.

Il risultato è che se si desidera utilizzare i CSS3 per dare ad una parte dei propri utenti una migliore esperienza di navigazione, non sarà possibile validare il foglio di stile.

Come comportarsi in questo caso? L’unica soluzione è trovare un compromesso. Su questo sito ad esempio l’unica proprietà particolare che ho utilizzato è text-shadow, ben supportata nella sua forma standard. Ho invece trascurato proprio border-radius e altre proprietà simili, che però utilizzo su altri progetti come il mio blog personale, dove sono meno rigido per quanto riguarda la validazione dei CSS.

La colpa di questa situazione è da attribuire soprattutto alla lentezza del W3C, perchè i produttori di browser stanno dimostrando una grande attenzione alle novità. Supportare certe funzionalità è comunque motivo di vanto sulla concorrenza. Non è possibile però chiedere ai produttori di utilizzare fin da subito la forma standard delle proprietà: le specifiche potrebbero cambiare prima del raggiungimento della loro forma standard.

Proprio sull’uso dei CSS3 sarei curioso di conoscere anche il vostro punto di vista: li utilizzate? Vi preoccupate della validazione del foglio di stile?

Uno dei migliori suggerimenti sull’argomento, segnalato su CSS3.info, riguarda una possibile modifica al validatore del W3C. La soluzione ideale infatti sarebbe vedere segnalate come “experimental” o “warning” le proprietà dei CSS3 ancora sperimentali, consentendone l’uso senza problemi. Gli errori sparirebbero per la felicità di tutti, ma è una speranza probabilmente troppo ottimista.

Dalle notizie della settimana appena conclusa infatti è possibile leggere:

2009-07-02: Today the Director announces that when the XHTML 2 Working Group charter expires as scheduled at the end of 2009, the charter will not be renewed. By doing so, and by increasing resources in the Working Group, W3C hopes to accelerate the progress of HTML 5 and clarify W3C’s position regarding the future of HTML.

Una decisione sicuramente importante per il futuro di chi sviluppa sul web, ma non così sorprendente come potrebbe sembrare. Ammetto di avere sperato in XHTML 2, ma i segnali colti fino ad ora non sono mai stati rassicuranti. Quest’ultima notizia è solo la conferma della strada fortemente voluta e consigliata (in modo più o meno forzato) da Google e dai vari sviluppatori di browser, che da tempo stanno spingendo per la specifica HTML 5.

Alla luce di quanto accaduto la decisione di Dave Shea, sviluppatore americano, che ha deciso di abbandonare XHTML da qualche tempo, non appare così sbagliata. Ne avevo parlato nel post “Abbandonare XHTML?”, ma in ogni caso non c’è alcun motivo di avere fretta di cambiare. Per quanto mi riguarda resto fermo sulla mia posizione: finchè HTML 5 non sarà pienamente supportato, XHTML 1.0 resterà la mia scelta principale; è semplicemente arrivato il momento di approfondire lo studio della nuova specifica per chi non l’avesse ancora presa in considerazione, visto che tra qualche tempo sarà largamente diffusa.

Come punto di partenza vi segnalo le Faq del W3C sul futuro di XHTML, ed il post “HTML 5: approfondimenti ed evoluzioni future”, dove troverete diversi link utili.

A proposito di tempi: quanto ci vorrà per vedere HTML 5 supportato da tutti i principali browser? Sicuramente qualche anno, ma la data potrebbe non essere così lontana. In alcuni casi certe funzionalità sono già ben supportate, e questo indica che gli stessi produttori hanno interesse a seguire la specifica. Non sarà comunque un cambiamento improvviso: c’è tutto il tempo per documentarsi ed approfondire.

Back to HTML 4.01 Strict for now, then HTML5 whenever that happens.

Un salto indietro di svariati anni, per tornare a realizzare pagine in semplice HTML, abbandonando una specifica ben più rigorosa come l’XHTML.

Questo cambiamento è da interpretare in proiezione futura, per via del supporto di alcuni browser (Opera soprattutto) e dell’attuale stato delle specifiche. Non è un mistero che XHTML 2 sia ancora indietro, mentre con HTML 5 sia già possibile ottenere dei risultati: ne avevo parlato anche in un articolo sui form.

La discussione per quanto riguarda l’Italia è proseguita su Edit, dove nei commenti del post Bye Bye XHTML si scontrano le due posizioni. Chi difende il web semantico e XHTML ha le sue ragioni, ma non è così incomprensibile appoggiare la semplicità di HTML 5.

E’ veramente ora di abbandonare XHTML?

La risposta a questa domanda va in controtendenza con quanto affermato da Dave Shea.

La specifica XHTML infatti è attualmente la scelta migliore.

Che senso avrebbe tornare a HTML 4? Dal mio punto di vista sarebbe un passo indietro, non giustificabile guardando al futuro. E’ lecito prepararsi a HTML 5, diversi siti lo stanno già facendo, ma il suo supporto è appena agli inizi: qualsiasi cambiamento è ancora prematuro. Ovviamente è un’opinione personale, se la pensate diversamente mi farebbe piacere discuterne nei commenti.

Il W3C ha da poco presentato la nuova versione del proprio sito, ancora in fase di sviluppo. Si tratta di un aggiornamento importante e doveroso, che va ben oltre il semplice restyling grafico. Potete vedere il nuovo sito all’indirizzo beta.w3.org.

La prima cosa che ho notato è il layout fluido, che continua a supportare elegantemente risoluzioni fino a 800×600. Il menu di navigazione inserito nella colonna sinistra è a larghezza fissa, mentre il resto del sito si adatta alla finestra del browser.

C’è uno slider JavaScript per le notizie in homepage e nel complesso il risultato è molto più ordinato rispetto a prima: è stato fatto anche un notevole lavoro di riorganizzazione dei contenuti. Sono cambiate inoltre le pagine della documentazione, come potete vedere nel caso delle specifiche XHTML 1.0.

Essendo una beta non mancano problemi, ma la direzione mi sembra quella giusta. Volendo cercare un difetto non sono molto convinto dell’ordine degli elementi nella pagina: il menu di sinistra appare prima del contenuto principale.

Se volete dare il vostro contributo, trovate maggiori informazioni su questa pagina. Ci sono anche alcune indicazioni per dei task da svolgere all’interno del sito, come cercare un tutorial HTML o la pagina dell’archivio news. Qualsiasi feedback inviato al W3C sarà ben accolto.

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.

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.

In questo contesto, sembra che negli ultimi tempi la questione abbia subito una decisa accelerata: si parla sempre più insistentemente di HTML 5 e molto probabilmente il 2009 sarà l’anno della sua affermazione.

Approfondimenti sulla specifica HTML 5

Per chi volesse saperne di più e scoprirne le basi è disponibile una Working Draft che illustra numerosi dettagli, i nuovi elementi a disposizione degli sviluppatori e l’utilizzo che ne dovrebbe essere fatto.

Inoltre proprio in questi giorni è stato pubblicato anche su A List Apart l’articolo Semantics in HTML 5 che affronta diversi argomenti, a partire dalla retrocompatibilità. Come era immaginabile, il problema principale è il mancato supporto di browser come Internet Explorer (6 e 7), mentre gli altri principali concorrenti si comportano egregiamente già adesso.

Parlando invece di nuove funzionalità, sul sempre eccellente Dev Opera è disponibile un articolo che illustra il funzionamento dei canvas, che permettono di creare della grafica direttamente in JavaScript.

In questo contesto, ci sono già stati i primi esperimenti:

• il sito di An Event Apart, realizzato utilizzando (in parte) HTML 5
• una pagina di test che comprende elementi come <header>, <nav> e <footer>, resa funzionante anche su IE grazie a JavaScript

Come è possibile vedere su quest’ultimo esempio, l’unico modo per rendere la specifica compatibile anche sul browser Microsoft è l’utilizzo di JavaScript: attenzione quindi perchè potrebbero esserci problemi per alcuni visitatori. Il modo più veloce per implementare questa soluzione è includere nella pagina questo script, tenendo presente i problemi di accessibilità.

Evoluzioni future

Allo stato attuale, è ancora prematuro parlare di HTML 5 su larga scala, soprattutto per i problemi di compatibilità citati. Dai numerosi interventi che sono stati pubblicati in questo inizio 2009 è comunque facile immaginare che sarà un anno importante per lo sviluppo della specifica.

Tenete presente però che lo stato di Proposed Recommendation è ancora lontano: qualcuno ha parlato addirittura del 2022. E’ sempre utile rimanere aggiornati sull’evoluzione degli standard web, ma le priorità attuali per un web designer sono ben altre.

La mia personale speranza è che ci sia la possibilità di continuare a vedere evolversi anche l’XHTML, ma non so quanto sarà possibile. E’ vero che anche adesso coesistono senza troppi problemi le due soluzioni, ma visto che lo stesso W3C ha voluto seguire con più convinzione una strada, non mi stupirei se questa restasse l’unica.