Paradosso Accessibile 2.0

Paradosso Accessibile 2.0

Alcuni giorni fa c’è stato parecchio rumore sulla

[!] Ci sono problemi con l’autore. Controllare il mapping sull’Author Manager

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

[!] Ci sono problemi con l’autore. Controllare il mapping sull’Author Manager

di

[!] Ci sono problemi con l’autore. Controllare il mapping sull’Author Manager

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

[!] Ci sono problemi con l’autore. Controllare il mapping sull’Author Manager

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.

[!] Ci sono problemi con l’autore. Controllare il mapping sull’Author Manager

infatti, come lo sono l’

[!] Ci sono problemi con l’autore. Controllare il mapping sull’Author Manager

Strict ed il

[!] Ci sono problemi con l’autore. Controllare il mapping sull’Author Manager

altrettanto consigliati, è il modo migliore per interagire con il

[!] Ci sono problemi con l’autore. Controllare il mapping sull’Author Manager

e non ha niente a che fare con l’

[!] Ci sono problemi con l’autore. Controllare il mapping sull’Author Manager

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

[!] Ci sono problemi con l’autore. Controllare il mapping sull’Author Manager

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?

Questo articolo contiene link di affiliazione: acquisti o ordini effettuati tramite tali link permetteranno al nostro sito di ricevere una commissione nel rispetto del codice etico. Le offerte potrebbero subire variazioni di prezzo dopo la pubblicazione.

Ti consigliamo anche

Link copiato negli appunti