[webaccessibile] Backoffice & WCAG

Roberto Scano - IWA/HWG rscano a iwa-italy.org
Ven 26 Mar 2004 13:45:14 CET


----- Original Message ----- 
From: "Cyberbuddha" <cyberbuddha a digiartstudio.com>
To: "'La mailing list di webaccessibile.org'"
<webaccessibile a itlists.org>
Sent: Friday, March 26, 2004 1:11 PM
Subject: R: [webaccessibile] Backoffice & WCAG


Toglimi un dubbio Roby... A volte faccio fatica a comprendere il limite
tra
accessibilità e compatibilità e parlando di CMS ed editor la cosa mi si
complica un po'.
Prendiamo ad esempio un content management come se ne vedono molti, che
sfrutta l'engine del browser (es: mshtml di IE) per l'editor oppure un
activeX (tipo Xstandard) e che ha una serie di strumenti che fanno largo
uso
di javascript e dhtml per rendere le pagine web più vicine ad un
software
che a un sito.
Tutto a favore dell'uso dello strumento, la tecnologia serve per questo.

Roberto:
Occhio a non limitarsi al plugin... Tutto il backoffice, per garantire
l'accessibilità, dovrebbe conformarsi alle WCAG (vedi ad esempio il
discorso dei campi modulo, i gruppi di collegamenti, ecc. ecc.).
Il plug-in "potrebbe" conformare alle ATAG oppure potrebbe eseguire le
indicazioni delle WCAG 1.0 relative agli oggetti:

* Punto di controllo 6.3 (Priorità 1)
"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."

In questo caso l'editor deve prevedere una versione <noscript>
contenente eventualmente un textfield, textfield che può essere
contenuto all'interno dell'elemento <object> nel caso non sia presente
l'oggetto.

* Punto di controllo 8.1 (Priorità 1 in quanto importante)
"Fare in modo che elementi di programmi come script e applet siano
direttamente accessibili o compatibili con le tecnologie assistive
[Priorità 1 se la funzionalità è importante e non presentata altrove,
altrimenti Priorità 2]."

Qui si passa alla competenza ATAG e UAAG...

* Punto di controllo 6.4 (Priorità 2)
"Per quanto riguarda script e applet, assicurarsi che i gestori di
eventi siano indipendenti dai dispositivi di input."

* Punto di controllo 9.2 (Priorità 2)
"Assicurarsi che ogni elemento che possiede una sua specifica
interfaccia possa essere gestito in una modalità indipendente da
dispositivo."

* Punto di controllo 9.3 (Priorità 2)
"Negli script, specificare gestori di evento logici piuttosto che
gestori di evento dipendenti da dispositivo."

Questi sono in ogni caso un must...



Cyberbuddha:
Se si rendono accessibili le varie sezioni interattive perdendo le
funzionalità avanzate (un semplice textfield al posto dell'editor, un
elenco
di 200 voci al posto di un treeview in js, ecc...), si può dichiarare
accessibile anche se, di fatto, non più così utile allo scopo (rendere
semplice per i non esperti aggiornare i contenuti)?
Altrimenti, è più facile rendere accessibile un software desktop per il
CMS
che una versione web-based.

Roberto:
Basta seguire le regole sopra e trovare un plug-in che sia accessibile
tramite tecnologie assistive. Altrimenti (vedi
www.robertoscano.info/files/ATAG10) effettivamente risulta più semplice
sviluppare un'applicazione client accessibile.



Maggiori informazioni sulla lista webaccessibile