(Davide Merlitti) – A distanza ormai di qualche anno dall’invenzione del termine Web 2.0 da parte di O’Reilly Media comincia a essere chiaro, grazie anche ad alcune dichiarazioni e interviste rilasciate da Tim-Berners Lee e circolate sul web, che il cosiddetto “Web 2.0” non rappresenta una nuova versione di Internet, a nessun livello tecnologico o sociale, né tanto meno una rivoluzione tecnologica.

Il Web 2.0 sembra invece denotare un insieme di modelli applicativi del web caratterizzati da alcune tecnologie emergenti, di tendenza, rese possibili dall’evoluzione di quelli che sono i componenti software basilari sui quali si regge tutto il web e cioè da un lato, i server, i distributori di informazioni, e dall’altro i browser che costituiscono la finestra delle persone sul web. Il fatto di essere basato su tecnologie emergenti ha fruttato al Web 2.0 l’appellativo di perennemente in beta, caratteristica appunto del software instabile, incompleto e quindi non ancora pronto per essere utilizzato in ambienti di produzione.
 
Nella originaria (e forse unica) visione di Berners-Lee, il web era documento-centrico: un insieme di documenti reperibili tramite il semplice meccanismo degli URL, messi a disposizione da alcuni server e fruibili tramite browser. Fu sufficiente quindi formalizzare il protocollo HTTP, il linguaggio HTML e sviluppare solo due componenti software: un server HTTP ed un browser web.

I protocolli Internet già esistenti si occupavano del trasporto delle informazioni da un capo all’altro del mondo, il protocollo HTTP si sarebbe occupato di far dialogare in modo semplice i browser ed i server, l’HTML (derivato da SGML) sarebbe servito come semplice linguaggio di formattazione dei documenti, talmente semplice da consentire la scrittura anche a mano dei documenti senza un elaboratore di testi ad hoc. Così nacque il web, in un luogo ed in un giorno precisi, Ginevra, presso il CERN, il giorno di Natale dell’anno 1990 connettendo due computer NeXT, uno nella stanza di Berners-Lee e l’altro in quella di Robert Cailliau, collega di Berners-Lee al CERN.

Da quel giorno il web ha continuato a crescere e ad evolvere in un susseguirsi di eventi che non è facile ripercorrere e che hanno portato nel giro di soli diciasette anni a quello che oggi chiamiamo molto brevemente web e che in realtà denota centinaia di tecnologie al servizio di un luogo virtuale frequentato da centinaia di milioni di persone di ogni ogni nazionalità che si informano e interagiscono per i motivi più disparati.

Molto brevemente, per tracciare una filogenesi del Web, possiamo elencare le seguenti tecnologie:

Primo nucleo di formalismi e componenti software:

1. URI, HTTP, HTML;
   
2. HttpServer, WebBrowser.

Evoluzione del lato server:

1. CGI e derivati (ISAPI, NSAPI, FastCGI etc.);
   
2. Linguaggi di scripting, framework, pattern, ambienti di sviluppo, componenti software, librerie;
   
3. Application Server (Web Application);
   
4. Web Service (SOAP, WSDL); 
   
5. Service Oriented Architecture.

Evoluzione del lato client:

1. Oggetti incorporati (Applet Java, oggetti Flash, etc.);
   
2. DOM (Document Object Model) + JavaScript; 
   
3. Rich Internet Application.

Con l’evoluzione del web e con l’emergere dei nuovi modelli, si osserva la convergenza tra le applicazioni classiche, quelle cioè basate su programmi compilati nel linguaggio macchina dei microprocessori o in linguaggi intermedi che necessitano di un notevole supporto a tempo di esecuzione, e le applicazioni cosiddette web-based, caratterizzate dall’uso di application server, web service e web browser.

Si è passati da un modello di web basato sulle capacità limitate di un browser di rappresentare informazioni codificate in HTML e di inviare dati tramite un semplice meccanismo di submit di form con il supporto del protocollo HTTP, ad un modello in cui il browser è un’interfaccia, o meglio, un ambiente grafico, universale in grado di rappresentare qualsiasi informazione (grazie al DOM e alle possibilità del CSS), gestire qualsiasi evento sia lato client che lato server (grazie a javascript e alla capacità di comunicazione asincrona tra browser e server). Il web browser è diventato insomma un componente versatile, per applicazioni assolutamente generiche, in grado di funzionare come una macchina virtuale e ospitare quindi le cosiddette rich internet application.

Il W3C, nell’ambito del famoso Web Accessibility Initiative, ha da tempo definito un task denominato WAI-ARIA Accessible Rich Internet Applications dedicato alla definizione e armonizzazione degli standard che stanno alla base delle rich internet application (Addresses dynamic Web content and rich Internet applications developed with AJAX, DHTML, and other Web technologies), proprio per considerare i problemi legati all’accessibilità. Rispetto alle applicazioni Internet classiche, dove a livello formale la situazione è ormai consolidata con le linee guida WAI-WCAG, le WAI-ARIA pongono problematiche complesse delineate e affrontate in un Working Draft del gruppo di lavoro “Protocols & Formats” del WAI pubblicato nel settembre del 2006 e che si spera produrrà i risultati attesi.

In Italia, a causa della decisione, forse troppo radicale, di includere nella Legge Stanca il tristemente famoso requisito 15 che rende molto difficile l’impiego di linguaggi di script lato browser nei siti web realizzati per la pubblica amministrazione, il problema delle RIA e dell’accessibilità delle stesse sembrerebbe eliminato alla radice e non costituire un problema per la pubblica amministrazione.

E’ evidente infatti che, se nelle normali applicazioni web, con accorgimenti tecnici non particolarmente avanzati è possibile realizzare pagine web fruibili ugualmente con e senza javascript, per le RIA il linguaggio di scripting è di vitale importanza e assolutamente non prescindibile per il funzionamento delle stesse. La conseguenza naturale delle limitazioni imposte dal requisito 15 è, da un lato l’esclusione delle tecnologie tipiche del web 2.0 nella realizzazione delle applicazioni internet per la pubblica amministrazione con l’evidente svantaggio per quest’ultima di non poter competere con le funzionalità offerte dall’applicazioni web sviluppate in un contesto internazionale; dall’altro lato, la disincentivazione delle aziende italiane ad investire in tecnologie addirittura illegali pagando così lo scotto di una ulteriore arretratezza tecnologia.

Il requisito tecnico numero 15 del D.M. 8 luglio 2005 recita: Garantire che le pagine siano utilizzabili quando script, applet, o altri oggetti di programmazione sono disabilitati oppure non supportati; ove ciò non sia possibile fornire una spiegazione  testuale della funzionalità svolta e garantire una alternativa testuale equivalente, in modo analogo a quanto indicato nel requisito n. 3.
Riferimenti WCAG 1.0: 6.3
Riferimenti Sec. 508: 1194.22 (l), 1194.22 (m)

Ho chiesto ad Oreste Signore, ricercatore presso il CNR-ISTI e responsabile dell’Ufficio Italiano del W3C, qual è la posizione ufficiale italiana nei confronti di questo problema.

In realtà si tratta di una posizione in parte ufficiale, in parte personale. Vanno considerai due aspetti: lo spirito con il quale è stato introdotto il requisito 15 e la necessità di mantenersi allineati con l’ evoluzione tecnologica del Web.

Per quanto concerne il primo aspetto, occorre ricordare che storicamente il vincolo deriva dalla possibile interferenza tra le tecnologie assistive e il codice javascript presente nella pagina. Ad oggi, questo problema è in gran parte superato, in quanto le tecnologie assistive più diffuse (es. JAWS) nelle loro versioni più recenti non presentano problemi di incompatibilità.

Tuttavia, non è possibile abolire tout-court il requisito, in quanto un sito pubblico è destinato a una grande varietà di utenti, e quindi non è ipotizzabile che tutti gli utenti siano allineati con le versioni più recenti delle tecnologie. Questo aspetto è stato considerato, infatti, nella definizione delle regole tecniche per l’ e-learning, dove si è potuto supporre che gli utenti disponessero di browser e tecnologie ragionevolmente recenti.

Per il secondo aspetto, anche in coerenza con le linee guida descritte nella suite WAI-ARIA, l’ ultima versione delle WCAG introduce il concetto di accessibility-supported per descrivere le tecnologie che funzionano correttamente con le tecnologie assistive e le caratteristiche di accessibilità degli user agent. Tutte le informazioni e le funzionalità della pagina devono essere presentate usando tecnologie accessibility-supported.

In questo modo viene lasciata aperta la possibilità di sviluppare applicazioni sempre più ricche, a mano a mano che evolvono le tecnologie assistive e le caratteristiche dei browser. A parte i vincoli normativi, che potrebbero in futuro anche essere resi meno rigidi, va però tenuto presente che lo spirito della legge 4/2004 è quello di rendere fruibile l’ informazione anche alle categorie deboli o svantaggiate.

Quindi, è nella progettazione della pagina e delle sue funzionalità che occorre considerare i problemi che potrebbero derivare da un utilizzo “estremo” di javascript. Oltre tutto, va tenuto presente che il javascript potrebbe essere disabilitato anche per altri tipi di esigenze (in alcune organizzazioni questo viene imposto per evitare che i dipendenti accedano a siti particolari).

Vale quindi sempre il suggerimento di evitare il javascript in tutti i casi in cui si possono ottenere gli stessi effetti per altra via (per es. con un uso appropriato dei CSS), e di farne un uso accorto. A mio parere la strada tracciata dalla suite WAI-ARIA è molto interessante.

Una volta caratterizzati gli elementi di interfaccia in base ad un’ ontologia, possono essere definiti dei comportamenti standard che lo user agent deve adottare (per es. aprire o chiudere un albero in funzione dello stato e del ruolo di  un certo elemento) e quindi liberare il codice (X)HTML di tutti quegli accorgimenti imposti dalla necessità di garantire l’ accessibilità dei siti.

A questo proposito, mi sembra opportuno sottolineare che l’ accessibilità dei siti deve essere garantita non perché è un obbligo di legge, ma semplicemente perché un sito Web che non sia accessibile contraddice la filosofia di base del Web.

Scritto da