Accessibilità dei siti Web
Tempi di rinnovamento per l’accessibilità dei siti. Sarà l’effetto WCAG 2.0, sarà che dal Decreto Ministeriale 8 luglio 2005 son passati un po’ di anni e l’effetto moltiplicatorio per Web e tecnologie, è noto, funziona un po’ come l’età dei gatti e il decreto oggi appare un po’ vecchierello, insomma sia quel che sia un nutrito e ben congegnato gruppo di lavoro sta ridisegnando quelli che vengono definiti “i requisiti” fondamentali dei siti Web della P.A. affinché gli stessi possano essere definiti a norma della Legge 04/2004 (Stanca).
Inoltre, sotto il cappello del Formez è stato costituito un laboratorio, se così si può dire, denominato “Osservatorio Accessibilità” con compiti sia di analisi sia di supporto agli sviluppatori. Insomma, un bel traffico.
Nel periodo precedente, ho usato la forma “a norma” perché c’è un po’ di confusione sui termini “accessibile” e “a norma Stanca”.
La legge Stanca non è l’unica normativa di riferimento sull’accessibilità esistente sul pianeta. Gli Stati Uniti possiedono da tempo la Section 508, la mamma di tutte le normative sull’accessibilità (anche lei in revisione), le già citate WCAG del W3C (in questo caso non si tratta di una legge, ma di “raccomandazioni”, l’Australia possiede una propria legislazione, il Canada anche, così come la Francia, il Giappone e l’Irlanda (un elenco è disponibile all’URL http://www.w3.org/WAI/Policy/).
Tornando alla precedente affermazione, non è detto che un sito “a norma Stanca” corrisponda a un sito “WCAG compatibile”, o conforme alla Section 508, mentre tutti possono essere detti accessibili. L’obiettivo di tutte queste leggi e raccomandazioni è comune, ovvero ottenere l’accessibilità dei siti Web, e tutte si basano su Section 508 e WCAG per formulare le proprie richieste. Però, ciascuna normativa ha anche caratteristiche proprie (per esempio, la legge Stanca richiede l’uso di una DTD Strict, mentre le WCAG no). Probabilmente le WCAG 2.0. faranno da elemento collante e tutte le normative cercheranno di adeguarsi ai nuovi requisiti proposti dal W3C.
È un bene o un male? Non lo so, personalmente trovo le WCAG 2.0 ottime nei principi ma un po’ scarse nelle tecniche proposte (francamente, in qualche caso davvero di basso livello). Si potebbe obbiettare “Sì, d’accordo, ma l’accessibilità non riguarda gli standard, si occupa esclusivamente di proporre delle tecniche che rendano accessibili le pagine”.
D’accordo, ma propongo un esempio credo significativo per chiunque si occupi di accessibilità. Fra gli elementi più importanti per la navigazione delle pagine ci sono i titoli, gli header di cui molto abbiamo parlato su questo blog. È un elemento indiscutibile, chiunque abbia provato a navigare delle pagine con uno screen reader si sarà reso conto della fontamentale importanza dell’uso di una struttura corretta per delineare i contenuti delle pagine, e di come sia importante utilizzare in modo congruente ai contenuti gli elementi da <h1> a <h6>.
Ebbene, proprio su un argomento così basilare nelle “HTML e XHTML Techniques” è presente un esempio così fatto:
<head> <title>Stock Market Up Today</title> </head> <body> <!-- left nav --> <div class="left-nav"> <h2>Site Navigation</h2> <!-- content here --> </div> <!-- main contents --> <div class="main"> <h1>Stock Market up today</h1> <!-- article text here --> </div> <!-- right panel --> <div class="left-nav"> <h2>Related links</h2> <!-- content here --> </div> </body>
Rieccoci da capo. La pagina inizia con un <h2>, si passa a <h1> e si torna a <h2>. Non mi pare un bell’esempio.
Per questo e altri motivi mi piacerebbe che i nuovi requisiti della Stanca mantenessero l’intrinseca richiesta di pulizia e semantica, si semplificassero nella forma e facessero esplicito riferimento alle best practice più affermate. Personalmente trovo inaccettabile che sia per la Stanca sia per le WCAG una barra di navigazione fatta a colpi di <div> e <br /> possa essere dichiarata “accessibile”.
Per qualsiasi sviluppatore appena sensato gli elementi da utilizzare per le barre di navigazione sono <ul> e <li> per le voci, magari facendo precedere alla barra un titolo esplicito utilizzando l’elemento <hn> opportuno.
Insomma, mi piacerebbero dei requisiti un po’ meno “saputelli” e un po’ più di senso pratico, per esempio prendendo spunto anche dall’elenco di Best Practice dell’iCITA (Illinois Center for Information Technology and Web Accessibility) utilizzate dal “Functional Accessibility Evaluator 1.0.2” dell’ University of Illinois at Urbana-Champaign.
Libri di testo e accessibilità: eppur si muove…
Sono davvero molto contento di aver iniziato un percorso importante con un grosso editore di scolastica. Un progetto che coinvolge tre redazioni complete, dai responsabili editoriali a redattori, grafici, impaginatori e tecnici che realizzeranno gli output elettronici finali.
Tre progetti editoriali già individuati, venti persone coinvolte, un corso lungo e impegnativo da svolgere per me, ma certamente entusiasmante. I tre team sono molto motivati e in gamba, attenti al massimo nella comprensione delle tematiche e tecniche relative all’accessibilità.
Vien da dire “finalmente!”…
Moduli PDF e WCAG 2.0
Paciello Group ha reso disponibile in streaming la registrazione video del webinar TPG/Adobe su questo argomento. Si tratta di materiale piuttosto interessante, e come bonus viene mostrata anche un’applicazione Flex che prende i dati da un complesso modulo PDF e li mostra in un browser. Se vi interessa l’argomento modulistica in PDF, da non perdere.
- Streaming video del webinar
- Slide(PDF)
- Transcript (in doc, 88Kb)
Con l’occasione sono stati aggiornati anche i materiali dei precedenti webinar, aggiungendo per quanto riguarda Flash e WCAG2.0:
- Webinar in formato Flash accessibile da tastiera (usare il tasto Tab per spostarsi nei controlli del Player)
- Transcript (in doc, 77Kb)
E per PDF e WCAG 2.0:
- Webinar in formato Flash accessibile da tastiera (usare il tasto Tab per spostarsi nei controlli del Player)
- Transcript (in doc, 89Kb)
Editoria per ipovedenti e non vedenti non equivale a editoria accessibile
Che cosa sarà mai l’editoria per ipovedenti e non vedenti? Il dubbio viene perché negli ultimi anni l’accessibilità dei documenti elettronici ha fatto passi da gigante, le tecnologie altrettanto e mai come oggi gli strumenti utilizzati da chi ha problemi di vista o di altro genere sono allineati agli standard e ben funzionanti.
Eppure, le associazioni di categoria di ipovedenti e non vedenti non se ne accorgono, e continuano a propagandare Braille e carattere ingrandito come unica soluzione, anzi la soluzione (se avete un po’ di tempo ascoltate le interviste ai principali attori del convegno “Il valore culturale del libro. Verso un formato accessibile e fruibile per i non vedenti. Problemi, esperienze e prospettive (Monza, 29 ottobre 2008)”).
Oggi uno screen reader, per esempio, può leggere al suo utilizzatore documenti anche complessi (sempre che siano stati realizzati nel modo definito “accessibile”) in praticamente tutti i formati più diffusi. I tasti funzione utilizzabili per ottenere una “vista” del documento che non sia una semplice lettura di caratteri ma una vera e propria descrizione semantica del contenuto (i titoli, le tabelle, i link, gli elenchi puntati e numerati, e così via) sono gli stessi sia per HTML, sia per PDF o per documenti Word.
A chi si occupa di accessibilità viene spontaneo pensare che i vari bandi e finanziamenti per ipovedenti e non vedenti riguardino questa editoria, ovvero l’editoria elettronica accessibile.
Questa lettura viene rafforzata (ingenuamente) dalla lettura di articoli pomposi e roboanti come quelli che hanno accompagnato il Decreto del 18 dicembre 2007, detto Rutelli.
Impressionante. Da Punto Informatico: “L’Italia sdogana per prima i libri accessibili” “La bomba è esplosa”. Madò. Che è successo?
“Quanto tempo ci vorrà prima che tutto questo si concretizzi nelle prime uscite in digitale? “Pochi mesi - dice Pietrosanti a Punto Informatico -“. Sì, già, pochi mesi. Siamo a maggio 2009 e non è successo niente. Ma questo sarebbe il meno. Si prosegue blaterando di XML, “”Con questo decreto - spiega Pietrosanti - ci possiamo assicurare che a 48 o 72 ore dall’uscita di un titolo anche noi lo si possa avere in formato digitale”. In quale formato? Si parla di XML o comunque di testo: deve essere un formato che possa essere facilmente letto e trasportato sui sistemi di riproduzione vocale utilizzati dai disabili visivi, condicio sine qua non per l’accesso ai finanziamenti del bando”.
E qui casca l’asino. Avete letto bene? “deve essere un formato che possa essere facilmente letto e trasportato sui sistemi di riproduzione vocale utilizzati dai disabili visivi”.
Ci risiamo: l’accessibilità dello screen reader. Qui non si parla di libri elettronici accessibili, ma soltanto di qualcosa che possa essere letto da ciechi e ipovedenti. Ovvero, ci risiamo con il txt e l’accenno a XML è persino controproducente: quale XML? Se la grammatica adottata non prevede l’accessibilità, che sia in XML, SGML o in Klingon poco cambia.
Tante volte mi sono chiesto come mai non ci sia dialogo fra comunità di sviluppatori e gruppi di discussione di ipovedenti e ciechi. In entrambi gli schieramenti ci sono persone capaci e in gamba, eppure non si riesce mai a parlare senza avviarsi in discussioni interminabili.
Ora ho capito: la parola accessibilità non ha lo stesso significato per i contendenti. Ognuno ne possiede un’interpretazione diversa. Per uno schieramento, l’accessibilità corrisponde a una possibilità di accesso ai contenuti universale, indipendente dalla particolare disabilità, un’editoria che possa essere utilizzata da chiunque e con qualsiasi tecnologia assistiva. Accessibile, appunto.
Per l’altro, “lo sdoganamento dei libri accessibili” (sic) corrisponde esattamente a qualcosa che possa essere letto e trasportato sui sistemi di riproduzione vocale utilizzati dai disabili visivi.
Questa è l’editoria per ipovedenti e non vedenti: libri braille, a carattere ingrandito e un qualsiasi formato elettronico leggibile da uno screen reader. Il txt, per esempio, se va bene un doc o un rtf. Basta che sia leggibile dallo screen reader, strutturato o meno è uguale.
Il formato per antonomasia meno accessibile in assoluto è quello che viene regolarmente finanziato con milioni di euro a botta.
Questo tipo di editoria non è nemmeno lontanamente definibile “accessibile”. Ma proprio nemmeno un po’.
Ogni tanto mi chiedo: ma se tutti i milioni di euro spesi negli ultimi anni “a favore dell’editoria per ipovedenti e non vedenti” li avessero dati direttamente agli editori per fare editoria elettronica accessibile, a che punto saremmo? Quante migliaia di libri elettronici accessibili ci sarebbero già in giro?
Quando sparirà la classificazione “editoria per ipovedenti e non vedenti” e riusciremo a vedere qualcosa del tipo “interventi a favore dell’editoria elettronica accessibile”?
Ma finché l’Unione Italiana dei Ciechi e degli Ipovedenti dichiarerà che “a spalancare ai ciechi le vie della cultura” è il Braille, difficile che si faccia qualche passo avanti. E non dieci anni fa, oggi.
Leggendo l’articolo citato nel link precedente, risulta evidente la scollatura fra sviluppatori e rappresentanti dei non vedenti di cui parlavo prima: conosco personalmente gli sviluppatori che hanno lavorato all’accessibilità del sito del Senato Italiano, e quanto impegno hanno messo nel rendere il sito accessibile (il sito non è conforme alla 4/2004, ma il lavoro fatto fino ad oggi è gigantesco, dato lo stato precedente e l’enorme quantità di pagine presenti).
Di conseguenza hanno reputato di fare cosa gradita presentando il proprio lavoro ai rappresentanti delle associazioni di disabili presenti all’avvenimento. In risposta, Tommaso Daniele, presidente nazionale dell’Unione italiana dei Ciechi e degli Ipovedenti, parla di “occasione sprecata”, non si è parlato del Braille.
Ma voi sapete quanti sono i ciechi che conoscono e usano il Braille? Pochi, anzi pochissimi, e costantemente in calo, con risultati su cui si dovrebbe riflettere. Però noi abbiamo l’Autorità Italiana del Braille e la Giornata nazionale del Braille, per legge.
Son sempre gli stessi… UIC, Biblioteca Italiana per i Ciechi “Regina Margherita” e così via, gli stessi che si spartiscono i fondi dell’editoria per ipovedenti e non vedenti in base a un accordo con AIE.
Qui mi fermo sennò mi denunciano. Ma qualche sospetto viene…
Concludo chiarendo un possibile dubbio: questa non è una crociata contro il Braille, strumento utilissimo in alcuni contesti (per esempio, basta pensare alle pulsantiere degli ascensori, ai semafori, biglietterie, etichette, visite guidate e quanto vi viene in mente). In alcune situazioni indispensabile, per esempio pensiamo ai sordo-ciechi.
Certamente e senza dubbio però il Braille non è in grado di spalancare alcuna porta alla cultura dei ciechi date le sue intrinseche limitazioni. Non può essere definito “formato accessibile” e per fortuna dal 1829 (invenzione del Braille) a oggi qualcosa è cambiato. Speriamo che se ne accorgano anche loro.
ePUB, una possibile soluzione per i problemi di editoria e accessibilità?
ePUB? Ci mancava anche questa. Però, abbiamo tanto lavorato per produrre il nostro libro digitale accessibile, è pronto. D’accordo, ma ora come lo distribuiamo? In PDF? In HTML? E funzionerà tutto a dovere? E se volessi fare qualche modifica, cosa uso per il PDF? E così via. Insomma, una soluzione davvero universale e semplice ancora non esiste. Una via potrebbe essere quella indicata da xfy e CDF (Compound Document Format), basata su un editor XML e linguaggi standard W3C. Il risultato potrà essere sicuramente standard e accessibile, ma questa soluzione obbliga però a produrre documenti linearizzati. Io sono più che d’accordo, ma come spiegare agli editori che quei layout a quattro colonne intersecati da figurine, sfondi, retini e ogni orpello li dovrebbero abbandonare?
Il mondo ne sarebbe felice, ma gli editori pagano fior di soldi a baldi impaginatori per ottenere quei design. Detto fra noi, pagano cifre esorbitanti, lo sapete che una pagina (una) di un libro didattico di un certo livello viene pagata anche 250 euro a pagina per la sola impaginazione?
Serve a qualcosa da un punto di vista didattico? Probabilmente no, anzi, però è bello…
Non si può nemmeno negare però che in qualche caso per riuscire a disporre il contenuto in gabbie anche complesse qualche volta sia necessario per migliorarne la comprensione. Abbiamo quindi di fronte diverse scelte da fare: per preservare il layout, lo strumento migliore è il PDF, non ci piove, è stato inventato proprio per fare quel lavoro. Però, è necessaria una discreta perizia per riuscire a gestire l’intero workflow che conduce alla creazione del PDF, e servono software piuttosto complessi.
Xfy e CDF sono gratuiti, ma certo è necessaria una buona conoscenza di XHTML, SVG, MathML e così via. Insomma, diciamolo, la via dell’editore elettronico è complessa, editore elettronico accessibile molto complessa.
Una possibile soluzione ora viene da un formato piuttosto maturo: ePUB.Perché?
Questo formato nasce con in mente alcune priorità ben precise: flessibilità, accessibilità, standard. Mica male. È abbastanza collaudato? Sì, ePUB è l’ultima incarnazione di un lungo lavoro svolto da IDPF (International Digital Publishing Forum). È supportato dai programmi di impaginazione? Sì, come spiega questa presentazione Powerpoint. C’è un validatore? Sì, epubcheck.
Insomma, quanto basta per cominciare a prenderlo in considerazione sul serio. È difficile? No, per esempio in Indesign CS4 basta selezionare File > Esporta per Digital Editions (attenzione…). Nelle opzioni di esportazione per il contenuto si può scegliere fra le DTD XHTML (ma guarda…) e DTBook, e convertire le voci di sommario create in Indesign in un sommario navigabile. Le font sono incorporabili (OpenType), e via.
Quello che si ottiene è un file con estensione .epub, praticamente uno zip contenente tutti i componenti del documento, fra cui il file XHTML 1.1 e il corrispettivo CSS.
Insomma, quanto basta a scatenare la mia curiosità.