vai ai contenuti
vai al menu

Regione Piemonte per l'Accessibilità e l'Usabilità



RIA e WAI-ARIA: che cosa sono?

Prima di spiagare che cosa sono le WAI-ARIA, bisogna fare una breve premessa sulle RIA (Rich Internet application).

RIA (Rich Internet application): un nuovo modo di creare pagine web

Sono applicazioni web che possiedono le caratteristiche e le funzionalità delle applicazioni desktop, senza però necessitare dell'installazione sul disco fisso. Nelle RIA la parte di applicazione che elabora le informazioni è nel client, mentre la maggior parte dei dati e la restante parte di applicazione restano sul server. Proprio per questo motivo le RIA si fondano su un'architettura di tipo distribuito.

In generale ci sono due modi per creare RIA:

  1. Utilizzando tecnologie standard come (X)HTML, CSS e Javascript;
  2. Utilizzando tecnologie incoroporate, create usando specifici tag (X)HTML che permettono l'esecuzione di applicazioni esterne.

Sviluppare RIA con le tecnologie standard non crea grossi cambiamenti al processo di sviluppo delle pagine web.
In generale, le pagine web (sia RIA che normali pagine web) si compongono di tre livelli:

  1. Livello di struttura e contenuto. Definisce i diversi blocchi che compongono la pagina e il contenuto che rappresentano. Normalmente la tecnologia utilizzata è l' (X)HTML;
  2. Livello di presentazione. Definisce l'aspetto visivo e il moo in cui vengono presentati i contenuti. Normalmente, la tecnologia utilizzata in questo strato è CSS.
  3. Livello di comportamento. Definisce il modo di reagire alle azioni dell'utente. Questo livello interagisce direttamente con il DOM del documento e può modificare la presentazione dei contenuti o i contenuti stessi.

Per lo sviluppatore, il livello di comportamento apre una vasta gamma di possibilità, come creare moduli che simulano le funzionalità delle applicazioni desktop. In questo livello viene anche codificato l'aggiornamento delle informazioni e si può fare in modo che le richieste vengano eseguite in un tempo minore. Con una combinazione di tecnologie denominata AJAX (Asynchronous JavaScript and XML) si possono eseguire delle richieste asincrone (ossia scambi di informazioni tra server e client che non interferiscono con il funzionamento della pagina) che modificano solo una parte del contenuto della pagina.

I principali problemi di accessibilità di una RIA

La maggior parte dei problemi di accessibilità delle RIA sono dovuti ai metodi di selezione e di interazione degli elementi, che spesso prevedono il solo utilizzo del mouse. Altri problemi sono rappresentati dal significato semantico degli elementi e dall'aggiornamento di determinate aree.
Quindi possiamo riassumere i principali problemi in tre categorie:

  • Problemi di operabilità. Spesso nelle RIA, i comandi sono selezionabili esclusivamente col mouse, così chi usa la tastiera o chi usa tecnologie assistive che simulano la tastiera non possono interagire con questi elementi.
  • Problemi di semantica. Tutti gli elementi interattivi di una normale pagina web sono definiti e hanno un ben preciso significato semantico oltre a possedere tag e attributi in grado di aiutare le tecnologie assistive a far interagire gli utenti con questi controlli. I controlli specifici per le RIA spesso mancano di questi attributi: ad esempio una o più immagini possono essere usate per creare un controllo slider oppure una pulsantiera senza che però ci siano attributi specifici che definiscono le proprietà o gli stati (Es: posizione della slide o stato del pulsante).
  • Live-region. La capacità delle RIA di aggiornare delle parti di pagina in modo asincrono rappresenta un grande problema per l'accessibilità. Se non correttamente implementati, questi aggiornamenti potrebbero sfuggire alle tecnologie assistive e venire persi dagli utenti.

Ed è per risolvere questi problemi che è si usano le WAI-ARIA, che definiscono metodi per rendere le RIA accessibili e usabili ad ogni categoria di utenti.

L'uso di RIA dovrebbe essere usato in modo adeguato e solo quando necessario. Se un particolare oggetto è supportato nativamente dal linguaggio è bene utilizzare quell'oggetto piuttosto che ricorrere ad una RIA in modo da presentare meno problemi di accessibilità e usabilità.

WAI-ARIA

WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) è un insieme di documenti pubblicati dal W3C (World Wide Web Consortium) che specificano come aumentare l'accessibilità dei contenuti dinamici e dei componenti per l'interfaccia utente sviluppati con AJAX, HTML, JavaScript e altre tecnologie collegate.

Da cosa è composto?

Il WAI-ARIA si compone di tre documenti principali:

  1. Accessible Rich Internet Applications (WAI-ARIA) Version 1.0: documento principalmente orientato agli sviluppatori di tecnologie web assistive ed altri programmi utente, sviluppatori di altre specifiche tecniche e sviluppatori di strumenti per valutare l'accessibilità.
  2. WAI-ARIA Primer: introduzione tecnica alla WAI-ARIA. Descrive i problemi a cui ci indirizza WAI-ARIA, i concetti di base, l'approccio tecnico e le motivazioni di business per cui si deve adottare WAI-ARIA.
  3. WAI-ARIA Esperienze più significative: descrive le migliori pratiche per diffondere rich internet applications con WAI-ARIA: affronta temi come i primi passi per costruire widgets, navigazione da tastiera, relazioni, proprietà di form, supporto per copia e incolla, avvisi e finestre di dialogo, librerie componenti riutilizzabili, e strumenti di test.
  4. WAI-ARI User Agent Implementation Guide: descrive come i browser e gli altri programmi utente incontrano WAI ARIA.

Perchè è stato creato questo documento?

Sempre più spesso gli sviluppatori web utilizzano script lato client per creare controlli che con il silo HTML sarebbero impossibili da fare ed arricchiscono le pagine con applet rendendo la pagina più interattiva e dinamica. Sebbene questo sia un grande vantaggio per la maggior parte degli utenti, per alcuni può rappresentare un ostacolo: basti pensare a tutti quegli utenti che utilizzano uno Screen reader o in generale chi è impossibilitato ad usare un sistema di puntamento come il mouse.
Per questo WAI-ARIA descrive come aggiungere una semantica o dei metadati al contenuto HTML in modo da rendere i controlli dinamici e i controlli lato utente più accessibili. WAI-ARIA fornisce un modo per aggiungere attributi per identificare le caratteristiche di iterazione con l'utente, come si relazionano e il loro stato attuale. Per esempio, un utente potrebbe essere costretto oppure voler interagire con un slider widget con la tastiera anzicè con il mouse. Perchè questo sia possibile in modo efficace, il programma deve comprendere la semantica del contenuto.

WAI ARIA fornisce agli sviluppatori web:

  • Regole per descrivere il tipo di widget presentato;
  • Regole per descrivere la struttura della pagina;
  • Proprietà per descrivere lo stato in cui si trova un widget;
  • Proprietà per definire delle regioni della pagina che possono subire un aggiornamento (Esempio un box che conterrà eventuali messaggi di errore);
  • Proprietà per il drag-and-drop che descrivono gli oggetti da trascinare e la loro destinazione;
  • Un modo per rendere gli oggetti web navigabili da tastiera.

L'uso di WAI-ARIA, può invalidare la pagina visto che i suoi attributi non sono supportati da tutte le DTD attualmente in uso.

Dentro la WAI-ARIA

Le applicazioni web complesse diventano inaccessibili quando le tecnologie assistive non riescono a determinare il significato semantico della porzione del documento. Molte pagine web contengono elementi interattivi che sono attivabili da diversi eventi scatenati dall'utente (Es: click del mouse, pressione di un tasto, Drag and Drop) e che sono realizzati utilizzando elementi del linguaggio originariamente destinati ad altri scopi. Per questo le tecnologie assistive hanno difficoltà a capire il significato semantico del controllo.
Il WAI ARIA, divide il significato semantico in ruoli e proprietà e stati supportati dai ruoli. Le WAI-ARIA perciò associano ad ogni elemento del documento un ruolo e degli attributi.

Ruoli

Secondo le WAI ARIA i ruoli sono definiti negli elementi usando l'attributo role.
es:

<li role="menuitem">Informazioni generali </li>

L'attributo role, serve per descrivere elementi che hanno ruoli diversi da quelli assegnati dall'html.
Per esempio, un'immagine usata per creare un bottone avrà l'attributo button. L'attributo role permettere agli screen reader e in generale alle diverse tecnologie assistive di capire qual'è la vera funzione del controllo.

Oltre che per diversi tipi di oggetto, le WAI-ARIA definiscono dei ruoli anche per le diverse porzioni di pagina. I Document landmarks sono dei ruoli che vengono assegnati a diverse zone della pagina per aiutare a definire meglio la struttura della stessa e aiutano l'utente ad orientarsi.

Per ogni ruolo della tassonomia sono definite delle caratteritiche che provvedono a descrivere le seguenti caratteristiche:

  • una descrizione del ruolo;
  • un'informazione sulla gerarchia dei ruoli collegati. (Es: Directory è un tipo di list);
  • il contesto del ruolo (Es: listitem contiene elementi di tipo list);
  • riferimenti a concetti correlati in altre specifiche;
  • l'utilizzo di OWL per fornire una gerarchia di tipo semantico che permette l'ereditarietà(simile all'ereditarietà delle classi);
  • stati e proprietà supportati da ogni ruolo.

Sul sito del W3 è consultabile una lista completa dei ruoli.

Stati e proprietà

Le WAI-ARIA forniscono una serie di stati e porprietà accessibili che sono usate a supporto delle API accessibili dei diversi sistemi operativi. In combinazione con gli i ruoli possono fornire alle tecnologie assistive maggiori dettagli sullo stato e sull'effettivo utilizzo degli elementi.

Nell'esempio seguente, un elemento lista (html: li) è stato utilizzato per creare un menù selezionabile e degli eventi Javascript cattureranno gli eventi del mouse e della tastiera per passare il valore all'attributo aria-checked.

<li role="menuitemcheckbox" aria-checked="true">Sort by Last Modified</li>

Alcuni stati, chiamati managed states (stati gestiti) sono controllati dagli utenti. Alcuni esempi di managed state sono il focus e la selezione da tastiera. Spesso, i managed states corrisondono a pesudo classi CSS (Come :focus e ::Selection) per definire cambiamenti di stile.
Molti degli stati specificati nelle WAI ARIA, sono controllati dagli autori e vengono chiamati unmanaged states (Stati non gestiti). Alcuni di questi stati sono gestiti dai programmi utente come l'aria-pointset e l' aria-setsize, ma l'autore può sovrascriverli se il DOM è incompleto e può portarare a degli errori da parte dei programmi utente. I programmi utente, possono associare sia gli stati gestiti che quelli non gestiti alle API della piattaforma.

La maggior parte dei moderni programmi utente, supportano il CSS Attribute Selector e permettono all'autore di creare interfacce utente che vengono modificate in base alle informazioni degli attributi WAI-ARIA, riducendo il numero di script necessari per ottenere lo stesso risultato.
esempio:

[aria-checked="true"] { font-weight: bold; }
[aria-checked="true"]:before { background-image: url(checked.gif); }

In questo caso, il CSS viene utilizzato per aggiungere un immagine di spunta all'elemento selezionato.
Se il CSS non è usato per visualizzare o meno l'immagine di spunta, l'autore può aggiungere markup e scripts per gestire l'immagine che rappresenta se un controllo menuitemcheckbox è selezionato.

<li role="menuitemcheckbox" aria-checked="true">
<img src="checked.gif" role="presentation" alt="">
<!-- note: additional scripts required to toggle image source -->
Sort by Last Modified
</li>

Gli stati e le proprietà sono divisi nel seguente modo:

  • Widget Attributes

    Attributi specifici per gli elementi comuni dell'interfaccia utente che possono ricevere l'input dell'utente e processare le azioni.
    Questi attributi possono essere mappati da un programma utente agli stati della piattaforma in modo da essere accessibili alle tecnologia assistive o potrebbero essere resi accessibili direttamente dal DOM. I programmi utente, devono notificare alle tecnologie assistive quando uno stato cambia si attraverso attributi del DOM sia attraverso eventi API della piattaforma di accessibilità

  • Live Region Attributes

    Questi attributi possono essere applicati a qualsiasi elemento. Lo scopo di questi attributi è quello indicare che un contenuto può cambiare senza avere il focus e aiutare le tecnologie assistive ad elaborare questi cambiamenti.

  • Drag-and-Drop Attributes

    Questo tipo di attributi provvede ad indicare informazioni riguardo elementi dell'interfaccia di tipo drag-and-drop come gli elementi trascinabili e i loro obbiettivi. Informazioni sulla destinazione saranno resi visivamente dall'autore e fornite alle tecnologie assistive attraverso una modalità alternativa.
    Per maggiori informazioni riguardo a questo tipo di attributi si può vedere Pratiche per il supporto al Drag-and-Drop nelle WAI-ARIA

  • Relationship Attributes

    Attributi che indicano le relazioni tra gli elementi o le associazioni che non possono essere facilmente determinate dalla struttura del documento.

Maggiori informazioni su stati e proprietà possono essere trovati all pagina Stati e proprietà supportati del W3.

Come validare una WAI-ARIA

Come già accennato sopra, le WAI-ARIA sono incompatibili con le DTD attualmente in vigore. Infatti se si prova a validare una pagina che fa ricorso alle RIA, vengono segnalati errori del tipo:

Line xx, Column yy: there is no attribute "ROLE".

Questo però, oltre a non essere un vero e proprio errore di validazione, non ci fornisce nessuna informazione sul contenuto dell'attributo "Role" e non ci dice se questo è usato correttamente.

Per ovviare a questo genere di problema si può estendere la DTD dell'XHTML 1.1 in modo da supportare gli attributi WAI-ARIA. Questo metodo, presenta però diversi problemi, primo tra tutti il fatto di non essere un documento ufficiale e quindi universalmente riconosciuto. Nell'appendice delle WAI-ARIA sono descritte diverse tecniche che permettono la validazione da parte di validatori automatici di pagine contenenti WAI-ARIA.

Alcuni esempi di utilizzo

Abbiamo visto che non sempre è necessario l'utilizzo delle RIA e che anzi bisognerebbe ridurne al minimo l'utilizzo, ma quand'è che è davvero necessario usare le WAI-ARIA e come andrebbero utilizzate?

Un esempio classico: applicazioni drag and drop

Uno degli esempi più significativi e utili è quello delle feature drag and drop che sono oramai presenti in tutti i programmi e che facilitano l'utiizzo di diverse funzionalità (basti pensare al semplice gesto di trascinare un file nel cestino). L'html però non supporta nativamente questo tipo di tecnologia e quindi bisogna ricorrere alle WAI-ARIA per creare un applicazione drag and drop che sia anche accessibile.

In questa pagina si può vedere un esempio di applicazione drag and drop realizzata in modo accessibile. Infatti, oltre a poter spostare gli oggetti con il mouse, è possibile interagire con essi tramite comandi da tastiera.

Le toolbar

Un'altro esempio pratico è quello della creazione di toolbar inserite all'interno di pagine web, come ad esempio quelle dei CMS che permettono di avere le stesse funzionalità di un normale programma. Nell' esempio presentato, i bottoni sono realizzati con elementi lista, a cui sono stati assegnati ruoli opportuni (in questo caso "button") in modo da poter permettere ai lettori di schermo di riconoscerli come tali. Come nel caso precedente, anche qui è possibile utilizzare i tasti (Tab,space e frecce direzionali) per utilizzare la toolbar.

Utlimo esempio: le griglie

L'ultimo esempio mostra una tabella vuota che può essere riempita con i dati dall'utente. Si possono precisare anche dei tipi di formato che ogni cella può accettare (ad esempio la data). Questo tipo di tabelle è utile per permettere agli utenti di modificare o inserire dei dati senza dover ricorrere ad applicazioni server-side o a soluzioni più costose o lente (es: applicazioni utente). Come per gli esempi precedenti l'applicazione si può usare sia con il mouse che con la tastiera.

Sitografia

Aggiornamento: giugno 2012

Torna su

stampa la pagina


Torna su


Torna su