Traduzione dell’articolo “Ajax accessibility” di John Resig

Una diffusa preoccupazione sulla maggior parte delle applicazioni Ajax riguarda la loro accessibilità. E’ vero che è possibile sviluppare pagine Web più o meno usabili anche senza l’uso di Javascript, ma d’altra parte è possibile – utilizzando gli script aggiuntivi – garantire una migliore “esperienza utente”. Ed è a questo punto che entrano in ballo le specifiche ARIA, le quali prevedono la definizione di una gran quantità di interazioni, per mezzo delle quali si può favorire una comunicazione più efficiente tra un’applicazione Web ed uno screen reader.

Per meglio comprendere queste interazioni, puoi consultare ARIA Live Regions (informazioni aggiuntive). Con queste funzionalità è possibile mantenere aggiornato in tenpo reale un elenco di utenti, permettendo nel contempo che anche lo screen reader comunichi progressivamente le modifiche.

Osserva il seguente codice HTML arricchito con ARIA:

<b>Active Users:</b>
<p id="users-desc">A list of the currently-connected users.</p>
<ol aria-live="polite" aria-relevant="additions removals"
    aria-describedby="users-desc" id="users">
  <li>John</li>
  <li>Mary</li>
  <li>Ted</li>
  <li>Jane</li>
</ol>

Alcuni di questi parametri hanno lo scopo di rendere questo codice particolarmente interattivo nei riguardi dello screen reader (il codice Javascript che aggiorna quest’elenco è stato omesso – ma alla fine non contiene altro se non una semplice operazione di inserimento/rimozione sul DOM).

  • aria-live=”polite” Questo attributo stabilisce come si comporta l’area attiva, cioè quanto essa risulti propensa ad interrompere quel che l’utente sta correntemente ascoltando o utilizzando. Il valore di default è ‘polite’, in presenza del quale si aspetta che ogni forma di interazione da parte dell’utente sia stata portata a termine, prima di comunicare gli aggiornamenti.
  • aria-relevant=”additions removals” Comunica all’utente solo l’aggiunta di nuovi nodi o la rimozione. Visto che il nostro scopo (nel codice di sopra) è di fornire un elenco aggiornato in tempo reale degli utenti connessi, potremmo attenderci le transizioni tra i due possibili stati (online ed offline) – questo parametro ci fornirà l’appropriato livello di aggiornamento per renderlo possibile.
  • aria-describedby=”users-desc” E’ un puntatore all’elemento che descrive il contenuto dell’area attiva. Se l’utente desidera avere maggiori informazioni su quello che il contenuto del campo rappresenta, gli si può comunicare il contenuto di quest’elemento.

Comunque, quel che più conta in tutto questo è che ARIA non è un sogno irrealizzabile, ma risulta già implementato – attualmente – da Firefox 2 e lo sarà ancora meglio nell’oramai prossimo Firefox 3.

Il gruppo di lavoro di Google Reader ha utilizzato queste funzionalità ed ha implementato un pieno supporto di ARIA alle proprie applicazioni. E bisogna dire che Google Reader non è certo un’applicazione banale, il che dimostra ancora di più la piena operatività di ARIA anche in applicazioni Web importanti e di grande respiro.

Durante questa implementazione, hanno creato uno strumento, AxsJAX, in grado di aggiungere le migliorie apportate da ARIA all’interno di molte pagine, in forma di bookmarklet, o utilizzando greasemonkey (un’estensione del browser) o Fire Vox (uno screenreader per Firefox). Hanno iniziato a dotare alcune applicazioni Google di queste funzionalità (insieme a pochi altri, tra cui XKCD un fumetto Web).

Sono positivamente colpito da quel che si può ottenere con ARIA – e vedere poi il lavoro fatto da Google nell’implementare queste funzionalità nelle loro applicazioni è incredibilmente illuminante ed incoraggiante.