[webaccessibile] Metà delle ricerche mondiali sull'accessibilità del web sono in italiano

[Luca Mascaro]

Fondo le due discussioni per praticità

> Non so dove hai trovato queste informazioni ma non coincidono con quanto riportato sul sito:
>
> "The Regions and Languages tabs work just like the Cities tab. Google Trends uses IP address information from our server logs to make a best guess about where queries originated.
> Language information is determined by the language version of the Google site on which the search was originally entered."

Interessante, non avevo notato la pagina di descrizione del servizio,
stamattina mi ero cercato di informare attraverso i commenti su
technorati (la mia fonte di informazioni preferita :).

http://www.technorati.com/search/google%20trends

In ogni caso è comunque interessante il fatto che partano dal .it, ora
supponendo che l'ipotesi di stefano (anglofoni che usano il .it) sia
giusta di quanto può essere deformata la cosa? io non penso più di un
10-20% e comunque è una cifra impressionante di ricerche di web
accessibility dall'italia

> Qui hai indubbiamente ragione ma il punto resta: quanti sono quelli che sentono il bisogno di andare alla fonte a documentarsi sulle WCAG quando vengono già spiegate in modo soddisfacente nella propria lingua, magari anche da una bozza di legge? Forse anche chi non riusciva a credere che dicessero proprio quello, d'accordo.
>

Può darsi, sta di fatto però che a parte qualche traduzione il grosso
delle techniques e della documentazione resta in inglese, tanto che
anche il decreto con i 22 requisiti rimanda parti alle WCAG

> Anche qui sono determinanti gli italiani all'estero oppure ci sono molti anglofoni che usano il .it?
>

Non lo possiamo sapere... ma di certo è una cosa che non mi spiego con
il buon senso

> Si, è quello che dico anch'io, non mi sembra di ricordare che la legge sia stata pubblicata sulla gazzetta ufficiale come un fulmine a ciel sereno. Chi si ricorda com'è andata confermerà che è stata in lavorazione per lungo tempo e che ha suscitato dibattiti da ben prima che venisse ratificata.
>

Esatto, e quei dibattiti risalgono più o meno a quel periodo quindi la
correlazione di ricerca di informazioni - legge potrebbe essere anche
fondata... vabbè comunque ci siamo capiti, passiamo al resto :-)

> Ho apprezzato molto lo sforzo ma purtroppo non sono riuscito a cogliere alcun nesso specifico tra la tua risposta su questa lista e la discussione su www-forms. E se c'era, la mia richiesta era quella di andare a rispondere là dove c'è chi sta impostando la questione in modo da spacciare come accessibili delle soluzioni che palesemente non sono mai neanche state sfiorate dal problema accessibilità.

Non ti ho ripetuto pari pari la stessa discussione della lista Xforms,
ma cercavo di parlarti più ad alto livello nel senso che secondo la
filosofia delle WCAG se un linguaggio è interpretato lato client deve
essere il suo user agent a conformarsi per l'accessibilità (per
capirci Xforms ha delle tag che forniscono informazioni alternative
vedi la più banale: xf:label ed è compito di per esempio Forms Player
fornire l'accessibilità agli screen reader).
Se invece è interpretato lato server li in fondo produce XHTML e
quindi valgono le solite regole sia per i form sia per javascript.
Detto questo è vero che oggi non ci sono implementazioni decenti e io
stesso mi sono dovuto reimplementare tutti gli xsl di rendering in
cocoon.

> Dovrebbe essere terreno facile per chi la questione la conosce bene ma non meno utile
>per tutti noi poveri ignoranti che abbiamo creduto che all'obiettivo
di maggiore accessibilità
>che XForms si prefigge esplicitamente corrispondesse un qualche
risultato per lo meno
>misurabile o discutibile nel concreto invece che astrattamente e in
modo totalmente
>slegato dallo stato attuale delle raccomandazioni W3C in termini di
accessibilità e >conseguenti leggi derivate.

Onestamente il linguaggio mi pare fornire le basi tecniche per
l'accessibilità (accesskey, hint, label, ...) poi se queste rimangono
teoriche non è certo colpa del w3c :-(

> Il tuo citare il problema del focus almeno un po' mi ha confortato invece, visto che effettivamente è il problema di fondo che sottende alle problematiche specifiche. Ma la tua spiegazione generica e un po' confusa, conclusa da un link totalmente generico e ovvio non mi hanno aiutato molto a capire di più e mi avevano un po' disilluso.

Perchè se ne parla in modo sporadico proprio in questi periodi, se n'è
discusso nelle techniques per javascript delle wcag, ci sono degli
accenni non tecnici nel documento Dynamic Accessibile Web Content
(http://www.w3.org/WAI/PF/roadmap/DHTMLRoadmap040506.html), se ne
parlerà nel gruppo web api probabilmente come nuovi metodi del DOM
level 3, se n'è parlato in concreto negli ultimi anni anche in questa
lista dove avevo proposto la soluzione di inserire al volo ancore
spostare i focus manualmente e gestirne in seguito il ritorno tramite
blur (ho una semplice implementazione di esempio in cocoon se ti
interessa te la mando)

> Anche l'accenno a una divisione tra i "semplici siti" e le "web application interattive" mi ha un po' spaventato, diciamo che mi sono ripromesso di cercare cosa vuol dire "baseline" all'interno delle venture WCAG.

Allora la divisione non formalizzata tra semplici siti e web
application e semplicemente guardare la differenza che c'è tra un
portale informativo e gmail... il secondo rientra tra le web
application per cui sono nati alcuni gruppi di lavoro ad hoc che
stanno sviluppando dei nuovi linguaggi per la gestione di Applicazioni
Software online (che usano sotto XHTML 2.0 e Xforms)

Anche il discorso di baseline sarebbe lungo ma per capirci un esempio
è: se io faccio un sito nella mia intranet dove garantisco sempre la
presenza di javascript e applet posso sviluppare il tutto direttamente
accessibile senza garantire che funzioni senza queste due tecnologie
(sono praticamente i prerequisiti tecnologici)

> O forse è la controprova che l'atteggiamento è proprio quello elitario di chi crede di poter decidere per gli altri meglio di quanto possano questi decidere da sè?
>

L'atteggiamento non è certo quello e non mi sembra che sia così dentro
il w3c, infatti anche per tutti i gruppi chiusi ci sono sempre delle
liste pubbliche informative che vengono seguite. In ogni caso l'ultima
parola (a parte quella di Tim :-) non spetta neanche al gruppo di
lavoro ma ai membri del TR che sono praticamente tutte grandi aziende.

> Per poi cozzare con il mondo che va avanti lo stesso, ignorando le supposte (in tutti i sensi) "best practices"?
>

Dipende da quali specifiche, certo che alcune sono difficilmente
implementabili ma se pensi che per esempio XHTML 2.0 ha già almeno 2
implementazioni native quasi complete non è male :-)

> Un link più interessante per fortuna l'ha indicato invece un membro dell'XForms WG su www-forms, d'altronde se questa è oggi una bozza di roadmap, mi sa che la strada da fare è ancora lunga, altro che last call fits all:
>
> http://www.w3.org/WAI/PF/roadmap/

ecco... è lo stesso link che ti stavo postando io (giuro che non ero
ancora arrivato a leggere questo pezzo di mail :-)

A questo punto ti suggerisco anche un altro documento che contribuirà
all'accessibilità dei cosidetti widget e che sono le ontologie di
ruolo per gli oggetti di interfaccia in XHTML 2.0

http://www.w3.org/WAI/PF/GUI/

> Cioè far cadere dall'alto il link a giochi fatti, magari in forma di specifica formale e quindi priva del dibattito necessario a giustificarla e spiegarla appieno a tutti.
>

No cosa centra... per esempio la discussione sui capcha accessibili
era nata in diversi newsgroup, il gruppo PF ne ha preso nota di tutte
le discussioni e le ha discusse e formalizzate... non mi sembra un
comportamento scorretto

> Forse però ciò avrebbe portato maggiore qualità. Ad ogni modo qui stiamo divagando non poco, io volevo solo capire perché non vi andava di partecipare alla discussione nel merito su www-forms e mi sembra che è già stato spiegato ampiamente dal thread che ne è derivato e da questo. Mi ritengo soddisfatto.
>

Su questo non ti so rispondere perchè sono entrato in seguito,
comunque nei gruppi sulle Web App abbiamo scelto la strada
dell'apertura.

Io la sto seguendo la discussione su www-forms ma è inutile che ti
dica cose teoriche sulla specifica quando hai li le persone che hanno
implementato orbeon o Forms Player.

> Amen. Intendevo solo capire se vi era sfuggito il dibattito nel merito su www-forms o se proprio non vi interessava affatto. Ora ho capito, grazie.
>

Non è sfuggito almeno a me

> Ah meno male che non tutti hanno competenza in tutto. Per fortuna. Quelli che fanno parte dei gruppi di coordinamento però per definizione non hanno competenza approfondita su niente a questo punto...
>

Questo non è vero, prendi per esempio il gruppo PF del WAI, loro non
hanno teoricamente (poi sono le stesse persone) competenze in ambito
di accessibilità in senso generale ma avendo conoscenze di OWL e di
XHTML 2.0 per esempio hanno sviluppato le ontologie di ruolo per le
interfacce richieste dalle WCAG... voglio vedermi uno psicologo
cognitivo esperto di disabilità a scrivere ontologie OWL :D

In fondo è il lavoro delle formichine, ognuno fa del suo meglio per il
gruppo con dei compiti specifici

> Eh a me bastava che uno dico uno che si assumesse la responsabilità di capirne di WCAG desse una risposta su www-forms riguardo a questioni specifiche molto banali (per chi fa parte del WAI).
>

Mhhh il mio dubbio è che se rigiri la domanda anche in WAI succede che
ti dicono che la specifica prevede l'accessibilità... poi le
implementazioni sono un altra cosa

> cocoon? un po' troppo impreciso, penso che tu intenda chiba

In generale

http://wiki.apache.org/cocoon/XFormsInCocoon

Tra cui un implementazione è quella di chiba in Chicoon

> Ma scherzi? Vuoi dire che siccome un'implementazione XForms lato server genera HTML allora non è più di competenza del gruppo di lavoro XForms? E allora perché sono entrati nella discussione molti autorevoli rappresentanti del gruppo tra cui il presidente, autore della prossima versione della specifica?
>

Onestamente io non scherzo, poi chiaramente è una mia opinione
personale e dovrei parlarne con il gruppo, ma se al client arriva un
normale form html e lato server è Xforms tu di chi valuti
l'accessibilità?

Il problema per l'accessibilità alla fine è sempre ciò che arriva al client.

> Non ti sembra di avere un approccio un po' troppo burocratico e un po' troppo impostato sul metodo tanto da non aver ancora sfiorato il merito della questione accessibilità delle soluzioni XForms lato server (e implementazioni XForms accessibili) così come è stata posta su www-forms?
>

Torniamo al concreto, ma se Xforms ha al suo interno tutte le
metainformazioni necessari per ottenere l'informazione in maniera
accessibile, la problematica si sposta sul client e quindi su HTML,
CSS, Javascript, DOM, ecc... dove le soluzioni tecniche sono già state
discusse da tempo. Il problema ora è semmai creare un corretto
adattamento tra i due layer.

Forse mi sono perso qualche post in particolare su cui volevi porre la
mia attenzione?

ciao

Luca