Il web accessibile e il progetto ARIA

Chi sviluppa siti web con particolari vincoli riguardo l’accessibilità e le tecnologie assistive è perfettamente conscio di una cosa: l’HTML non è stato originariamente progettato per creare applicazioni web. Esso si basa su una struttura ben precisa di marcatura di linguaggio, con elementi che hanno una loro specifica identificazione e funzione, e con interazioni client-server che nella maggior parte dei casi sono di natura sequenziale. Questa linearità, logica e chiarezza di struttura fa sì che, se utilizzato con criterio, l’HTML possa sopperire alle difficoltà che molti utenti disabili potrebbero incontrare nell’utilizzo e nella comprensione delle pagine web.

Utilizzare gli elementi di codice e i tags secondo la funzione per cui sono nati è sempre stato il miglior consiglio, e forse l’unico realmente valido, che i corsi sull’accessibilità e lo stesso W3C abbiano potuto dare alla comunità di sviluppatori e web designers. Perché mai utilizzare un elemento di testo, come può essere un tag <p>, formattato attraverso fogli di stile per farlo apparire come un titolo di una pagina, quando esiste un elemento ben preciso per raffigurare un titolo? Questo è solo un banalissimo esempio di come il non corretto uso semantico del codice possa provocare disagi a chi fa uso di tecnologia assistive nella consultazione del web. Nel caso specifico, se a consultare la pagina fosse un cieco che utilizza uno screen reader, leggerebbe comunque quel titolo come un paragrafo, in quanto il mezzo che si utilizza, a prescindere dalla componente visuale che l’autore avrebbe voluto dare alla pagina e al testo, riconosce la funzione specifica dei tags. Si può immaginare quindi che tipo di confusione tutto ciò possa generare nell’utente, il quale si troverebbe e cercare di comprendere un testo senza logica, proprio come se un paragrafo di un libro fosse stato scritto al rovescio.

Purtroppo però la buona regola della semanticità e sequenzialità del codice viene spesso infranta per poter utilizzare le applicazioni web di nuova generazione, quelle che cercano di arricchire l’esperienza dell’utente medio nella consultazione delle pagine web e che sono state foriere del web 2.0. La maggior parte di esse sono composte da librerie di codice JavaScript (AJAX, JQuery, Dojo ecc.) che hanno la capacità di scatenare eventi all’interno dei documenti web secondo una logica di casua-effetto. Grazie ad esse è possibile creare interazioni ed effetti di animazione intercettando gli elementi di una pagina ed associando ad essi un determinato comportamento. Il problema è che molto spesso queste librerie vanno a snaturare la funzione originaria di alcuni elementi ma soprattutto il loro funzionamento è totalmente sconosciuto alle varie tecnologie assistive utilizzate da utenti disabili.

Un sito web che propone nella sua homepage uno slide accattivante di immagini apparirà ad uno screen reader come una pagina che al suo interno ha una serie di immagini in sequenza; un menu che si apre a tendina tramite uno script in JavaScript apparirà come una semplice lista di link. In tutti questi casi se non si chiarisce nel codice che la sequenza di immagini in realtà è uno slide fotografico o che la lista dei link fa parte di un menu di navigazione, l’utente rimarrà sempre disorientato, e questi esempi forse sono quelli di natura più ottimistica.

Per far fronte a questo tipo di problema il W3C sta elaborando un progetto che prende il nome di WAI-ARIA. Il progetto non è ancora una raccomandazione ma è nello status di working draft (bozza), nonostante ciò le sue funzioni possono essere già utilizzate. In sostanza ARIA prevede l’implementazione nei browser di un sistema di parsing capace di riconoscere determinati attributi associati agli elementi HTML di una pagina web i quali hanno il compito di “spiegare” alle tecnologie assistive i ruoli e le funzioni che gli vengono associati tramite le librerie JavaScript, in modo da rendere chiaro il contenuto della pagina a chi non è capace di avere un riscontro visuale dei loro effetti. Gli ambiti di utilizzo possono variare dal semplice layout di una pagina ai particolari utilizzi dei form in essa contenuti piuttosto che alle chiamate asincrone che vanno a modificare il contenuto di una pagina altrimenti non visibile da un non vedente.

Per esempio ARIA può essere utilizzato per rendere esplicito il ruolo di alcuni contenitori che definiscono le sezioni di un documento web. Così un <div> che abbia come attributo “role=banner” renderebbe noto all’utente che quella sezione sia destinata alla pubblicità, un <div role=”navigation”> che quello spazio in realtà conterrebbe un menu di navigazione o ancora un <div role=”main”> raffigurerebbe il contenuto principale del documento. Tra gli altri attributi possibili indicati dalla bozza del W3C possono esserci anche i seguenti:  search, contentinfo, complementary, article ecc..

In un form sul quale si è costruito un effetto grafico di un misuratore di qualità, con animazione tipo lancetta di volume, ARIA può aiutare l’utente che non è in grado di vederla indicando lo specifico ruolo di ciascun tag  <input> utilizzato. Un <input aria-valuemin=”0”> puo’ indicare il valore minimo di voto da dare compreso tra sé e un <input aria-valuemax=”10”>. Attributi come “aria-labelledby” o “aria-valuetext” sono tutti finalizzati a rendere più chiaro il funzionamento del form che viene adattato per esigenze di applicazione web.

Ancora con ARIA si sarebbe finalmente capaci di far notare quale parte del contenuto di una pagina si sia modificato a seguito di un evento scatenato dall’utente che ha dato origine ad una chiamata asincrona al server . I moderni screen reader infatti, non sono capaci di riconoscere i contenuti di una pagina che si sono modificati all’interno della pagina stessa, ma danno aggiornamenti all’utente solo quando tramite link ipertestuale si va su di una nuova pagina, anche se dinamica. ARIA identifica le zone del documento che hanno contenuto variabile come “live regions” prevedendo una serie di attributi capaci di avvertire l’utente quando un contenuto di tali zone o di un menu si sia modificato “al volo”:  “aria-live” che avverte se una zona ha contenuto variabile; ”aria-atomic” che specifica se l’utente deve essere informato di tutta la parte del documento aggiornata o meno e via discorrendo.

Tutta la serie di proprietà e di attributi previsti è consultabile direttamente sulla bozza del W3C a questo indirizzo: http://www.w3.org/TR/wai-aria/

Come al solito però per poter usufruire degli effetti completi del progetto bisognerà aspettare che tutti i browser in circolazione implementino ARIA. A quanto pare al momento solo le versioni più recenti  la supportano, creando sempre problemi agli sviluppatori, i quali di fronte alle nuove norme sull’accessibilità dovranno continuare a fare salti mortali per implementare nuove soluzioni web con un compromesso di accessibilità.

Sarà inoltre interessante vedere come il progetto in questione si rapporterà al recente sviluppo dell ‘HTML 5, il quale già preve dei tag  a cui si è voluto dare un ruolo specifico di fronte all’esigenza di identificare contenuti multimediali all’interno del documento.

Marco Marasco

Fonti e documentazione:

• http://dev.opera.com/articles/view/introduction-to-wai-aria/
• http://www.w3.org/WAI/intro/aria
• http://www.alistapart.com/articles/the-accessibility-of-wai-aria/

Corsi e Ricorsi storici

 

La rincorsa dei Web Designer agli standard di marcatura del linguaggio dettati da quella grande organizzazione che è il W3C continua a non avere fine. Eppure una sorta di equilibrio con l’avvento dell’XHTML e dei CSS2 lo si era trovato, un equilibrio risultante più dalla fantasia dei designer stessi che dallo stretto attenersi alle specifiche consigliate. Tutto ciò nel nome di quella “chimera” conosciuta come “cross-browser compatibility”, la compatibilità multi piattaforma, che in teoria dovrebbe permettere la stessa, o quanto meno simile, interpretazione del lingiaggio HTML nei vari browser presenti oggi sul mercato.

I tempi in cui si ricorreva a codice Javascript o a regole di eccezione negli stessi CSS per adattare determinati comportamenti o visualizzazioni del sito web a seconda del browser utilizzato dall’utente sono pressapoco terminati. Questo grazie al grande balzo in avanti che hanno fatto alcuni interpreti di browser più diffusi. Basta pensare al famigerato Internet Explorer, che nella sua versione 8 ha finalmente colmato un gap, divenuto ormai insostenibile, che lo separava da altri prodotti come Firefox, Opera e Safari.

Tale balzo e l’ottima implementazione della semantica e dei CSS2 hanno contribuito alla produzione di codice HMTL meno “cervellotico” e più manutenibile, che ha permesso agli sviluppatori, forti della loro esperienza, di avere più meno lo stesso risutlato sulle varie piattaforme, facendo risparmiare tempi di produzione in precedenza ancorati a stressanti test di compatibilità del sito web.

L’annuncio in pompa magna da parte del W3C dell’imminente approvazione delle nuove specifiche dell’HTML5 ha destato grande interesse nella comunità degli sviluppatori, interesse purtroppo anche accompagnato da un timore: rompere l’equilibrio trovato e tornare al punto di partenza. In rete si trovano tantissimi articoli sulle novità introdotte da questo aggiornamento del linguaggio, uno degli aggiornamenti che ha richiesto più tempo di tutti i precedenti e che allo stato attuale non ha ancora raggiunto lo status di raccomandazione ufficiale del W3C. Inviti a testare le nuove funzionalità multimediali e non, pongono in fermento chi si occupa di HMTL da anni e le promesse di semplificare e di oltrepassare vecchi limiti del linguaggio di marcatura contribuiscono a mitizzare questa rivoluzione annunciata. Per carità, le anticipazioni e gli esempi proposti sembrano davvero rivoluzionari, ma la domanda rimane la stessa: tutti i browser saranno capaci di supportare il nuovo linguaggio? In un immediato futuro si presuppone di sì, ma allo stato attuale delle cose c’è il rischio di tornare ai tempi in cui bisoganva trovare soluzioni fantasiose per ottenere compatibilità multi-browser, considerando anche che i test attuali dimostrano come i due browser che sono più avanti degli altri sulla rincorsa dei nuovi standard HMTL5 sono Opera e Safari; decisamente non i più diffusi.

Approfondendo questo argomento è da sagnalare un articolo su A List Apart che descrive l’utilizzo di una interessante libreria Javascript che prende il nome di Modernizr. Tale libreria una volta scaricato il pacchetto .js e incorporato nei tag <head> del documento HMTL

<!DOCTYPE html>

<html>

<head>

<meta charset=”utf-8″>

<title>My Beautiful Sample Page</title>

<script src=”modernizr-1.5.min.js”></script>

</head>

…

ha l’abilità di riconoscere quale browser l’utente sta utilizzando e il suo livello di compatibilità con l’HTML5. Modernizr sarà in grado di rendere attivi tutti quegli elementi CSS3 e HTML5 inseriti dallo sviluppatore, mentre se il browser scelto non è ancora compatibile con il linguaggio, le nuove regole saranno interpretate alla vecchia maniera. Tutto ciò senza preoccuparsi di inserire regole condizionali nel css a seconda del browser che si usa, in quanto è lo stesso script che rileverà l’user-agent automaticamente. Quello che bisogna fare è aggiungere una classe al tag <html> a questa maniera:

<html>

Modernizr rimpiazzerà la classe con una nominata “js” che ti permetterà di sapere nel tuo documento se è attivato lo javascript o meno. Ma non si ferma qui: aggiungerà classi per ogni proprità riconosciuta, modificando la classe con un prefisso “no-” se il browser non supporta quell’elemento o attributo. Un esempio di elemento <html> con Modernizr è il seguente:

<html class=”js canvas canvastext no-geolocation rgba hsla multiplebgs borderimage borderradius boxshadow opacity cssanimations csscolumns cssgradients cssreflections csstransforms csstransforms3d csstransitions video audio localstorage sessionstorage webworkers applicationcache fontface”>

Notare il “no-geolocation” che dovrebbe significare il non supporto di quel browser per tale proprietà HTML5. Maggiori informazioni e documentazione comunque possono essere trovate sul sito ufficiale dello script.

A prima vista parliamo di un ottimo strumento per poter sperimentare l’attuale compatibilità dei browser, ma ancora una volta si tratta di un “trick” ben lontano dalla filosofia perseguita dal W3C. Fino a che i browser non saranno tutti allineati toccherà sperimentare e sperimentare, rendendo lo sviluppo di applicazioni web sempre più contorto. In questo caso però, non mi sento di dare tutta la colpa agli sviluppatori di browser, è verò anche infatti che lo stesso W3C, fino a quando non ufficializza le nuove specifiche, implicitamente consente alle case produttrici di browser di prendersi le tempistiche che vogliono.

Il cane continua a mordersi la coda così come accadde nella metà degli anni 90 con la guerra dei browser. A farne le spese rimangono gli sviluppatori. Un potenziale cliente bada al risultato, il mezzo per raggiungerlo tecnicamente sta agli sviluppatori stessi, e in certi casi è quasi un dovere sacrificare gli standard in favore di soluzioni che non lo sono, ma che permettono di risolvere problemi di compatibilità. Tutto ciò lo sento ancor più giustificato nel momento in cui sul mercato ci sono strumenti non completi al cento per cento nel supporto di nuove tecnologie.

A tali problematiche si aggiunge quella inerente l’accessibilità dei siti web e la garanzia del supporto dell’HTML5 alla stessa. Ciò che preoccupa è che le maggiori novità introdotte da tale linguaggio si concentrano molto su elementi multimediali del web e si spera che ciò non avvenga a discapito degli elementi di usabilità di un sito, anche se pare che negli ultimi sviluppi l’importanza semantica di un documento e la sua marcatura stia facendo la parte del leone.

La corsa continua.

“…For the times they are a-changin’…” -Bob Dylan

Marco Marasco, web developer Asernet