Nel ’98 lavoravo per la E-text di Marco Calvo. In quel periodo lanciammo – come iniziativa di Liber Liber – un progetto di traduzione in italiano delle Specifiche HTML 4.0. Divenni il coordinatore dell’iniziativa e, come tale, mi toccò leggere più o meno tutte le traduzioni effettuate dai volontari che aderirono al progetto. Quando finalmente due anni dopo la traduzione integrale delle Specifiche HTML 4.0 vide la luce, mi ero nel frattempo familiarizzato con alcuni concetti importanti per l’accessibilità: la necessità di comporre pagine rispettose delle regole del linguaggio HTML (ovvero rispettose della sintassi definita dalla DTD prescelta), l’esistenza di elementi e attributi disapprovati, l’importanza di separare il contenuto dalla presentazione del documento, la possibilità di fornire alternative accessibili per immagini, applet, javascript e strutture a frame, e così via.

L’interesse profondo per l’accessibilità si sviluppò tra la fine del 1999 e l’inizio del 2000. In quel periodo scrissi in collaborazione con Giancarlo Fornari, allora direttore dell’Ufficio informazione del Contribuente presso il Ministero delle Finanze, un libro intitolato “Internet per le Pubbliche Amministrazioni”, che fu pubblicato ad aprile 2000.

Nell’ambito di quel libro mi occupai di scrivere i capitoli tecnici: struttura di Internet, motori di ricerca, hardware e software di base per navigare in Rete, ecc. Uno dei capitoli aveva come argomento proprio le regole di accessibilità e fu così che lessi per la prima volta le WCAG 1.0, che erano state pubblicate da meno di un anno. Un altro dei capitoli del libro consisteva in una valutazione sommaria di accessibilità – basata appunto sui concetti contenuti nelle WCAG 1.0 – di buone e cattive pratiche, scelte tra i numerosissimi siti della Pubblica Amministrazione italiana. Fu allora che capii che c’era tantissima strada da compiere nel campo dell’accessibilità e che, per farlo, occorreva far nascere una nuova mentalità tra gli sviluppatori di siti, basata su una maggiore professionalità e sul rispetto degli standard W3C.

Lavoro professionalmente in campo informatico fin dall’inizio degli anni ’90, il primo abbonamento ad Internet lo sottoscrissi nel ’95 e cominciai ad occuparmi per lavoro di sviluppo di siti web tra la fine del ’96 e l’inizio del ’97. Dunque all’epoca in cui nacque il mio interesse per l’accessibilità disponevo già di una serie di conoscenze di grafica e di HTML, che mi consentivano di svolgere impaginazioni accurate usando per lo più gli onnipresenti – allora come oggi - editor visuali.

Il fatto che, a partire dal ’98, mi sia occupato della traduzione delle Specifiche HTML 4 e, dopo di quelle, della lettura, dell’approfondimento e della traduzione di altri documenti W3C, mi ha messo in una condizione molto diversa da quella tipica della maggioranza degli sviluppatori che lavorano oggi in Italia.

La differenza è che la gran parte di coloro che sviluppano pagine web si limita ad utilizzare gli editor visuali, disinteressandosi più o meno completamente del codice che quelli generano. La ricerca dell’effetto visuale desiderato mette in secondo piano qualsiasi altra considerazione relativa al rispetto degli standard e dell’accessibilità. E questa, secondo me, è una cosa che non va bene. Lo sviluppatore professionista dovrebbe conoscere quanto meno il contenuto delle specifiche HTML, XHTML, CSS e WCAG 1.0. Sono i ferri del mestiere, gli attrezzi indispensabili per svolgere il proprio lavoro con competenza.

Direi addirittura che l’assunzione di un dipendente o di un collaboratore con mansioni di sviluppatore di siti web dovrebbe essere subordinata all’accertamento che quello disponga di tali conoscenze. Personalmente credo di essere, se non l’unico, sicuramente tra i pochissimi in Italia che abbia letto integralmente le Specifiche HTML 4.01, se non altro perché le ho tradotte in italiano. Il mio consiglio per chi si avvicina oggi al lavoro di sviluppatore è di impadronirsi dei ferri del mestiere: impari sì ad utilizzare DreamWeaver, FrontPage, GoLive e compagnia bella, ma legga in primo luogo le regole per creare pagine valide e accessibili.

In una guida sull’accessibilità che ho appena terminato di scrivere, in un capitolo dedicato alla validazione del codice, ho effettuato un test con il MarkUp Validation Service del W3C sulla prima pagina di Repubblica.it: sono risultati ben 757 errori di codice! Credo che questo sia inaccettabile. Siti come Yahoo! – che non dichiara neppure la DTD - o Repubblica.it dovrebbero contenere codice valido e soluzioni d’impaginazione accessibili. Se ciò non accade, è perché l’idea di sviluppo professionale tarda ancora a farsi strada. Solo la conoscenza dei linguaggi standard può svincolare gli occupati in questo settore da un modo così dilettantesco di lavorare, che ha effetti negativi sull’accessibilità delle pagine web e, in ultima analisi, sulla democrazia dell’informazione e dei servizi.

Che diresti se scoprissi che il dentista che ti ha appena chiesto 200 euro per un’otturazione non sapesse come impugnare il trapano o fare un’anestesia? Diresti che è un cialtrone, e ti alzeresti di corsa dalla sua poltrona. Ecco, lo stesso dovrebbe fare un datore di lavoro che sentisse da uno sviluppatore “professionista” frasi come queste, che a me è capitato di ascoltare: “Sì, l’HTML. Lo conosco, lo conosco. A che versione siamo arrivati? La sette o la otto mi pare, giusto?

Per scrivere pagine web uso da anni HTML-kit, uno straordinario editor gratuito, giunto attualmente alla versione 2.92. Non è un editor visuale, la vista predefinita è quella sul codice. Dispone di una vasta serie di funzioni che coprono tutto l’arco delle mie necessità, non ultima quella di controllare la conformità alla DTD dichiarata e alcuni requisiti di accessibilità per mezzo di HTML Tidy, integrato nel programma.

Credo davvero che un professionista non abbia bisogno di null’altro che di HTML-kit per lavorare proficuamente. Lo uso per scrivere codice (X)HTML, CSS e ASP e se la cava ottimamente in tutti e tre i casi: tanto sempre di testo si tratta...

Altri programmi che adopero abitualmente sono ACDSee 4.0 e OpenOffice 1.1.0.

Per il resto la mia stazione di lavoro “predefinita” (cioè quella sulla quale lavoro tutto il giorno) è del tutto obsoleta rispetto agli standard correnti. Ho da oltre tre anni e mezzo un AMD 800 con 512 Mb di RAM e sistema operativo Windows 2000 Pro, ma non sento alcun bisogno di comprare un computer più potente: penso che le attrezzature debbano essere tarate sulla loro capacità di svolgere con efficacia i compiti che gli richiediamo, non sul numero di Ghz a cui Intel e AMD hanno deciso di spingere i loro ultimi processori... Lo so, Tremonti e il Berlusca non saranno contenti delle mie affermazioni.

Innanzitutto la validità del codice (X)HTML e CSS con gli appositi validatori. Dai fogli di stile cerco di eliminare anche i problemi secondari che generano avvertimenti e non errori, ciò allo scopo di favorire l’accessibilità fin dall’inizio.

Effettuo poi delle verifiche di buon funzionamento delle pagine con i principali browser grafici, sia su PC sia su Macintosh (oltre al PC, ho un G4 con su due sistemi operativi Apple ed una bella schiera di browser). Per Linux mi sto attrezzando... Effettuo naturalmente anche prove con browser obsoleti come Netscape 3 o bacatissimi come Netscape 4 (che è stato giustamente definito da Joe Clark il carcinoma del Web o anche “Ebola-like” browser). Una bella prova con Lynx è naturalmente d’obbligo, così come qualche tentativo con Jaws, di cui ho installato la demo della versione 4.50. Però non sono nelle condizioni per capire se una pagina funzioni davvero bene con Jaws, per cui preferisco chiedere valutazioni ad amici non vedenti, qualora mi serva un parere preciso riferito all’uso di questo screen reader.

In generale credo che i riscontri diretti ricevuti dagli utenti siano di gran lunga lo strumento migliore per valutare la bontà del lavoro compiuto. A me per fortuna capita di riceverne parecchi, grazie alla discreta popolarità raggiunta da Diodati.org.

Ah, una cosa importante: nel controllare una pagina con più browser grafici non mi soffermo più di tanto sul fatto che si veda allo stesso modo su tutti (di solito non accade mai...). Mi preoccupo piuttosto che il contenuto della pagina sia assolutamente fruibile con tutti i browser, sia quelli che supportano i fogli di stile, sia quelli che non li supportano o che li supportano male, sia infine quelli che trattano solo il testo come Lynx.

L’accessibilità è interessata a che i contenuti siano universalmente accessibili, non a che le presentazioni visuali siano universalmente uguali.

Penso che il vero scopo dell’accessibilità sia fare pagine accessibili per gli uomini, non pagine che espongano bollini. Uso i software automatici come Bobby giusto per scoprire gli errori più banali e marchiani, come la mancanza di qualche testo alternativo. Per tutto ciò che rappresenta l’aspetto “nobile” dell’accessibilità, cioè il significato umano dei contenuti, mi affido alla attenta e continua revisione delle cose che produco, nonché alle valutazioni dei diretti destinatari del mio lavoro, cioè le persone che si collegano alle pagine da me sviluppate.

Sono stati tre mesi interi di difficoltà e di sfide con me stesso. La prima sfida è stata quella di inventarmi programmatore. Possedevo qualche rudimento di ASP, ma ho dovuto apprendere l’uso vero e proprio di questo linguaggio di programmazione (query SQL, oggetti ADO, Vbscript) a mano a mano che mi serviva trovare il modo di realizzare nella pratica le funzioni che avevo in mente per i miei forum. In particolare è stata una soddisfazione trovare un modo funzionale per creare l’albero delle risposte concatenate ad un messaggio, riuscire a creare un valido sistema di citazioni che fosse accessibile anche per i non vedenti, inventare un sistema lato server per consentire agli ipovedenti di ingrandire i campi modulo, cosa che mi pare non sia stata fatta finora da nessun altro sito.

Una seconda sfida è stata progettare un sistema di forum basato su convenzioni diverse da quelle universalmente accettate. I miei forum infatti hanno una struttura molto differente da quella di quasi tutti gli altri forum in circolazione: mentre gli altri sono basati su sistemi di registrazione degli utenti, su tabelle, su etichette piene di termini in inglese e sull’idea di mostrare un’intera discussione, non importa quanto sia lunga, all’interno di un’unica pagina, i forum di Diodati.org non richiedono registrazioni e login, sono basati su elenchi annidati (o semplici), sull’uso “istituzionale” della lingua italiana, e sull’idea di mostrare in una pagina il testo di un unico messaggio alla volta. Ciò ha richiesto di valorizzare al massimo il sistema delle citazioni da messaggi precedenti, allo scopo di contestualizzare sempre il discorso, ma allo stesso tempo mi ha permesso di alleggerire enormemente il peso materiale (in Kb) e cognitivo (in informazioni) della pagina di lettura dei messaggi.

Il fatto che i forum che ho realizzato abbiano avuto fin dall’inizio un buon successo mi ha ripagato della fatica compiuta e mi ha dimostrato che molte convenzioni radicate si possono cambiare, purché le nuove siano in un certo senso migliori – almeno limitatamente agli scopi dell’accessibilità – rispetto alle precedenti.

I miei forum sono comunque un prodotto in continua evoluzione. Non appena ricevo un suggerimento utile per migliorarne l’accessibilità e l’usabilità, tento di tradurlo in pratica, compatibilmente con il sempre poco tempo a disposizione. Colgo anzi l’occasione per ringraziare pubblicamente tutti quelli che mi hanno dato aiuti importanti per migliorare i forum: in primo luogo Franco Frascolla, che ha testato per due mesi interi, prima della pubblicazione, le varie modifiche che quotidianamente apportavo, e poi Sofia Postai, Germano Carella, Roberto Dodi, Luca Mascaro, Maurizio Boscarol, Roberto Scano, e mi scuso con chi ho dimenticato di citare.

La lettura del progetto di legge Stanca mi ha fatto sorgere due grossi punti interrogativi. Il primo è la definizione delle regole di accessibilità a cui conformarsi. Il testo del PDL dice infatti all’art. 9 che i requisiti tecnici per l’accessibilità, nonché le regole per valutarli, verranno stabiliti per decreto dal Governo o, più specificamente, dal ministro per l’innovazione tecnologica.

Non c’è alcun riferimento a normative esistenti né, quindi, alle raccomandazioni del WAI-W3C. Ciò rientra naturalmente nella sovranità in materia di legislazione dello Stato italiano, però questo rimandare al futuro la definizione dei riferimenti tecnici normativi è fonte di dubbi per chi conosce la materia. Infatti in virtù di un testo di legge così concepito, nulla vieterebbe di creare ex novo delle regole di accessibilità proprietarie, sul modello della Section 508 statunitense.

Ecco, io credo che quello sarebbe un grosso errore. Non solo si perderebbe molto tempo a definire tali regole, ma si rischierebbe alla fine di trovarsi con un sistema non omogeneo rispetto allo standard internazionale riconosciuto, e possibile fonte di dubbi ed equivoci per gli sviluppatori. A sentire per esempio Emily Dixon di Usable.net, che ben conosce dall’interno la Section 508, l’applicazione di questa legge negli USA, a due anni dalla sua promulgazione, non solo è in gran parte trascurata, ma è anche causa di notevoli problemi di interpretazione e di comprensione.

Penso invece che all’Italia converrebbe recepire le raccomandazioni di accessibilità definite dal WAI-W3C - soprattutto ora che stanno per nascere le WCAG 2.0 - e sfruttare così il grande bagaglio di conoscenze ed esperienze maturate in questo settore dagli esperti internazionali che si occupano ormai da anni di tali raccomandazioni.

La mia proposta non è quella di recepire passivamente i documenti di specifiche del W3C, ma di creare una commissione tecnica, in grado di fare da cuscinetto, da interprete attivo, da consigliere, da “medico di famiglia”, per tutta quella massa di sviluppatori che sarà interessata dall’applicazione della futura legge e che sicuramente non possiede le nozioni per interpretare da subito al meglio il testo delle WCAG, formulato nel linguaggio inevitabilmente tecnico ed asettico di un documento normativo.

Il secondo punto oscuro del progetto Stanca è la faccenda dei bollini. L’ultimo articolo del PDL, il 10, dice che il “Ministro per l'innovazione e le tecnologie, di concerto con il Ministro per la funzione pubblica”, definisce:

• le modalità con cui può essere reso noto il possesso del requisito dell'accessibilità;
• i controlli esercitabili sugli operatori che abbiano reso nota l'accessibilità dei propri siti e delle applicazioni informatiche.

In linea di principio è giustissimo che il gestore di un sito, che ha lavorato magari duramente per rendere accessibili al meglio le sue pagine web, veda riconosciuto pubblicamente il lavoro svolto, esibendo un bollino di conformità che dichiari il livello di accessibilità raggiunto.

Nella pratica, purtroppo, ciò dà luogo ad immancabili abusi. Un po’ per superficialità un po’ per malizia, la gran parte delle dichiarazioni di conformità, esposte dai siti italiani interessati all’accessibilità, sono fasulle: dichiarano cioè livelli di accessibilità maggiori di quelli effettivi. E ciò è facilmente accertabile, confrontando i requisiti di conformità richiesti dalle WCAG 1.0 con ciò che questi siti effettivamente hanno implementato nelle proprie pagine web.

Il problema nasce dal fatto che non esiste un ente super partes che certifichi il livello di accessibilità di una pagina o di un sito. Ma anche se un simile ente venisse istituito con la nuova legge, il problema delle certificazioni rimarrebbe comunque di difficilissima soluzione: non solo infatti le valutazioni di accessibilità sono lunghe e complesse (e i siti da valutare un numero letteralmente sterminato), ma sono anche limitate nel tempo. Il giorno dopo aver conseguito, per esempio, una conformità al livello tripla-A delle WCAG 1.0, basterebbe immettere nuovi contenuti non accessibili nella pagina dichiarata conforme, per annullare la conformità e rendere del tutto fasullo il relativo bollino.

Bisogna allora creare un sistema che sia il più possibile svincolato dalle dichiarazioni basate sulla fiducia, cioè dai bollini esposti “a caso” dagli stessi sviluppatori delle pagine presunte accessibili. La cosa non è affatto semplice, e non vedo con quali strumenti il ministro Stanca pensi di far fronte alla immensa quantità dei controlli da effettuare e alla continua variabilità dei contenuti delle pagine in rete.

Per il momento – nell’attesa che si chiarisca la questione - suggerirei a chi fa del bollino uno scopo in sé, di considerare che l’obiettivo vero dell’accessibilità è produrre risorse accessibili, non glorificare gli autori con un medagliere di “patacche”, come con una certa dose di ragione Gianluca Troiani di Constile.org definisce i bollini rilasciati da Bobby.