Crasch

Il blog di Carlo Folini
posts - 33, comments - 734, trackbacks - 253

Accessibilità con asp.net

Dovendo incastrare la legge Stanca in asp.net (uso la 2.0) ci si scontra con la difficoltà di estendere i controlli per effettuare un rendering custom.

I controlli asp.net sono compliant con la 508 (http://www.section508.gov/) che però (purtroppo) è molto più light della WCAG (http://www.w3.org/TR/WAI-WEBCONTENT/) che, dal mio punto di  vista, è ancora meno stringente della legge Stanca (http://www.senato.it/japp/bgt/showdoc/frame.jsp?leg=14&id=00078630&tipodoc=Ddlpres&modo=PRODUZIONE).
Questa prevede una verifica formale dei 20 punti 'tecnici' (http://webnews.html.it/news/2528.htm)  e una soggettiva in cui un team di disabili verifica l'effettiva usabilità del sito.

Per riassumere i siti devono avere gli attributi ALT a tutte le immagini, non devono usare le tabelle per il layout (solo css), i contenuti dinamici devono essere disabilitabili (no javascript), nessun popup, niente frame.

Sommando tutti questi requisiti, che in dosi adeguate mi trovano completamente concorde, rendono la scrittura di un sito un incubo.

Per alleviare il peso della compliancy alla legge ho pensato quindi di usare i componenti asp.net 2.0.
Come dicevo se generate una pagina asp.net e la validate con il tool di verifica dell'accessibilità di vs2005 vi ritrovate con un tot di segnalazioni di errore.
Scatta quindi il solito build or buy.
Componenti asp.net ce ne sono tonnellate, cercando delle suite che ne contengano un numero congruo, sono finito su ComponentOne e Infragistics.
Il primo ha solo una compliance con la 508 (ancora nulla per la 2.0).
Il secondo pur non avendo una versione trial della 2.0(solo per chi ha una licenza per la 1.1) dice che il supporto per l'accessiblità è lo stesso. Da un rapido controllo è completamente dipendente dal javascript.

NOn avendo trovato nulla di pronto l'unica alternativa è farselo in casa.

L'idea è quindi di estendere i componenti asp.net 2.0 per renderli completamente server side e aggiungere css quanto basta.
Strano che tutti i controlli utilizzino la funzione __doPostBack (es. href="javascript:__doPostBack('Menu1','New Item1')"), quando una semplice href poteva bastare (href="MyPage.aspx?Menu1=New Item1").

L'estensione però non è banale non trovando grossi agganci per estendere solo la parte di rendering.
Il primo esempio è il Menu.
L'idea iniziale è quella di togliere il supporto javascript.
Modifico il file .browser (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50110\CONFIG\Browsers\ie.browser) impostando a "0.0"  l'"ecmascriptversion". Rigenero la factory (aspnet_regbrowsers.exe) provo...
Nada il javascript è ancora presente....
Magari un baco della CTP di febbraio, magari il componente non sà nulla delle browsercapability, magari ho ciccato qualcosa.
Quindi estendo la classe Menu per non fargli emettere il codice javascript.
Il Menu è costituito da una collection di MenuItem, ognuno con la propria render.
Purtroppo la classe è sealed per cui non c'è modo di intervenire a livello di Item. Nella Render del Menu bisogna quindi fare tutto il lavoro, scordandosi le bellezze della OO.
Magari c'è qualche metodo più brillante per estendere le classi, ma non mi viene in mente nulla.

 

 


 

Print | posted on mercoledì 23 marzo 2005 20:02 | Filed Under [ .Net ]

Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET