Accessibilità nel Web 2.0

Accessibilità nel Web 2.0

Il Web 2.0 non ha una data di nascita. La convenzione vuole che con questa denominazione si indichi un certo trend che può collocarsi cronologicamente intorno al 2005. Da allora questo fenomeno si è notevolmente consolidato: se all'inizio si poteva parlare di alcune caratteristiche comuni a pochi siti, oggi queste caratteristiche si sono estese ad una fetta considerevole del panorama del Web.

Le caratteristiche in comune possono essere brevemente riassunte come segue:

  1. uso massivo di AJAX e JavaScript, con spesso alle spalle un framework solidamente orientato agli oggetti
  2. uso di feed RSS e Atom
  3. separazione tra contenuto e presentazione attraverso l'adozione dei CSS
  4. uso di stilemi comuni nell'implementazione dell'interfaccia grafica (icone, fonts, immagini)
  5. orientamento user-centric, con contenuti generati dagli utenti.

Il punto focale nei riguardi dell'accessibilità è certamente il quinto: permettere a tutti gli utenti di usufruire di un sito, indipendentemente dal dispositivo o dalla piattaforma usata. Questa affermazione, tuttavia, va accuratamente calata nel contesto del Web reale, al fine di evitare sterili dictat che non farebbero altro che generare l'effetto contrario, ossia una chiusura verso questa tematica.

Sia chiaro, sin da ora, che l'accessibilità assoluta non esiste. Per quanto ci si sforzi di testare un sito su differenti dispositivi e piattaforme e con differenti tipologie di utenti, esiste sempre una zona d'ombra che va rischiarata con la luce dell'esperienza. In altre parole, sbagliare e imparare è l'approccio migliore.

Infatti chi naviga con tecnologie assistive o browser alternativi spesso non viene considerato nelle statistiche di un sito. Ciò è normale, se si pensa che molto spesso è difficile se non impossibile identificare questi dispositivi. Vediamo ora in dettaglio le problematiche inerenti ad alcune caratteristiche del Web 2.0.

AJAX e JavaScript

La prima cosa da tenere a mente è che chi naviga con un browser testuale (come Lynx), o chi ha disabilitato JavaScript nel proprio browser, non ha accesso ai contenuti generati tramite questi standard. Come regola generale, si può ricorrere a meccanismi di ripiego, come per esempio la tecnica del contenuto nascosto. Si supponga per esempio di dover validare un form tramite JavaScript, mostrando dove opportuno dei messaggi di errore. Invece di generare tali messaggi tramite JavaScript, li si può inserire nella marcatura e poi nasconderli tramite i CSS, e quindi mostrarli con JavaScript al momento opportuno.

Questa tecnica si rivela inefficace, tuttavia, con quegli utenti il cui browser non supporta i CSS ed anche nel caso di chi ha JavaScript disabilitato: il risultato, infatti, sarà quello di visualizzare dei messaggi di errore su tutti i campi, anche quando l'utente ha digitato il valore corretto. In casi come questo, la soluzione migliore è quella di affidare la visualizzazione dei messaggi di errore ad un linguaggio lato server , evitando di duplicare il codice con la validazione lato client.

Questo esempio serve ad evidenziare una regola fondamentale: laddove non ci siano evidenti penalizzazioni a livello di performance per l'implementazione lato server, questa è da preferire a quella lato client. È certamente vero che con AJAX non è necessario ricaricare la pagina e che da questo provengono numerosi vantaggi in termini di performance, ma è altrettanto vero che da un punto di vista dell'accessibilità l'affidarsi completamente a questa tecnologia è sicuramente dannoso.

Tuttavia una soluzione esiste, e si chiama progressive enhancement. In breve: progettate il vostro sito perchè funzioni bene senza AJAX e JavaScript ed aggiungete questi ultimi solo alla fine dello sviluppo. Scoprirete come in fondo questi due standard funzionino molto bene per quella parte dell'architettura di un sito che, con una terminologia presa in prestito agli sviluppatori di Firefox, possiamo chiamare widget.

Un widget è un elemento che completa, abbellisce, arrichisce un'architettura, senza con questo pregiudicarne il funzionamento qualora esso non fosse presente. Facciamo un esempio: l'elaborazione dei dati di un form tramite AJAX. Questo widget deve funzionare anche se AJAX e JavaScript non sono supportati. Poniamo che il form si presenti così:


<form action="process.php" method="post" id="login">
...
</form>

L'elaborazione del form avviene nello script process.php. Con AJAX, dobbiamo prevedere che tale script restituisca un messaggio da mostrare all'utente che gli notifichi che l'azione ha avuto o meno successo. Con un framework come jQuery è alquanto semplice:


$('#login').submit(function() {
   
   $('#login').parent().load('process.php #message');
   return false;
});

jQuery inserisce un frammento HTML contenuto nello script di destinazione usando come riferimento un attributo ID specifico. Nello script process.php avviene il progressive enhancement di cui sopra:


header('Content-Type: text/html');
// elaborazione del form

echo '<div id="message">Benvenuto</div>' . "\n";
echo '<p><a href="pagina.php#login">Torna indietro</a></p>';

In questo modo gli utenti che non beneficiano di JavaScript e AJAX apriranno la pagina process.php, ma avranno un utile backlink per poter tornare sui loro passi.

Tuttavia, esiste un'altra categoria di utenti i cui dispositivi di navigazione sono ancor più complessi da trattare di quelli precedentemente visti. Mi riferisco agli utenti di lettori di schermo (screen reader). Un lettore di schermo presenta due problematiche principali:

  1. non può essere identificato come tale in quanto utilizza il browser del computer dell'utente per la navigazione
  2. presenta un supporto parziale a JavaScript.

Uno studio di qualche tempo fa di Cameron Adams (condensato nel capitolo 16 del volume The JavaScript Anthology edito da SitePoint) ha evidenziato che:

A questo punto dell'evoluzione del Web, non è ancora possibile dare consigli definitivi sul modo migliore per coniugare JavaScript e accessibilità, in modo particolare per quel che riguarda i lettori di schermo e altre tecnologie assistive, poichè le implementazioni sono molte e diverse, e le tecnologie cambiano rapidamente.

Il capitolo si concentra su due categorie di utenti:

  1. chi naviga con la tastiera
  2. chi usa un lettore di schermo

Per quanto riguarda i lettori di schermo, Adams fa intendere che non esiste una soluzione definitiva a questo problema. Infatti i lettori di schermo presentano un supporto assolutamente incoerente ed inaffidabile agli eventi JavaScript. Non solo: per quanto riguarda AJAX esiste anche il problema della memoria virtuale di un lettore di schermo. Tale memoria serve al programma per mantenere una copia del documento in modo tale da permettere all'utente di accedervi più facilmente. Purtroppo questa funzione non è automaticamente impostata nel lettore di schermo.

Con AJAX si assiste a questo: quando il contenuto di una pagina viene aggiornato dinamicamente, se il lettore di schermo non ha la sua memoria virtuale attivata, la lettura della pagina riprenderà dall'inizio e non dal punto in cui è avvenuto l'inserimento del nuovo contenuto. Il W3C ha cercato di ovviare a questi problemi tramite la promozione delle tecniche e degli standard WAI ARIA, purtroppo fino ad ora con scarsi risultati pratici.

In definitiva, si consiglia di vagliare attentamente l'uso di AJAX anche tenendo presente questa categoria di utenti e le problematiche poc'anzi citate.

CSS

Nonostante i CSS abbiano contribuito notevolmente a portare il Web verso una maggiore accessibilità tramite la separazione tra contenuto e presentazione, essi presentano alcune aree critiche per quanto riguarda l'accessibilità. Esse sono:

  1. colori e sfondi
  2. font
  3. interlinea
  4. dimensioni dei blocchi di testo
  5. elementi nascosti
  6. dimensione degli elementi.

Il primo punto vede coinvolta quella categoria di utenti che soffre di una forma più o meno grave di disabilità visiva (ipovisione, cecità ai colori, daltonismo, ecc.). In pratica, occorrerebbe che:

  • il colore dello sfondo e del testo abbiano un contrasto adeguato
  • si evitino le abbinazioni immagini di sfondo/testo.

Il contrasto di colore corretto si può desumere utilizzando il Colour Contrast Analyser del W3C.

Il secondo punto riguarda la leggibilità del testo. In linea di massima si dovrebbero sempre evitare font di difficile lettura e usare font di uso comune. Di norma è consigliabile usare font sans-serif, perchè sono più leggibili su schermo e usare i font serif per la stampa o, al limite, per i titoli. Le dimensioni dei font andrebbero specificate usando misure relative (come gli em), in modo da permettere agli utenti di ridimensionare il testo a loro piacimento.

Il terzo punto riguarda l'affaticamento della vista. È buona norma regolare l'interlinea del testo in modo che alla lunga la lettura non risulti penalizzata

Torna su