Paradosso Accessibile 2.0

Alcuni giorni fa c’è stato parecchio rumore sulla normativa olandese in termini di accessibilità e perchè no di Web 2.0, dato che tale normativa è rivolta soprattutto ai nuovi siti.

Nonostante abbia già espresso sul post dedicato di Edit quello che è il mio pensiero riguardo il confronto con la normativa italiana, vorrei cogliere l’occasione per esporre la mia tesi sul paradosso dei linguaggi di scripting, JavaScript, e le linee guida di riferimento, premettendo che tale tesi sia basata esclusivamente su una mia interpretazioni di alcuni punti delle stesse.

A differenza dell’Olanda in Italia si punta molto sul rispetto degli standard, anche se allo stesso tempo qualora sia stato utilizzato uno script, questo non deve in alcun modo vincolare l’utente, il quale dovrà avere il sacrosanto diritto di poter godere delle informazioni e funzionalità della pagina proposta anche in assenza di compatibilità … ed è proprio sul punto scripting che vorrei dire la mia.

In Olanda sembra si sia data molta importanza allo scripting al punto da consigliare di:

• aggiungere links basati sullo scripting solo tramite questo stesso
• utilizzare il DOM per interagire con gli elementi della pagina

Direi eccellente, non solo perchè si introduce un ulteriore “strato” al servizio, funzionalità avanzate non per forza degradabili ma implementabili tramite scripting, soprattutto perchè si consiglia lo standard DOM il quale potrebbe anche vincolare, finalmente, i browsers “irrispettosi” degli standard ad adeguarsi ed allo stesso tempo si agevola gli sviluppatori a creare applicativi clients recenti, aggiornati, compatibili con tali standards e quindi “più longevi”, implicando automaticamente costi minori per la manutenzione, d’obbligo in portali articolati.

Il DOM infatti, come lo sono l’XHTML 1.0 Strict ed il CSS altrettanto consigliati, è il modo migliore per interagire con il markup language e non ha niente a che fare con l’innerHTML o le procedure spesso discutibili sfruttate dalle interazioni asincrone, Ajax, per popolare un elemento di informazioni. Essendo inoltre standard nonchè più recente permette agli stessi sviluppatori dei browsers di avere linee guida ben definite dal W3 per supportare al meglio le specifiche.

Il paradosso della normativa italiana è quindi il seguente:

1. Realizzare le pagine e gli oggetti al loro interno utilizzando tecnologie definite da grammatiche formali pubblicate, nelle versioni più recenti disponibili quando sono supportate dai programmi utente (primo requisito)
2. lo script non dovrebbe vincolare le funzionalità del portale (requisito 15)
3. le funzionalità veicolate per mezzo di programmazione o oggetti che utilizzino tecnologie non definite da grammatiche formali pubblicate devono essere direttamente accessibili (requisito 17)

Questi i punti più importanti, da me interpretati e presi in esame. Partiamo dal fatto che il solo primo punto si contraddice, dato che se scrivessimo siti veramente standards, tutti gli utenti che navigano con il browser Internet Explorer, circa l’80% dei navigatori, sarebbero tagliati fuori a causa dello storico mancato rispetto da parte di tale browser, almeno fino all’ultima versione, per gli stessi. Ed ecco infatti che entra in gioco la seconda parte del punto in esame, “quando sono supportate dai programmi utente” … che azzera le considerazioni appena fatte sugli standards. Perchè non promuovere invece banalmente l’uso esplicito di tecnologie definite da grammatiche formali, e basta? Questo solo punto implica, sencondo me, le seguenti considerazioni:

• non usare gli standards perchè distribuire gratuitamente un browser alternativo e rispettoso “costerebbe troppo”
• puoi usare innerHTML e tutti i metodi proprietari e non ufficiali che vuoi purchè ufficiosamente riconosciuti anche da altri browser
• il W3 perde tempo ad aggiornare, proporre e curare tutti gli aspetti del Web, dato che la maggiorparte degli utenti, compresi “alcuni” sviluppatori browser, ignorano la problematica ed il consorzio stesso

Quindi, utilizzare gli standards e le nuove tecnologie formali … senza incoraggiare gli sviluppatori a sfruttare gli standards e le nuove tecnologie formali, vedi il DOM. Il punto 2 e 3 invece li interpreto in questo modo:

• non è possibile aggiungere funzionalità tramite scripting a favore di una maggiore usabilità del sito per tutti coloro che potranno utilizzarle
• tutte le volte che usi innerHTML o outerHTML invece del DOM, cerca di ricordare che il markup iniettato deve essere direttamente accessibile

Secondo voi quanto c’è di discutibile in questa mia interpretazione? C’è qualcuno capace di spiegarmi bene perchè in Olanda si impone l’uso di DOM e “si agevola” in qualche modo anche lo scripting, parte integrante del Web 2.0 ed estremamente utile, in alcuni casi, in termini di usabilità, mentre in Italia non è nemmeno chiaro se bisogna utilizzare questi standards, oppure no?

Sono solo io ad avere tanta confusione in merito?