Re: [webaccessibile] Accessibilità delle tecniche co n XMLHttpRequest

Andrea Martines andrea.martines a gmail.com
Mer 9 Feb 2005 14:14:15 CET


Cyb:
Nel web non ci sono solo siti anzi, si stanno cercando modi per rendere le
applicazioni sempre più "desktop" ... 
Perché negargli l'esistenza solo perché c'è chi non può sfruttarli? 

Andrea:
Secondo me avete portato la discussione verso un punto a cui io non
volevo arrivare: non volevo affatto inibire chi progetta prodotti non
perfettamente accessibili, volevo al contrario stimolare gli esperti
per trovare delle soluzioni che consentano di renderli tali.

-------

Luca:
Devi fare in modo che funzioni in normale html e form magari in maniera
asincrona, sempre che abbia senso.

Andrea:
Credo che l'utilità di sviluppare con XMLHttpRequest sia proprio nel
consentire una ricca e prolungata sessione di interscambio con il
server senza ricaricamento della pagina. E per il momento credo
l'unica modalità asincrona per rendere accessibile un processo di
questa complessità sia di consentire il suo spezzettamento
multipagina, cioè progettare una modalità alternativa che si comporti
come le applicazioni attuali: insomma, chiusi fuori dalla porta i siti
alternativi ci rientrano dalla finestra le applicazioni alternative!

Luca:
devi trattare l'applicazione qualunque sia come un sistema lineare non
finito, in pratica se tu carichi un contenuto dal remoto in un determinato
punto della pagina dovresti spostare li il focus, permettere la lettura e
ritornare al punto di partenza. In pratica si tratta di modellare il
percorso del focus nella pagina senza fargliene rendere conto all'utente.

Andrea:
Mica basta: dovresti rimodellare al volo tutti i riferimenti semantici
della pagina all'oggetto che, mutando contenuto, spesso cambia
funzione. Se hai un form in origine e questo cambia dinamicamente in
una pagina di risultati, dovrai cambiare anche i riferimenti negli
eventuali sommari accessibili, breadcrumb, title della pagina, tag H1
ecc..., altrimenti ti troverai una pagina con contenuti non
sincronizzati.
Ma in questo modo tu hai cambiato parecchie cose contemporaneamente, e
quindi il concetto di spostare il focus all'elemento mutato perde di
efficacia! E se oltre al contenuto principale (seguendo l'esempio, il
form diventa dinamicamente un elenco di risultati di ricerca)
l'operazione fa mutare contemporaneamente altri oggetti? Poniamo,
cambia il contenuto di un menu contestuale in una sidebar? La vedo
dura la tecnica di gestione del focus, perché presuppone che cambi
solo un elemento per volta, localizzato. Ci sono strade alternative?

-------

Michele:
Credo che chi sta
dietro a Google abbia investito tesori di tempo e di risorse nella
ricerca del codice e dell'interfaccia utente migliori in relazione
allo scopo prefisso. Penso quindi che abbiano risolto il problema
dell'accessibilità a modo loro: non seguendo le WCAG e privilegiando
consapevolmente alcune categorie di utenti a danno di altre, molto
meno numerose. Scelta eticamente non condivisibile, ma dire che non
sappia cos'è l'accessibilità proprio il sito che fa del poter essere
consultato da tutti, in tutte le lingue, la propria missione, mi
sembra quanto meno strano.

Andrea:
Michele, noi tutti ormai abbiamo dei pattern di sviluppo che ci fanno
collegare immediatamente fra loro esigenze e tecniche correlate. Vista
la home page di Google, immediatamente pensiamo che QUEL design,
caratterizzato da semplicità e pulizia, debba e possa facilmente
essere realizzato con le tecniche web standard (tra cui design
tableless, la separazione di dati e presentazione, il doctype,
l'attributo Type nel tag Style ecc...) e con semplici accorgimenti di
accessibilità (specie nel form).
Quale scelta consapevole di target, quale politica aziendale può
spiegare il fatto che, ad oggi, quella pagina ignori invece queste
elementari regole di sviluppo? Proprio per essere accessibile al
maggior numero possibile di persone dovrebbe essere sviluppata in un
certo modo, che tra l'altro non comporta alcuna controindicazione
verso l'utenza normodotata. Ed è una semplice pagina HTML statica, non
necessita quindi di rielaborazione del CMS retrostante.
Perché, dunque, è così deludente? La risposta di Luca dà una
spiegazione possibile. Non ne vedo altre.

Ciao a tutti



Maggiori informazioni sulla lista webaccessibile