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:

Informazioni su redazione

www.gargano.it

Pubblicato il dicembre 13, 2010, in Comunicazione con tag , , . Aggiungi il permalink ai segnalibri. Lascia un commento.

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: