[webaccessibile] Legge Stanca e 22 requisiti: la guida di Scano

[Roberto Scano - IWA/HWG]

----- Original Message ----- 
From: "Lorenzo Ferrara" <ml a lorenzoferrara.net>
To: "La mailing list di webaccessibile.org" <webaccessibile a itlists.org>
Sent: Monday, October 15, 2007 6:53 PM
Subject: Re: [webaccessibile] Legge Stanca e 22 requisiti: la guida di Scano


Da quanto leggo, riesco a capire che anche il backend deve essere
accessibile, "in quanto sono di fatto delle pagine web", volendo citare
Roberto Scano. Mi chiedo, però, come facciano molti siti istituzionali
ad avere un backend come typo3.

Roberto Scano:
Come fanno molti ad avere case senza averne diritto, altri come fanno ad 
acquistare servizi di dipintura per 160 mila euro...
Il problema è sempre quello: qualcuno che ha un interesse direttamente leso 
(vedasi: concorrente che partecipa a medesima gara di selezione), può agire 
in giudizio.
Il problema come dicevo sopra è di trovare poi qualche magistrato che ne 
capisce... altrimenti fai la causa per nulla (e posso darti precedenti...)

Lorenzo Ferrara:
Se, come penso, la legge Stanca non tralascia il backend, vuol dire che
alcuni siti istituzionali hanno qualcosa che non rispetta la legge,
anche se si tratta di un'area non visibile al normale visitatore.

Roberto scano:
Giustissimo.

Lorenzo Ferrara:
Ancora, se anche il backend deve essere accessibile secondo la legge
Stanca, mi piacerebbe sapere come è stato risolto questo problema dagli
sviluppatori che seguono questa mailing list.

Roberto Scano:
Il problema dell'editor interno alle pagine è uno dei più astiosi per i cms 
"semplici" (la gestione di contenuti, menu, ecc. ecc. è facilmente 
implementabile tramite form et similia) e le soluzioni possibili sono le 
meno considerate: gli oggetti di programmazione accessibili.
I requisiti di legge applicabili in questo caso sono parecchi, ma 
soprattutto:

1. requisito 3: se manca l'oggetto / script / ... deve comunque esserci 
qualcosa che consenta all'utente di conoscerne le funzionalità e che 
consenta comunque la fruibilità della pagina
2. requisito 15: se manca l'oggetto / script / ...la pagina deve comunque 
essere fruibile (quindi, ad esempio,  è necessario che vi sia comunque una 
text area in sostituzione dell'oggetto)
3. requisito 16: script indipendente dal dispositivo: onclick , onkeypress, 
etc.
4. requisito 17: se ha una propria interfaccia (per assurdo, anche un editor 
scritto in Adobe Flash), deve essere direttamente accessibile, ovvero 
sviluppato seguendo le indicazioni per garantire le funzionalità e 
l'interazione accessibile previste dal produttore della tecnologia. Questo 
significa che se produco un oggetto Java o Flash accessibile secondo le 
linee guida degli sviluppatori della tecnologia ho rispettato il requisito 
(se un utente non usa un plugin accessibile per fruire delle caratteristiche 
di accessibilità è un problema del plug-in, non del contenuto).

Poi, per gli editor basati su js e dom injection, il problema è la 
conformità col requisito 1: se inseriscono un iframe, e la DTD dichiarata è 
strict, il codice viene invalidato.




Vedasi a tal punto W3C ATAG 1.0 - meglio le nascenti 2.0 per riferimenti su 
cosa si intende per authoring tool accessibile (stasera dovremmo approvare 
la definizione "definitiva")