Bolli e bollini
Questo sito viola tutti gli standard W3C.
…ma tanto a nessuno importa…
(Nonciclopedia, footer)
XHTML2, HTML5, XML: e l’accessibilità?
(In attesa di HTML 6…) “As the conversation about HTML 5 and XHTML has played out this week, I’ve felt like Regan in The Exorcist, my head snapping around in 360 degree arcs as one great comment cancels out another”.
In giro per il Web ci sono molte discussioni riguardo la scelta del W3C di abbandonare lo sviluppo di XHTML 2 a favore di HTML 5. Molti siti rilanciano la notizia in modo becero, affermando “XHTML è morto”, o cose del genere.
Si può capire la voglia di audience, ma si tratta di un modo di fare informazione davvero sciocco, ignorante. Certo, titolare “XHTML è morto” fa molta più scena di “XHML 2.0 non verrà più sviluppato”. Nel secondo caso, più che lecito pensare e chi se ne frega, meglio così. Nel primo si leggono commenti di lettori ignari che affermano cose come “ma come, io che mi ero studiato XHTML, ora devo tornare a HTML?”. Oppure si trovano i rete strane filastrocche che prendono in giro Zeldman, Meyer, il Wasp e quanti si sono battuti per la diffusione degli standard e di XHTML 1.0. L’invidia è davvero una brutta cosa.
Meglio saperlo: l’XHTML 1.0 che avete utilizzato fino ad oggi, è vivo e vegeto e ci vorranno decenni prima che vada in pensione e HTML5 è ben lontano dal venire.
Non c’è molto da dire, e quello che c’è da dire lo fa molto meglio di me Jeffrey Zeldman nel suo post “In defense of Web Developer“.
Il motivo di questo post è un altro, e riguarda il rapporto fra markup e accessibilità.
XML sul Web sarebbe un problema (ovvero, la possibilità di usare elementi XML personalizzati per descrivere i contenuti delle pagine): se il markup utilizzato non è uno standard e non prevede i necessari attributi (alt, title, scope, ecc.) le tecnologie assistive non sapranno come gestirlo e quello che si otterrà è una lettura sequenziale di elementi senza alcun significato semantico specifico.
Per esempio, non sarà possibile navigare le pagine con Jaws utilizzando il tasto H per individuare i titoli, non sarà possibile individuare le tabelle, le immagini, i link, tutti quegli elementi che se dotati di significato semantico e dei necessari attributi possono essere individuati e gestiti dalle tecnologie assistive.
È abbastanza semplice capirlo: se utilizzo una DTD standard, riconosciuta a livello mondiale come quelle del W3C, esiste un riferimento certo da leggere in MSAA e gestire. Se invece di< h1> il mio titolo di livello principale si chiama <titolone>, è impossibile che una tecnologia possa capire il mio “intento semantico”. Per questo motivo il rispetto della semantica degli elementi delle DTD del W3C è un requisito irrinunciabile per l’accessibilità, molto più della validità del codice o della DTD utilizzata.
È la stessa cosa che accade con i tag dei PDF: per estrarre informazioni semantiche dal documento, è necessario lavorare sulle mappe ruolo e dichiarare esplicitamente che <titolone> ha ruolo di <H1>, e così via.
Ancora oggi l’accessibilità per molti “accessibilisti” sembra essere fatta di formule bizzarre, incantesimi e riti da eseguire nei pleniluni.
Non è così: l’accessibilità è una cosa veramente concreta, funziona soltanto se un computer riesce ad individuare tramite il layer dedicato presente nel sistema operativo gli elementi conosciuti. In Windows questo avviene, fin dal 2000, tramite MSAA. Linux e Mac OS sono rimasti per molto tempo inattivi, ma ora stanno lavorando per risolvere il problema.
In ogni caso, affinché le tecnologie assistive possano funzionare, cosa che mi sembra abbastanza importante per l’accessibilità, è necessario essere in presenza di markup standard i cui elementi siano noti e semanticamente definiti.
Il markup deve essere “designed for all“, oppure non funzionerà niente. Sarà come leggere un txt.
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)