AJAX e l'accessibilità reale per gli screen reader

Riporto per motivi di maggiore documentazione una mia riflessione fatta sulla lista webaccessibile che intendo integrare completamente in questa pagina anche visto il recente articolo su sitepoint (http://www.sitepoint.com/article/ajax-screenreaders-work)

Le problematiche di AJAX e l'accessibilità sono molteplici e variano sulle singole
implementazioni ma in ogni caso non sono problematiche specifiche di
AJAX ma di javascript in generale quando si va a toccare l'albero DOM.

Tra i vari problemi il più difficile è la gestione del Focus.

Io avevo provato a fare un paio di implementazioni e me ne sono state
mostrate un paio da persone di mozilla e ibm (le riporto sotto) che
davanti ai test sembravano soddisfacenti (ce le aveva provate un
dipendente cieco di Google che è con me nell'HTML WG su piattaforma
linux fedora con uno screen reader che non mi ricordo)

• http://developer.mozilla.org/en/docs/Accessible_DHTML
• http://www.w3.org/WAI/PF/roadmap/DHTMLRoadmap040506.html

Il possibile metodo

Quando avevo scritto il capitolo su javascript del libro di Roberto
avevo effettuato diversi test ed ero giunto ad una problematica in
particolare (e la relativa soluzione che però era molto complessa)
tralasciando quelle di pura degradabilità.

Immaginiamo che il nostro applicativo preveda che all'attivazione di
un link (es: in gmail scrivi nuova mail) venga caricata dinamicamente
(con ajax o costruita direttamente con il DOM) una porzione di HTML
in un punto diverso del DOM. Se noi siamo utenti abili ci accorgiamo
dell'avvenimento di questa azione, ma se invece siamo ciechi noi
continueremo a sentire il punto dove si trova il focus, vale a dire
subito dopo il link.

Ora la soluzione a prima vista è ovvia e semplice, spostare il focus
nel punto dove inseriamo il nuovo pezzo di html, ma purtroppo
l'interfaccia di programmazione focusable (elementi che possono
ricevere il focus) è implementata solo da link e input.

Quindi per spostare il focus ci sono due soluzioni, o forzare un
attributo tabindex al div contenitore del nuovo html e rendendolo cosi
focusabile ma violando la DTD in memoria, oppure inserendo un ancora
vuota e puntando a quella.

fatto questo si può puntare il nuovo elemento con il metodo focus() ma
ce poi un altro problema, vale a dire che una volta che l'utente
finisce di leggere il nuovo html il focus dovrebbe essere riportato al
punto di partenza (in pratica sull'evento onblur) ma la problematica
si ripete con anche ulteriori problematiche legate al fatto che
l'evento onblur si attiva in modo strano e differente tra i vari
browser.

Già fino a quì c'è da farsi venire un bel mal di testa, ma ora
immaginiamo altre problematiche che si aggiungono nel mondo ajax come
per esempio:

• la ricezione dei dati dal server fallisce o arriva incompleta non permettendoci di agganciare correttamente tutti gli eventi vi possono essere attivazioni successive o consecutive di chiamate o anche bug dei browser che vanno in loop (che tra l'altro questo problema forza google a tenere i suoi applicativi in beta... immaginatevi un paio di milioni di browser che andassero in loop sui suoi server continuando a fare chiamate XMLHttp che tra l'altro non si possono in alcun modo bloccare)
• in alcuni casi bisogna fare cambiare le schermate in modo automatico creando un effetto tipo refresh che come sapete non permette all'utente cieco di leggere fino in fondo il contenuto
• in genere in un applicativo AJAX based un po complesso le funzioni concorrenti sono sempre qualche decina se non centinaio

Detto questo questo approccio testato da me unicamente in Jaws 4.5, che teoricamente è quello più corretto sotto il profilo di quello che
il DOM ci fornisce come API e dove si dice che il punto di ascolto sul
browser si dovrebbe spostare sempre dov'è il focus, quello a cui
sono arrivati anche altri e che è stato ripreso e provato anche da
sitepoint che a differenza di me lo ha testato anche in altri screen
reader.

Il risultato è pubblico (The Third Test) purtroppo in tutti gli altri
screen reader al di fuodi da Jaws non pare funzionare e quindi non
posso che giungere anchio alle stesse conclusioni del'articolo in
questione, dove alla fine IBM e Mozilla stanno spingendo per cambiare
gli screen reader, però aggiungendo un altra potenziale soluzione...
fondere tutti i metodi assieme come il cambiamento di url, la gestione
di focus su input e ancora (in sequenza) e delle ontologie di ruolo
(che sono tutto un nuovo orizzonte in xhtml 2.0 e sono sfruttabili in
mozilla).

postato da Luca Mascaro alle 21:54
2 Commenti Sphere: Related Content