[webaccessibile] Gli standard web sono inutili (dasoli) [lungo]

Roberto Ellero rellero a webaccessibile.org
Gio 18 Mar 2004 19:11:25 CET


La questione è interessante. Personalmente non sono persuaso del riferimento
delle WCAG al backoffice allo stesso modo del lato utente. Vorrebbe dire che
il backoffice dovrebbe essere utilizzabile anche, ad esempio, con Lynx.

Poniamo che il backoffice in cui si attiva l'editor basato su JS sia
accessibile, e che quindi sia fruibile appieno anche senza JS (è il caso del
sito universitario cui mi riferivo), ma non lo sia unicamente per l'uso
dell'editor
(limitiamo per ora il discorso al solo supporto JS).

Senza supporto JS attivato, con HTMLArea è comunque disponibile la textarea,
per contenuti semplici basterà saper utilizzare <p> e <br /> per poter
pubblicare testi.

L'editor in sé non mi sembra possa considerarsi contenuto in quanto fruibile
o meno, poiché la fruibilità ha significato per l'editor solo in quanto
generatore di contenuti, e allora siamo in ambito ATAG.

Considerando il punto di controllo 6.3: "Assicurarsi che le pagine siano
utilizzabili quando script, applet, o altri oggetti di programmazione sono
disabilitati oppure non supportati. Se questo non è possibile, fornire
informazione equivalente in una pagina accessibile alternativa. [Priorità
1]", mi sembra rivolto all'utente del frontoffice, poiché l'utente dovrà
poter fruire dell'informazione e dell'interazione anche con programmi utente
che non supportano in modo nativo JS.

Posso essere d'accordo che il backoffice debba poter essere utilizzato anche
senza supporto JS, ma non ne vedo il beneficio in concreto. Come già detto,
allora il backoffice dovrebbe potersi utilizzare anche con browser solo
testo, con palmari, con versioni datate dei browser.
Ora, esistono editor che funzionano con NS 4.7?
HTMLArea funziona con IE 5.5 e 6 e versioni recenti di NS e Mozilla.
Considerato questo, per quale motivo utilizzando questi browser si dovrebbe
disattivare il supporto browser?

Quindi il problema non è JS ma semmai la compatibilità browser.

Mentre sarebbe un problema irrisolvibile se il CMS fosse pubblico, quindi
aperto al contributo degli utenti (e non è un caso impossibile, si pensi
all'utilità di una rivista online aperta ai cittadini), per un CMS dedicato
ad una redazione o si accetta che si usino certi browser e aggiornati, o si
decide di rinunciare ai sistemi di gestione dei contenuti.

Se si volesse considerare il punto di controllo citato e le WCAG in generale
con riguardo al lato amministratore, si presenterebbero inoltre ben altri
problemi. Ad esempio, il sistema richiede i CSS attivati?
Il sistema di
backend del sito universitario che curo funziona anche senza senza CSS e JS,
ma rimane il problema della risoluzione del monitor (noto però testando che
anche a 640x480, grazie alla possibilità di lavorare senza CSS e al layout
tableless, non ci sono problemi anche a questa risoluzione. La textarea è
comunque disponibile anche senza JS).

Rimane la compatibilità browser lato backoffice.

Si tratta di decidere se è un problema che
riguarda solo le ATAG o anche le WCAG. sarei della prima ipotesi.
Credo che se un editor wysiwyg in grado di pulire il codice funziona con NS
e con IE
5.5 (con JS attivati) non sia da scartare. Mentre è indiscutibile che il
lato
utente debba essere fruibile con qualsiasi configurazione, in un ente
è improbabile che la scelta browser sia caduta su un browser solo testo, se
poi fosse presente una versione NS 4 o IE 3 o 4, non vedo il problema di
aggiornare i browser, cosa anche utile per aumentare la sicurezza.

Saluti,
Roberto Ellero




Maggiori informazioni sulla lista webaccessibile