Questo documento è la nostra traduzione di Introduction to WAI ARIA scritto da Gez Lemon e presente su Dev.Opera all'indirizzo http://dev.opera.com/articles/view/introduction-to-wai-aria/. Ringraziamo l'autore e Opera per averci dato l'opportunità di ripubblicare questo articolo su HTML5 Today

Introduzione

L'HyperText Markup Language (HTML) non è stato progetto per creare web applications. HTML ha un set piuttosto limitato di controlli di interfaccia e si basa su un modello di comunicazione sequenziale fra client e server. Gli sviluppatori web hanno aggirato questi problemi creando i propri "widget" utilizzando JavaScript per "animare" questi widget.

Sfortunatamente, le tecniche utilizzate per risolvere questo limite hanno grossi limiti di accessibilità. Sebbene i widget web possano sembrare e comportarsi in maniera molto simile ai corrispondenti widget desktop – pensiamo ad un visualizzatore di schemi ad albero, ad esempio – il ruolo (che cosa fa il widget), lo stato (la configurazione attuale, ad esempio "checked") e altri importanti proprietà non sono accessibili a tecnologie di supporto come gli screen reader. Ciò è simile a quando si utilizza lo stile per far sembrare del testo normale un heading: è vero che il testo avrà l'aspetto di un heading ma non sarà rilevato come tale da tecnologie di supporto.

Gli aggiornamenti e modifiche di un documento, poi, spesso non sono fruibili dalle persone che utilizzano tecnologie di supporto. Queste tecnologie di solito si attendono che i contenuti web cambino in conseguenza di un evento di navigazione, come ad esempio il click di un link. Le web applications utilizzano tecnologie, tipo AJAX, che aggiornano il contenuto in background risultando così di solito "invisibili" alle tecnologie di supporto. Anche se queste possono riconoscere che c'è stato un update, poi, gli utenti non riescono ad riconoscerlo o a capire quale contenuto è stato aggiornato.

WAI-ARIA è una specifica che fornisce un metodo per specificare ruoli, stati e proprietà per widget "custom" in modo da renderli riconoscibili e utilizzabili per gli utenti delle tecnologie di supporto. WAI-ARIA fornisce anche un meccanismo per assicurare che gli utenti di queste tecnologie si rendano sempre conto di un aggiornamento nei contenuti presentati dall'applicazione.

Una breve storia di HTML

HTML è nato originariamente come sistema ipertestuale per strutturare e condividere documenti collegati. Le prime versioni di HTML specificavano dei tag, quali heading, paragrafi, liste e anchor, per aggiungere una "struttura" a documenti "lineari", testuali. La prima proposta di una specifica HTML da parte della IETF includeva anche il tag <img> per inserire elementi grafici da mostrare inline. La prima specifica formale e ufficiale fu HTML 2, basata su draft precedenti. Questa specifica introduceva i form e definiva una piccola serie di componenti di interfaccia per creare box di editing, bottoni, checkbox, radio buttons e menu e tendina. Questo piccolo set di componenti è cambiato molto poco rispetto al set che si utilizza adesso con HTML 4.01.

Il modello di comunicazione per HTML si basa su un dialogo client/server. Il client manda le richieste e può ricevere risposte, il server aspetta richieste, processa le richieste e invia risposte al client. Visto che HTML non aveva un livello "behaviour", la comunicazione si intendeva sequenziale – il cliente richiede una pagina dal sever, il server processa la richiesta e manda la pagina al client.

Web applications

Le "applicazioni web" tentano di emulare applicazioni "native" (desktop) – tranne che per il fatto che queste applicazioni web vengono eseguite all'interno di un'altra applicazione desktop – il browser. Ci sono poi altre due differenze fondamentali fra il modello di comunicazione di HTML e quello delle applicazioni "native" per desktop:

  1. le applicazioni native hanno un funzionamento che non dipende da richieste ad un server
  2. le applicazioni native hanno la possibilità di creare un'interfaccio con un set molto più ampio di componenti

Emulare applicazioni desktop native

Richieste al server in background

Per emulare nella maniera migliore possibile le applicazioni desktop, le applicazioni web utilizzando JavaScript. Per esempio, JavaScript può essere utilizzato per espandere o contrarre un menu quando l'utente ci interagisce. In certi casi alcuni dati potrebbero essere richiesti dal server. Per esempio, l'applicazione potrebbe richiedere dei record da un database e aggiornare i contenuti della pagina. Quando l'applicazione deve interagire con il server si utilizzano tecnologie quali AJAX o IFrame nascosti per comunicare con il server "silenziosamente" in background.

Emulare un'interfaccia più evoluta

Dal momento che HTML ha un limitato set di componenti di interfaccia, le web applications hanno talvolta bisogno di widget più complessi, come ad esempio un checkbox con tre possibili stati o un controllo slider. Il look'n'feel di questi widget si ottiene di solito disegnandoli in maniera grafica e aggiungendo il funzionamento con un linguaggio di scripting.


Un checkbox con tre stati possibili


Uno slider

Problemi di accessibilità con il "look and feel" emulato

Dal punto di vista visuale, emulare questi componenti di interfaccia e effettuare le richieste al server in background crea un'esperienza molto più ricca per gli utenti. Sfortunatamente, però, dal punto di vista dell'accessibilità sorgono grossi problemi in particolare per utenti che usano tecnologie di supporto quali screen reader o altro:

  • I widget costruiti con queste tecnologie avanzate quali AJAX sono spesso non accessibili da tastiera
  • Il "ruolo" (cosa fa il widget) non è disponibile alla tecnologia di supporto
  • Stati e proprietà del widget non sono disponibili alla tecnologia di supporto
  • Aggiornamenti e rilevamento di aggiornamenti non sono comunicati alla tecnologia di supporto

Meno male che c'è WAI-ARIA

Fortunatamente, tutti i problemi indicati sopra possono essere risolti da WAI-ARIA (che chiameremo solo ARIA nel resto dell'articolo). ARIA è una tecnologia che arricchisce l'esperienza dell'utente e il lavoro del programmatore – dicendogli che cosa fare piuttosto che le cose da non fare. ARIA consente ai developers di creare ricche e accessibili applicazioni web in maniera molto facile.

Navigazione da tastiera

Dopo la definizione di testo alternativo alle immagini, fornire agli utenti la possibilità di navigare il proprio sito solo con la tastiera è una delle funzionalità di base per l'accessibilità. I developers che hanno ben presenti i problemi di accessibilità costruiscono i loro widget utilizzando componenti che possono ricevere focus, come ad esempio gli elementi di input di tipo "image" (<input type="image"…>). Sfortunatamente la maggior parte dei widget non sono costruiti utilizzando componenti accessibili da tastiera ma utilizzando piuttosto elementi quali <img> o sono composti da una serie di componenti che richiedono la presenza di un "container" (ad esempio un <div>) che non può ricevere focus.

HTML4 ha introdotto l'attributo

tabindex

per i tag a, area, button, input, object, select e textarea. Questo attributo accetta valori positivi tra 0 e 32767. La navigazione comincia con l'elemento dal numero più basso e procede verso quello col numero più alto. Elementi col valore di 0 sono visitati nell'ordine in cui appaiono, e dunque se il nostro markup ha già una struttura ordinata, tabindex non è necessario per accedere agli elementi da tastiera.

ARIA estende l'attributo tabindex rendendolo utilizzabile su tutti gli elementi visibili. ARIA consente inoltre di specificare un valore negativo per elementi che non devono apparire nell'ordine di accesso da tastiera ma che possono ricevere il focus programmaticamente (da script). Visto che il valore negativo effettivo non è importante (l'element non riceve mai focus da tastiera) il valore di "-1" è di solito utilizzato per questi elementi che non sono nell'ordine dei tab ma che potrebbero ricevere focus da script. Per esempio, si potrebbe creare un menu dove il menu pul ricevere focus da tastiera (e dunque ha un tabindex positivo) ma i singoli menu non sono accessibili dal tab della tastiera. Le voci di menu potrebbero essere programmate per essere rese accessibili con i tasti delle frecce. In questo modo, gli utenti non sono obbligati a passare con il tab tutti gli elementi del menu e possono navgare meglio il documento. Questo è vero per tutti i widget che hanno una serie di componenti che richiedono accesso da tastiera, quali ad esempio una rappresentazione ad albero.

Aggiungere l'ordine naturale di tabulazione

L'esempio seguente usa un attributo tabindex ugule a 0 per inserire il div nell'ordine degli elementi accessibili da tab così da consentire una navigazione da tastiera nell'elemento:

<div tabindex="0"><br />    ...<br />    </div>

tabindex negativo

L'esempio seguente invece usa un valore uguale a -1 per specificare che l'elemento può ricevere focus da script ma non è nel flusso di tab del documento

<div id="progaccess" tabindex="-1"><br />    ...<br />    </div>

Queste linee di JavaScript possono essere utilizzate per spostare il focus all'elemento che abbiamo definito prima:

var objDiv = document.getElementById('progaccess');<br />    // Focus on the element<br />    objDiv.focus();

Ma io che cosa sono?

ARIA introduce l'attributo

role

per definire i widget, tipo uno slider, e la struttura della pagina, come ad esempio una sezione di navigazione. Uno dei principali problemi con le web applications è che ogni tipo di  elemento può essere usato per creare dei widget. Gli elementi HTML hanno già dei ruoli definiti, il "ruolo" essendo ciò che fa, il suo compito nella struttura del documento. Per esempio, il ruolo di un'intestazione è ben chiara agli strumenti che utilizza tecnologie di supporto. Quando però dei componenti esistenti vengono utilizzati per creare dei nuovi widget, il "ruolo" è quello che la tecnologia si aspetta, non quello per cui visiviamente viene utilizzato il componente. Se ad esempio usiamo un'immagine chiamata "indicatore" per creare uno slider, la tecnologia di supporto lo identificherà come "immagine, indicatore" e non come "slider, valore 16 percento".


Uno slider con il suo indicatore

Il ruolo indicato nell'attributo role prevale su quello "nativo" dell'elemento. Nell'esempio seguente, ad esempio, un elemento <input> ha un ruolo definito slider (vedremo in seguito altre proprietà ARIA) – il ruolo che verrà interpretato dalla tecnologia di supporto è dunque "slider", non "input"

<input type="image"<br />           src="thumb.gif"<br />           alt="Effectiveness"<br />           role="slider"<br />           aria-valuemin="0"<br />           aria-valuemax="100"<br />           aria-valuenow="42"<br />           aria-valuetext="42 percent"<br />           aria-labelledby="leffective">

Quando questo elemento riceve focus uno screen reader capirà il "ruolo" di questo elemento. La specifica ARIA fornisca una lista di diversi "ruoli".

Ruoli all'interno del documento

Oltre a definire ruoli per i widget, ARIA definisce anche ruoli che aiutano a comprendere la struttura del documento. "Document landmarks" sono un subset dei ruoli che aiutano gli screen reader a capire il ruolo di una sezione, aiutando l'utente ad orientarsi all'interno del documento.


Classica pagina con header, navigazione e contenuto

ARIA definisce i seguenti "ruoli di pagina":

article
    Contenuto che ha una sua importanza propria, come ad esempio un post su un blog, un commento, un post su un forum e così via

banner
    Contenuto legato al sito, come ad esempio il titolo della pagina e il logo

complementary
    Contenuto di "supporto" al contenuto principale della pagina, ma comunque con un significato compiuto anche se slegato la main content. Esempio: previsioni del tempo

contentinfo
    Contenuto "figlio", ad esempio note, copyright, link al documento della privacy etc.

main
    Contenuto direttamente collegato o che si estende nella parte centrale del documento

navigation
    Contenuto che contiene i link per navigare il documento o i documenti collegati

search
    Sezione che contiene il form di ricerca del sito

L'esempio seguente specifica i ruoli per banner, navigazione e main per creare la struttura che abbiamo visto nell'immagine precedente

<div role="banner"><br />    ...<br />    </div><br />    <div role="navigation"><br />    ...<br />    </div><br />    <div role="main"><br />    ...<br />    </div>

Stati e proprietà ARIA

Gli stati e le proprietà ARIA consentono di fornire alla tecnologia di supporto maggiori informazioni sul widget così da consentirne un utilizzo più semplice. Lo stato definisce una univoca condizione di informazione per un oggetto. Ad esempio, la proprietà aria-checked può avere tre stati: vero, falso, misto.

Nell'esempio precedente con lo slider abbiamo incluso varie proprietà ARIA, mostrate qui di seguito, che aiutano a descrivere il widget a strumenti di tecnologia di supporto:

aria-valuemin
    Minimo e massimo per un range

aria-valuemax
    Massimo valore per un range

aria-valuenow
    Valore attuale di un range

aria-valuetext
    Un testo utile a capire il contesto. Ad esempio: "30 dollari".

aria-labelledby
    Il valore dell'ID di una label contenente il prompt adeguato a questo widget

Alcune proprietà possono essere aggiornate con uno script. Per esempio, il valore di aria-valuenow e di aria-valuetext del nostro slider vengono aggiornate quando l'indicatore viene spostato:

// Set the ARIA property values when the thumb is<br />    // moved on the slider<br />    objThumb.setAttribute('aria-valuenow', iValue);<br />    objThumb.setAttribute('aria-valuetext', iValue + ' %');

Aggiungere ruoli e attributi ARIA renderà non valido il documento, nè HTML 4.01 nè XHTML 1.0, ma va bene così. ARIA aggiunge elementi e informazioni importanti a specifiche scritte un sacco di tempo fa. Si sta lavorando alla definizione di un DTD che può essere usato con XML modulare, tipo XHTML 1.1.

Ecco invece la lista completa degli stati e proprietà per rendere più accessibili i widget tramite ARIA: http://www.w3.org/TR/wai-aria/#supported

Live Regions

"Live regions" è un sistema che consente agli elementi di un documento di annunciare che ci sono stati dei cambiamenti, senza che l'utente perda il focus attuale. Per esempio, una applicazione di chat potrebbe avvertire l'utente che è arrivato un messaggio della persona con cui sta chattando senza togliere il focus dal campo di testo dove si trova ora per comporre il suo messagio.

aria-live

La possiblità di "scoprire" contenuto aggiornato è uno degli ostacoli principali agli screen readers. ARIA fornisce la proprietà

aria-live

che serve per indicare il livello di verbosità della regione. Di seguito i livelli che possono essere utilizzati:

off

    Valore di default, indica che la regione non è "live"

    <ul aria-live="off">

polite

    Operatività normale ed attesa per le regioni "live". Questo valore indica che non è necessari rispondere fino a che l'utente non ha terminato la sua attività attuale.

    <ul aria-live="polite">

assertive

    Questo valore indica una priorità superiore alla normale e dunque richiede un'interruzione immediata dell'utente

    <ul aria-live="assertive">

Di seguito vediamo alcune altre importanti proprietà che possono essere utilizzate quando si definiscono regioni live.

La proprietà aria-atomic

Questa proprietà opzionale delle live regions può avere valore di "true" o "false". Quando la regione è aggiornata, questa proprietà indica se la tecnologia di supporta debba presentare tutto o solo una parte della regione aggiornata all'utente. Se questa proprietà è "true" tutta la regione dovrà essere presentata, in caso contarrio potrà essere annunciata solo la parte aggiornata.

Nell'esempio seguente tutti gli elementi della lista saranno annunciati quando verrà letta a voce alta la regione, a meno che un elemento seguente non annulli questo comando.

<ul aria-atomic="true"<br />        aria-live="polite">

La proprietà aria-busy

Con questa proprietà opzionale ("true" o "false") si indica se gli aggiornamenti di una specifica regione devono essere aggiornati appena avvengono o solo quando la regione ha finito tutti gli aggiornamenti.

<ul aria-atomic="true"<br />        aria-busy="true"<br />        aria-live="polite">

La proprietà aria-relevant

Questa proprietà opzionale accetta una lista di cambiamenti che devono essere condierati "rilevanti" per una certa regione. La lista è separata da spazi e accetta i seguenti valori:

additions
    Quando nodi sono aggiungi al DOM

removals
    Quando nodi sono rimossi dal DOM

text
    Quando del testo è inserito nel DOM

all
    Quando avviene una qualsiasi delle modifiche indicate prima ("additions removals text")

Il valore di "default" è "additions text" (cioè quando vengono aggiunti elementi al DOM o pezzi di testo). Nel seguente esempio solo aggiunte di nodi vengono annunciate all'utente mentre rimozioni di nodi o aggiune di testo no:

<ul aria-relevant="additions"<br />        aria-atomic="true"<br />        aria-live="polite">

Quando potrà essere usata ARIA?

Oggi. Non ci sono controindicazioni all'utilizzo di ARIA, tutti i 4 principali browser lo supportano o stano programmando di supportarlo. Opera 9.5 e Firefox 1.5+ lo supportano già, IE8 Beta ha supporto ARIA e Webkit, il framework opensource base di Safari, ha annunciato che hanno cominciato a lavorare sul supporto di ARIA.

ARIA inizia inoltre ad essere molto diffuso su tecnologie di supporto quali JAWS 7.1+, Window-Eyes 5.5+, NVDA, Zoomtext 9+ e altri – e la situazioni non potrà che migliorare da oggi in avanti.

Siate degli early adopter

Visto che non ci sono controindicazioni all'utilizzo di ARIA e il supporto c'è, non c'è nulla da perdere ma anzi un sacco da guadagnare a diventarne degli utilizzatori della prima ora. Anche se avete dei siti web semplici potreste includere dei landmark roles per aiutare gli utenti a navigare e ad orientarsi meglio nel contenuto.

Usare landmark roles

Potreste includere i landmark roles per la sezione principale, la navigazione, ricerca e le parti secondarie. Consideriamo la seguente struttura di un documento HTML:

<div id="ads"><br />    ...<br />    </div><br />    <div id="nav"><br />        <form id="searchform" ...><br />        ...<br />        </form><br />    ...<br />    </div><br />    <div id="content"><br />    ...<br />    </div>

Potremmo scrivere l'attributo "role" direttamente nel markup:

<div id="ads" role="banner"><br />    ...<br />    </div><br />    <div id="nav" role="navigation"><br />        <form id="searchform" role="search" ...><br />        ...<br />        </form><br />    ...<br />    </div><br />    <div id="content" role="main"><br />    ...<br />    </div>

In alternativa, visto che la maggior parte delle pagine sono strutturate in modo da poter ricevere uno stile CSS, è probabile che i vari elementi abbiamo degli ID che possiamo passare ad una funzione JavaScript tipo quella seguente, che accetta un ID e un ruolo e aggiorna dinamicamente l'attributo dell'elemento:

function addARIARole(strID, strRole) {<br />        // Find the element to add a role property to<br />        var objElement = document.getElementById(strID);<br />    <br />        if (objElement) {<br />            // Add the role property to the element<br />            objElement.setAttribute('role', strRole);<br />        }<br />    }

Considerando dunque una struttura come quella di cui sopra potremmo utilizzare questa funzione per aggiungere l'attributo role senza doverlo scrivere nel markup:

function setupARIA() {<br />        // Add ARIA roles to the document<br />        addARIARole('content', 'main');<br />        addARIARole('nav', 'navigation');<br />        addARIARole('searchform', 'search');<br />        addARIARole('ads', 'banner');<br />    }<br />    <br />    window.onload = setupARIA;

Indicare campi obbligatori

Se avete dei form con dei campi obbligatori potete usare la proprietà aria-required. Questa proprietà indica che è necessario un controllo sull'input utente prima che il form sia inviato. Vediamo un esempio con un normale campo di testo:

<label for="contactname">Name</label><br />    <input type="text"<br />           id="contactname"<br />           name="contactname"<br />           size="30"<br />           aria-required="true">

Wordpress ha iniziato ad aggiungere la proprietà aria-required nei campi obbligatori dei commenti di un post.

Aggiungere altre proprietà rilevanti

Ci sono un sacco di altre proprietà ARIA interessanti e utili anche per website semplici, tipo aria-labelledby e aria-describedby. La prima punta ad uno o più elementi che sono considerati la "label" per questo elemento mentre la seconda punta ad uno o più elementi che ne sono la descrizione.

<h2 id="limg">Paragliding</h2><br />    <p id="dimg"><br />    A long description of our paragliding trip ...<br />    </p>

<div><br />    <img src="takeoff.png"<br />         alt="Getting ready to take off"<br />         aria-labelledby="limg"<br />         aria-describedby="dimg"><br />    </div>

Precedenza sul markup

Il markup ARIA ha la precedenza sul resto: questo significa che se si usa la proprietà aria-labelledby insieme a label for="", la prima avrà la precedenza. L'elemento label è comunque ancora consigliato per i vecchi browser che non capiscono ARIA, e dunque una soluzione ottimale per la massima compatibilità è usare aria-labelledby che si riferisce ad una label:

<label id="lblef" for="effectiveness">Effectiveness</label><br />    <br />    <input type="image"<br />           role="slider"<br />           id="effectiveness"<br />           aria-labelledby="lblef"<br />           ...>

Date un'occhiata alla lista completa di proprietà e stati ARIA per capire come vi può aiutare a rendere il vostro contenuto più accessibile.

Ed ora, tutti insieme!

HTML non è nato per creare applicazioni web, ma gli sviluppatori le hanno create costruendo i loro widget e aggiungendo vita con JavaScript. Il problema è che il ruolo, lo stato e le proprietà di questi widget o del contenuto aggiornato non sono correttamente comunicati alle tecnologie di supporto. La specifica ARIA risolve questo problema, consentendo ai developer di descrivere in dettagli i propri widget, definire la struttura del documento e definire regioni della pagina che vengono aggiornate.

Che voi stiate sviluppando una completa applicazione web con dei widget complessi e sezioni live, o che voi abbiate un semplicissimo sito web, potete iniziare a usare ARIA oggi per venire incontro e migliorare la vita online di tutti gli utenti con delle disabilità.

The following two tabs change content below.
Silvio Porcellana
Silvio Porcellana è il fondatore di mob.is.it, il tool che centinaia di agenzie e professionisti di tutto il mondo utilizzano per creare con semplicità siti mobili e applicazioni native per i loro clienti. Tiene anche un podcast dove racconta ogni venerdì le sue avventure imprenditoriali, senza veli o segreti: Opus Digitalis